Enforce the cost allocation tag with CDK tagging and deploy SQS queues defined as CDK constructs through CDK stacks
A company has deployed a landing zone that has a well-defined AWS Organizations structure and an SCP. The company's development team can create their AWS resources only by using AWS CloudFormation and the AWS Cloud Development Kit (AWS CDK). A DevOps engineer notices that Amazon Simple Queue Service (Amazon SQS) queues that are deployed in different CloudFormation stacks have different configurations. The DevOps engineer also notices that the application cost allocation tag is not always set. The DevOps engineer needs a solution that will enforce tagging and promote the reuse of code. The DevOps engineer needs to avoid different configurations for the deployed SQS queues. What should the DevOps engineer do to meet these requirements?
Community Votes
64% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
CDK Aspects applied at the stack or app level apply tags to every construct they cover, which is what enforces the tag consistently no matter which stack or account the resource lands in (C). Defining the SQS queue once as a CDK construct and deploying via CDK stacks is what promotes code reuse and eliminates configuration drift between stacks, since every stack instantiates the same construct with the same settings (C). Option D's use of CDK feature flags is not a deployment mechanism, so the queues would not be deployed through them at all.
Two problems must be solved together: the cost allocation tag is not always applied, and SQS queues in different stacks end up with different configurations. Using AWS CDK tagging, applied at the stack level so every construct inherits it, enforces the cost allocation tag uniformly across all stacks including those deployed through StackSets. Defining the queues as CDK constructs and deploying them with CDK stacks then makes the queue definition a reusable component, so every stack produces identically configured queues.
Using AWS CDK feature flags to deploy the SQS queues (D) — feature flags are switches that change construct behavior or CDK itself, not a deployment target, so no queues would be deployed this way; Srikantha's support for D rests on treating feature flags as a deployment mechanism, which they are not. Updating the SCP to enforce the cost allocation tag (B) — SCPs govern IAM API permissions, not resource tags, so an SCP cannot enforce a cost allocation tag; teo2157 and ArunRav preferred B but the mechanism does not exist. Using an Organizations tag policy for the tag and CloudFormation modules for reuse (A) — an Organizations tag policy can enforce tags on resource creation, but the development team in this scenario deploys through CDK and CDK, and the question emphasizes the CDK path.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The engineer must both enforce the cost allocation tag and eliminate configuration differences between SQS queues. AWS CDK addresses the first problem through tagging applied at the stack level: tags declared on the stack propagate to every construct it contains, so any queue, and any other resource, receives the cost allocation tag automatically regardless of which pipeline or account deploys it. Because CDK Aspects can be applied at the stack level, this also holds across CDK stacks deployed through CloudFormation StackSets (C). The second problem is solved by defining the queue once as a CDK construct and deploying those stacks with CDK, so every stack instantiates an identical definition and cannot drift into different configurations (C). C is the only option that addresses both requirements with the CDK tooling the development team is already mandated to use.Why the Other Options Are Wrong
D uses CDK tagging correctly but instructs the team to deploy the SQS queues by using CDK feature flags. Feature flags are switches that alter construct behavior or CDK itself; they are not a deployment mechanism, so the queues would not actually be deployed, and no reuse of the queue definition occurs. This is the objection that Srikantha's support for D overlooks. B updates the SCP to enforce the cost allocation tag. Service control policies govern which API actions principals may perform, not which tags resources carry, so an SCP cannot enforce a cost allocation tag, and teo2157 and ArunRav both preferred this option on the mistaken premise that SCPs restrict tagging. The option's remaining steps, CloudFormation modules and stacks, would address reuse but not the tag. A creates an Organizations tag policy, which is a genuine tag-enforcement mechanism, but the scenario states the development team creates resources only through CloudFormation and CDK, and the option then directs the team back to CloudFormation modules and StackSets rather than addressing the problem within the CDK path the team is standardized on. C is the correct answer.Community Comment Notes
Community voted C (64), with D at 18 and B at 18. sn61613 supported C on the grounds that it enforces tagging across all accounts via StackSets and uses CDK stacks to deploy identically configured SQS queues. jojewi8143 also chose C. Srikantha favored D and treated feature flags as contributing to configuration enforcement, but feature flags are not a deployment mechanism. teo2157 and ArunRav preferred B, believing an SCP could enforce the cost allocation tag, which is not something SCPs can do.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →