DOP-C02 - Configuration Management and Infrastructure as Code (17% of the exam) - Section 2.2

Build reusable infrastructure components with the AWS Cloud Development Kit, CloudFormation modules and the AWS Serverless Application Model.

Build sharable infrastructure patterns using the AWS Cloud Development Kit constructs, CloudFormation modules, and the AWS Serverless Application Model. Recognise which abstraction layer suits a team - typed programming constructs in CDK versus template-level modules versus SAM transforms for serverless resources.

AWS Cloud Development KitCloudFormation modulesAWS Serverless Application ModelReusable constructs

Practice question for this objective

Free sampleConfiguration Management and Infrastructure as Codemedium

A team defines a serverless API using plain CloudFormation. Each endpoint requires an AWS::Lambda::Function, an AWS::IAM::Role, an AWS::Logs::LogGroup, and several AWS::ApiGateway resources, so the template has grown long and error-prone, and engineers frequently misconfigure the IAM role and log retention. They want a template authoring model where a single resource declares the function and wires its API event, permissions and logging, while still producing standard CloudFormation under the hood. Which change BEST reduces this boilerplate?

AKeep the raw CloudFormation resources but move the IAM role and log group into a nested stack so the main template is shorter, referencing them from each function through cross-stack outputs.
BReplace the inline resources with a CloudFormation macro the team writes to generate the function and its dependencies, registering the macro so each template calls it for every endpoint.
CAdopt the AWS Serverless Application Model transform and declare each endpoint as an AWS::Serverless::Function with an Api event, letting the transform expand it into the underlying function, role, permissions and API resources. Correct
DContinue using the existing resources but add a CloudFormation parameter for log retention and a managed policy reference for the role, so the misconfigured values are supplied consistently across endpoints.

Use the AWS Serverless Application Model transform so one AWS::Serverless::Function declaration expands into the function, role, permissions and API resources as standard CloudFormation. The AWS Serverless Application Model is a CloudFormation transform: a single AWS::Serverless::Function with an Api event expands at deploy time into the Lambda function, its execution role, permissions and API Gateway resources as ordinary CloudFormation, removing repetitive boilerplate that nested stacks, a custom macro or parameters do not eliminate.

Why A is wrong: A nested stack hides some lines behind a separate template but each endpoint still declares the full function, role, log group and API resources by hand, so the misconfiguration and boilerplate the team wants to remove remain.

Why B is wrong: A self-written macro could expand the resources but it puts the burden of authoring and maintaining a Lambda-backed transform on the team, whereas the managed serverless transform already provides this expansion.

Why C is correct: The AWS Serverless Application Model transform lets one AWS::Serverless::Function resource declare the function plus its API event and generate the role, permissions and API plumbing as standard CloudFormation, removing the hand-written boilerplate the team struggles with.

Why D is wrong: Parameters and a shared policy standardise specific values but every endpoint still declares all four resource types explicitly, so the lengthy error-prone template the team wants to simplify is unchanged.

See more DOP-C02 practice questions, answers explained.

Exam traps in Configuration Management and Infrastructure as Code

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

An L1 construct, mapping one to one onto the underlying CloudFormation resources so consumers configure every property of the queue, function and dead-letter queue explicitly through the generated interface.
Why it is wrong: L1 constructs map directly onto raw CloudFormation resources and expose every low-level property, which is the opposite of the opinionated multi-resource pattern with a small property surface the engineer wants to publish.
Commit the construct source into a shared folder that each application repository pulls in through a git submodule, so every team builds the constructs from source alongside their own application code.
Why it is wrong: A git submodule shares source but it does not give versioned, pinnable releases consumed through normal dependency tooling, so teams build from raw source and updates are managed by moving submodule pointers rather than version constraints.
Move the repeated bucket code into a shared CloudFormation parameter file that each synthesised stack imports at deploy time, so the encryption key is supplied centrally to every service stack.
Why it is wrong: A shared parameter file can centralise the key value but it cannot encapsulate the bucket policy and lifecycle resources, so the forty lines stay duplicated in every stack and a structural change still touches each copy.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.