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.

• ✗

  Set a DeletionPolicy on the stack to retain resources when the stack is deleted.

  Why it's wrong here

  A DeletionPolicy is an attribute applied to individual CloudFormation resources, not to the stack as a whole. It determines what happens to a resource when it is removed from the stack template or when the stack is deleted (e.g., Retain, Snapshot, Delete). It is a lifecycle control, not an access control, so it does nothing to restrict who can modify or delete the stack. To protect a stack from accidental deletion, you would instead use IAM policies or an explicit deny on DeleteStack.

• ✓

  Use a service role with least privilege when creating the stack.

  Why this is correct

  A service role is an IAM role that CloudFormation assumes to make API calls on your behalf when creating, updating, or deleting stacks. By specifying a service role with least privilege, you ensure CloudFormation only has the permissions required to provision the intended resources, limiting the impact if a resource definition is malicious or misconfigured. This also enables separation of duties because users can create stacks without holding direct resource permissions, and all actions are attributed to the service role.

• ✓

  Use IAM policies to restrict CloudFormation actions to specific users and roles.

  Why this is correct

  IAM policies let you allow or deny specific CloudFormation API actions such as CreateStack, UpdateStack, DeleteStack, and DescribeStacks for particular users, groups, or roles. This is an identity-based access control that ensures only authorized principals can interact with CloudFormation stacks. You can further restrict actions using conditions, such as requiring a service role or limiting by stack name or tag. This is a fundamental mechanism for enforcing least privilege over CloudFormation operations.

• ✗

  Define a StackSetPolicy to control permissions across accounts.

  Why it's wrong here

  There is no AWS resource called 'StackSetPolicy' in AWS CloudFormation StackSets. StackSets use IAM roles to perform deployments across accounts—typically an administration role and target-account execution roles—but authorization is managed through standard IAM policies and trust relationships, not a dedicated policy resource attached to the stack set. Attempting to define a StackSetPolicy in a template or API call would result in an error because the resource type does not exist.

• ✓

  Apply a stack policy to prevent updates to sensitive resources during stack updates.

  Why this is correct

  A stack policy is a JSON document attached to a CloudFormation stack that controls what update actions are allowed on each resource (e.g., Update, Replace, Delete). By default, all resources are updatable; applying a policy with explicit Deny statements can protect sensitive resources, such as a production database, from unintentional replacement or deletion during stack updates. This resource-level guard works alongside IAM and service roles to prevent destructive changes even when a Developer has CloudFormation access.

Go deeper

Related to this question