DOP-C02 Security and Compliance 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.

• ✗

  Use AWS Service Catalog to enforce tagging on all products.

  Why it's wrong here

  AWS Service Catalog centralizes governance for end users who provision products (CloudFormation templates) from a portfolio. While you can define launch constraints and apply tags to provisioned products, the scenario involves deploying infrastructure directly with CloudFormation stacks, not through Service Catalog's product-provisioning workflow. Adopting Service Catalog would require re-architecting the deployment process and cannot retroactively enforce tags on stacks created outside of it, so it fails to satisfy the requirement.

• ✗

  Create an AWS Config rule to detect untagged resources and trigger auto-remediation.

  Why it's wrong here

  An AWS Config rule is detective and runs post-creation; it evaluates resources against the rule after they exist and triggers auto-remediation, leaving a window where untagged resources are already created and incurring cost. Auto-remediation via Systems Manager can add the missing tag, but it does not prevent the initial creation, and the remediation may fail for resources that don't support Systems Manager documents. Thus, this approach is reactive rather than preventive and does not guarantee that tags are present at the moment of resource creation.

• ✓

  Specify the tag in the CloudFormation stack's Tags parameter, which applies the tag to all resources in the stack.

  Why this is correct

  When you specify a tag in the Tags parameter of the AWS CloudFormation stack, CloudFormation automatically applies that tag to every resource in the stack that supports tagging during stack creation and update operations. This is a native cloudformation capability that propagates the tag at launch time, ensuring the CostCenter tag is consistently applied without custom code or post-creation processing. Resources that do not support tagging are the only exceptions, but the tag is applied to all taggable resources as part of the stack lifecycle.

• ✗

  Use a custom Lambda function as a CloudFormation hook to tag resources after creation.

  Why it's wrong here

  Using a custom Lambda function as a CloudFormation hook is incorrect because hooks are primarily for custom validation or modification of specific resources during stack operations, not for declaring inherent, automatic default tags across all resources within a stack. Implementing this would require complex custom code to identify and apply the 'CostCenter' tag to every resource programmatically. This option is tempting as Lambda can tag resources, and hooks allow customisation. Hooks are suitable for enforcing custom compliance rules or performing complex conditional actions on individual resources where native CloudFormation features are insufficient.

Go deeper

Related to this question