# Smart Tags

> Policy-driven virtual tags that give under-tagged resources a consistent cost-attribution key, plus tag-compliance checks and an optional apply-to-cloud that writes the tag onto the real resource. Used inside ZopNight for attribution; pushed to your cloud only when you ask.

Source: https://zop.dev/docs/zopnight/concepts/smart-tags

---

Real cloud estates are unevenly tagged. Some accounts have clean `cost-center` and `env` tags on everything; others have resources with no tags at all. That inconsistency breaks cost attribution, because showback can only split spend by the tags that exist. **Smart Tags** close the gap: they derive a consistent virtual tag from a policy you define, so every resource gets an attribution key even when its cloud tags don't.

![Smart Tags page showing three summary cards — Pending Review (90 awaiting your decision), Accepted (30 counted for cost attribution), and Tag Compliance (10 to fix, with a Review non-compliant link) — above the Pending Review and Accepted tabs listing per-resource derived tag values (cloud-platform, cost-allocation, data-residency, workload-class), a provider filter, and a Manage tag policies button](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260903/3b81ba7a-5e03-4bcd-8094-67bb6e1735ff-smarttags.png)

*Smart Tags; the Pending Review, Accepted, and Tag Compliance summary cards over the Pending Review and Accepted tabs, filterable by provider and managed from a tagging policy.*

