Ace Cloud Interviews
Home/AWS Tutorial/CloudFormation
📊

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 SectionRequired?Purpose
AWSTemplateFormatVersionNoTemplate version (always "2010-09-09" if used)
DescriptionNoHuman-readable description of the template
ParametersNoInput values passed at stack creation/update
MappingsNoStatic lookup tables (e.g., AMI IDs per region)
ConditionsNoConditional logic based on parameter values
ResourcesYesAWS resources to create - the only required section
OutputsNoValues 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.

yaml
# 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.

ScenarioDefault BehaviorHow to Change
Stack creation failureRollback and delete all resourcesUse --disable-rollback for debugging
Stack update failureRollback to previous stable stateSet rollback config with monitoring alarm
Rollback itself failsStack enters UPDATE_ROLLBACK_FAILED stateUse ContinueUpdateRollback API to retry
Accidental stack deletionNo protection by defaultEnable 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.

bash
# 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-v2

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

PatternHow It WorksBest For
Nested stacksParent template includes AWS::CloudFormation::Stack resource referencing a child template URLReusing modular templates within one account/region
Cross-stack referencesStack A exports output; Stack B uses Fn::ImportValueSharing values between independently managed stacks
StackSetsDeploy one template to multiple accounts and regions simultaneouslyOrganization-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.

ApproachLanguageAbstraction LevelBest For
Raw CloudFormationJSON/YAMLResource-levelSimple stacks, learning
SAMYAML with TransformServerless-focusedLambda + API Gateway + DynamoDB apps
CDK (L1)TypeScript/Python/etcDirect CloudFormation resourceFull control with type safety
CDK (L2/L3)TypeScript/Python/etcHigh-level constructsOpinionated, batteries-included patterns
TerraformHCLProvider-agnosticMulti-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).

bash
# 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 DELETED

cfn-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?