Lesson 18 of 30

AWS CDK

Q: A teammate says 'let's just write raw CloudFormation instead of CDK, it's one less thing to learn.' How would you make the case for CDK, and what would you say actually changes versus what stays the same underneath?

A strong answer covers: Explains CDK synthesizes to a real CloudFormation template — it's an authoring layer, not a replacement deployment engine; Names concrete language-level benefits: type checking on resource properties, loops/functions for repeated resources, shareable constructs as packages; States explicitly that stacks, change sets, and drift behavior are unchanged, since the same CloudFormation engine deploys the synthesized output; Distinguishes L1 (raw 1:1 mapping) from L2 (opinionated defaults) constructs.

CDK doesn't replace CloudFormation — it's a compiler that generates it, which means every stack, change set, and drift rule from the CloudFormation lesson still applies underneath.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A team writes their infrastructure using CDK in TypeScript instead of hand-written CloudFormation YAML. What actually happens when they run `cdk deploy`?

The TypeScript is synthesized into a CloudFormation template, which CloudFormation then deploys through its normal stack mechanismCDK deploys resources directly through its own engine, bypassing CloudFormation entirelyThe TypeScript code runs live in the AWS account each time, making direct API calls as it executes

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on AWS CDK

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate says 'let's just write raw CloudFormation instead of CDK, it's one less thing to learn.' How would you make the case for CDK, and what would you say actually changes versus what stays the same underneath?

A strong answer covers

Explains CDK synthesizes to a real CloudFormation template — it's an authoring layer, not a replacement deployment engine
Names concrete language-level benefits: type checking on resource properties, loops/functions for repeated resources, shareable constructs as packages
States explicitly that stacks, change sets, and drift behavior are unchanged, since the same CloudFormation engine deploys the synthesized output
Distinguishes L1 (raw 1:1 mapping) from L2 (opinionated defaults) constructs

Likely follow-ups

A `cdk deploy` fails partway through. How would you figure out whether the problem is in the CDK code itself or in the CloudFormation stack it generated?
If an L2 construct's default configuration turns out to be wrong for your use case, what are your options?

Practice these with the AI interviewer →

The plain-language idea

The CDK (Cloud Development Kit) lets infrastructure be authored in a real programming language — TypeScript, Python, and others — instead of raw CloudFormation YAML or JSON. You write classes and function calls describing the resources you want; running cdk synth compiles that code down into an actual CloudFormation template, and cdk deploy hands that template to CloudFormation exactly the same way a hand-written YAML file would be. CDK is a code generator sitting on top of CloudFormation, not a separate deployment engine — every stack, change set, and drift concept from the CloudFormation lesson is still exactly what's running underneath.

The building block is a construct — a composable unit representing one or more resources, at three levels:

L1 — a direct, one-to-one mapping to a raw CloudFormation resource, no added behavior.
L2 — a curated wrapper around an L1 with sensible defaults baked in (e.g. an S3 bucket construct that enables encryption by default) — most day-to-day CDK code lives here.
L3 (patterns) — whole pre-wired architectures in one construct, like a load-balanced Fargate service that provisions the ALB, the ECS service, and the target group together as one unit.

See it in a real thing: TypeScript in, a CloudFormation template out

import * as s3 from "aws-cdk-lib/aws-s3";

new s3.Bucket(this, "UploadsBucket", {
  versioned: true,
});

This is the CDK equivalent of the AWS::S3::Bucket resource from the CloudFormation lesson's template — same versioned bucket, same underlying resource type, but written as a typed constructor call instead of a YAML block. cdk synth turns it into an actual CloudFormation template you can inspect directly; cdk diff is the CDK-level equivalent of reviewing a change set before committing to it.

What people usually miss

Watch out

cdk deploy still goes through CloudFormation's real stacks and change sets underneath. Nothing about drift, stack deletion cascading to everything it manages, or change sets as a review gate changes just because the authoring layer is nicer — CDK doesn't introduce a different deployment model, it generates input for the same one.
L2 constructs' "sensible defaults" are real opinions, not neutral output. A CDK L2 bucket construct and a hand-written CloudFormation AWS::S3::Bucket block don't necessarily produce identical templates — the defaults CDK chooses (naming, encryption, removal behavior) are worth knowing rather than assuming.
The synthesized template is inspectable, not a black box. cdk synth output is plain, readable CloudFormation — when a deploy behaves unexpectedly, reading the actual synthesized template to see what CDK generated is a legitimate and sometimes necessary debugging step.
CDK doesn't remove the need to understand CloudFormation concepts — it removes the need to write CloudFormation syntax. Stacks, change sets, and drift are still the mental model; CDK changes how you author input for that model, not what the model is.

Why this matters in interviews

"Why would a team choose CDK over raw CloudFormation?" tests whether a candidate can name the real, specific value — a real programming language's tooling (types, loops, reusable constructs) generating the same underlying CloudFormation stacks — rather than a vague "it's easier," and whether they understand a CDK deploy failure could be either the CDK code or the CloudFormation stack it synthesized, which changes where you'd look first.