Components — Deep Dive

The settings, functions, and CLI verbs that show up repeatedly inside scenario questions.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

Integrations & Architecture Example

Related Services

End-to-End Architecture Example

See 08 — Cross-Service Architectures for this pattern drawn out in full alongside four other realistic architectures, and 09 — Hands-On Lab to build a version of it yourself with sam deploy --guided and cdk deploy.

Best Practices & Common Exam Traps

When to Use Each Tool

CloudFormation vs SAM vs CDK

Common Exam Traps

Memory Anchors

Hands-On Lab

Three short, self-contained exercises that put the concepts from the other tabs under your fingers instead of just in your head — raw CloudFormation, then SAM, then CDK, all deploying to the same underlying engine. All commands target the eu-west-1 (Ireland) Region and use AWS CLI v2. Clean up each exercise's stack when you're done to avoid ongoing charges (the resources used here are all within the AWS Free Tier for light use, but SNS/S3 are not free to leave running indefinitely at scale).

Lab 1 — Raw CloudFormation: Deploy, Change Set, and a Real Rollback

Author a small template by hand, deploy it, preview a modification with a change set, then deliberately break an update so you can watch CloudFormation's automatic rollback happen in front of you.

mkdir cfn-lab && cd cfn-lab

Create template.yaml:

AWSTemplateFormatVersion: '2010-09-09'
Description: DVA-C02 Lab 1 - S3 bucket + SNS topic

Parameters:
  BucketNameSuffix:
    Type: String
    Description: Unique suffix to avoid global S3 name collisions

Resources:
  LabBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "dva-lab-${BucketNameSuffix}"
      VersioningConfiguration:
        Status: Enabled

  LabTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: dva-lab-topic
      DisplayName: DVA Lab Notifications

Outputs:
  BucketArn:
    Description: ARN of the lab bucket
    Value: !GetAtt LabBucket.Arn
  TopicArn:
    Description: ARN of the lab topic
    Value: !Ref LabTopic
    Export:
      Name: dva-lab-topic-arn

1. Deploy the stack for the first time using aws cloudformation deploy, which internally creates and executes a change set for you:

   aws cloudformation deploy \
     --region eu-west-1 \
     --template-file template.yaml \
     --stack-name dva-lab-1 \
     --parameter-overrides BucketNameSuffix=$(date +%s) \
     --capabilities CAPABILITY_NAMED_IAM

   Stack dva-lab-1 reaches CREATE_COMPLETE; the CLI prints "Successfully created/updated stack".
2. Confirm the outputs were populated:

   aws cloudformation describe-stacks \
     --region eu-west-1 \
     --stack-name dva-lab-1 \
     --query "Stacks[0].Outputs"

   A JSON array showing BucketArn and TopicArn with real ARN values.
3. Edit template.yaml: add a Tags block to LabTopic (e.g. Tags: [{Key: env, Value: lab}]), then create a change set manually instead of deploying directly:

   aws cloudformation create-change-set \
     --region eu-west-1 \
     --stack-name dva-lab-1 \
     --change-set-name add-tags-cs \
     --template-body file://template.yaml \
     --parameters ParameterKey=BucketNameSuffix,UsePreviousValue=true

   Change set is created in CREATE_PENDING then CREATE_COMPLETE status — nothing in the live stack has changed yet.
4. Review exactly what the change set will do before committing to it:

   aws cloudformation describe-change-set \
     --region eu-west-1 \
     --stack-name dva-lab-1 \
     --change-set-name add-tags-cs \
     --query "Changes[].ResourceChange.{Action:Action,Resource:LogicalResourceId,Replacement:Replacement}"

   Shows Action: Modify on LabTopic with Replacement: False — an in-place update, safe to execute.
5. Execute the change set:

   aws cloudformation execute-change-set \
     --region eu-west-1 \
     --stack-name dva-lab-1 \
     --change-set-name add-tags-cs

   Stack transitions through UPDATE_IN_PROGRESS to UPDATE_COMPLETE.
