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: ...

This is Chapter 2 of the Infrastructure as Code with AWS CDK series. Four approaches to environment-specific configuration in CDK stacks - same use case throughout so the trade-offs sit side by side. Use case: An S3 bucket and Lambda function where bucket name, log level, and Lambda timeout vary per environment (dev, staging, prod). Quick comparison Approach Version controlled Supports secrets Change without redeploy Shared across stacks Static config (cdk.json) Yes No No No Dynamic config No Partial Yes No Secrets Manager No Yes Yes Yes CI/CD context injection No No Yes No Local dev patterns Suitable for personal projects or local development. Neither is a good fit for CI/CD pipelines or shared team environments. ...