AWS Monitoring & Management
CloudFormation
Infrastructure as Code using JSON or YAML templates to provision AWS resources
AWS CloudFormation is the native Infrastructure as Code (IaC) service for AWS, allowing you to define your entire infrastructure in JSON or YAML templates and provision it as repeatable stacks. It handles dependency ordering, rollbacks on failure, and drift detection - making it the foundation for consistent, auditable infrastructure deployments across environments.
How CloudFormation Processes Templates and Manages Stacks
A CloudFormation template is a declarative document describing the desired end state of your infrastructure. When you create or update a stack, CloudFormation builds a dependency graph from resource references (Ref, Fn::GetAtt, DependsOn), determines the correct creation order, and calls AWS service APIs on your behalf.
| Template Section | Required? | Purpose |
|---|---|---|
| AWSTemplateFormatVersion | No | Template version (always "2010-09-09" if used) |
| Description | No | Human-readable description of the template |
| Parameters | No | Input values passed at stack creation/update |
| Mappings | No | Static lookup tables (e.g., AMI IDs per region) |
| Conditions | No | Conditional logic based on parameter values |
| Resources | Yes | AWS resources to create - the only required section |
| Outputs | No | Values to export for cross-stack references or display |
Stack updates go through a change set: CloudFormation computes the diff between the current deployed state and the new template, classifies each change (Add, Modify, Remove), and shows whether modifications require replacement (resource will be deleted and recreated) or can be done in-place.
Resource replacement is destructive. If you rename a resource in a template or change a property that requires replacement (like an RDS engine version), CloudFormation will delete the old resource and create a new one. Always review change sets before executing updates in production.
# Minimal CloudFormation template
AWSTemplateFormatVersion: "2010-09-09"
Description: Simple S3 bucket example
Parameters:
BucketNameSuffix:
Type: String
Description: Suffix appended to bucket name for uniqueness
Resources:
MyBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub "my-app-${BucketNameSuffix}"
VersioningConfiguration:
Status: Enabled
Outputs:
BucketArn:
Value: !GetAtt MyBucket.Arn
Export:
Name: !Sub "${AWS::StackName}-BucketArn"Rollback Behavior, Stack Policies, and Deletion Protection
CloudFormation automatically rolls back a stack to the last stable state if a resource creation fails during a new stack creation. For stack updates, the rollback behavior is configurable.
| Scenario | Default Behavior | How to Change |
|---|---|---|
| Stack creation failure | Rollback and delete all resources | Use --disable-rollback for debugging |
| Stack update failure | Rollback to previous stable state | Set rollback config with monitoring alarm |
| Rollback itself fails | Stack enters UPDATE_ROLLBACK_FAILED state | Use ContinueUpdateRollback API to retry |
| Accidental stack deletion | No protection by default | Enable termination protection on the stack |
Stack policies prevent unintended updates to critical resources. A stack policy is a JSON document that denies update actions on specified resources. Once set, it cannot be deleted (only replaced), and any update must explicitly override it.
Enable termination protection on every production stack. It takes one extra API call to disable before a delete, which is exactly the friction you want to prevent accidental teardowns.
# Enable termination protection
aws cloudformation update-termination-protection \
--stack-name my-prod-stack \
--enable-termination-protection
# Preview a change set before applying
aws cloudformation create-change-set \
--stack-name my-prod-stack \
--template-body file://template.yaml \
--change-set-name preview-v2 \
--parameters ParameterKey=Env,ParameterValue=prod
aws cloudformation describe-change-set \
--stack-name my-prod-stack \
--change-set-name preview-v2Nested Stacks, StackSets, and Cross-Stack References
As infrastructure grows, a single template becomes unmanageable. CloudFormation provides three mechanisms for decomposition and multi-account/multi-region deployment:
| Pattern | How It Works | Best For |
|---|---|---|
| Nested stacks | Parent template includes AWS::CloudFormation::Stack resource referencing a child template URL | Reusing modular templates within one account/region |
| Cross-stack references | Stack A exports output; Stack B uses Fn::ImportValue | Sharing values between independently managed stacks |
| StackSets | Deploy one template to multiple accounts and regions simultaneously | Organization-wide baseline resources (IAM roles, CloudTrail, Config rules) |
Cross-stack references create a hard dependency: you cannot delete a stack that has outputs being imported by another stack. This is intentional - it prevents accidental deletion of shared infrastructure - but requires planning for decommissioning.
Nested stacks and cross-stack references are often confused in interviews. Key difference: nested stacks are part of the parent stack lifecycle (updating the parent can update children). Cross-stack references are independent stacks that only share values - they have separate lifecycles.
StackSets require a delegated admin account or use of the Organizations service principal. They support two deployment models: SERVICE_MANAGED (Organizations manages accounts) and SELF_MANAGED (you specify account IDs and assume roles manually).
Custom Resources, CloudFormation Macros, and CDK
Custom Resources let you run arbitrary Lambda code during stack create, update, and delete operations. This enables managing resources that don't have native CloudFormation support, or running configuration tasks as part of a deployment.
The Lambda function receives a cfn-response call contract: it must send a SUCCESS or FAILED signal back to CloudFormation's pre-signed S3 URL. If it does not respond within the timeout (up to 1 hour), the stack hangs.
Custom Resource Lambda functions that fail silently are a leading cause of stacks stuck in CREATE_IN_PROGRESS or DELETE_IN_PROGRESS for hours. Always wrap your Lambda handler in a try/catch and send cfn-response in the finally block.
CloudFormation Macros (Transform) let you preprocess templates before CloudFormation parses them. The most well-known macro is AWS::Serverless Transform (SAM), which expands shorthand serverless syntax into full CloudFormation resources.
AWS CDK (Cloud Development Kit) compiles high-level TypeScript, Python, or Java code into CloudFormation templates. CDK is now the recommended approach for complex infrastructure - it brings type safety, loops, and abstractions that are impossible in raw YAML. The output is still CloudFormation under the hood.
| Approach | Language | Abstraction Level | Best For |
|---|---|---|---|
| Raw CloudFormation | JSON/YAML | Resource-level | Simple stacks, learning |
| SAM | YAML with Transform | Serverless-focused | Lambda + API Gateway + DynamoDB apps |
| CDK (L1) | TypeScript/Python/etc | Direct CloudFormation resource | Full control with type safety |
| CDK (L2/L3) | TypeScript/Python/etc | High-level constructs | Opinionated, batteries-included patterns |
| Terraform | HCL | Provider-agnostic | Multi-cloud, existing Terraform teams |
Drift Detection, cfn-guard, and Compliance
Drift detection identifies resources whose actual configuration has diverged from the CloudFormation template. This happens when someone makes manual changes to a resource outside of CloudFormation (via the console or CLI).
# Initiate drift detection on a stack
aws cloudformation detect-stack-drift \
--stack-name my-prod-stack
# Check drift detection status
aws cloudformation describe-stack-drift-detection-status \
--stack-drift-detection-id <detection-id>
# View drifted resources
aws cloudformation describe-stack-resource-drifts \
--stack-name my-prod-stack \
--stack-resource-drift-status-filters MODIFIED DELETEDcfn-guard is an open-source policy-as-code tool that validates CloudFormation templates against rules before deployment. It integrates with CI/CD pipelines to catch misconfigurations like public S3 buckets or unencrypted RDS instances before they reach production.
Drift detection does not auto-remediate. It only reports differences. To remediate drift, you either update the template to match the actual state (codify the manual change) or import the changed resource and re-apply the template. The correct approach depends on whether the manual change was intentional.
Interview Focus Points
- 1What is the difference between a CloudFormation change set and a stack update - why would you use a change set?
- 2Explain what resource replacement means in CloudFormation and give an example of a property change that triggers it.
- 3How do nested stacks differ from cross-stack references - what are the tradeoffs of each?
- 4How would you deploy a baseline security configuration to 200 AWS accounts using CloudFormation?
- 5What happens when a Custom Resource Lambda function times out or does not send a response?
- 6How does CDK differ from raw CloudFormation - what does CDK actually produce?
- 7How do you handle secrets and sensitive values in CloudFormation templates without hardcoding them?
- 8What is CloudFormation drift, when does it occur, and how do you remediate it?
- 9Compare CloudFormation and Terraform - when would you choose one over the other?