A logistics team manages 200 CloudFormation stacks and needs reusable TypeScript networking constructs with unit tests, deterministic previews, and drift handling while keeping declarative state. Developers prefer imperative logic over raw YAML. Which infrastructure-as-code approach delivers reusable tested components with declarative deployment?
Select an answer to reveal the explanation.
Short Explanation
You want code brains with stateful guardrails. CDK synthesis lets you unit-test TypeScript constructs, preview with diff, then deploy as CloudFormation stacks.
Full Explanation
The correct approach succeeds because AWS CDK defines reusable networking abstractions as TypeScript classes with loops, conditionals and composition while synthesizing to declarative CloudFormation templates, preserving the 200-stack fleet and state model, enabling Jest unit tests without deployment, offering deterministic previews via cdk diff comparing synthesized templates against deployed stacks, and retaining native drift detection for post-deployment mutation. The CDKTF remote-state approach fails on continuity because despite TypeScript modules, Jest tests and speculative plans with declarative remote state, it shifts authority from CloudFormation and cannot natively manage versioning, change sets and drift for existing stacks. The in-place shared library approach fails on safety because while reusing CDK code with Jest coverage to update stacks declaratively, direct in-place updates without synthesis comparison remove preview gates and allow unreviewed mutations. The hand-built template generator approach fails on tooling because, although it can emit CloudFormation and use change sets, the team would have to write and maintain its own construct library, asset handling and diff workflow that CDK already provides, so it does not deliver reusable tested components as directly as CDK constructs with cdk diff. Exam caveat: never equate TypeScript support with meeting constraints; trace where state lives, how previews are produced, and how drift is detected rather than matching language keywords. Practical check: verify aws-cdk-lib imports, Jest construct tests, required cdk synth and cdk diff approval before deploy, plus scheduled drift detection with remediation runbooks.