Outcome
By the end of this lesson, you will be able to explain what a Smart Tag is, distinguish a derived tag from a cloud tag, and read the pending and accepted queues on the Smart Tags page.
| Tier | Engineer |
| JTBD | ”Get cost attribution working on resources nobody tagged, without waiting for a tagging project.” |
| Personas | Platform Engineer · FinOps Lead |
| Prerequisites | T0.M0.1.L4 (tags and attribution) |
| Time | 9 minutes |
| Bloom verb | Explain (Understand), Distinguish (Analyze), Read (Apply) |
1. Concept
Nobody has every resource tagged. Some were created by hand in a hurry, some are older than the tagging standard, and some belong to a team that never adopted it.
All of them land in the Unattributed pile on every report you produce. The usual response is a tagging project, and the usual outcome is a tagging project that stalls at 70%.
Smart Tags are ZopNight’s answer: a virtual tag, derived from a policy you write, that counts toward cost attribution inside ZopNight without anything being written to your cloud account first.
A CLOUD TAG A SMART TAG─────────────────────────────────────────────────────────────Lives in AWS / GCP / Azure Lives in ZopNightSomeone set it, by hand or IaC Derived by a policy you wroteChanging it is a cloud write Changing it is a policy editAlways authoritative Counts once you accept itThe important word is derived. A Smart Tag is not a guess about what the tag should have been. It is a deterministic function of fields the resource already carries.
What a policy can derive from
Each tagging policy enforces one tag key and computes its value from the resource’s own fields:
SOURCE FIELDS AVAILABLE TO A POLICY provider aws | gcp | azure region us-east-1, europe-west1, ... type ec2, rds, gke-cluster, ... instance_type m5.large, db.r6g.xlarge, ... name the resource's own name
EXAMPLE Policy key: cost-allocation Derived from: provider + region Result: cost-allocation = aws-us-east-1That is the whole vocabulary. There is no metric input, no activity signal, no ownership lookup. If the answer cannot be computed from those five fields, a tagging policy cannot produce it.
What changed, and why it matters if you used the old one
Smart Tags replaced the earlier heuristic auto-tagger, which predicted environment and noStop values from naming patterns and instance configuration and attached a confidence score to each prediction.
THE OLD AUTO-TAGGER SMART TAGS─────────────────────────────────────────────────────────────Predicted env / noStop Derives any key you defineConfidence tiers (high/med/low) No confidence. It is a function.Accept / REJECT Accept / REVOKE (no reject state)Heuristics owned by ZopNight Policies owned by youThe removal of confidence is the substantive change, not a cosmetic one. A prediction can be wrong, so it needs a confidence score and a reject state. A derivation cannot be wrong about its own inputs: if provider is aws and region is us-east-1, then aws-us-east-1 is simply what the policy says. What you are judging when you accept it is whether the policy is useful, not whether this particular value is correct.
The two states
DERIVED every policy runs against every matching resource │ ├─ value already equals the resource's live cloud tag │ └─> AUTO-ACCEPTED at derivation │ └─ otherwise └─> PENDING, until a human accepts it
pending = derived − acceptedThere is no third state. A tag you do not want is one you leave pending, or a policy you edit; there is nothing to reject.
Why auto-accept exists
The auto-accept rule is worth understanding because it prevents a specific bad experience. Suppose your policy derives cost-allocation = aws-us-east-1, and a resource already carries that exact cloud tag because someone tagged it correctly last year.
Without auto-accept, that resource would sit in the pending queue forever, asking you to approve a tag it already has. Multiply by a well-tagged estate and the pending queue fills with no-ops, which is the fastest way to get a queue ignored.
So the invariant is: a derived tag whose value already equals the live cloud tag is accepted at derivation. A resource the customer already tagged correctly is counted as done, not stranded.
Reading the page
SMART TAGS Provider: [All ▾]
PENDING (412) ACCEPTED (1,847)
KEY DERIVED VALUE RESOURCES ───────────────────────────────────────────────── cost-allocation aws-us-east-1 184 cost-allocation aws-eu-west-1 96 cost-allocation gcp-europe-west1 72 workload-class ec2-compute 60
[Accept selected] [Apply to cloud]The counts are org-wide, the tabs split pending from accepted, and the provider filter narrows to AWS, GCP or Azure. Accepting is per key.
2. Demo
An org closing an attribution gap without a tagging project:
STARTING POSITION Reports → Tags shows 31% of spend Unattributed Root cause: 640 resources with no cost-centre tag, almost all provisioned before the taxonomy
THE OLD PLAN Ticket every owning team. Estimated 6 weeks, historically never finishes past about 60%.
WHAT THEY DID INSTEAD Settings → Policy → Tagging → new policy key: cost-allocation derived from: provider + region
On the next refresh: Derived on 2,259 resources Auto-accepted: 1,847 (already carried a matching cloud tag) Pending: 412 (the genuinely untagged set)
Reviewed the 412 by derived value, not one by one: aws-us-east-1 184 -> accept aws-eu-west-1 96 -> accept gcp-europe-west1 72 -> accept aws-ap-south-1 60 -> LEFT PENDING. This is the analytics estate, and region is the wrong axis for it: three teams share the region. A second policy keyed on name suits it better.
Elapsed: about 20 minutes. Unattributed dropped 31% -> 9%.
WHAT REMAINED The 60 analytics resources are still Unattributed, on purpose. A derived value that is precise but not meaningful is worse than no value: it would have made the report look complete while attributing three teams' spend to one bucket.The judgement call in the last block is the whole skill. Accepting is cheap; accepting a value that reads as attribution but is not is expensive, because it hides the gap instead of closing it.
3. Hands-on (6 min)
1. Open Reports → Tags. What percentage of spend is currently Unattributed? ____%
2. Open Smart Tags. Counts today: Pending ______ Accepted ______
3. Pick one pending key and sort by derived value. How many DISTINCT values does it produce? ______ If it produces one value for most of your estate, the policy is not attributing anything. Note it.
4. For your largest pending group, answer honestly: does this derived value identify an owner, or does it just identify a location? ______
5. Find one resource in the accepted list that you did NOT accept manually. That is the auto-accept invariant: its cloud tag already matched. Resource: ______________________________________Step 4 is the one that matters. region is easy to derive and frequently useless for chargeback.
4. Knowledge check
Q1
A resource already carries the cloud tag cost-allocation = aws-us-east-1, and a tagging policy derives exactly that value. Where does it appear?
A. In the pending queue, waiting for an approval
B. Nowhere, because it is a duplicate
C. In both queues
D. In the accepted list, auto-accepted at derivation
Show answer
Correct: D. The “cloud implies accepted” invariant exists so that a resource the customer already tagged correctly is counted as done rather than stranded as un-clearable pending. Without this rule, a well-tagged estate would fill the pending queue with no-op approvals, which is the fastest way to get the queue ignored. The same matching logic later makes “Apply to cloud” skip the redundant write.
Q2
What can a tagging policy derive a value from?
A. CloudTrail events and the resource’s creator
B. The resource’s own fields: provider, region, type, instance_type and name
C. A machine-learning model trained over the organisation’s historical tag data
D. The resource group it belongs to
Show answer
Correct: B. There is no metric input, no activity signal and no ownership lookup, so anything that cannot be computed from those five fields is out of reach for a policy. This is the constraint that shapes every policy you write. It is also why Smart Tags cannot derive an owner: no field on the resource carries one. Ownership detection is a separate feature that reads cloud activity logs.
Q3
Why do Smart Tags have no confidence score, when the auto-tagger they replaced did?
A. The scores were removed to simplify the UI
B. Because all Smart Tags are high confidence
C. Because a derivation cannot be wrong about its own inputs
D. Because the confidence is shown on the policy instead
Show answer
Correct: C. A prediction guesses at something unobservable and therefore needs a confidence and a reject state; a policy computes a deterministic function of fields the resource already carries. What you judge on accept is whether the policy is useful, not whether the value is correct. This is why the state model is accept/revoke rather than accept/reject: there is no wrong value to reject, only a policy that is or is not worth applying. If a derived value is unhelpful, edit the policy rather than rejecting individual resources.
5. Apply
Open Smart Tags and look at the ratio of accepted to pending. A large accepted count on day one is the auto-accept invariant telling you your existing cloud tagging is better than you thought; a large pending count is the real gap.
Manage the policies that produce these values at Settings → Policy → Tagging, covered in L2.
Related lessons
- L2: Writing a tagging policy (next)
- L3: Accept, revoke, apply to cloud
- T0.M0.1.L4: Tags and the cost-attribution problem
- T3.M3.5.L4: The Tag Coverage widget
Glossary terms touched
Smart Tag · Tagging policy · Derived tag · Tag coverage