Cargando...
Cargando...
Define cloud infrastructure using familiar programming languages — CDK synthesizes to CloudFormation so you ship faster with less YAML
AWS Cloud Development Kit (CDK) is an open-source software development framework that lets you define AWS infrastructure using TypeScript, Python, Java, C#, or Go. CDK apps synthesize into CloudFormation templates offline — no AWS API calls happen during synthesis. At deploy time, CDK uses CloudFormation under the hood, giving you all the safety of stack-based deployments with the expressiveness of a real programming language.
Eliminate CloudFormation verbosity by expressing infrastructure as typed, testable, reusable code constructs while retaining CloudFormation's deployment safety and rollback guarantees
Use When
Avoid When
Multi-language support via JSII
TypeScript core is transpiled to Python, Java, C#, Go via JSII — write once, publish to all languages
cdk synth (offline synthesis)
Generates CloudFormation templates locally without making live AWS API calls — critical exam distinction
cdk deploy
Synthesizes then calls CloudFormation CreateChangeSet + ExecuteChangeSet under the hood
cdk diff
Compares local synthesized template against deployed stack — uses CloudFormation GetTemplate
CDK Pipelines (self-mutating CI/CD)
Built on CodePipeline; pipeline updates itself before deploying application stages — no manual pipeline updates needed
CDK Bootstrapping (cdk bootstrap)
Required before first deploy to any account/region; provisions S3 bucket, ECR repo, and IAM roles
Aspects (policy-as-code)
Apply transformations or validations across all constructs in a scope — used for tagging, compliance checks
Escape hatch to raw CloudFormation
Use L1 (Cfn*) constructs or cfnOptions to override any synthesized CloudFormation property
Unit testing with assertions library
aws-cdk-lib/assertions lets you test synthesized templates with hasResourceProperties, resourceCountIs, etc.
Context values and cdk.json
Runtime context can be passed via --context flag or cdk.json; used for environment-specific configuration
Custom Resources via CDK
CDK provides aws-cdk-lib/custom-resources with Provider framework to wrap Lambda-backed Custom Resources cleanly
Cross-stack references
CDK automatically creates CloudFormation Exports/Imports for cross-stack references within the same app
Cross-account/region deployments
Use Environment (account, region) on stacks; requires bootstrap in each target account/region
Hot-swap deployments (cdk deploy --hotswap)
Bypasses CloudFormation for supported resources (Lambda, ECS) during development — NOT for production use
CDK Watch (cdk watch)
Monitors code changes and automatically hot-swaps or deploys — development workflow only
CDK-to-CloudFormation synthesis and deployment
high freqCDK is a CloudFormation generator — cdk synth produces CloudFormation templates, cdk deploy calls CloudFormation APIs. Every CDK stack IS a CloudFormation stack. Understanding this relationship is foundational: CloudFormation limits, drift detection, stack policies, and rollback behaviors all apply to CDK deployments.
Inline code, asset bundling, and NodejsFunction/PythonFunction constructs
high freqCDK's aws-lambda-nodejs.NodejsFunction and aws-lambda-python.PythonFunction constructs automatically bundle and package Lambda code using esbuild or Docker. Lambda assets are uploaded to the CDK bootstrap S3 bucket during cdk deploy. This is one of the most common CDK patterns in exam scenarios.
S3 bucket construct with enforced security defaults
high freqCDK's L2 s3.Bucket construct applies secure defaults (block public access, versioning options, encryption) that raw CloudFormation CfnBucket does not. Exam questions test whether candidates know CDK L2 constructs add opinionated defaults beyond the raw CloudFormation resource.
Managed encryption key integration across constructs
high freqCDK L2 constructs (S3, DynamoDB, SQS, SNS, etc.) accept an encryptionKey prop to pass a kms.Key construct. CDK automatically adds the necessary key policy statements — a major advantage over manually writing KMS key policies in CloudFormation. Critical misconception area: CDK synthesis does NOT rotate keys or re-encrypt data.
CDK Pipelines — self-mutating CI/CD pipeline
high freqCDK Pipelines is a high-level construct built on CodePipeline that creates a pipeline which updates itself before deploying application stages. The pipeline runs cdk synth in CodeBuild, then deploys stacks. This is the canonical CDK CI/CD pattern tested in DOP-C02 and DVA-C02.
DynamoDB table with GSI, billing mode, and stream configuration
medium freqCDK's dynamodb.Table L2 construct simplifies GSI creation, billing mode switching (PAY_PER_REQUEST vs PROVISIONED), and DynamoDB Streams configuration. Exam scenarios test whether candidates can identify CDK as the right tool for repeatable, environment-specific DynamoDB table definitions.
Render farm infrastructure provisioning
low freqAWS Deadline Cloud uses CDK constructs for provisioning render farm infrastructure including worker fleets, queues, and storage. This is a niche but listed integration in exam blueprints — know that CDK can provision Deadline Cloud resources as construct-based infrastructure.
cdk synth is OFFLINE — it generates CloudFormation templates without making any live AWS API calls. If a question asks what happens during synthesis, no AWS resources are created or queried. Actual deployment happens during cdk deploy via CloudFormation.
CDK is NOT a replacement for CloudFormation — it IS CloudFormation. Every CDK stack becomes a CloudFormation stack. All CloudFormation limits (500 resources/stack, 200 stacks/account/region, template size limits) apply to CDK deployments. Never treat them as separate systems.
Know the three construct levels cold: L1 (CfnBucket — 1:1 CloudFormation, no defaults), L2 (Bucket — curated, adds security defaults and helper methods), L3 (patterns like ApplicationLoadBalancedFargateService — opinionated multi-resource patterns). Exam questions present scenarios and ask which level is appropriate.
cdk synth is OFFLINE — zero AWS API calls, zero resource creation. Only cdk deploy touches AWS (via CloudFormation). Any exam question about 'what happens during synthesis' = answer is nothing in AWS.
CDK IS CloudFormation — every CDK stack is a CloudFormation stack. All CFN limits, rollback behavior, drift detection, and StackSets apply. CDK adds developer productivity ON TOP of CloudFormation, not instead of it.
L2 constructs add opinionated SECURE DEFAULTS (e.g., S3 blocks public access, grantRead() generates least-privilege IAM). L1 constructs are raw CloudFormation with no added safety. Choose L2 for security-by-default scenarios.
cdk bootstrap is REQUIRED before first deploy to any account/region pair. It creates the CDKToolkit CloudFormation stack containing an S3 bucket (for large templates and assets) and ECR repository (for Docker image assets). Forgetting bootstrap in a new region is a common real-world and exam scenario.
CDK Aspects are the mechanism for policy-as-code across a CDK app. Use Aspects to enforce tagging, check for encryption, or apply compliance rules across all constructs in a scope. Exam questions about applying a policy change to ALL resources in a CDK app point to Aspects.
Cross-stack references in CDK automatically create CloudFormation Exports (SSM or CloudFormation Outputs) and Imports. This creates a hard dependency — you cannot delete the exporting stack while the importing stack exists. Exam questions test whether candidates understand this dependency behavior.
cdk deploy --hotswap and cdk watch BYPASS CloudFormation for supported resource types (Lambda functions, ECS service images, Step Functions state machines). These are development-only tools — exam questions will test that you know hotswap is NOT appropriate for production because it skips CloudFormation change sets and rollback safety.
CDK unit testing uses the aws-cdk-lib/assertions module. Key methods: Template.fromStack(stack), template.hasResourceProperties('AWS::S3::Bucket', {...}), template.resourceCountIs('AWS::Lambda::Function', 2). Exam questions on DVA-C02 and DOP-C02 ask how to test CDK infrastructure before deployment.
CDK Pipelines (pipelines.CodePipeline) is self-mutating — the pipeline updates its own definition before deploying application stages. This means you commit a change to the pipeline definition, push it, and the pipeline updates itself automatically. No manual pipeline reconfiguration needed.
When CDK needs to query live AWS state during synthesis (e.g., looking up VPC IDs, AMI IDs), it uses Context Providers. The first synth queries AWS and caches results in cdk.context.json. Subsequent synths use cached values. This is why synthesis can be done offline after the first run.
Common Mistake
CDK makes live AWS API calls during cdk synth to create or check resources
Correct
cdk synth is entirely offline — it executes your CDK app code in memory and produces CloudFormation JSON/YAML templates without contacting AWS. The only exception is Context Provider lookups (e.g., Vpc.fromLookup), which query AWS once and cache results in cdk.context.json. Resource creation only happens during cdk deploy via CloudFormation.
This is the #1 CDK misconception on exams. Questions will describe a scenario where a developer runs cdk synth and ask what AWS resources were created — the answer is none. Confusing boto3 (live SDK calls) with CDK synthesis (offline template generation) is explicitly listed as a top exam trap.
Common Mistake
CDK is an alternative to CloudFormation that works independently
Correct
CDK is a CloudFormation template generator. Every CDK stack IS a CloudFormation stack. CDK deploy calls CloudFormation's CreateChangeSet and ExecuteChangeSet APIs. All CloudFormation behaviors — rollback, drift detection, stack policies, resource limits, and StackSets — apply directly to CDK deployments. CDK adds developer productivity on top of CloudFormation, not instead of it.
Candidates who think CDK bypasses CloudFormation will get questions wrong about resource limits, rollback behavior, and what happens when a CDK deploy fails. The answer is always 'CloudFormation rolls back' not 'CDK rolls back'.
Common Mistake
CDK L2 constructs are just syntactic sugar with no behavioral differences from L1 (CfnBucket vs Bucket)
Correct
CDK L2 constructs apply opinionated, secure defaults that L1 constructs do NOT. For example, s3.Bucket (L2) blocks public access by default and can enforce SSL. CfnBucket (L1) maps directly to CloudFormation with no added defaults — public access is not blocked unless explicitly configured. L2 constructs also add helper methods like bucket.grantRead(lambdaFunction) that automatically generate correct IAM policies.
Exam questions present security scenarios asking which CDK construct level provides secure defaults out of the box. The answer is L2. Knowing that L2 adds behavioral defaults (not just syntax) is critical for security-focused questions on SAA-C03 and DOP-C02.
Common Mistake
You only need to run cdk bootstrap once per AWS account
Correct
CDK bootstrap must be run once per account per region. Each region gets its own CDKToolkit CloudFormation stack with its own S3 bucket and ECR repository. If you deploy a CDK app to us-east-1 and then to eu-west-1 for the first time, you must run cdk bootstrap aws://ACCOUNT-ID/eu-west-1 separately.
Multi-region deployment scenarios are common on DOP-C02 and DVA-C02. A question describing a CDK deploy failure in a new region almost always traces back to missing bootstrap.
Common Mistake
CDK and boto3 are equivalent tools — both can be used to provision AWS infrastructure programmatically
Correct
CDK synthesizes CloudFormation templates (declarative, state-managed, rollback-capable infrastructure). boto3 makes direct AWS API calls (imperative, no state management, no automatic rollback). CDK is for infrastructure provisioning with lifecycle management. boto3 is for application-level AWS service interactions. Mixing them up leads to wrong answers on questions about idempotency, rollback, and drift detection.
This misconception is explicitly called out in the exam question bank. A question might ask: 'A developer uses boto3 to create S3 buckets in a script vs a developer uses CDK to define S3 buckets — what is the key difference?' The answer centers on CloudFormation state management, rollback, and idempotency that CDK provides and boto3 does not.
Common Mistake
KMS key rotation configured in a CDK app re-encrypts existing data automatically when deployed
Correct
Enabling KMS key rotation (enableKeyRotation: true on a kms.Key construct) schedules AWS to rotate the KEY MATERIAL annually. Existing data is NOT re-encrypted. AWS KMS keeps all previous key versions and can decrypt data encrypted with any prior version. The key ID and ARN do NOT change after rotation. CDK simply sets the CloudFormation property — the actual rotation behavior is governed by KMS, not CDK.
This misconception appears directly in the exam question bank. Candidates confuse 'enabling rotation in CDK' with 'CDK will re-encrypt my data.' CDK only sets CloudFormation properties — it cannot and does not re-encrypt data at rest.
SYNTH = Static YAML/JSON, No Talking to Hosts — cdk synth never calls AWS
L1-L2-L3 ladder: L1=Low-level (CfnRaw), L2=Lovable defaults (secure), L3=Lego sets (full patterns)
CDK = CloudFormation Dressed up in Kotlin/Python/TypeScript — it's still CloudFormation underneath
BOOTSTRAP before DEPLOY, every Account every Region — BAD things happen if you skip it
Aspects = Apply to ALL — when you need a policy across every resource, reach for Aspects
CertAI Tutor · SAA-C03, DEA-C01, DOP-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns