CI-CD on Bastab C - Notes to Self

DevSecOps Guardrails - Series Overview

Thu, 18 Sep 2025 00:00:00 +0000

Running CDK in production, one thing becomes clear: a passing cdk synth is not the same as a safe deploy. There are four categories of risk that a standard CI/CD pipeline leaves unchecked: IaC policy violations, CloudFormation template errors, application code quality issues, and vulnerable dependencies. Each one has a tool that catches it at build time - and together they form a pipeline where “it deployed” also means “it deployed safely.”

cdk-nag - CDK-specific. Runs against the CDK construct tree; no direct equivalent outside a CDK project.
cfn-lint - works anywhere you synthesise a CloudFormation template.
SonarQube, OWASP - work with any CI/CD pipeline: GitHub Actions, Jenkins, GitLab CI, or anything else.

The examples use CDK Pipelines but the tools are portable.

The series

Chapter 1 - Policy Checks with cdk-nag

cdk-nag runs NagPacks (AwsSolutions, HIPAA, NIST, PCI DSS) against the synthesised CDK app at synth time - violations block the build before any CloudFormation changeset is created.

Chapter 2 - Template Linting with cfn-lint (coming soon)

cfn-lint validates the synthesised CloudFormation template for invalid properties, deprecated fields, and best practice violations.

Chapter 3 - Static Analysis with SonarQube (coming soon)

SonarQube runs static analysis on the application code and gates the pipeline on quality thresholds - bugs, security hotspots, code smells.

Chapter 4 - Dependency Scanning with OWASP (coming soon)

OWASP Dependency-Check scans Python and Node dependencies against the CVE database and fails the build on any HIGH or above finding.

Notes

The series assumes CDK familiarity. The Infrastructure as Code with AWS CDK series covers project setup, constructs, configuration, testing, and CI/CD pipelines.
Each guardrail is independent - add cdk-nag without cfn-lint, wire in OWASP without SonarQube. No requirement to implement all four at once.

AWS Well-Architected Framework - Series Overview

Thu, 21 Aug 2025 00:00:00 +0000

The Well-Architected Framework is one of the more useful things to have internalised for serious AWS work. It comes up in architecture trade-off discussions, CDK design decisions, cost justifications, security reviews - not as a formal checklist but as a consistent vocabulary for reasoning through decisions. I started writing notes to keep the structure clear and they grew into this series.

The framework is AWS’s documented approach to evaluating cloud workloads against a set of architectural best practices. It is structured around six pillars, supported by a tool for running formal reviews against your own workloads, and extended by Lenses that apply the same thinking to specific domains like serverless or SaaS. This series works through each component.

The Well-Architected Framework whitepaper is the primary source behind all of it. First published in 2015 and updated regularly since, it formalised what AWS Solutions Architects were doing in customer workload reviews into a consistent, documented system. Every revision to the pillars - including the addition of sustainability in 2021 - and the full question set in the Well-Architected Tool originate here. If you work with the framework seriously, this is the document to read.

The six pillars

The pillars are the core of the framework. Each defines a set of design principles and best practices. AWS lists them in this order consistently across the whitepaper, documentation, and the Well-Architected Tool.

Our Systems Run Perfectly, Cheaply, Sustainably

Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization
Sustainability

Pillar	What it addresses
Operational Excellence	Running and monitoring workloads, improving processes over time
Security	Protecting data, systems, and assets
Reliability	Recovering from failures and meeting demand
Performance Efficiency	Using resources efficiently as demand changes
Cost Optimization	Avoiding unnecessary spend
Sustainability	Minimising the environmental impact of cloud workloads

No pillar operates in isolation - a decision that improves reliability (multi-AZ) has cost implications; a decision that improves performance (larger instance) has sustainability implications. The framework acknowledges these trade-offs rather than pretending they do not exist.

The series

Chapter 1 - The Well-Architected Tool

What the Tool is, how to run a workload review, how to interpret findings, and how the Tool differs from ad hoc pillar checklists.

Chapter 2 - The Six Pillars

An overview of all six pillars - design principles, key questions, and the trade-offs each one introduces. The map before the deep dives.

Chapter 3 - Operational Excellence Pillar

Operations as code, observability, deployment automation, and continuous improvement of operational processes.

Chapter 4 - Security Pillar

Identity, detection, infrastructure protection, data protection, and incident response - the security pillar in detail.

Chapter 5 - Reliability Pillar

Foundations, workload architecture, change management, and failure management - what reliability means in the context of AWS workloads.

Chapter 6 - Performance Efficiency Pillar

Selecting and right-sizing resources, monitoring performance over time, and maintaining efficiency as demand evolves.

Chapter 7 - Cost Optimization Pillar

Expenditure awareness, cost-effective resources, matching supply to demand, and optimising over time.

Chapter 8 - Sustainability Pillar

Measuring and reducing the environmental impact of cloud workloads - right-sizing, Graviton, efficient storage tiers, and sustainability metrics.

Chapter 9 - Lenses

How Lenses extend the framework for specific domains - Serverless, SaaS, Machine Learning, and others - and when to apply them.

Notes

Content is based on the public AWS Well-Architected Framework documentation, not any specific workload or employer environment.

Infrastructure as Code with AWS CDK - Series Overview

Fri, 21 Feb 2025 00:00:00 +0000

AWS CDK lets you define cloud infrastructure in familiar programming languages - Python, TypeScript, Java - and synthesise it into CloudFormation. Compared to writing raw CloudFormation or Terraform HCL, CDK gives you loops, conditionals, type safety, and reusable constructs.

This series covers practical CDK patterns using Python, with a consistent use case across all parts so the trade-offs are easy to compare.

Why CDK over CloudFormation for AWS-native workloads?

CloudFormation is YAML or JSON - no loops, no conditionals, no abstraction. Any shared pattern gets copy-pasted.
CDK uses a real programming language - loops, functions, classes, and type checks all apply to infrastructure the same way they apply to application code.
L2 constructs handle boilerplate. bucket.grant_read(fn) generates the IAM policy, role attachment, and resource reference in one call. The CloudFormation equivalent is four resources wired together manually.
The compiler catches mistakes before CloudFormation ever sees the template.
CDK still synthesises to CloudFormation under the hood - rollbacks, drift detection, and stack history are unchanged.

Why CDK over Terraform for AWS-native workloads?

Terraform’s strength is multi-cloud. For AWS-only workloads, that comes with overhead that doesn’t pay off - a state backend, a provider version to pin, and HCL alongside the application code.
CDK uses CloudFormation as the deployment engine - AWS manages state natively. No S3 bucket for state, no DynamoDB table for locking, no terraform init in the pipeline.
New AWS services appear in CDK constructs faster.
IAM is easier. Terraform requires writing policy JSON by hand and threading ARNs between resources. CDK’s grant_* methods generate least-privilege policies from the resource graph.
Terraform is the right call when infrastructure spans multiple cloud providers, or when the team already has a mature Terraform codebase.

Use case

Deploy an AWS Lambda function that processes files uploaded to an S3 bucket. Configuration - bucket name, log level, Lambda timeout - varies per environment (dev, staging, prod).

Simple infrastructure by design - the CDK patterns are the point, not the resources.

The series

Chapter 1 - Project Setup and Bootstrapping

Getting a CDK project off the ground - directory structure, virtual environments, bootstrapping an AWS account, and understanding the synth/deploy cycle.

Chapter 2 - Managing Configuration and Context

How environment-specific values flow into CDK stacks - four approaches covering local static config, local dynamic config, SSM Parameter Store, and Secrets Manager, with trade-offs and code examples for each.

Building L3 constructs - extracting resources into reusable units, the keyword-only props pattern, and sharing constructs across stacks.

Chapter 4 - Testing CDK Stacks

Unit testing constructs and stacks with aws_cdk.assertions - fine-grained assertions, snapshot testing, and when each applies.

Chapter 5 - CI/CD Pipelines

Automating CDK deployments with GitHub Actions, Jenkins, and Azure DevOps - auth setup, multi-environment promotion, and approval gates.

Notes

All examples use Python and CDK v2.
Steps are tested on WSL2/Ubuntu on Windows and native macOS terminal.
More chapters added as I work through these patterns.

AWS Certified AI Practitioner (AIF-C01) Study Notes

Mon, 15 Jun 2026 00:00:00 +0000

I sat the AWS Certified AI Practitioner (AIF-C01) and passed. This is the retrospective I wish I had read before starting - what the exam actually tests, the services and concepts to know well, and which prep resources earned their place.

AIF-C01 covers more ground than the name suggests: classical ML, generative AI, foundation models, and responsible AI. Domains 2 and 3 carry the most weight and the vocabulary is denser than it looks. Your starting point will shape where you need to spend time, so calibrate accordingly.

For more content on other relevant certifications, check Certifications.

The exam at a glance


Questions	65 (50 scored, 15 unscored)
Time	90 minutes
Format	Multiple choice and multiple response
Passing score	700 out of 1000 (scaled)
Cost	100 USD
Validity	3 years

Confirm these against the live AWS certification page before your exam - costs and question counts occasionally change.

Where I wrote this up

I’ve written about the concepts and service distinctions that come up across this exam in Fundamentals of AWS AI and ML - algorithm types, performance metrics, inference options, Bedrock vs SageMaker, customization approaches, and prompt engineering techniques, all in one place.

The five domains

AIF-C01 has five domains. The percentages are from the official exam guide - weight your study time accordingly.

Domain 1 - Fundamentals of AI and ML (20%)

The conceptual foundation the rest of the exam builds on. Know the core ML concepts - types of learning, how models are trained and evaluated, and what the lifecycle of an ML project looks like. This domain tests breadth more than depth.

Focus areas:

Types of ML: supervised, unsupervised, reinforcement learning - and when each applies
Core concepts: training vs inference, features, labels, overfitting, underfitting
Model evaluation metrics: accuracy, precision, recall, F1, AUC-ROC
The ML pipeline: data preparation, training, evaluation, deployment, monitoring
AWS ML services overview: SageMaker, Rekognition, Comprehend, Polly, Transcribe, Translate

Domain 2 - Fundamentals of Generative AI (24%)

Heavier than the name implies. Know what foundation models are, how LLMs work at a conceptual level, and the vocabulary of generative AI - tokens, embeddings, context windows, temperature. This is the domain where terminology trips people up most.

Focus areas:

Foundation models vs traditional ML models - pre-trained, general-purpose, fine-tunable
Large language models: tokenization, embeddings, context windows, attention mechanisms (conceptual)
Generative AI output types: text, image, code, audio
Key inference parameters: temperature, top-p, max tokens - what they control
Amazon Bedrock: managed access to foundation models; providers and model IDs
Prompt engineering basics: zero-shot, few-shot, chain-of-thought

Domain 3 - Applications of Foundation Models (28%)

The largest domain and the most practical. It covers how you actually use foundation models - retrieval-augmented generation, fine-tuning, agents, and the AWS services that enable them. Know when to use each approach and the trade-offs each carries.

Focus areas:

Retrieval-Augmented Generation (RAG): how it works, why it reduces hallucinations, when to prefer it over fine-tuning
Fine-tuning vs RAG vs prompt engineering - the trade-off matrix: cost, data needs, latency, freshness
Amazon Bedrock Knowledge Bases - managed RAG on AWS
Amazon Bedrock Agents - multi-step task orchestration with foundation models
Vector databases and embeddings: how semantic search enables RAG
Evaluating generative AI outputs: human review, automated metrics, hallucination detection

Domain 4 - Guidelines for Responsible AI (14%)

