The four stages
What runs at each stage of synth & validate, and what a failure looks like.
Every submission runs through the same four stages, in order, inside an isolated sandbox that never touches a real AWS account. A failure at an earlier stage stops the run there — later stages never see broken input.
Stage 1 — Synthesize
Your CDK code becomes a CloudFormation template, the same translation cdk synth performs locally. This is where a TypeScript/Python error, a missing required construct property, or invalid CDK usage shows up first.
What a failure looks like: the workspace shows Synth failed, with the raw build error in a code block — nothing later runs, and the Synthesized template/Architecture tabs stay empty since there's no template yet to show.
Stage 2 — Lint
The synthesized CloudFormation template is checked for structural validity with cfn-lint — the same tool many teams run in CI before ever attempting a deploy. This catches template-level mistakes CDK's own type system doesn't, like a resource property with the wrong shape at the CloudFormation level.
Example: a required property on a resource is missing entirely from the synthesized template — a real cfn-lint failure class, not a stylistic nitpick.
Stage 3 — Security scan
cdk-nag applies AWS's own published best-practice rule sets (AwsSolutions) against the template — the checks real teams wire into CI. A blocking finding here fails the run; a non-blocking one still surfaces, collapsed, so you can see what a stricter setup would flag.
Example: AwsSolutions-S1 — an S3 bucket with server access logging disabled — is a real, standard cdk-nag finding, exactly the kind of thing this stage exists to catch before it reaches a real account.
Stage 4 — Intent assertions
Hand-written checks specific to the lesson — never string-matching your source code, always properties of the synthesized result. Two different-looking correct answers pass identically; one wrong property fails, no matter how the surrounding code is written.
Example: the "Granting public read access" lesson doesn't check how you wrote the bucket policy — it asserts that public read access is actually granted through a bucket policy, on the right bucket, for the right action, however you got there.