6. Now break it on purpose: edit template.yaml and set BucketName: !Sub "dva-lab-${BucketNameSuffix}" to a hardcoded name that already exists globally (e.g. reuse a well-known bucket name like aws-cloudtrail-logs-123456789012, which belongs to another account), then deploy directly:

   aws cloudformation deploy \
     --region eu-west-1 \
     --template-file template.yaml \
     --stack-name dva-lab-1 \
     --parameter-overrides BucketNameSuffix=$(date +%s) \
     --capabilities CAPABILITY_NAMED_IAM

   The update fails because the bucket name is already taken (a Replacement is required and the new resource can't be created), and the CLI eventually reports the stack rolled back.
7. Watch the automatic rollback happen in the stack's event stream:

   aws cloudformation describe-stack-events \
     --region eu-west-1 \
     --stack-name dva-lab-1 \
     --query "StackEvents[?contains(ResourceStatus,'ROLLBACK')].{Status:ResourceStatus,Reason:ResourceStatusReason}" \
     --output table

   Events show UPDATE_ROLLBACK_IN_PROGRESS then UPDATE_ROLLBACK_COMPLETE — CloudFormation automatically reverted the stack to the last known-good state with no manual intervention required.
8. Clean up:

   aws cloudformation delete-stack --region eu-west-1 --stack-name dva-lab-1

   Stack and all its resources (bucket, topic) are removed since neither had a DeletionPolicy: Retain.

Lab 2 — AWS SAM: Scaffold, Build, Test Locally, Then Deploy

SAM's whole value proposition is the fast local loop before you ever touch CloudFormation. This exercise builds a minimal API Gateway + Lambda app and proves that loop end to end.

1. Scaffold a new app from a starter template (choose the Hello World Example runtime Python 3.12 when prompted, and accept the default project name):

   sam init --runtime python3.12 --name dva-sam-lab --app-template hello-world

   A dva-sam-lab/ directory is created containing template.yaml, a hello_world/ function directory with app.py, and an events/event.json test event.
2. Open template.yaml and identify the shorthand SAM resource types:

   Transform: AWS::Serverless-2016-10-31
   Resources:
     HelloWorldFunction:
       Type: AWS::Serverless::Function
       Properties:
         CodeUri: hello_world/
         Handler: app.lambda_handler
         Runtime: python3.12
         Events:
           HelloWorld:
             Type: Api
             Properties:
               Path: /hello
               Method: get

   You can see the same Transform: AWS::Serverless-2016-10-31 line from the Components tab, and one AWS::Serverless::Function resource whose Events block implicitly creates the underlying AWS::Serverless::Api — this single resource expands into a Lambda function, an execution role, an API Gateway REST API, and the permissions wiring them together.
3. Build the function (packages dependencies, in a Docker container matching the Lambda runtime if native deps are present):

   cd dva-sam-lab
   sam build

   A .aws-sam/build/ directory appears containing the built artifact and a rewritten template pointing at it — nothing has been uploaded or deployed yet.
4. Test the function locally, without deploying anything, using the generated test event:

   sam local invoke HelloWorldFunction --event events/event.json

   Docker starts a container emulating the Lambda runtime, invokes the handler, and prints a response body like {"message": "hello world"} along with a START/END/REPORT log — confirming the function logic works before any AWS resource exists.
5. Run the guided first deploy, targeting eu-west-1:

   sam deploy --guided --region eu-west-1

   An interactive prompt asks for a stack name (e.g. dva-sam-lab), confirms the Region, asks whether to allow SAM CLI IAM role creation, then packages and deploys — on completion it prints the deployed HelloWorldApi endpoint URL and saves all your answers to samconfig.toml for future non-interactive sam deploy runs.
6. Hit the live endpoint to confirm the deployed version matches what you tested locally:

   curl $(aws cloudformation describe-stacks \
     --region eu-west-1 --stack-name dva-sam-lab \
     --query "Stacks[0].Outputs[?OutputKey=='HelloWorldApi'].OutputValue" --output text)

   Same JSON response as the local invoke — proving sam local invoke is a genuinely reliable stand-in for the deployed behavior.
7. Clean up:

   sam delete --region eu-west-1 --stack-name dva-sam-lab --no-prompts

   The underlying CloudFormation stack, and every resource the AWS::Serverless::Function expanded into, is deleted.

Lab 3 — CDK: Same Destination, Different Road

This exercise deliberately mirrors Lab 1's simple S3 use case, but authored imperatively in CDK, so you can see with your own eyes that cdk synth produces the same kind of plain CloudFormation template that you hand-wrote in Lab 1.

1. One-time per account/Region setup (skip if you've already bootstrapped eu-west-1 in this account):

   cdk bootstrap aws://ACCOUNT_ID/eu-west-1

   A CDKToolkit CloudFormation stack is created in eu-west-1, containing a staging S3 bucket, an ECR repository, and the IAM roles CDK uses to deploy — required exactly once before any cdk deploy in this account/Region.
2. Scaffold a new TypeScript app:

   mkdir cdk-lab && cd cdk-lab
   cdk init app --language typescript

   A project is generated with lib/cdk-lab-stack.ts (your Stack class), bin/cdk-lab.ts (the App entry point), and cdk.json pointing at eu-west-1 via your default AWS profile/Region config.
3. Edit lib/cdk-lab-stack.ts to add one L2 construct — an S3 bucket:

   import * as cdk from 'aws-cdk-lib';
   import { Construct } from 'constructs';
   import * as s3 from 'aws-cdk-lib/aws-s3';
   
   export class CdkLabStack extends cdk.Stack {
     constructor(scope: Construct, id: string, props?: cdk.StackProps) {
       super(scope, id, props);
   
       new s3.Bucket(this, 'LabBucket', {
         versioned: true,
         removalPolicy: cdk.RemovalPolicy.DESTROY,
         autoDeleteObjects: true,
       });
     }
   }

   Nine lines of imperative TypeScript — compare this to the ~10 lines of declarative YAML the equivalent bucket took in Lab 1's template. versioned: true is the L2 shorthand for the same VersioningConfiguration: {Status: Enabled} property block you wrote by hand earlier.
4. Synthesize the CloudFormation template without deploying anything:

   cdk synth

   A full CloudFormation template prints to stdout and is written to cdk.out/CdkLabStack.template.json — no AWS API call to create or update anything has happened yet.
5. Open cdk.out/CdkLabStack.template.json and find the bucket resource:

   "LabBucket...": {
     "Type": "AWS::S3::Bucket",
     "Properties": {
       "VersioningConfiguration": { "Status": "Enabled" }
     },
     "UpdateReplacePolicy": "Delete",
     "DeletionPolicy": "Delete"
   }

   A plain AWS::S3::Bucket resource — the exact same resource type you wrote by hand in Lab 1, plus a Custom Resource (Lambda-backed) that CDK auto-generated to implement autoDeleteObjects, since that behavior has no native CloudFormation property.
6. Preview the diff against what's currently deployed (nothing yet, so everything shows as new):

   cdk diff

   Output lists the stack's IAM changes and resources to be created, formatted like a change-set preview — this is CDK's analogue to aws cloudformation describe-change-set from Lab 1.
7. Deploy — this synthesizes again internally, uploads assets, then calls CloudFormation:

   cdk deploy --region eu-west-1

   CDK prompts you to approve the IAM/security-related changes, then shows the same kind of CREATE_IN_PROGRESS → CREATE_COMPLETE stack events Lab 1's raw aws cloudformation deploy produced, because it's calling the identical underlying API.
8. Confirm it's a real CloudFormation stack like any other:

   aws cloudformation describe-stacks --region eu-west-1 \
     --stack-name CdkLabStack --query "Stacks[0].StackStatus"

   "CREATE_COMPLETE" — indistinguishable from a stack created via raw CloudFormation or SAM, because it is one.
9. Clean up:

   cdk destroy --region eu-west-1

   The stack and its bucket are deleted (the DESTROY removal policy + autoDeleteObjects mean the bucket is emptied and removed automatically, rather than blocking deletion the way a non-empty bucket normally would).

Flashcards — 24 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 13 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.