resource-naming-and-tagginglisted

## Purpose Give every resource a name and a set of tags that let anyone — not just the person who created it — answer "what is this, who owns it, what does it cost, and can we turn it off" without having to ask around. This is the concrete template behind the "Consistent Naming And Tagging" rule. ## When to use it Any time you're scaffolding a new resource, renaming an existing one to bring it into line, or reviewing a plan/diff for naming and tagging consistency. ## Naming convention Compose resource names from fixed segments, in a fixed order, separated by a single consistent delimiter (hyphen is the safest default — some resource types don't allow underscores or dots): ``` <resource-type-abbreviation>-<workload>-<environment>-<region>[-<instance>] ``` - **resource-type-abbreviation** — a short, consistent code for what the resource *is* (e.g. `vm`, `sql`, `st` for storage, `kv` for a secret/key vault, `func` for a function app). Pick one abbreviation per resource type and never vary it. - **workload** — the application or system the resource belongs to, short and stable (e.g. `billing`, `checkout`, `ingest`). This is usually the most important segment for grouping resources in cost/ownership views. - **environment** — `dev`, `test`, `stage`, `prod` (or your project's equivalent set — pick one fixed vocabulary and don't let synonyms like `production`/`prd`/`prod` coexist). - **region** — a short code for the deployed region (provider-specific, e.g. `eus` for East US,