Synth, Bootstrap, and Deploy

## What synthesis actually is The CDK is not a template language with extra syntax. A CDK app is an ordinary program in a general-purpose language, and running it is the whole point of `cdk synth`. The CLI reads `cdk.json`, finds the `app` entry (something like `"app": "npx ts-node --prefer-ts-exts bin/app.ts"`), and executes it as a subprocess. Your program constructs an `App`, adds one or more `Stack`s to it, and adds constructs to those stacks — building an in-memory tree. At the end, `app.synth()` walks that tree, asks each construct to render itself, and writes the result to disk. What each construct renders is CloudFormation. A high-level construct may expand into many resources, IAM policies and log groups; a low-level `Cfn*` resource maps to exactly one. Either way the output is plain CloudFormation JSON — there is no CDK runtime in AWS, and nothing in the deployed account knows your app was written in TypeScript. ## What lands in cdk.out The directory the CLI writes is called a *cloud assembly*, and it is a self-describing artifact: ``` cdk.out/ cdk.out # marks the directory, with the assembly schema version manifest.json # the stacks, their environments, and their dependencies tree.json # the construct tree, used by tooling MyStack.template.json # one CloudFormation template per stack MyStack.assets.json # the file and image assets this stack needs asset.3f9c.../ # staged asset content, named by content hash ``` Every stack in the app gets its own template file, regardless of how many you asked for on the command line. `manifest.json` is what tells the CLI which account and region each stack targets and in what order dependent stacks must go out. ## Your code runs now, not at deploy time This is the point juniors most often miss. A `for` loop that creates ten buckets produces ten `AWS::S3::Bucket` resources in the template — there is no loop in the template, because the loop already ran on your laptop. An `if` on an environment name picks a branch at synthesis time and the other branch simply does not exist in the output. Anything you want CloudFormation itself to decide at deploy time has to be expressed as CloudFormation constructs, not as language constructs. Values that genuinely are not known until deploy — the ARN of a resource being created in this very deployment, for example — appear in the template as *tokens*: opaque placeholder strings during synthesis that render into CloudFormation references in the output. That is why printing such a value in your program shows something like `${Token[TOKEN.42]}` rather than a real ARN. ## Why the artifact matters Because synthesis is deterministic and local, the cloud assembly is a reviewable, storable build output. A pipeline typically synthesizes once, publishes `cdk.out` as a build artifact, and every later stage deploys *that* assembly with `cdk deploy --app cdk.out` instead of re-running the program. That removes a whole class of surprises where the code drifted, a dependency resolved differently, or a lookup returned something new between the review and the deploy. `cdk.out` is a build output and belongs in `.gitignore`. You regenerate it; you never hand-edit it. If you find yourself wanting to edit the template, that is a signal to reach for an escape hatch in the program instead, so the change survives the next synth. ## What synth does not do It does not create, modify or delete anything in AWS — you can run it with no credentials at all, unless your app performs environment lookups that need to call AWS. It does not ask CloudFormation whether the template is acceptable, so an invalid property value, a service quota, or a name collision surfaces later during deploy, not here. It does not compare against what is deployed — that is `cdk diff`. And it does not publish assets; it only *stages* them into `cdk.out` and records their hashes, leaving the upload to deploy time. The practical takeaway for an interview: synth is "run my program, get templates". Everything that touches AWS happens afterwards.