DOP-C02 Configuration Management and IaC Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create nested stacks that include the common resources and pass parameters as needed.

  Why it's wrong here

  Nested stacks allow you to split a template into child templates using the AWS::CloudFormation::Stack resource, but they do not address duplication of common resource definitions across separate stacks. Each parent template still references its own child template, and the same resource snippet must be defined or copied again in every child template that needs it. Adding parameters to nested stacks only helps customize a specific instantiation, not reuse a shared configuration as a versioned, distributable artifact.

• ✗

  Store the common resource definitions in an AWS CodeCommit repository and copy them into each template.

  Why it's wrong here

  Storing common resource definitions in CodeCommit and copying them into each template just moves the maintenance problem into a version-control repository. Every template that copies the snippet becomes a fork that can drift when the source definition changes, requiring manual updates and increasing the chance of configuration inconsistencies. CodeCommit is a Git service, not a mechanism for dynamic reuse; CloudFormation templates are static and will not automatically pull or reference those stored snippets at deployment time.

• ✗

  Use cross-stack references by exporting outputs from a central stack and importing them in other stacks.

  Why it's wrong here

  Cross-stack references through exports and imports share actual output values, such as a VPC ID or a security group ARN, not the resource definitions or configuration logic themselves. Importing a value creates a hard dependency between stacks and requires the exporting stack to exist first, but it still doesn't reduce the work of writing the shared resource configuration in each consuming template. This approach couples stacks operationally while leaving the duplication of common resource definitions completely untouched.

• ✓

  Develop CloudFormation modules that encapsulate common resource configurations and publish them in a registry.

  Why this is correct

  CloudFormation modules are purpose-built for encapsulating and reusing common resource configurations: you package a template, a schema, and optional resource providers into a module and publish it to the CloudFormation registry. Once published, any stack can reference the module by type, version, and optional alias, enabling consistent, versioned, and shareable infrastructure components across accounts and regions. Modules support parameter and resource typing, and they can be privately shared within an organization, making them the correct way to eliminate duplicate resource definitions while keeping templates concise.

Go deeper

Related to this question