Lighter on services, heavier on principles. Know the AWS responsible AI pillars and what each means in practice. The exam tests whether you can identify responsible vs irresponsible AI design decisions, not just recite definitions.

Focus areas:

AWS responsible AI pillars: fairness, explainability, transparency, privacy, robustness, safety, controllability
Bias in AI: types of bias, where it enters the pipeline, how to detect and mitigate it
Explainability: what it means, why it matters for regulated use cases
Amazon SageMaker Clarify - bias detection and explainability tooling
Human oversight: when to require human review of AI outputs

Domain 5 - Security, Compliance, and Governance for AI Solutions (14%)

Overlaps with general AWS security but scoped to AI workloads. Know the shared responsibility model as it applies to managed AI services, and what guardrails exist to control model behaviour.

Focus areas:

Shared responsibility for managed AI services vs self-hosted models
Amazon Bedrock Guardrails - content filtering, denied topics, PII redaction
Data privacy for training and inference: where data goes, what AWS controls
IAM for Bedrock and SageMaker - least privilege for ML workloads
Compliance considerations: data residency, model provenance, audit logging

Services to know well

The exam tests AWS services at a conceptual level, not deep implementation detail. Know what each does, which use case it fits, and what it is commonly confused with:

Service / Concept	Know this about it
Amazon Bedrock	Managed access to foundation models; providers, model IDs, inference parameters
Amazon SageMaker	Full ML lifecycle - build, train, deploy custom models; contrast with Bedrock
Bedrock Knowledge Bases	Managed RAG - connects foundation models to your data via vector search
Bedrock Agents	Orchestrates multi-step tasks using foundation models and external tools
Bedrock Guardrails	Content filtering, topic denial, PII handling for model responses
SageMaker Clarify	Bias detection and explainability across training data and model predictions
Amazon Rekognition	Image and video analysis - object detection, facial analysis, content moderation
Amazon Comprehend	NLP service - entity recognition, sentiment, key phrase extraction
Amazon Transcribe	Speech-to-text; Transcribe Medical for clinical audio
Amazon Polly	Text-to-speech with multiple voices and languages
Amazon Lex	Conversational AI for chatbots - same technology as Alexa
Amazon Kendra	Intelligent enterprise search; often confused with Bedrock Knowledge Bases
Amazon Personalize	Real-time personalisation and recommendations without ML expertise
RAG	Grounds model responses in your data at inference time to reduce hallucination

Easy things to mix up

Bedrock vs SageMaker - Bedrock is for consuming pre-built foundation models via API; SageMaker is for building, training, and deploying your own models. The exam constructs scenarios specifically to distinguish them.
RAG vs fine-tuning - RAG retrieves relevant context at inference time (no retraining, data stays fresh); fine-tuning bakes new knowledge into model weights (requires retraining, more expensive, knowledge becomes stale). Fine-tuning suits tone and style; RAG suits factual, updatable knowledge.
Bedrock Knowledge Bases vs Kendra - both do search, but Bedrock Knowledge Bases is semantic vector search to feed a generative model; Kendra is keyword and ML-powered enterprise search without a GenAI layer.
Temperature vs top-p - temperature scales the probability distribution across all tokens (higher = more random, more creative output; lower = more deterministic and conservative); top-p limits the token pool to the smallest set whose cumulative probability meets a threshold. Both control randomness but from different angles.
Supervised vs unsupervised vs reinforcement learning - supervised learns from labelled examples; unsupervised finds structure in unlabelled data; reinforcement learns from reward signals. Clustering = unsupervised, classification = supervised.
Overfitting vs underfitting - overfitting is when a model memorises training data and fails to generalise (high variance: performs well on training data, poorly on new data); underfitting is when the model is too simple to capture the pattern (high bias: performs poorly on both). The bias-variance trade-off is the tension between them - more model complexity reduces bias but increases variance.
Precision vs recall - precision is “of what I predicted positive, how many were actually positive” (minimise false positives); recall is “of all actual positives, how many did I catch” (minimise false negatives). The trade-off matters in content moderation and medical diagnosis scenarios.
Hallucination - model produces confident but factually wrong output. RAG is the primary mitigation the exam points to; scenario questions will describe it and ask how to address it.
Foundation model vs LLM - foundation model is the broader term for large pre-trained general-purpose models (includes image and multimodal); LLM is specifically language-based. All LLMs are foundation models; not all foundation models are LLMs.

Resources

More so than most AWS certs, the official Skill Builder material is worth starting with here - it’s closely aligned to what the exam actually tests.

Essential

Official Exam Guide (AIF-C01) - read this first. The five domains, their weights, and the in-scope services list are the syllabus. Available on the AWS certification page.
Exam Prep Standard Course: AWS Certified AI Practitioner (AIF-C01) - the AWS-authored prep course. More directly exam-relevant here than third-party alternatives.
Standard Exam Prep Plan: AWS Certified AI Practitioner (AIF-C01) - a structured plan that sequences all the prep material.
Official Practice Question Set - AWS-authored practice questions. The style matches the real exam closely.
Official Practice Exam - the full-length timed version; available via AWS Skill Builder. Do one complete timed run before sitting the real exam.

Useful

Amazon Bedrock documentation - the Bedrock service is central to Domains 2 and 3. The concepts overview and Guardrails docs are high-yield reading.
AWS Responsible AI resources - AWS publishes a responsible AI FAQ and whitepaper; Domain 4 pulls from this framing directly.

Skip if you are tight on time

General ML textbooks and courses - this exam tests conceptual awareness, not implementation depth. Andrew Ng’s ML course is excellent but goes far deeper than required. Save it for after.
SageMaker deep-dives - SageMaker appears in the exam but at a high level. A full SageMaker course is overkill for AIF-C01 specifically.

Notes

The Skill Builder prep plan and practice question set cover most of what the exam tests - more so than the equivalent material for other AWS certs I’ve sat. Start there.
Domain 3 (Applications of Foundation Models, 28%) carries the most weight. Know RAG vs fine-tuning vs prompt engineering well enough to pick the right approach in a scenario question - not just as definitions.
Domain 4 (Responsible AI) is lighter on services and heavier on principles. Read through the AWS responsible AI pillars and be able to identify violations in scenario questions.
If you have CLF-C02, the cloud fundamentals carry over - the AI/ML concepts, generative AI vocabulary, and responsible AI principles are what’s new.
Verify question count, time, and cost on the live AWS certification page before your exam date.

AWS Kiro CLI - Manage AWS Infrastructure from the Terminal

Fri, 15 May 2026 00:00:00 +0000

Kiro CLI is an AI-assisted terminal tool for AWS, rebranded from Amazon Q Developer CLI in November 2025. It sits on top of your existing AWS credentials and tooling. The q and q chat shortcuts from Q CLI still work but kiro-cli is the current entry point.

Install

macOS

brew install --cask kiro-cli

Or via script:

curl -fsSL https://cli.kiro.dev/install | bash

Windows (PowerShell)

irm 'https://cli.kiro.dev/install.ps1' | iex

Linux / WSL2 (Ubuntu / Debian) - .deb

wget https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.deb
sudo dpkg -i kiro-cli.deb
sudo apt-get install -f

Linux - ZIP (x86-64, non-Debian distros)

curl --proto '=https' --tlsv1.2 -sSf \
  'https://desktop-release.q.us-east-1.amazonaws.com/latest/kirocli-x86_64-linux.zip' \
  -o kirocli.zip
unzip kirocli.zip
./kirocli/install.sh

Verify:

kiro-cli version
kiro-cli doctor   # diagnoses config and auth issues

Authenticate

kiro-cli login     # opens browser to complete sign-in
kiro-cli whoami    # shows current user and auth method
kiro-cli logout

AWS Builder ID - free individual account at builder.aws. No existing AWS account required. Enough to get started with 50 free credits/month (500 bonus credits on first sign-in).

Builder ID with AWS accounts - You can log in to Kiro with a personal Builder ID for the AI features, and connect to your AWS account using AWS SSO profile. Kiro picks up AWS credentials are active in the environment:

Set the profile for the session and run commands targeting the profile:

export AWS_PROFILE=my-prod
aws sts get-caller-identity              # confirm which account is active
aws sts get-caller-identity --profile my-prod
kiro-cli chat "get Compute Optimizer recommendations"

Key commands

kiro-cli with no arguments opens an interactive session - type prompts directly without any prefix. kiro-cli chat "prompt" is for scripted or one-shot use.

kiro-cli                          # interactive session - type prompts directly
kiro-cli chat "your prompt"       # start session with an initial prompt
kiro-cli chat --resume            # continue previous session
kiro-cli chat --no-interactive "prompt"  # one-shot, no interaction - useful in scripts
kiro-cli translate "list S3 buckets"    # natural language to shell command
kiro-cli agent list               # list available agents
kiro-cli mcp add                  # add an MCP server
kiro-cli mcp list                 # list configured MCP servers
kiro-cli mcp status               # check MCP server health
kiro-cli settings list            # view current settings
kiro-cli update                   # upgrade to latest version

Infrastructure workflows

Kiro CLI does not call AWS APIs directly - it generates and optionally runs commands using your existing AWS credentials. A few patterns that work well:

Generate and run AWS CLI commands from natural language:

kiro-cli translate "list all EC2 instances in us-east-1 with their state"
# outputs: aws ec2 describe-instances --region us-east-1 --query ...

Pipe AWS CLI output into chat for analysis:

aws cloudwatch describe-alarms --state-value ALARM | \
  kiro-cli chat --no-interactive "summarise these alarms and suggest remediation"

Generate Terraform or CloudFormation:

kiro-cli chat "write a Terraform module for a private S3 bucket with versioning and a 90-day lifecycle rule to Glacier"

Use in CI without interaction:

KIRO_API_KEY=ksk_xxxxxxxx kiro-cli chat --no-interactive \
  "explain this deployment error: $(cat deploy.log | tail -50)"

Run commands with auto-approval in trusted environments:

kiro-cli chat --trust-all-tools "get Compute Optimizer recommendations for my account"

Notes

If migrating from Q CLI, config migrates automatically from ~/.aws/amazonq to ~/.kiro on first run.
kiro-cli doctor is the first thing to run if auth or config behaves unexpectedly.
The CLI is not open source - the license changed from Apache to AWS Intellectual Property License with the Kiro rebrand.
For the IDE-side equivalent of this kind of AI-assisted tooling, Configure GitHub Copilot Custom Instructions covers the same ground for Copilot.

AWS Certified Developer Associate (DVA-C02) Study Notes

Sun, 03 May 2026 00:00:00 +0000

I sat the AWS Certified Developer Associate (DVA-C02) recently and passed. This is the retrospective I wish I had read before starting - what the exam actually tests, the services you need to know well, the concepts that trip people up, and which resources earned their place.

I came in comfortable across most of the exam’s services from day-to-day work, so for me this was more about confirming and formalising what I already knew than learning it fresh. Your starting point will shape where you spend time, so calibrate the advice accordingly.

For more content on other relevant certifications, check Certifications.

The exam at a glance


Questions	65 (50 scored, 15 unscored)
Time	130 minutes
Format	Multiple choice and multiple response
Passing score	720 out of 1000 (scaled)
Cost	150 USD
Validity	3 years

The scaled score means you do not need 72% of questions right - scoring is normalised across question difficulty. Aim to be comfortably clear of the line rather than counting questions.

The four domains

DVA-C02 has four domains. The percentages are the share of scored content, straight from the exam guide - the bigger the share, the more of your study time it deserves.