By default a derived value lives **inside ZopNight for cost attribution only** — nothing in your AWS / GCP / Azure account changes. When you *want* the tag on the real resource, an explicit **Apply to cloud** action writes it to the provider — never automatically. See [Applying tags to the cloud](#applying-tags-to-the-cloud).

## How a tagging policy works

A tagging policy enforces one **tag key** and derives its **value** from the resource's own fields. You choose which field drives the value:

| Derive value from | Example result |
|---|---|
| `provider` | `cloud = aws` |
| `region` | `region = us-east-1` |
| `type` | `workload = rds` |
| `instance_type` | `size = m5.xlarge` |
| `name` | `service = payments-api` (parsed from the resource name) |

Because the value comes from fields ZopNight already has for every resource, the policy produces a value for **every** resource in scope; including the ones with no cloud tags at all.

Manage policies from **Settings → Policy → Tagging**.

## Pending vs accepted

A derived Smart Tag doesn't count toward cost attribution until you accept it. This keeps you in control of what shows up in showback.

**Pending**

    The policy derived a value but you haven't accepted it yet. Pending values are visible on the Smart Tags page but are **excluded** from showback and reports.

**Accepted**

    You've accepted the derived value. It now counts toward tag attribution in [Showback](https://zop.dev/docs/zopnight/reports/showback), marked as a derived (Smart Tag) value rather than a native cloud tag.

A derived value is either pending or accepted; anything not yet accepted stays pending. There is no separate "rejected" state; to drop a value, revoke it and it returns to pending.

## Applying tags to the cloud

Accepting a value is a ZopNight-only decision — it drives cost attribution but leaves your cloud account untouched. When you want the tag to actually exist on the resource, use **Apply to cloud**: ZopNight writes it onto the live resource through the provider's own API (AWS / GCP / Azure).

**From Pending**

    **Accept & apply** does both in one step — the value is accepted in ZopNight *and* written to the cloud resource.

**From Accepted**

    **Apply to cloud** writes an already-accepted value onto the resource. Once written it shows an **on cloud** marker; it's counted *and* live, with nothing left to do.

A few properties keep this safe:

- **Additive only.** Apply *sets* the policy's tag; your existing cloud tags are never removed. Revoking a Smart Tag later doesn't strip the tag from the cloud either.
- **Always confirmed.** Every apply asks first, naming how many tags and resources it will write and on which provider.
- **Bulk or single.** Apply one resource or select many; each resource is written independently, so one failure never blocks the rest.
- **Not every type yet.** Some resource types can't be tagged from ZopNight and are skipped — they stay detection-only.

Once the write lands, the tag is genuinely on the cloud resource. On the next discovery refresh ZopNight reads it back as a native tag, so the value shows as **on cloud** and any compliance violation for that key clears at the source.

## Tag compliance

A tagging policy does one of two jobs, and ZopNight picks which from the policy itself; there is no separate mode switch to set:

**Derive**

    The policy supplies a **value** built from resource fields. ZopNight fills the gap by deriving that value where it's missing; the result is a **pending** Smart Tag you accept, exactly as above.

**Validate**

    The policy states a **rule** about a tag rather than a value; a required key, an allowed set of values, or a key that must not exist. ZopNight checks every in-scope resource against the rule and raises a **violation** wherever the tag doesn't comply.

Violations surface under the **Tag Compliance** card on the Smart Tags page — its **Review non-compliant** link opens the full list, each violation labelled by type so you can see *why* a resource is out of policy:

| Violation | What it means | Example |
|---|---|---|
| `missing_required` | The policy requires a tag key and the resource doesn't have it (on the cloud, or as an accepted Smart Tag). | Policy requires `env`; an EC2 instance has no `env` tag. |
| `value_not_allowed` | The tag key is present but its value isn't in the policy's allowed set. | Policy allows `env ∈ {prod, staging, dev}`; a resource is tagged `env = production`. |
| `forbidden` | The tag key is present but the policy says it must not be. | Policy forbids `owner`; a resource still carries a legacy `owner` tag. |

A tag counts as **present** whether it lives on the cloud resource **or** you've accepted it as a Smart Tag. So accepting a Smart Tag for a required key **clears its `missing_required` violation** automatically a short while later, without touching the cloud account — or you can [Apply to cloud](#applying-tags-to-the-cloud) to write the tag onto the resource and fix it at the source. Accepting never hides a wrong value, though; a `value_not_allowed` or `forbidden` violation stays until the actual tag is corrected on the resource.

Only resources the policy's scope selects are judged; a policy scoped to one account or resource type never raises violations elsewhere. Compliance is re-evaluated on every refresh alongside derivation, so a violation clears automatically once the tag is fixed (or the policy changes), the same way an accepted value is reconciled below.

## Reconciliation on every refresh

Smart Tags are re-evaluated on every discovery refresh. An accepted tag is kept **only while it's still derived with the same value**. If a resource changes such that the policy would now derive a different value (for example, it moved region), the old accepted value is dropped and the new one returns to pending for you to review. This stops stale attribution from silently lingering.

## Reviewing derived tags

The **Smart Tags** page opens on two tabs — **Pending Review** and **Accepted** — with a row of summary cards above them: Pending Review, Accepted, and **Tag Compliance**, each with its own org-wide count. Pending Review and Tag Compliance answer different questions; Pending Review is "derived values awaiting your decision", Tag Compliance is "resources breaking a tag rule", so the two counts are unrelated and won't match. The **Review non-compliant** link on the Tag Compliance card opens the violations. From here you can:

- Filter by cloud provider (AWS / GCP / Azure)
- Accept a pending value (per key) so it counts toward attribution
- Revoke an accepted value to return it to pending
- **Apply to cloud** — write an accepted value onto the real resource, one at a time or in bulk
- Review compliance violations by type, and clear a `missing_required` one by accepting a Smart Tag for that key

## Where Smart Tags show up

Once accepted, Smart Tags behave like cloud tags everywhere attribution is done:

- **Showback → Tags tab**: accepted Smart Tags feed the tag attribution table alongside native cloud tags, labelled as derived values so you can tell them apart.
- **Cost Flow Sankey**: any layout with a tag-derived dimension reflects accepted Smart Tags.
- **Tag Coverage widget**: accepting Smart Tags on untagged resources raises your tagged-cost percentage.

## What Smart Tags are not

- They are **not** written to the cloud provider *unless you ask*. A derived value stays inside ZopNight until you explicitly [Apply to cloud](#applying-tags-to-the-cloud) — there is no automatic or silent write-back.
- They are **not** a scheduling trigger on their own; they help you *find and group* resources, but schedules act on the resources you attach. See [Scheduling](https://zop.dev/docs/zopnight/concepts/scheduling).
- They do **not** predict stop-eligibility or any other resource behaviour — a Smart Tag is only an attribution label, never a signal about what a resource does.