Teams in your AWS Organization keep launching resources with no `CostCenter` tag, or spelling it `costcenter`. Explain what an AWS Organizations tag policy actually enforces, and how you would prevent untagged resources from being created at all.

## Three different controls, often confused Governing tags at organization scale uses three mechanisms that do genuinely different things. Candidates who name only one usually name the wrong one. ### 1. Tag policies — the vocabulary A **tag policy** is a policy type in AWS Organizations (it must be enabled in the management account, and the organization needs all features enabled). You attach it to the root, an OU or a single account, and policies inherit down the tree. What it declares is the *shape* of a tag: the canonical capitalisation of the key, and optionally the list of permitted values. ```json { "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": ["CC-1001", "CC-1002"] }, "enforced_for": { "@@assign": ["secretsmanager:*"] } } } } ``` By default this is **advisory**. Nothing is blocked; instead Resource Groups produces an organization-wide compliance report telling you which resources carry a key with the wrong case or a value outside the list. That report is exactly what a cost allocation programme needs, because a mis-cased key silently splits a chargeback report in two. The `enforced_for` element raises it to a **preventive** control, but narrowly: for the resource types you list, a tagging operation that would produce a non-compliant tag fails. Two limits matter. First, it applies only to the resource types you name, and the supported list is service-specific, not universal. Second — and this is the part interviewers probe — it constrains tags you *are* setting; it has nothing to say about a resource created with no tags whatsoever, which is the actual failure mode in a cost allocation programme. ### 2. Deny on the tag-on-create condition keys — the gate To make a tag mandatory you deny the creating action unless the request carries it. The global condition key `aws:RequestTag/<key>` reflects tags supplied *in the request*, and `aws:TagKeys` is the set of keys supplied. ```json { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "Null": { "aws:RequestTag/CostCenter": "true" } } } ``` Put this in a service control policy to apply it across accounts, or in the roles teams actually use. `Null` with `"true"` means "the key is absent from the request", so this denies any `RunInstances` that does not tag the instance. You can pair it with `"ForAllValues:StringEquals": {"aws:TagKeys": [...]}` to reject unknown keys. The hard part is coverage. Support for tag-on-create condition keys is per service and per action, and it is not universal: some actions do not accept tags at creation at all, and some create secondary resources (volumes, ENIs, snapshots) that the parent call may or may not propagate tags to. Writing one deny per creating action across a whole estate is real work with real breakage risk, which is why most organizations scope it to the handful of expensive resource types that dominate the bill. ### 3. Detection and remediation — the safety net Whatever the gate misses, detection catches. The AWS Config managed rule `required-tags` evaluates resources against a list of keys and flags the non-compliant ones; it can be deployed organization-wide as a conformance pack and wired to an automatic remediation that tags or notifies. This is also where you catch resources created before the policy existed. ## Why this ordering The three layers map to three failure modes. Tag policies fix *inconsistent* tagging, which corrupts reports quietly. Deny policies fix *absent* tagging on the things worth gating, at the cost of friction and breakage when a team hits an action you did not anticipate. Config rules fix *drift and history*, and they are the only one that tells you the size of the problem. A senior answer also says what none of them fix: charges with no taggable resource behind them, and services that do not carry tags through to every billing line. Those need a different allocation mechanism entirely, not a stricter tag policy. ## Rollout advice worth stating Start in report-only mode and read the compliance report before enforcing anything — turning on a deny across an organization you have not measured is how you break a deploy pipeline at 2am. Enforce on new accounts and new OUs first, give teams the compliance report for their own accounts, and only then narrow the deny to the resource types where the money actually is.