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.

• ✓

  Always create a change set before executing a stack update.

  Why this is correct

  A change set is a read-only preview of the exact modifications CloudFormation will make to a running stack, including whether each resource is created, updated, replaced, or deleted. By generating a change set before executing, you can inspect the action on every resource and confirm that the update does not introduce unintended destructive changes or interruption. Execution is a separate, explicit step, which gives engineers a checkpoint in the IaC workflow.

• ✓

  Use a stack policy to prevent updates to critical resources.

  Why this is correct

  A stack policy is a JSON document that defines update permissions per resource, allowing you to explicitly deny updates to critical components such as production databases or load balancers. Without such a policy, CloudFormation can update or replace any resource in the stack, so a stack policy adds a guardrail on top of IAM to prevent accidental template changes from causing downtime. This protection is especially valuable when multiple teams or automated pipelines can submit stack updates.

• ✗

  Perform updates directly from the AWS Management Console to see immediate results.

  Why it's wrong here

  Directly updating from the AWS Management Console immediately submits the template to CloudFormation and begins applying changes, skipping the change-set review phase. The console's event stream only shows results after resources have started changing, so a typo in a template can trigger an unintended resource replacement before any human approval. In a disciplined IaC practice, all updates should be staged as change sets and reviewed before execution.

• ✗

  Delete the stack and create a new one with the updated template.

  Why it's wrong here

  Deleting a stack removes all of its resources in the order defined, and unless a DeletionPolicy is set, this permanently destroys data and state such as RDS databases or EBS volumes. Recreating the stack from the updated template then builds resources from scratch, causing downtime, data loss, and breaking external dependencies like DNS records or VPC peering connections. CloudFormation updates are designed to support in-place, controlled migrations, so this approach should be reserved for truly throwaway stacks.

• ✗

  Use the --disable-rollback flag to avoid unnecessary rollbacks.

  Why it's wrong here

  The --disable-rollback flag prevents AWS CloudFormation from automatically reverting the stack to its last known good state when an update fails. If a resource fails during the update, the stack can be left in a partially updated and inconsistent condition, with some resources using new properties and others still using old ones, making recovery difficult. Leaving rollback enabled preserves the previous stable version and simplifies debugging and correction.

Go deeper

Related to this question