Cargando...
Cargando...
Choose your weapon wisely — the definitive Infrastructure-as-Code decision guide for AWS practitioners and certification candidates
Same goal, radically different developer experience and operational model
| Feature | CloudFormation Native AWS IaC, no code required | CDK Code-first IaC, compiles to CloudFormation | Terraform (on AWS) Multi-cloud IaC, HCL-based open standard |
|---|---|---|---|
Authoring Language CDK synthesizes (cdk synth) to CloudFormation templates under the hood — understanding this pipeline is critical for DOP-C02 and DVA-C02. | JSON or YAML (declarative templates) | TypeScript, Python, Java, Go, C#, JavaScript (general-purpose programming languages) | HCL (HashiCorp Configuration Language) — purpose-built declarative DSL |
State Management Terraform state file stored in S3 with DynamoDB locking is a classic SAP-C02 and DOP-C02 architecture pattern. CloudFormation's managed state is a key differentiator — no risk of state drift from lost files. | AWS-managed state stored natively in the CloudFormation service — no external state file needed | Delegates to CloudFormation — state is managed by CloudFormation (CDK itself is stateless) | Developer-managed state file (terraform.tfstate) — must be stored remotely (e.g., S3 + DynamoDB for locking) for team use |
Multi-Cloud / Hybrid Support If an exam scenario mentions managing infrastructure across AWS AND another cloud provider (Azure, GCP), Terraform is almost always the correct answer. | AWS-only (can manage some third-party resources via CloudFormation Registry extensions, but fundamentally AWS-centric) | AWS-only natively; CDK for Terraform (cdktf) exists as a separate project for multi-cloud | True multi-cloud — manages AWS, Azure, GCP, on-premises, SaaS resources from a single codebase |
AWS Native Integration For exam questions about 'newest AWS service support' or 'tightest AWS integration', CloudFormation wins. CDK is a close second since it compiles to CloudFormation. | Deepest AWS integration — new AWS services get CloudFormation support at or near launch, IAM integration built-in, free drift detection, rollback, change sets | Excellent — inherits all CloudFormation integrations plus higher-level constructs (L2/L3) that encode AWS best practices | Good but lags — AWS provider updates may trail new service launches; relies on community/HashiCorp to publish new resource types |
Abstraction Level / Reusability CDK Constructs (L1/L2/L3) are tested in DVA-C02. L3 constructs (aws-solutions-constructs) encode complete multi-service patterns like API Gateway + Lambda + DynamoDB in a few lines. | Low-to-medium — Modules, Nested Stacks, StackSets for reuse; verbose for complex patterns | Highest — L1 (CloudFormation resource wrappers), L2 (opinionated constructs), L3 (Patterns/Solutions constructs); full OOP inheritance, loops, conditionals in real code | Medium-high — Modules for reuse; supports loops (count, for_each), conditionals; Terraform Registry for community modules |
Drift Detection CloudFormation drift detection is free and native. For DOP-C02, know that AWS Config + CloudFormation drift detection together provide comprehensive compliance monitoring. | Built-in native drift detection — detects when actual resource configuration differs from template; free | Inherits CloudFormation drift detection (CDK deploys via CloudFormation stacks) | terraform plan shows drift; terraform refresh reconciles state; no automatic scheduled drift detection — must be triggered manually or via CI/CD |
Rollback Behavior CloudFormation's automatic rollback on failure is a critical exam differentiator. Terraform's lack of automatic rollback is a known limitation tested in DOP-C02 scenarios. | Automatic rollback on failure (configurable); stack rollback triggers; can disable rollback for debugging; supports rollback triggers with CloudWatch alarms | Inherits CloudFormation rollback behavior exactly | No automatic rollback — partial applies leave infrastructure in intermediate state; must plan and apply again to fix; requires careful error handling |
Change Preview / Plan Terraform's plan/apply workflow is considered the gold standard for change preview. CloudFormation Change Sets are the equivalent — know both for DOP-C02. | Change Sets — preview proposed changes before execution; shows add/modify/remove actions | cdk diff — shows logical changes; cdk deploy creates a Change Set under the hood | terraform plan — industry-leading change preview; shows exact resource additions, modifications, destructions with color coding; saved plan files for approval workflows |
Pricing Model All three tools are free at the IaC layer — you pay for AWS resources. This is a common trap: candidates think CDK or CloudFormation has per-API-call charges. It does NOT. | Free for CloudFormation service itself — you pay only for AWS resources provisioned. Exception: CloudFormation hooks may incur costs for third-party extensions | Free — CDK is an open-source SDK; costs only for the CloudFormation stacks it creates and AWS resources provisioned | Open-source Terraform CLI is free; HCP Terraform (formerly Terraform Cloud) has paid tiers; AWS charges only for provisioned resources |
StackSets / Multi-Account / Multi-Region CloudFormation StackSets with AWS Organizations SERVICE_MANAGED permission model is heavily tested in SAP-C02 and DOP-C02. Know the SELF_MANAGED vs SERVICE_MANAGED deployment models. | Native StackSets — deploy stacks across multiple accounts and regions from a single operation; integrates with AWS Organizations for automatic deployment to new accounts | CDK Pipelines + CDK StackSets construct available; can deploy to multiple accounts/regions but requires more setup than native StackSets | Requires provider aliases and workspace configurations; no native equivalent to StackSets; third-party tooling (Terragrunt, Atlantis) often used for multi-account |
Custom Resources / Extensibility CloudFormation Custom Resources backed by Lambda are heavily tested. Know the response URL pattern (pre-signed S3 URL for async responses) and the 4,096-byte response limit. | Custom Resources (Lambda-backed or SNS-backed), CloudFormation Registry (resource types, modules, hooks), Macros (template transforms) | Custom Resources via AwsCustomResource construct; can call any AWS API; also supports CloudFormation custom resources underneath | null_resource, external data source, local-exec/remote-exec provisioners; custom providers via Go SDK; very extensible |
Secret / Sensitive Value Handling Terraform's state file plaintext secret storage is a major SCS-C02 exam topic. Always encrypt the S3 state bucket and restrict access. CloudFormation dynamic references never expose secrets in templates. | Dynamic references to SSM Parameter Store ({{resolve:ssm:...}}) and Secrets Manager ({{resolve:secretsmanager:...}}); NoEcho for parameter masking | Same dynamic references available; SecretValue class for CDK-level handling; integrates with Secrets Manager natively | Sensitive values marked with sensitive = true; state file stores secrets in plaintext — S3 encryption + strict IAM on state bucket is critical; aws_secretsmanager_secret data source |
Testing & Validation CDK's ability to write real unit tests against infrastructure code is a key selling point tested in DVA-C02. You can assert that a synthesized stack contains specific resources and properties. | cfn-lint (linting), cfn-guard (policy-as-code validation), taskcat (multi-region testing); CloudFormation Hooks for pre/post deployment validation | Full unit testing with Jest/pytest/JUnit on synthesized CloudFormation templates; assertions library (aws-cdk-lib/assertions); cdk synth for synthesis validation | terraform validate, terraform fmt; Terratest (Go-based integration testing); Checkov/tfsec for security scanning; OPA (Open Policy Agent) for policy enforcement |
Learning Curve Exam scenarios about 'developer productivity' and 'familiar programming languages' point to CDK. Scenarios about 'operations teams with no coding background' may favor CloudFormation or Terraform. | Medium — JSON/YAML is accessible but verbose; intrinsic functions (Fn::Sub, Fn::If, Ref, !GetAtt) require study; large templates become unwieldy | Medium-High initially — requires programming language knowledge; lower long-term for developers already fluent in Python/TypeScript | Medium — HCL is purpose-built and readable; strong community resources; concepts like state, workspaces, providers require understanding |
CI/CD Integration CDK Pipelines (self-mutating) is tested in DOP-C02. The pipeline updates itself when you add new stages — a key feature. CloudFormation has native CodePipeline integration with CloudFormationCreateUpdateStackAction. | Native with AWS CodePipeline (CloudFormation deploy action); AWS SAM CLI for serverless; AWS CodeBuild for validation | CDK Pipelines (self-mutating pipeline construct) is the recommended pattern; integrates with CodePipeline natively; cdk deploy in any CI system | HCP Terraform for VCS-driven runs; integrates with any CI/CD (GitHub Actions, Jenkins, GitLab CI); no native AWS pipeline action (use script steps) |
Import Existing Resources Terraform's import capability is more mature. CloudFormation resource import is available but has limitations. Both are tested in migration scenarios on SAP-C02. | CloudFormation Import — bring existing resources under stack management; supports most resource types; requires resource identifier | Uses CloudFormation import underneath; CDK migrate command (preview) can generate CDK code from existing CloudFormation stacks | terraform import — mature feature; imports existing resources into state; terraform import block (v1.5+) for declarative imports; strong support |
Template/Config Size Limits CloudFormation's 500-resource-per-stack limit is CRITICAL for SAP-C02 and DOP-C02. Solution: Nested Stacks or StackSets. CDK inherits this same limit — a common trap. | Template body: 51,200 bytes (direct); 1 MB (S3); Stack: 500 resources max; 200 outputs max; 200 parameters max; 200 mappings max; 60 dynamic references per template | CDK app itself has no size limit; synthesized CloudFormation template inherits all CloudFormation limits (500 resources, 1 MB S3 template, etc.) | No hard template size limits; practical limits based on provider API rate limits and state file size; large state files (millions of resources) can slow operations |
Summary
CloudFormation is the AWS-native choice offering the deepest integration, managed state, automatic rollback, and StackSets for multi-account governance — ideal for AWS-only environments and operations teams. CDK is the developer-first choice that compiles to CloudFormation, enabling full programming language power (loops, OOP, testing) while inheriting all CloudFormation benefits — ideal for development teams who think in code. Terraform wins for multi-cloud environments, organizations standardizing across cloud providers, and teams that prefer HCL's explicit, readable syntax with mature import and plan capabilities.
🎯 Decision Tree
If multi-cloud or non-AWS resources needed → Terraform | If AWS-only + developers prefer real programming languages + want unit testing → CDK | If AWS-only + operations team + maximum AWS integration + StackSets for Organizations → CloudFormation | If question mentions 'compiles to CloudFormation' or 'synthesizes' → CDK | If question mentions 'state file' or 'remote state' or 'state locking' → Terraform | If question mentions 'Change Sets' or 'drift detection' (native) → CloudFormation | If question mentions 'multi-account deployment' with Organizations → CloudFormation StackSets
CDK synthesizes (compiles) to CloudFormation templates — it is NOT a separate IaC engine. Every CDK deployment creates/updates a CloudFormation stack. This means CDK inherits ALL CloudFormation limits including the 500-resource-per-stack limit. When a question asks what CDK uses 'under the hood', the answer is always CloudFormation.
Terraform's state file is the #1 security risk in IaC on AWS. The tfstate file stores ALL resource attributes including secrets in plaintext JSON. For SCS-C02 and DOP-C02: always store state in S3 with SSE-KMS encryption, enable versioning, restrict IAM access, and use DynamoDB for state locking to prevent concurrent modifications.
CloudFormation StackSets with SERVICE_MANAGED permissions (using AWS Organizations) automatically deploy to new accounts added to an OU — no manual intervention. SELF_MANAGED requires explicit administrator/target account role setup. SAP-C02 loves scenarios where a new account must automatically get baseline infrastructure — answer is SERVICE_MANAGED StackSets.
CloudFormation Custom Resource responses are limited to 4,096 bytes AND must be sent to a pre-signed S3 URL (the ResponseURL in the event). If the Lambda function fails to send a response (timeout, error), the stack will hang until the default timeout (1 hour for custom resources). Always implement error handling and always call cfnresponse.send() in finally blocks.
CloudFormation Change Sets let you preview changes BEFORE applying them — analogous to Terraform's 'terraform plan'. The key difference: CloudFormation Change Sets are stored and can be reviewed/approved asynchronously, while Terraform plan output is ephemeral unless saved with -out flag. For approval workflows in CodePipeline, use the 'Create Change Set' + 'Execute Change Set' two-step action pattern.
When a CloudFormation stack is in UPDATE_ROLLBACK_FAILED state, you cannot update or delete it normally. You must use ContinueUpdateRollback API (or console option) and optionally skip specific resources causing the rollback failure. This is a common DOP-C02 troubleshooting scenario.
CloudFormation dynamic references ({{resolve:ssm:...}} and {{resolve:secretsmanager:...}}) are resolved AT DEPLOY TIME, not at template authoring time. This means the actual secret value never appears in the template itself — critical for compliance. The 60 dynamic references per template limit applies to the combined total of all dynamic reference types.
For multi-cloud IaC, Terraform is always the answer. If the scenario mentions AWS + Azure, AWS + GCP, AWS + on-premises non-AWS resources in a unified IaC workflow — choose Terraform. CloudFormation and CDK are AWS-only tools.
The #1 certification trap: Assuming CDK is independent of CloudFormation. CDK synthesizes to CloudFormation templates — it inherits the 500-resource-per-stack limit, all CloudFormation quotas, and deploys via CloudFormation stacks. A close second trap: Terraform state file security — candidates forget that tfstate stores plaintext secrets and that S3 encryption + DynamoDB locking is required for production use.
CertAI Tutor · SAP-C02, DOP-C02, DVA-C02, SAA-C03, DEA-C01, SCS-C02, CLF-C02 · 2026-02-22
Services
Guides & Patterns