Domain 1 - Development with AWS Services (32%)

The largest domain and the heart of a developer exam. Lambda, DynamoDB, and API Gateway show up everywhere. Know event-driven patterns, how services pass data, and the SDK behaviours - pagination, retries, and error handling. This is where hands-on time pays off the most.

Focus areas:

Lambda - triggers, environment variables, layers, versions and aliases, concurrency
DynamoDB - data modelling, partition vs sort keys, indexes (LSI vs GSI), capacity modes, streams
API Gateway - REST vs HTTP APIs, integration types, stages, caching, throttling
S3 - storage classes, lifecycle, presigned URLs, multipart upload, event notifications
SQS and SNS - fan-out, FIFO vs standard, dead-letter queues
Step Functions - standard vs express, when orchestration beats chaining Lambdas
Caching - ElastiCache vs DAX, and where each fits

Domain 2 - Security (26%)

Bigger than people expect, and an easy domain to under-prepare for. It covers the practical IAM, encryption, and auth mechanics a developer wires into an application every day, not abstract security theory.

Focus areas:

IAM - roles vs users, policy evaluation, assume-role, least privilege
Cognito - user pools vs identity pools, and which problem each solves
KMS - envelope encryption, customer-managed vs AWS-managed keys, key policies
Secrets Manager vs SSM Parameter Store - rotation, cost, when to use which
Encryption in transit and at rest across S3, DynamoDB, and the rest
STS and temporary credentials

Domain 3 - Deployment (24%)

The CI/CD and packaging domain. If you have shipped anything through a pipeline this is familiar ground, but the exam wants the specific AWS service behaviours, not generic DevOps intuition.

Focus areas:

The Code suite - CodeCommit, CodeBuild, CodeDeploy, CodePipeline and how they connect
CodeDeploy deployment configs - all-at-once, linear, canary, and what each means for Lambda vs EC2
SAM and CloudFormation - templates, change sets, nested stacks, sam local
Elastic Beanstalk - deployment policies (rolling, immutable, blue/green)
Environment configuration and artifact management

Domain 4 - Troubleshooting and Optimization (18%)

The smallest domain, but do not skip it - it leans on observability and the small operational details that the other domains gloss over. A handful of focused hours here is good value.

Focus areas:

CloudWatch - metrics, custom metrics, logs, alarms, Logs Insights
X-Ray - tracing, segments and subsegments, annotations vs metadata
Lambda performance - cold starts, memory-to-CPU relationship, timeouts
Exponential backoff with jitter, and handling throttling
Reading and reacting to API error codes

Services to know well

If you can explain what each of these does, when to reach for it, and one thing it is commonly confused with, you are in good shape:

Service	Know this about it
Lambda	Concurrency models, versions/aliases, layers, env vars
DynamoDB	Key design, LSI vs GSI, on-demand vs provisioned, streams
API Gateway	REST vs HTTP, integration types, throttling, caching
S3	Storage classes, presigned URLs, event notifications
IAM	Policy evaluation logic, roles vs users, assume-role
Cognito	User pools (authn) vs identity pools (AWS access)
KMS	Envelope encryption, key policies vs IAM
SQS / SNS	FIFO vs standard, fan-out, DLQs, visibility timeout
Step Functions	Standard vs express, orchestration over chaining
SAM	Local testing, `template.yaml`, transform
CodeDeploy	Deployment configs and rollback triggers
X-Ray	Tracing model, annotations vs metadata

Easy things to mix up

These are the pairs and details that the exam likes to probe. Knowing the distinction cleanly is worth more than memorising any single service:

Cognito user pools vs identity pools - user pools authenticate users (who are you), identity pools hand out AWS credentials (what can you access). Questions blur the two on purpose.
DynamoDB on-demand vs provisioned - on-demand for unpredictable traffic, provisioned (with auto scaling) for steady, forecastable load. Watch for cost-driven wording.
LSI vs GSI - LSI shares the partition key and must be created at table creation; GSI has its own keys and can be added later.
Lambda reserved vs provisioned concurrency - reserved caps and guarantees a slice of the account limit; provisioned keeps instances warm to kill cold starts. They solve different problems.
CodeDeploy configs - all-at-once, linear, and canary differ in blast radius and rollout speed. Know which suits a low-risk vs high-risk deploy.
Secrets Manager vs Parameter Store - Secrets Manager has built-in rotation and costs per secret; Parameter Store is cheaper and fine for non-rotating config.
SQS visibility timeout vs message retention - visibility timeout hides an in-flight message; retention is how long an unconsumed message survives.
Exponential backoff with jitter - the standard fix for throttling and transient errors. If a question describes retry storms, this is usually what it is after.
STS / assume-role - reach for temporary credentials whenever cross-account access comes up, not long-lived keys.

Resources

There is no shortage of DVA-C02 material. These are the ones worth your time, ranked by how much they actually helped.

Essential

Exam Guide (DVA-C02) - read the source. The domain breakdown and in-scope services list are the syllabus.
Official Practice Question Set and Official Practice Exam - calibrate against AWS-authored questions before the real thing.
A real AWS account on the free tier - build a Lambda, wire it to DynamoDB and API Gateway, deploy it through CodePipeline. The hands-on sticks far better than reading.

Useful

DigitalCloud cheat sheets - good for last-week revision once the concepts are already in place.
Per-service FAQ pages (Lambda FAQs, DynamoDB FAQs, and so on) - AWS exam questions lean heavily on FAQ-level detail. High yield for the time spent.
Resources to prepare (community.aws) - a decent jumping-off point to the official material.

Skip if you are tight on time

Towards the Cloud study guide and the dev.to write-ups (study guide, how I passed) - useful for orientation and motivation, but they overlap heavily with the guide and your own practice. Read one, skim the rest.
Rishab Kumar’s CloudNotes - handy as a quick reference, not a primary study source.

Notes

Do a timed practice exam early, even before you feel ready - it surfaces the gaps while there is still time to close them.
The exam rewards the services you do not touch day to day as much as the ones you do. The practice exams are what flush out those blind spots.
If you write infrastructure as code already, lean on it - building these services is the fastest way to internalise them. My AWS CDK series covers a lot of the same services from the building side.
Treat the exam guide as the syllabus and the practice exams as the gap finder. Everything else is supporting material.
Score is scaled - aim to clear 720 comfortably rather than chasing a number on practice tests.

GitHub PR Fix: "Commits must have verified signatures"

Sat, 25 Apr 2026 00:00:00 +0000

Problem

GitHub branch protection requires all commits to have verified GPG signatures. Two commits at the base of the branch (made before GPG signing was configured) were unsigned, blocking the merge.

Root cause

Commits made before commit.gpgsign=true was configured in git have no GPG signature. GitHub requires all commits in a PR to be verified - one unsigned commit blocks the merge regardless of approvals.

Steps to fix

1. Identify unsigned commits

git log --format="%G? %ad %s" --date=short origin/main..HEAD

Look for lines starting with N (no signature). Note the hash of the oldest unsigned commit’s parent on main.

2. Re-sign all branch commits using filter-branch

git filter-branch -f --commit-filter 'git commit-tree -S "$@"' -- origin/main..HEAD

Rewrites all branch commits adding a GPG signature - no content changes, no conflicts.

3. Verify no unsigned commits remain

git log --format="%G?" origin/main..HEAD | Select-String "^N$"

Should return nothing.

4. Force push

Attempt force push via terminal using the configured remote:

git push --force origin <branch>

If this fails with “repository not found” (HTTPS remote, no credentials) or “Could not read from remote repository” (SSH not configured), use a classic PAT with repo scope directly in the URL:

git push --force https://<username>:<PAT>@github.com/<org>/<repo>.git <branch>

5. Update local tracking ref (if GitHub Desktop shows stale state)

git update-ref refs/remotes/origin/<branch> <tip-commit-hash>

Notes

Avoid git rebase --exec "git commit --amend -S" if the branch has merge commits - it drops them and causes conflicts.
Avoid git rebase --rebase-merges - re-applying old merge commits causes conflicts from the original merges.
filter-branch rewrites commit objects without replaying merges, which is what’s needed here.
Fine-grained PATs do not work for org repositories - use classic PAT only.
After force pushing, avoid git pull / IDE auto-sync until the PR is merged - it will re-introduce the old unsigned commits via a new merge.

Configure GitHub Copilot Custom Instructions

Sun, 05 Apr 2026 00:00:00 +0000

I set up Copilot instructions on a CDK project and went looking for confirmation that the structure actually matched GitHub’s model, rather than carrying over an assumption from Claude Code. Claude Code works by walking the directory tree and picking up any CLAUDE.md it finds in the current or parent folder - drop a file next to the code it should govern, and Claude finds it. Copilot has no equivalent “drop a file in the folder” convention. It centralises everything under .github/ instead, and scopes by path through frontmatter rather than by file location.

Here’s the order I’d actually set it up in, in VS Code, from a blank repo.

1. Create the repo-wide file

.github/copilot-instructions.md is the one file every Copilot Chat request sees, regardless of which file is open. VS Code picks it up automatically from the workspace on disk - no setting to enable, no reference needed in chat.

A minimal version covers project overview, conventions, how to add something new, the deploy command, and comment style:

# Project name

AWS CDK v2 (Python) infrastructure. `app.py` registers all stacks.

## Conventions

- Stack and construct IDs use PascalCase; file names use snake_case
- Every stack takes `env` and `config` as constructor arguments
- Tag every stack with `Environment` and `Owner`

## Adding a new stack

1. Create `cdk_app/<area>/<name>_stack.py`
2. Register it in `app.py`
3. Add a README entry under `cdk_app/<area>/`

## Deploying

Run `cdk deploy --require-approval never -c env=dev` from the project root.

## Comments

Explain why, not what - skip a comment that just restates the line below it.

Anything that would otherwise repeat across every path-scoped file belongs here instead - it’s worth getting right before anything else, since on its own it already covers most of what a project needs.

2. Add path-scoped files where conventions diverge

.github/instructions/*.instructions.md is for subtrees where the repo-wide file falls short:

A module with hard architectural constraints that don’t apply anywhere else
A CI pipeline format every file in ci/ has to follow exactly
A subsystem mid-redesign, where the assistant needs to know what’s actually built versus just planned

Each file starts with frontmatter declaring where it applies:

---
applyTo: "src/payments/**"
---

The glob syntax:

Pattern	Matches
`*`	current directory
`` or `/*`	recursive, all directories
`src/*/.py`	a specific subtree and extension
`"*/.ts,*/.tsx"`	more than one pattern, comma-separated

When the glob matches the file currently open or being edited, this file loads alongside the repo-wide one - not instead of it.

Reach for a path-scoped file only when the guidance would be wrong outside that subtree - not just because it’s specific to it.

If you’re coming from Claude Code and reach for a per-folder file instinctively, stop - .github/instructions/ with applyTo globs is the actual recommended structure here, not a workaround for the lack of one.

You can exclude a path-scoped file from a particular Copilot surface with excludeAgent, useful if a file is tuned for Chat suggestions but shouldn’t influence Copilot code review:

---
applyTo: "src/payments/**"
excludeAgent: "code-review"
---

3. Decide on AGENTS.md - probably not yet

AGENTS.md is a cross-tool standard - read by Copilot, Codex, and other AI coding tools, not just Copilot. Support varies by surface, and all of it coexists with copilot-instructions.md and instructions/*.instructions.md rather than replacing them:

Copilot coding agent - reads a root AGENTS.md plus nested ones per subtree
Copilot code review - reads a root-level AGENTS.md
VS Code - lists it alongside copilot-instructions.md and CLAUDE.md as a recognised source

What’s undocumented is precedence - when CLAUDE.md, AGENTS.md, and copilot-instructions.md all exist at once, whether they’re merged, layered, or something else. That’s reason enough to leave an established .github/instructions/ setup alone for now rather than migrate it onto AGENTS.md.

Resources

Notes

This is the area most likely to change. Worth revisiting once GitHub documents how copilot-instructions.md, instructions/*.instructions.md, AGENTS.md, and CLAUDE.md actually interact when more than one is present in the same repo - that’s the gap driving the “not yet” on AGENTS.md above, and it’s the kind of thing that gets settled in a changelog post with no fanfare.

On the terminal side rather than the IDE, AWS Kiro CLI is the AI-assisted equivalent for AWS work.

Kubernetes and Cloud Native Associate (KCNA) Study Notes

Thu, 19 Mar 2026 00:00:00 +0000

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.

For more content on other relevant certifications, check Certifications.

The exam at a glance


Questions	60
Time	90 minutes
Format	Multiple choice, online proctored
Passing score	75%
Cost	250 USD (two attempts included)
Validity	2 years

The pass mark is a flat 75%, not a scaled score, so the smaller domains still count - do not leave them to chance.

The four domains

KCNA has four domains. The percentages are the share of scored content, straight from the official curriculum - the bigger the share, the more of your study time it deserves. Note the curriculum was restructured: older guides reference a five-domain version, so calibrate against the current one below.

Kubernetes Fundamentals (44%)

By far the largest domain, and the core of the exam. The Kubernetes architecture, the main resources, and how you interact with a cluster. If you only have time for one area, this is it.

Focus areas:

Kubernetes architecture - control plane vs node components
Core resources - Pods, Deployments, ReplicaSets, Services, namespaces
Configuration - ConfigMaps and Secrets
kubectl basics and the API-driven, declarative model
Containers and the container runtime (CRI)

Container Orchestration (28%)

The second-largest domain. Why orchestration exists and how Kubernetes does it - scheduling, networking, storage, and security at a conceptual level.

Focus areas:

Scheduling and how Pods land on nodes
Networking model - Services, the CNI, Pod-to-Pod communication
Storage - volumes, persistent volumes, the CSI
Container security and the runtime ecosystem
Service mesh and the role it plays

Cloud Native Application Delivery (16%)

How cloud native software gets built and shipped. CI/CD, GitOps, and the packaging tools you would meet around Kubernetes.

Focus areas:

CI/CD fundamentals in a cloud native context
GitOps and declarative delivery
Packaging - Helm and templating
Application delivery patterns and rollout strategies

Cloud Native Architecture (12%)

The wider landscape around Kubernetes. Autoscaling, serverless, open standards, and the roles and personas in the cloud native world. Conceptual, breadth-first.

Focus areas:

Autoscaling - horizontal vs vertical, cluster autoscaling
Serverless and event-driven concepts
Open standards and the role of the CNCF
Observability concepts - metrics, logs, traces (Prometheus, OpenTelemetry)
Community, governance, and personas

Concepts to know well

For KCNA you need to recognise what each piece is and what it is for, not how to configure it:

Concept	Know this about it
Pod	Smallest deployable unit; one or more containers sharing network and storage
Deployment	Declarative rollouts and scaling of stateless Pods via ReplicaSets
Service	Stable networking endpoint for a set of Pods; ClusterIP, NodePort, LoadBalancer
kube-apiserver	The control plane front door; everything goes through the API
etcd	The cluster's key-value store of record
kubelet	Node agent that runs and reports on Pods
kube-scheduler	Decides which node a Pod runs on
ConfigMap / Secret	Non-sensitive vs sensitive configuration injected into Pods
CNI	Pluggable networking layer for Pod connectivity
Helm	Package manager for Kubernetes applications
Prometheus	The default cloud native metrics and monitoring project
kubectl	The CLI you use to talk to the API server

Easy things to mix up

These are the distinctions the exam likes to probe. Knowing the boundary between a pair is usually the whole question:

Deployment vs StatefulSet vs DaemonSet - Deployments for stateless replicas, StatefulSets for stable identity and storage, DaemonSets for one Pod per node.
Service types - ClusterIP is internal only, NodePort exposes a port on every node, LoadBalancer provisions an external load balancer.
ConfigMap vs Secret - both inject configuration, but Secrets are for sensitive data and are base64-encoded (not encrypted by default).
Liveness vs readiness vs startup probes - liveness restarts a stuck container, readiness gates traffic, startup protects slow-starting apps.
Requests vs limits - requests are what the scheduler reserves, limits are the hard ceiling the runtime enforces.
Labels vs annotations - labels are for selecting and grouping objects, annotations are for non-identifying metadata.
Control plane vs node components - api-server, scheduler, etcd, and controllers run the cluster; kubelet, kube-proxy, and the runtime run the workloads.
Container vs container runtime - the container is the running unit, the runtime (containerd, CRI-O) is what runs it via the CRI.

Resources

KCNA is conceptual, so a structured course plus practice questions covers most of it. You do not need to spend much.

Essential

KCNA Curriculum (CNCF) - the syllabus. The domains and their weights tell you exactly what is in scope.
LFS250: Kubernetes and Cloud Native Essentials - the Linux Foundation’s own course, written to the KCNA curriculum. The closest thing to an official study path.
KodeKloud KCNA course - the most recommended third-party prep, with hands-on labs and practice questions. Pick this or LFS250 if you want one guided path.
A throwaway cluster to poke at - minikube, kind, or a free Killercoda sandbox - plus the kubectl Quick Reference. Even on a conceptual exam, touching the objects makes them stick.

Useful

The KCNA Sample Curriculum Path - the Linux Foundation’s suggested learning order.

Skip if you are tight on time

Community write-ups like How to Ace the KCNA and Pass the KCNA Exam - good for orientation and a second pass over the topics, but they overlap with the course and curriculum. Pick one, skim the rest.

Notes

Verify the curriculum version. KCNA was restructured to four domains - plenty of older guides still teach the five-domain layout, and the weightings have shifted.
This is a breadth exam. Know what each piece is for and how the control plane and nodes fit together; do not go deep on any single object.
Even though it is multiple choice, a few hours with kubectl on a throwaway cluster makes the concepts far more concrete than reading.
The cloud native landscape questions reward knowing the flagship CNCF projects by what they do - Prometheus for metrics, Helm for packaging, etcd for state.
KCNA is the on-ramp to the hands-on CNCF exams. If CKA or CKAD is next, treat this as the groundwork for them.

DevSecOps Guardrails - Policy Checks with cdk-nag

Sun, 12 Oct 2025 00:00:00 +0000

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.

The examples use the S3 + Lambda stack from the Infrastructure as Code with AWS CDK series.

What cdk-nag checks

cdk-nag is an open-source library from cdklabs that runs rule sets (called NagPacks) against a synthesised CDK app. It traverses the CDK construct tree and raises a finding for any resource that violates a rule.

Two severity levels:

NagError - blocks synthesis. The cdk synth command fails and no CloudFormation template is written until the violation is resolved or suppressed with a justification.
NagWarning - does not block synthesis. Worth reviewing but will not stop a deploy.

NagPacks that ship out of the box:

AwsSolutionsChecks
HIPAASecurityChecks
NIST80053R5Checks
PCIDSS321Checks

For most CDK projects, AwsSolutionsChecks is the right starting point - it maps to AWS best practice guidance and covers the most common misconfiguration patterns.

Installation

Run this from the project root - the same folder as app.py, cdk.json, and requirements.txt - with the virtual environment from Chapter 1 activated. Outside the project, or without the venv active, it installs somewhere pip freeze below won’t see:

pip install cdk-nag

Add cdk-nag to requirements.txt so it is installed in CI - pin it with pip freeze rather than a bare cdk-nag line, matching the rest of the file:

pip freeze | grep cdk-nag >> requirements.txt

Adding cdk-nag to the app

cdk-nag v3 dropped the Aspect-based wiring - NagPacks are now validation plugins registered through CDK’s native Validations API, not Aspects.of(app).add(). Register cdk-nag in app.py, after the stacks are instantiated:

import aws_cdk as cdk
from aws_cdk import Validations
from cdk_nag import AwsSolutionsChecks
from my_cdk_app.my_stack import MyStack

app = cdk.App()

env = app.node.try_get_context("env") or "dev"
config = app.node.try_get_context(env)

MyStack(app, "MyStack",
    env=cdk.Environment(account="123456789012", region="us-east-1"),
    config=config
)

Validations.of(app).add_plugins(AwsSolutionsChecks(app))

app.synth()

Every subsequent cdk synth run - locally or in CI - will check the synthesised template against the AwsSolutions rules.

Using additional NagPacks

add_plugins() takes more than one pack in a single call. In app.py, extend the same call from the previous section - add the others after AwsSolutionsChecks once those findings are clean; layering in a compliance-specific pack at that point is low friction.

from cdk_nag import AwsSolutionsChecks, HIPAASecurityChecks, NIST80053R5Checks, PCIDSS321Checks

Validations.of(app).add_plugins(
    AwsSolutionsChecks(app),
    HIPAASecurityChecks(app),   # HIPAA Security Rule
    NIST80053R5Checks(app),     # NIST 800-53 Rev 5
    PCIDSS321Checks(app),       # PCI DSS 3.2.1
)

Each pack runs independently and has its own rule IDs (e.g. HIPAA.Security-S3BucketLoggingEnabled, NIST.800.53.R5-S3BucketLoggingEnabled). A suppression for AwsSolutions-S1 does not suppress the equivalent rule in HIPAA or NIST - if the same resource violates rules across multiple packs, each needs its own suppression with a justification.

Start with AwsSolutionsChecks on its own. Running all four packs simultaneously on a codebase that has not been through any nag checks yet produces a lot of noise and makes it harder to prioritise.

How violations look

bucket = s3.Bucket(self, "FilesBucket",
    bucket_name=config["bucket_name"]
)

No server_access_logs_bucket - this triggers AwsSolutions-S1, a NagError, at construct path /MyStack/FilesBucket/Resource. cdk-nag writes it to cdk.out/policy-validation-report.json, with a summary printed to the terminal.

Suppressions

Sometimes a rule genuinely does not apply - a development bucket that intentionally has no access logging, a Lambda that has a pinned runtime for a documented reason. v3 dropped NagSuppressions entirely; suppressing is now “acknowledging” a finding through the same Validations API used to register the NagPacks:

from aws_cdk import Validations, Acknowledgment

Validations.of(fn).acknowledge(
    Acknowledgment(
        id="AwsSolutions-L1",
        reason="Runtime pinned to 3.12; upgrade tracked in backlog"
    )
)

The acknowledgment lives in the same stack code as the resource it covers. That means it is code-reviewed alongside the change that triggered it - not buried in a config file or applied globally.

For a stack-wide acknowledgment (use sparingly):

Validations.of(self).acknowledge(
    Acknowledgment(
        id="AwsSolutions-IAM4",
        reason="AWSLambdaBasicExecutionRole is an AWS-managed policy; risk accepted"
    )
)

v3 also dropped bulk suppression by rule ID prefix - a wildcard finding like AwsSolutions-IAM5 on an auto-generated policy now needs its own specific ID per finding (e.g. AwsSolutions-IAM5[Resource::*]), taken from the actual finding text rather than guessed.

cdk-nag in Jenkins, GitHub Actions, and Azure DevOps

Because cdk-nag is registered as a validation plugin in app.py, it runs automatically on every cdk synth call - wherever that call happens. The synth step already exists in the Jenkins and GitHub Actions pipelines from Chapter 5 of the CDK series; Azure DevOps follows the same pattern. Adding cdk-nag to requirements.txt is all the pipeline change needed - no new pipeline code.

A NagError causes cdk synth to exit non-zero, and each platform blocks the deploy the same way:

Jenkins - the Synth stage is marked failed; the Deploy stage never runs.
GitHub Actions - the Synth step fails the job, which blocks the deploy job downstream via needs: deploy-dev.
Azure DevOps - the Synth step is marked failed and the pipeline stops; the Deploy step never runs.

Nothing ships until the violation is fixed or acknowledged.

Generating a report

Pass verbose to a NagPack’s constructor for more detail in that report:

Validations.of(app).add_plugins(AwsSolutionsChecks(app, verbose=True))

If existing tooling depends on the v2-style cdk_nag metadata block in the synthesised CloudFormation template, cdk-nag has a flag to restore it - check the current docs for the exact option name before relying on it for an audit pipeline.

Surfacing the report in CI

The report is just a JSON file in cdk.out/ - archive it as a build artifact after the Synth stage so it’s visible without re-running the pipeline, including on a failed build.

Jenkins

stage('Synth') {
    steps {
        sh 'cdk synth -c env=dev'
    }
    post {
        always {
            archiveArtifacts artifacts: 'cdk.out/policy-validation-report.json', allowEmptyArchive: true
        }
    }
}

allowEmptyArchive: true stops the archive step itself from failing the build on a run where the file doesn’t exist (e.g. synth failed before writing it). The report shows up as a downloadable artifact on the build page.

GitHub Actions

- name: Synth
  run: cdk synth -c env=dev

- name: Upload cdk-nag report
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: policy-validation-report
    path: cdk.out/policy-validation-report.json

if: always() runs the upload step even if the Synth step above it failed - the report is attached to the workflow run.

Azure DevOps

- script: cdk synth -c env=dev
  displayName: Synth

- task: PublishBuildArtifacts@1
  condition: always()
  inputs:
    pathToPublish: 'cdk.out/policy-validation-report.json'
    artifactName: policy-validation-report

condition: always() does the same job - the report attaches to the pipeline run regardless of whether the Synth step passed.

Notes

Register cdk-nag in app.py, not inside a stack. Registered at the app level it covers every stack in the app. Registered inside a stack it only covers that stack.
Start with AwsSolutionsChecks and add other NagPacks once the AwsSolutions findings are clean - running all packs at once on a new codebase produces a lot of noise.
An acknowledgment without a reason string will not be accepted by cdk-nag. The reason field is required and shows up in the audit report.
cdk-nag does not check runtime behaviour - it checks the synthesised CloudFormation template. It catches misconfiguration, not application bugs.
This post targets cdk-nag v3 (3.0.0+, released June 2026). Pin your version in requirements.txt - a major version bump like this will break a pipeline that was passing the day before.

AWS CDK - CI/CD Pipelines

Sun, 27 Jul 2025 00:00:00 +0000

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.

-c env=prod passes the environment context from Chapter 2.

GitHub Actions

Auth

OIDC is the recommended auth method - no long-lived credentials stored in GitHub. The pipeline assumes an IAM role directly via GitHub’s OIDC provider.

Create the OIDC provider in AWS once per account:

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

Create an IAM role with a trust policy scoped to your repository:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*"
      }
    }
  }]
}

Attach whatever IAM policies the CDK deploy needs (CloudFormation, S3, Lambda, IAM) to this role.

Workflow

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy-dev:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install CDK CLI
        run: npm install -g aws-cdk

      - name: Install dependencies
        run: pip install -r requirements.txt -r requirements-dev.txt

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1

      - name: Synth
        run: cdk synth -c env=dev

      - name: Test
        run: pytest

      - name: Deploy dev
        run: cdk deploy --require-approval never -c env=dev

  deploy-prod:
    runs-on: ubuntu-latest
    needs: deploy-dev
    environment: production
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install CDK CLI
        run: npm install -g aws-cdk

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: us-east-1

      - name: Deploy prod
        run: cdk deploy --require-approval never -c env=prod

The environment: production job pauses for a manual approval before running. Configure required reviewers under Settings > Environments > production in the GitHub repository.

Jenkins

Auth

The simplest setup: run the Jenkins agent on an EC2 instance with an IAM instance role. The CDK CLI picks up credentials automatically via the instance metadata service - no credentials to manage.

If the agent is not on EC2, store AWS credentials as a Jenkins credential (Credentials > Add > AWS Credentials) and inject them into the pipeline with the withCredentials block.

Jenkinsfile

pipeline {
    agent any

    environment {
        AWS_DEFAULT_REGION = 'us-east-1'
    }

    stages {
        stage('Install') {
            steps {
                sh 'pip install -r requirements.txt -r requirements-dev.txt'
                sh 'npm install -g aws-cdk'
            }
        }

        stage('Synth') {
            steps {
                sh 'cdk synth -c env=dev'
            }
        }

        stage('Test') {
            steps {
                sh 'pytest'
            }
        }

        stage('Deploy dev') {
            steps {
                sh 'cdk deploy --require-approval never -c env=dev'
            }
        }

        stage('Approve prod') {
            steps {
                input message: 'Deploy to production?', ok: 'Deploy'
            }
        }

        stage('Deploy prod') {
            steps {
                sh 'cdk deploy --require-approval never -c env=prod'
            }
        }
    }

    post {
        failure {
            echo 'Pipeline failed - check CloudFormation events for rollback details'
        }
    }
}

The input step pauses the pipeline until someone clicks Deploy in the Jenkins UI.

If credentials are stored in Jenkins rather than on an instance role, wrap the deploy steps:

withCredentials([[
    $class: 'AmazonWebServicesCredentialsBinding',
    credentialsId: 'aws-deploy-credentials'
]]) {
    sh 'cdk deploy --require-approval never -c env=prod'
}

Azure DevOps

Auth

Store AWS credentials as secret pipeline variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) or use the AWS Toolkit for Azure DevOps extension, which adds an AWSShellScript task with a configured service connection.

The example below uses secret variables directly, which works without the extension.

Pipeline

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main

variables:
  pythonVersion: "3.12"
  awsRegion: "us-east-1"

stages:
  - stage: DeployDev
    displayName: Deploy to dev
    jobs:
      - job: Deploy
        pool:
          vmImage: ubuntu-latest
        steps:
          - task: UsePythonVersion@0
            inputs:
              versionSpec: $(pythonVersion)

          - script: |
              pip install -r requirements.txt -r requirements-dev.txt
              npm install -g aws-cdk
            displayName: Install dependencies

          - script: cdk synth -c env=dev
            displayName: Synth
            env:
              AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
              AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)
              AWS_DEFAULT_REGION: $(awsRegion)

          - script: pytest
            displayName: Test

          - script: cdk deploy --require-approval never -c env=dev
            displayName: Deploy dev
            env:
              AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
              AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)
              AWS_DEFAULT_REGION: $(awsRegion)

  - stage: DeployProd
    displayName: Deploy to prod
    dependsOn: DeployDev
    jobs:
      - deployment: Deploy
        environment: production
        pool:
          vmImage: ubuntu-latest
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self

                - task: UsePythonVersion@0
                  inputs:
                    versionSpec: $(pythonVersion)

                - script: |
                    pip install -r requirements.txt
                    npm install -g aws-cdk
                  displayName: Install dependencies

                - script: cdk deploy --require-approval never -c env=prod
                  displayName: Deploy prod
                  env:
                    AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
                    AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)
                    AWS_DEFAULT_REGION: $(awsRegion)

The deployment job type with environment: production enables approval gates. Configure approvers under Pipelines > Environments > production in Azure DevOps.

AWS CodePipeline

CDK ships a pipelines module that creates a CodePipeline pipeline directly from CDK code:

from aws_cdk import pipelines

pipeline = pipelines.CodePipeline(self, "Pipeline",
    synth=pipelines.ShellStep("Synth",
        input=pipelines.CodePipelineSource.git_hub("my-org/my-repo", "main"),
        commands=[
            "pip install -r requirements.txt",
            "npm install -g aws-cdk",
            "cdk synth"
        ]
    )
)

The pipeline is self-mutating - when CDK code changes, the pipeline updates itself before deploying application changes. It is tightly coupled to CodePipeline and requires more upfront setup than the external CI approaches above, but is the right fit when the deployment needs to stay fully within AWS.

Notes

--require-approval never skips the IAM diff prompt. Review IAM changes in cdk diff output or pull request checks before merging rather than at deploy time.
The cdk.context.json file should be committed - pipelines need it for SSM lookups cached in Chapter 2 to avoid live SSM calls on every run.
CloudFormation automatically rolls back a failed deployment to the previous stable state. No extra rollback configuration is needed in the pipeline.
For OIDC in GitHub Actions, scope the trust condition to a specific branch (repo:my-org/my-repo:ref:refs/heads/main) rather than * to limit which workflows can assume the role.

AWS CDK - Testing CDK Stacks

Thu, 05 Jun 2025 00:00:00 +0000

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.

Setup

cdk init adds pytest to requirements-dev.txt automatically. Install it if not already active:

pip install -r requirements-dev.txt

Create the test files:

my-cdk-app/
├── tests/
│   ├── __init__.py
│   ├── test_file_processor.py
│   └── test_stack.py

Testing the construct

Each test builds a minimal stack, instantiates the construct inside it, and asserts against the synthesized template:

# tests/test_file_processor.py
import pytest
from aws_cdk import App, Stack
from aws_cdk.assertions import Template, Match
from my_cdk_app.file_processor import FileProcessorConstruct

TEST_PROPS = dict(
    bucket_name="test-bucket",
    log_level="DEBUG",
    lambda_timeout=30,
)


@pytest.fixture
def template():
    app = App()
    stack = Stack(app, "TestStack")
    FileProcessorConstruct(stack, "TestConstruct", **TEST_PROPS)
    return Template.from_stack(stack)


def test_bucket_created(template):
    template.has_resource_properties("AWS::S3::Bucket", {
        "BucketName": "test-bucket"
    })


def test_lambda_runtime_and_timeout(template):
    template.has_resource_properties("AWS::Lambda::Function", {
        "Runtime": "python3.12",
        "Timeout": 30,
        "Environment": {
            "Variables": {"LOG_LEVEL": "DEBUG"}
        }
    })


def test_lambda_has_read_access(template):
    template.has_resource_properties("AWS::IAM::Policy", {
        "PolicyDocument": {
            "Statement": Match.array_with([
                Match.object_like({
                    "Action": Match.array_with(["s3:GetObject*"]),
                    "Effect": "Allow"
                })
            ])
        }
    })

has_resource_properties does a subset match - the resource only needs to contain the specified properties, not match them exactly. Match.array_with and Match.object_like apply the same subset logic to nested arrays and objects.

Testing the stack

Test MyStack the same way, using a config dict that matches what app.py passes:

# tests/test_stack.py
from aws_cdk import App
from aws_cdk.assertions import Template
from my_cdk_app.my_cdk_app_stack import MyStack

TEST_CONFIG = {
    "bucket_name": "test-bucket",
    "log_level": "INFO",
    "lambda_timeout": 60,
}


def test_stack_resource_count():
    app = App()
    stack = MyStack(app, "TestStack", config=TEST_CONFIG)
    template = Template.from_stack(stack)
    template.resource_count_is("AWS::S3::Bucket", 1)
    template.resource_count_is("AWS::Lambda::Function", 1)

Snapshot testing

Snapshot tests capture the full synthesized template and fail if anything changes. Write the template to a file on first run, then compare on subsequent runs:

import json
from pathlib import Path
from aws_cdk import App
from aws_cdk.assertions import Template
from my_cdk_app.my_cdk_app_stack import MyStack

SNAPSHOT_PATH = Path(__file__).parent / "snapshots" / "stack.json"

TEST_CONFIG = {
    "bucket_name": "test-bucket",
    "log_level": "INFO",
    "lambda_timeout": 60,
}


def test_stack_snapshot():
    app = App()
    stack = MyStack(app, "TestStack", config=TEST_CONFIG)
    template = Template.from_stack(stack).to_json()

    if not SNAPSHOT_PATH.exists():
        SNAPSHOT_PATH.parent.mkdir(exist_ok=True)
        SNAPSHOT_PATH.write_text(json.dumps(template, indent=2))
        return

    expected = json.loads(SNAPSHOT_PATH.read_text())
    assert template == expected

Commit the snapshot file. To update it after an intentional change, delete the file and run the test once to regenerate.

The downside: CDK version bumps routinely touch metadata in the template - aws:cdk:path, asset hashes, checksums. Any of these invalidates the snapshot even when nothing meaningful changed. They work well for catching unintended IAM or resource config changes, but generate noise as a general regression check.

Running tests

pytest
pytest -v                             # verbose output
pytest tests/test_file_processor.py  # single file

Notes

has_resource_properties only checks the Properties block. To assert on the full resource including DeletionPolicy, DependsOn, or Metadata, use has_resource instead.
Template.from_stack calls app.synth() implicitly - no need to call it manually.
CDK assigns logical IDs based on the construct path. Changing a construct’s id argument changes its logical ID, which CloudFormation treats as a delete and recreate. Snapshot tests catch this; has_resource_properties tests do not.
For TypeScript CDK projects, Jest has built-in snapshot support via toMatchSnapshot(). Python has no equivalent - the manual file approach above is the workaround.

AWS CDK - Writing and Sharing Constructs

Wed, 14 May 2025 00:00:00 +0000

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:

class MyStack(Stack):
    def __init__(self, scope, id, config, **kwargs):
        super().__init__(scope, id, **kwargs)

        bucket = s3.Bucket(self, "FilesBucket",
            bucket_name=config["bucket_name"]
        )

        fn = _lambda.Function(self, "ProcessorFunction",
            runtime=_lambda.Runtime.PYTHON_3_12,
            handler="handler.handler",
            code=_lambda.Code.from_asset("lambda"),
            timeout=Duration.seconds(config["lambda_timeout"]),
            environment={"LOG_LEVEL": config["log_level"]}
        )

        bucket.grant_read(fn)

If you need a second processor - say one for raw uploads and one for processed files - all of this gets duplicated. That’s what a construct solves.

Writing the construct

Add file_processor.py inside the existing app module:

my-cdk-app/
├── app.py
├── my_cdk_app/
│   ├── __init__.py
│   ├── my_cdk_app_stack.py
│   └── file_processor.py     ← new

# my_cdk_app/file_processor.py
from aws_cdk import (
    Duration,
    aws_s3 as s3,
    aws_lambda as _lambda,
)
from constructs import Construct


class FileProcessorConstruct(Construct):
    def __init__(
        self,
        scope: Construct,
        id: str,
        *,
        bucket_name: str,
        log_level: str,
        lambda_timeout: int,
    ):
        super().__init__(scope, id)

        self.bucket = s3.Bucket(self, "Bucket",
            bucket_name=bucket_name
        )

        self.fn = _lambda.Function(self, "Function",
            runtime=_lambda.Runtime.PYTHON_3_12,
            handler="handler.handler",
            code=_lambda.Code.from_asset("lambda"),
            timeout=Duration.seconds(lambda_timeout),
            environment={"LOG_LEVEL": log_level}
        )

        self.bucket.grant_read(self.fn)

The * before the keyword arguments makes them keyword-only - callers must pass them by name, not by position. self.bucket and self.fn are public so callers can reach in and extend if needed.

Using it in a stack

# my_cdk_app/my_cdk_app_stack.py
from aws_cdk import Stack
from constructs import Construct
from my_cdk_app.file_processor import FileProcessorConstruct


class MyStack(Stack):
    def __init__(self, scope: Construct, id: str, config: dict, **kwargs):
        super().__init__(scope, id, **kwargs)

        FileProcessorConstruct(self, "FileProcessor",
            bucket_name=config["bucket_name"],
            log_level=config["log_level"],
            lambda_timeout=config["lambda_timeout"]
        )

Reusing the construct

Two processors in the same stack, no duplication:

class MyStack(Stack):
    def __init__(self, scope: Construct, id: str, config: dict, **kwargs):
        super().__init__(scope, id, **kwargs)

        FileProcessorConstruct(self, "RawProcessor",
            bucket_name=f"{config['bucket_name']}-raw",
            log_level=config["log_level"],
            lambda_timeout=config["lambda_timeout"]
        )

        FileProcessorConstruct(self, "ProcessedProcessor",
            bucket_name=f"{config['bucket_name']}-processed",
            log_level=config["log_level"],
            lambda_timeout=config["lambda_timeout"]
        )

CDK uses the id argument (RawProcessor, ProcessedProcessor) to make all resource logical IDs unique within the stack. Both constructs deploy without naming conflicts.

Using exposed attributes

Use self.bucket and self.fn when something needs to be added at the call site:

processor = FileProcessorConstruct(self, "FileProcessor",
    bucket_name=config["bucket_name"],
    log_level=config["log_level"],
    lambda_timeout=config["lambda_timeout"]
)

# Grant a second function read access to the same bucket
processor.bucket.grant_read(reporting_fn)

If it’s specific to one stack, keep it there rather than baking it into the construct.

Notes

Do not name the constructs directory constructs/ - it conflicts with the CDK constructs package import. Putting files inside the app module (my_cdk_app/) sidesteps this entirely.
The * in the __init__ signature enforces keyword arguments. Without it, callers can pass values positionally, which gets confusing with three or more parameters.
self.bucket and self.fn being public is a choice. If the construct is fully self-contained and callers should never reach in, keep them private with a leading underscore (self._bucket).
To use a construct across multiple CDK projects, move it into a standalone Python package and install it as a dependency. Cross-language support (TypeScript, Java) requires jsii - a separate topic.

AWS CDK - Managing Configuration and Context

Mon, 28 Apr 2025 00:00:00 +0000

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.

Static config (`cdk.json`)

Store environment-specific config in cdk.json under the context key. CDK reads this file automatically at synth time.

When to use: Stable, non-sensitive values that are the same for everyone on the team.

{
  "app": "python3 app.py",
  "context": {
    "dev": {
      "bucket_name": "my-bucket-dev",
      "log_level": "DEBUG",
      "lambda_timeout": 30
    },
    "prod": {
      "bucket_name": "my-bucket-prod",
      "log_level": "INFO",
      "lambda_timeout": 60
    }
  }
}

Read context in app.py:

app = cdk.App()
env_name = app.node.try_get_context("env") or "dev"
config = app.node.try_get_context(env_name)

MyStack(app, f"MyStack-{env_name}", config=config)

Deploy with:

cdk deploy -c env=dev
cdk deploy -c env=prod

Trade-off: Any config change requires a commit and redeploy. Never put secrets here - cdk.json is committed to source control.

Dynamic config

Load config at synth time from a local file or environment variables, outside the CDK project. Useful when values differ per developer or machine.

When to use: Values that differ between developers - e.g. personal AWS account IDs, local endpoint overrides.

Create a config.dev.json outside source control:

{
  "bucket_name": "my-bucket-dev",
  "log_level": "DEBUG",
  "lambda_timeout": 30
}

Load it in app.py:

import json
import os

app = cdk.App()
env_name = os.environ.get("ENV", "dev")

with open(f"config.{env_name}.json") as f:
    config = json.load(f)

MyStack(app, f"MyStack-{env_name}", config=config)

Add config files to .gitignore:

config.*.json

Deploy with:

ENV=dev cdk deploy
ENV=prod cdk deploy

Trade-off: Config lives outside source control - harder to audit and reproduce. Not suitable for team environments where config needs to be consistent.

Production patterns

Config lives in AWS or is injected by the pipeline - not in the codebase. Values can change without a code commit.

Secrets Manager

Store sensitive config in Secrets Manager. Values are fetched at deploy time and injected into the Lambda environment - they are never visible in the CloudFormation template.

When to use: API keys, database passwords, tokens. Secrets should never go in cdk.json or plain environment variables.

Create a secret (run once per environment):

aws secretsmanager create-secret \
  --name "/my-app/dev/config" \
  --secret-string '{"api_key":"abc123","db_password":"s3cr3t"}'

Reference the secret in the stack:

from aws_cdk import aws_secretsmanager as secretsmanager

class MyStack(Stack):
    def __init__(self, scope, id, env_name, **kwargs):
        super().__init__(scope, id, **kwargs)

        secret = secretsmanager.Secret.from_secret_name_v2(
            self, "AppSecret", f"/my-app/{env_name}/config"
        )

        fn = _lambda.Function(self, "MyFunction",
            ...
            environment={
                "SECRET_ARN": secret.secret_arn
            }
        )

        secret.grant_read(fn)

The Lambda reads the secret at runtime using the ARN:

import boto3, json, os

def handler(event, context):
    client = boto3.client("secretsmanager")
    secret = json.loads(client.get_secret_value(
        SecretId=os.environ["SECRET_ARN"]
    )["SecretString"])
    api_key = secret["api_key"]

Trade-off: Cost per secret per month. Values are only available at runtime, not synth time. Rotation adds operational overhead but is worth setting up for credentials.

For non-sensitive shared config that needs to change without a code commit - bucket names, log levels, timeouts - SSM Parameter Store is an alternative. Parameters are fetched at synth time via value_from_lookup and cached in cdk.context.json:

from aws_cdk import aws_ssm as ssm

bucket_name = ssm.StringParameter.value_from_lookup(
    self, f"/my-app/{env_name}/bucket_name"
)

Commit cdk.context.json so CI doesn’t need live SSM access on every run. SSM has no secrets support - keep anything sensitive in Secrets Manager.

CI/CD context injection

Pass values into the stack directly from the pipeline via CDK context flags. The stack reads them at synth time - no external config files or AWS lookups required.

When to use: Values that are known to the pipeline at deploy time - environment name, account ID, deploy target region, feature flags. Works well when the pipeline is the source of truth for what gets deployed where.

The stack reads context with try_get_context and uses Stack.of(self).account for the resolved AWS account:

from aws_cdk import Stack
from constructs import Construct

class MyStack(Stack):
    def __init__(self, scope: Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        env_name = self.node.try_get_context("env")
        profile = self.node.try_get_context("profile")
        account_id = Stack.of(self).account

        bucket = s3.Bucket(self, "FilesBucket",
            bucket_name=f"my-bucket-{env_name}-{account_id}"
        )

The pipeline passes context at deploy time:

# GitHub Actions, CodePipeline, or any CI runner
cdk deploy -c env=prod -c profile=my-prod

A GitHub Actions step looks like:

- name: Deploy
  run: cdk deploy --require-approval never -c env=prod -c profile=my-prod
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

try_get_context returns None if the key is not passed. Add a guard if the value is required:

env_name = self.node.try_get_context("env")
if not env_name:
    raise ValueError("env context is required - pass with -c env=<name>")

Trade-off: Context values are visible in the pipeline logs and the synthesized CloudFormation template. Keep secrets in Secrets Manager and pass only non-sensitive identifiers this way.

Notes

These approaches combine well - SSM for non-sensitive shared config, Secrets Manager for secrets, CI/CD context injection for environment identifiers.
Secrets Manager values are never embedded in CloudFormation templates - they are resolved at runtime by the Lambda itself.
On Windows with PowerShell, set the env var with $env:ENV="dev"; cdk deploy instead of the bash syntax.

AWS CDK - Project Setup and Bootstrapping

Tue, 11 Mar 2025 00:00:00 +0000

This is Chapter 1 of the Infrastructure as Code with AWS CDK series. Two things come before writing any stack code: initialising the CDK project and bootstrapping the AWS account.

Prerequisites

Python 3.9+
Node.js 18+ (CDK CLI is a Node package)
AWS CLI v2 configured with valid credentials - see Connect to AWS SSO and SSH into EC2 Instance
An AWS account with permissions to create IAM roles, S3 buckets, and CloudFormation stacks

Install the CDK CLI globally:

npm install -g aws-cdk
cdk --version

Initialise project

Create a new directory and initialise a CDK Python project inside it:

mkdir my-cdk-app && cd my-cdk-app
cdk init app --language python

This scaffolds the project with a virtual environment, a sample stack, and a cdk.json config file.

Activate the virtual environment and install dependencies:

# macOS / Linux
source .venv/bin/activate

# Windows (PowerShell)
.venv\Scripts\activate.ps1

pip install -r requirements.txt

Directory structure

After initialisation the project looks like this:

my-cdk-app/
├── app.py                  # CDK app entry point
├── cdk.json                # CDK config and context
├── requirements.txt        # Python dependencies
├── requirements-dev.txt    # Dev dependencies (e.g. pytest)
├── .venv/                  # Python virtual environment
└── my_cdk_app/
    ├── __init__.py
    └── my_cdk_app_stack.py # Default stack

app.py is where the CDK app is defined and stacks are instantiated. my_cdk_app_stack.py is where resources are defined. The folder and class names match the project name passed to cdk init.

Bootstrap AWS account

CDK needs a one-time setup in each AWS account and region it deploys to. Bootstrapping creates an S3 bucket (for assets) and IAM roles (for deployments) in the account:

cdk bootstrap aws://123456789012/us-east-1

Replace 123456789012 with your account ID and us-east-1 with your target region. If credentials are already configured via AWS CLI or SSO, the account ID can be omitted:

cdk bootstrap

This only needs to run once per account/region combination. Re-running it is safe - it updates the bootstrap stack if needed.

Synth and deploy

CDK compiles Python into CloudFormation before deploying. Run synth to see the generated CloudFormation template:

cdk synth

This outputs a CloudFormation template to cdk.out/. Use it to verify what CDK will create before deploying.

Deploy the stack:

cdk deploy

CDK shows a diff of changes and prompts for confirmation before creating or modifying any IAM resources.

Verify

After deploying, the stack appears in CloudFormation in the AWS console. Check:

CloudFormation > Stacks > MyCdkAppStack - status should be CREATE_COMPLETE
S3 > Buckets - the CDK bootstrap bucket should be visible (cdk-hnb659fds-assets-...)

To tear down the stack:

cdk destroy

Notes

The bootstrap stack itself is a CloudFormation stack - it can be viewed and managed in the console under CDKToolkit.
Each AWS account + region combination needs its own bootstrap - e.g. deploying to both us-east-1 and ap-southeast-2 requires bootstrapping both.
cdk synth is useful for debugging - the generated CloudFormation is in cdk.out/ and can be inspected directly.
The .venv/ folder and cdk.out/ should be in .gitignore - they are added automatically by cdk init.

Install CloudWatch Agent in EC2 Instance

Tue, 03 Dec 2024 00:00:00 +0000

EC2 does not send memory or disk metrics to CloudWatch by default - only CPU, network and status checks. The CloudWatch agent runs inside the instance and collects system-level metrics and logs directly.

Prerequisites

EC2 instance running (Amazon Linux 2 or Ubuntu)
SSH access to the instance - see Connect to AWS SSO and SSH into EC2 Instance
Terminal

Attach IAM role to the instance

The agent needs permission to write metrics and logs to CloudWatch. In the AWS console:

EC2 > Instances > select your instance
Actions > Security > Modify IAM role
Attach a role that has CloudWatchAgentServerPolicy managed policy

If no such role exists, create one:

IAM > Roles > Create role
Trusted entity: AWS service > EC2
Add permission: CloudWatchAgentServerPolicy
Name it (e.g. ec2-cloudwatch-agent-role) and create

Install the agent

SSH into the instance, then run the appropriate command for your OS.

Amazon Linux 2:

sudo yum install -y amazon-cloudwatch-agent

Ubuntu:

sudo apt-get install -y amazon-cloudwatch-agent

Configure the agent

Run the configuration wizard - it steps through metrics and log collection interactively:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Alternatively, create a config file manually at /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json:

{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "root"
  },
  "metrics": {
    "namespace": "CWAgent",
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"]
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/"]
      }
    }
  }
}

Collects memory and disk usage every 60 seconds under the CWAgent namespace.

Start the agent

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  -s

Verify

Check the agent is running:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

Expected output:

{
  "status": "running",
  "starttime": "...",
  "version": "..."
}

In the AWS console, go to CloudWatch > Metrics > All metrics > CWAgent to confirm metrics are coming in. Give it 2-3 minutes after starting for metrics to show up.

Notes

If the instance had no IAM role before, restart the agent after attaching the role - it picks up credentials on start.
The wizard config is saved to /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json by default.
To collect logs, add a logs block to the config pointing to the log file paths.
Agent logs are at /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log - check here if metrics are not appearing.

AWS Certified Cloud Practitioner (CLF-C02) Study Notes

Fri, 15 Nov 2024 00:00:00 +0000

I sat the AWS Certified Cloud Practitioner (CLF-C02) back in 2024 and passed. CLF-C02 is AWS’s foundational certification - broad rather than deep, covering cloud concepts, security, core services, and billing at a level anyone working around AWS should recognise.

It is the most accessible AWS exam, so if you already work with AWS day to day, a lot of this will be familiar. Treat it as a breadth check rather than a deep technical exam, and calibrate the prep to what you already know.

For more content on other relevant certifications, check Certifications.

The exam at a glance


Questions	65 (50 scored, 15 unscored)
Time	90 minutes
Format	Multiple choice and multiple response
Passing score	700 out of 1000 (scaled)
Cost	100 USD
Validity	3 years

The score is scaled, so you do not need 70% of questions right - it is normalised across question difficulty. The exam is conceptual: it tests whether you understand what AWS services do and when they apply, not whether you can build with them.

The four domains

CLF-C02 has four domains. The percentages are the share of scored content, straight from the exam guide - the bigger the share, the more of your study time it deserves.

Domain 1 - Cloud Concepts (24%)

The “why cloud” domain. Value proposition of the cloud, the AWS global infrastructure, and the basics of how cloud economics differ from running your own hardware. Conceptual, not technical.

Focus areas:

Benefits of cloud - elasticity, agility, pay-as-you-go, economies of scale
AWS global infrastructure - Regions, Availability Zones, edge locations
Cloud economics - CapEx vs OpEx, total cost of ownership
The AWS Well-Architected Framework at a high level
Migration and the cloud adoption basics

Domain 2 - Security and Compliance (30%)

The second-largest domain. The shared responsibility model is the spine of it - know exactly where AWS’s responsibility ends and yours begins. The rest is IAM basics and where to find compliance information.

Focus areas:

Shared responsibility model - what AWS secures vs what you secure
IAM - users, groups, roles, policies, MFA, root account protection
Security services - Shield, WAF, GuardDuty, Inspector, KMS at a high level
Compliance - AWS Artifact, where audit reports come from
Encryption in transit and at rest as concepts

Domain 3 - Cloud Technology and Services (34%)

The largest domain and the widest. You need recognition-level knowledge of a long list of services - what each one is for, not how to configure it. Breadth beats depth here.

Focus areas:

Compute - EC2, Lambda, Elastic Beanstalk, ECS/EKS at a glance
Storage - S3, EBS, EFS, Glacier and when each fits
Databases - RDS, DynamoDB, Aurora, ElastiCache at a glance
Networking - VPC, Route 53, CloudFront, the basics
Management and monitoring - CloudWatch, CloudTrail, Organizations, Trusted Advisor
Ways to access AWS - console, CLI, SDKs, infrastructure as code

Domain 4 - Billing, Pricing, and Support (12%)

The smallest domain, but easy marks if you know the tools. Pricing models, the billing and cost tools, and the support plan tiers. Worth a focused hour - the distinctions are clean and frequently tested.

Focus areas:

Pricing models - On-Demand, Reserved, Spot, Savings Plans
Cost tools - Cost Explorer, Budgets, Cost and Usage Report, Billing Conductor
Support plans - Basic, Developer, Business, Enterprise and what each includes
AWS Organizations and consolidated billing
Trusted Advisor cost checks

Services to know well

For CLF-C02 you need recognition-level knowledge - what each service is for and when you would reach for it, not how to configure it:

Service	Know this about it
EC2	Virtual servers; the pricing models attach here
S3	Object storage, storage classes, durability
RDS	Managed relational databases vs running your own
Lambda	Serverless compute, pay per execution
VPC	Your private network boundary in AWS
IAM	Users, groups, roles, policies, MFA
CloudWatch	Monitoring, metrics, alarms, logs
CloudTrail	API activity auditing (who did what)
Organizations	Multi-account management, consolidated billing
Trusted Advisor	Best-practice checks across cost, security, performance
Cost Explorer / Budgets	Viewing spend vs alerting on spend
Well-Architected Tool	Reviewing workloads against the six pillars

Easy things to mix up

These are the distinctions the exam likes to probe. At this level, knowing the boundary between a pair is usually the whole question:

Shared responsibility model - AWS secures the cloud (hardware, global infrastructure); you secure what you put in it (data, IAM, configuration). Managed services shift more onto AWS.
Regions vs Availability Zones vs edge locations - a Region is a geographic area, an AZ is one or more data centres within it, an edge location serves CloudFront content closer to users.
Security groups vs network ACLs - security groups are stateful and act at the instance; NACLs are stateless and act at the subnet.
On-Demand vs Reserved vs Spot - On-Demand for flexibility, Reserved/Savings Plans for steady long-term workloads at a discount, Spot for interruptible workloads at the biggest discount.
Cost Explorer vs Budgets vs Cost and Usage Report - Explorer visualises past spend, Budgets alerts on thresholds, the CUR is the detailed line-item export.
IAM users vs roles - users are long-lived identities, roles are assumed temporarily and avoid long-lived credentials.
Support plans - Basic is free, Developer adds business-hours email support, Business adds 24/7 and a fuller Trusted Advisor, Enterprise adds a TAM.
Trusted Advisor vs Well-Architected Tool - Trusted Advisor runs automated best-practice checks; the Well-Architected Tool is a guided self-review against the framework.

Resources

CLF-C02 is well served by free, AWS-authored material. You do not need to spend much here.

Essential

Exam Guide (CLF-C02) - the syllabus. The domain breakdown and in-scope service list tell you exactly what is fair game.
Exam Prep Enhanced Course (Skill Builder) - AWS’s own guided prep, free, and enough to carry most people through on its own.
Official Practice Exam (Skill Builder) - calibrate against AWS-authored questions before booking.

Useful

Exam Prep Standard Course (Skill Builder) - a lighter path than the enhanced course if you only need a refresher.
DigitalCloud cheat sheets - good for last-week revision once the concepts are in place.

Skip if you are tight on time

DigitalCloud resources page and Rishab Kumar’s CloudNotes - handy as references, but they overlap with the official course and your practice exams. Skim, do not study cover to cover.

Notes

This is a breadth exam. Recognising what a service is for matters far more than any configuration detail - do not over-study any single service.
The free Skill Builder enhanced course plus one set of practice exams is enough for most people. There is no need to buy multiple courses.
Learn the shared responsibility model and the support plan tiers cold - they are reliable marks and the distinctions are clean.
The score is scaled, so aim to clear 700 comfortably on practice exams rather than chasing a specific number.
If you want the developer-level depth that this exam only touches, the DVA-C02 study notes are the natural next step up.

Setting Up WSL2 on Windows

Fri, 27 Sep 2024 00:00:00 +0000

WSL (Windows Subsystem for Linux) lets you run a Linux environment directly on Windows - no VM, no dual boot. WSL2 runs a real Linux kernel in a lightweight managed VM, giving you full syscall compatibility and much better performance than WSL1.

Prerequisites

Windows 10 version 2004+ or Windows 11
Admin access to your machine
PowerShell or Windows Terminal

Install WSL

From an elevated PowerShell or Command Prompt:

wsl --install

This installs WSL2 and Ubuntu (the default distro) in one step. Restart when prompted.

To install a different distro, list what’s available first:

wsl --list --online

Then install by name:

wsl --install -d Debian

To check what’s installed and running:

wsl --list --verbose

First run

Launch the distro from the Start menu or by typing its name in a terminal. The first launch prompts you to create a UNIX username and password - this is local to the distro and doesn’t need to match your Windows credentials.

Set WSL2 as the default version if it isn’t already:

wsl --set-default-version 2

Update the distro

After first launch, update the package list and upgrade installed packages:

sudo apt update && sudo apt upgrade -y

Install any essentials you need:

sudo apt install -y curl git build-essential unzip

Configuration

WSL has two config files that control different things.

`.wslconfig` - Windows-side limits

Controls resources WSL2 allocates from Windows. Create or edit C:\Users\<your-username>\.wslconfig:

[wsl2]
memory=8GB
processors=4
swap=2GB

By default WSL2 can use up to 50% of system RAM and all CPU cores. On a machine shared with other workloads, it’s worth capping this.

After editing, restart WSL for changes to take effect:

wsl --shutdown

`wsl.conf` - distro-side settings

Controls behaviour inside the distro. Create or edit /etc/wsl.conf inside WSL:

sudo nano /etc/wsl.conf

Useful options:

[boot]
systemd=true

[automount]
enabled=true
options="metadata"

[network]
hostname=my-dev-box
generateResolvConf=true

[user]
default=myusername

systemd=true - enables systemd, needed for Docker Engine, services, etc.
automount options="metadata" - lets you set Linux file permissions on Windows-mounted drives
hostname - sets the hostname inside WSL (useful to distinguish from the Windows host)
user.default - the user WSL drops you into on launch

Restart WSL after saving:

wsl --shutdown

Useful WSL commands

# List installed distros and their state
wsl --list --verbose

# Stop all running distros
wsl --shutdown

# Stop a specific distro
wsl --terminate Ubuntu

# Set a different distro as default
wsl --set-default Debian

# Run a command directly without entering the shell
wsl ls -la /home/myusername

# Export a distro to a backup file
wsl --export Ubuntu ubuntu-backup.tar

# Import from backup
wsl --import Ubuntu C:\WSL\Ubuntu ubuntu-backup.tar --version 2

Corporate proxy

If you’re on a corporate network, WSL2’s outbound connections go through a virtual network adapter that often doesn’t inherit Windows proxy settings. Here’s what to configure.

Shell environment

Open ~/.bashrc (or ~/.zshrc if you use zsh):

nano ~/.bashrc

Add the proxy variables:

export HTTP_PROXY="http://proxy.your-company.com:8080"
export HTTPS_PROXY="http://proxy.your-company.com:8080"
export NO_PROXY="localhost,127.0.0.1,169.254.0.0/16,10.0.0.0/8"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export no_proxy="$NO_PROXY"

Reload the shell:

source ~/.bashrc

apt

Create /etc/apt/apt.conf.d/proxy.conf:

sudo nano /etc/apt/apt.conf.d/proxy.conf

Add the proxy config:

Acquire::http::Proxy "http://proxy.your-company.com:8080";
Acquire::https::Proxy "http://proxy.your-company.com:8080";

Test:

sudo apt update

curl and wget

curl and wget pick up HTTP_PROXY/HTTPS_PROXY from the environment automatically once the shell variables are set above. No extra config needed.

git

git config --global http.proxy http://proxy.your-company.com:8080
git config --global https.proxy http://proxy.your-company.com:8080

To unset if you move off the corporate network:

git config --global --unset http.proxy
git config --global --unset https.proxy

Keeping WSL updated

The WSL platform itself (separate from the distro) updates via Windows Update or manually:

wsl --update

The distro packages update via apt inside WSL as usual. There’s no automatic update mechanism for the distro - run sudo apt update && sudo apt upgrade periodically.

Notes

WSL2 uses a real Linux kernel running in a lightweight VM - this is why it needs a virtual network adapter, which is the root cause of most proxy and connectivity issues on corporate networks.
Windows Firewall rules apply to WSL2 traffic. If a connection is blocked for no obvious reason, check Windows Defender Firewall inbound/outbound rules.
VPNs are a common cause of WSL2 connectivity failures. Many corporate VPN clients replace or restrict the virtual network adapter WSL2 uses. Disconnecting the VPN is usually the fastest way to confirm this is the cause.
File I/O is significantly faster when working inside the Linux filesystem (/home/...) vs on the Windows mount (/mnt/c/...). Keep project files in the Linux filesystem if performance matters.
Once WSL2 is set up, AWS Kiro CLI installs directly via its Linux/WSL2 package - no separate Windows setup needed.

Connect to AWS SSO and SSH into EC2 Instance

Mon, 15 Jul 2024 00:00:00 +0000

Two paths depending on your setup - follow one:

Without SSO: personal AWS account, direct IAM credentials
With SSO: enterprise/team setup with an SSO start URL (e.g. https://company.awsapps.com/start)

Prerequisites

Without SSO:

AWS CLI v2
AWS IAM user credentials (Access Key ID and Secret Access Key)
Terminal

With SSO:

AWS CLI v2
AWS SSO start URL and access
Terminal

Files you will need

~/
├── .aws/
│   ├── config
│   └── credentials
└── .ssh/
    ├── ec2-key.pem
    └── config

Path A: Without SSO

Create .aws folder if it doesn’t exist. Run from your home directory (~).

mkdir -p ~/.aws

Create ~/.aws/credentials.

[default]
aws_access_key_id = YOUR_ACCESS_KEY_ID
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY

Create ~/.aws/config.

[default]
region = ap-southeast-2
output = json

Test your config.

aws sts get-caller-identity

Path B: With SSO

Add a profile block to ~/.aws/config for each environment (e.g. aws-dev, aws-prod):

[profile aws-prod]
sso_session = aws-prod
sso_account_id = 123456789123
sso_role_name = aws-prod-SystemAdmin
region = ap-southeast-4
output = json
credential_process = aws configure export-credentials --profile aws-prod

Sample .aws folder structure:

Setup SSH config

Download the .pem keypair when launching the EC2 instance and move it here.

mkdir -p ~/.ssh
mv ~/Downloads/ec2-prod.pem ~/.ssh/ec2-prod.pem
chmod 400 ~/.ssh/ec2-prod.pem

Basic SSH config (no SSO)

Add to ~/.ssh/config:

Host ec2-prod
    HostName 1.2.3.4             # Replace with your EC2's public IP
    User ec2-user                # Use 'ubuntu' for Ubuntu instances
    IdentityFile ~/.ssh/ec2-prod.pem

SSO ProxyCommand config

Use this if connecting via AWS SSM Session Manager with an SSO profile. Add to ~/.ssh/config (or a separate file under ~/.ssh/config.d/):

Host ec2-prod
  User ec2-user
  IdentityFile ~/.ssh/ec2-prod.pem
  ProxyCommand aws ssm start-session --target i-01xyz7659824a123q --profile aws-prod --document-name AWS-StartSSHSession --parameters portNumber=22

Sample .ssh folder structure:

Connect

If using SSO, log in first:

aws sso login --profile aws-prod

Then SSH in:

ssh ec2-prod

CI-CD on Bastab C - Notes to Self

DevSecOps Guardrails - Series Overview

The series

Chapter 1 - Policy Checks with cdk-nag

Chapter 2 - Template Linting with cfn-lint (coming soon)

Chapter 3 - Static Analysis with SonarQube (coming soon)

Chapter 4 - Dependency Scanning with OWASP (coming soon)

Notes

AWS Well-Architected Framework - Series Overview

The six pillars

The series

Chapter 1 - The Well-Architected Tool

Chapter 2 - The Six Pillars

Chapter 3 - Operational Excellence Pillar

Chapter 4 - Security Pillar

Chapter 5 - Reliability Pillar

Chapter 6 - Performance Efficiency Pillar

Chapter 7 - Cost Optimization Pillar

Chapter 8 - Sustainability Pillar

Chapter 9 - Lenses

Notes

Infrastructure as Code with AWS CDK - Series Overview

Why CDK over CloudFormation for AWS-native workloads?

Why CDK over Terraform for AWS-native workloads?

Use case

The series

Chapter 1 - Project Setup and Bootstrapping

Chapter 2 - Managing Configuration and Context

Chapter 3 - Writing and Sharing Constructs

Chapter 4 - Testing CDK Stacks

Chapter 5 - CI/CD Pipelines

Notes

AWS Certified AI Practitioner (AIF-C01) Study Notes

The exam at a glance

Where I wrote this up

The five domains

Domain 1 - Fundamentals of AI and ML (20%)

Domain 2 - Fundamentals of Generative AI (24%)

Domain 3 - Applications of Foundation Models (28%)

Domain 4 - Guidelines for Responsible AI (14%)

Domain 5 - Security, Compliance, and Governance for AI Solutions (14%)

Services to know well

Easy things to mix up

Resources

Essential

Useful

Skip if you are tight on time

Notes

AWS Kiro CLI - Manage AWS Infrastructure from the Terminal

Install

Authenticate

Key commands

Infrastructure workflows

Notes

AWS Certified Developer Associate (DVA-C02) Study Notes

The exam at a glance

The four domains

Domain 1 - Development with AWS Services (32%)

Domain 2 - Security (26%)

Domain 3 - Deployment (24%)

Domain 4 - Troubleshooting and Optimization (18%)

Services to know well

Easy things to mix up

Resources

Essential

Useful

Skip if you are tight on time

Notes

GitHub PR Fix: "Commits must have verified signatures"

Problem

Root cause

Steps to fix

1. Identify unsigned commits

2. Re-sign all branch commits using filter-branch

3. Verify no unsigned commits remain

4. Force push

5. Update local tracking ref (if GitHub Desktop shows stale state)

Notes

Configure GitHub Copilot Custom Instructions

1. Create the repo-wide file

Static config (`cdk.json`)