I sat the Kubernetes and Cloud Native Associate (KCNA) and passed. KCNA is the entry-level CNCF certification - it covers Kubernetes fundamentals and the wider cloud native landscape at a conceptual level, and it is the natural first step before the hands-on CKA, CKAD, and CKS exams. It is a multiple-choice exam, so it rewards knowing what the pieces are and how they relate, not hands-on kubectl skill. If you already work with Kubernetes, a lot of this will be familiar, so calibrate the prep to what you already know. ...

This is Chapter 1 of the DevSecOps Guardrails series. cdk-nag runs against the CDK construct tree at synth time and blocks the build on any rule violation - before a changeset is created, before any AWS API call is made. I wired it in as the first guardrail because it is CDK-native: it sees the construct level, not just the synthesised template, which means it can catch things cfn-lint cannot. Adding it is a five-line change to app.py. The part that matters more than setup is suppressions: knowing when to suppress versus fix, and writing a reason string that makes the decision visible in a code review. A synth failure maps directly to a blocked pipeline stage in Jenkins, GitHub Actions, and Azure DevOps with no extra configuration needed. ...

This is Chapter 5 of the Infrastructure as Code with AWS CDK series. The same cdk deploy command that runs locally works in any pipeline - the differences are auth and orchestration. Common flags for CI These apply regardless of which CI system you use: cdk synth # generate CloudFormation template cdk deploy --require-approval never -c env=prod # deploy without interactive prompts cdk deploy --outputs-file outputs.json # write stack outputs to file --require-approval never skips the IAM change confirmation that CDK shows interactively. Required in CI. ...

This is Chapter 4 of the Infrastructure as Code with AWS CDK series. Chapter 3 built FileProcessorConstruct - the tests here cover that construct and the stack it lives in. How CDK testing works CDK unit tests don’t deploy anything. They synthesize a stack into a CloudFormation template and run assertions against that template. No AWS credentials needed, and the suite runs in CI without any special setup. The aws_cdk.assertions module is already part of aws-cdk-lib - no extra install required. ...

This is Chapter 3 of the Infrastructure as Code with AWS CDK series. Chapters 1 and 2 put the S3 bucket and Lambda directly in MyStack. Both get extracted into a reusable construct here. L1, L2, L3 CDK organises constructs into three levels: L1 - raw CloudFormation resource wrappers, prefixed with Cfn. CfnBucket, CfnFunction. No defaults added - every property must be set explicitly. L2 - CDK’s built-in higher-level constructs. s3.Bucket, _lambda.Function. These set sensible defaults, expose helper methods, and handle IAM via grant_* methods. L3 - composite constructs you write that bundle multiple resources into a single unit. The previous chapters used L2 constructs directly inside a stack. This chapter builds an L3. The problem The current MyStack creates the bucket and Lambda directly: ...