CAF Naming — The Convention That Scales

The Microsoft Build 2026 refresh turns the CAF matcher from a simple puzzle explainer into a governance article about naming that scales. The SPA teaches the same muscle memory platform teams need in production: choose the resource type, match the CAF pattern, validate the name before provisioning, and keep Azure and Microsoft Fabric artifacts consistent enough for ownership, cost attribution, and automation.

• {type}-{project}-{env}-{region}-{instance} — Core Azure CAF Pattern

• PR-Gated — Names Validated Before Merge

• Azure Naming Tool — Standardize and Automate

• lh_<domain>_<layer> — Fabric Pattern

Choose Type→ Match Pattern→ Validate→ Provision→ Govern

Why Naming Conventions Matter

Cloud sprawl starts as a readability problem. If a resource name does not reveal type, workload, environment, and region, every incident, cleanup, and cost review begins with a manual lookup. CAF-aligned naming converts the name itself into operational metadata.

The matcher game reinforces that pattern by asking players to connect resource types to compliant names. In production, the same matching happens in pull requests, deployment pipelines, inventory exports, and chargeback reviews.

Consistent naming improves ownership, cost attribution, and governance. A resource named func-coredata-prd-usw2-001 immediately reads as an example project code for a production Function App in West US 2. A name like app-final-v2 does not.

The CAF Pattern Explained

The Azure resource convention used by the demo follows a hyphenated Cloud Adoption Framework pattern:

{type}-{project}-{env}-{region}-{instance}
func-project-dev-usw2-001
kv-coremon-prd-usw2-001   # coremon is an example project code
umi-coredata-dev-usw2-ctl  # ctl marks a control-plane identity

Resource-Type Abbreviations

The canonical table keeps names predictable across subscriptions. It is grounded in the Microsoft CAF abbreviation guidance and extended with common deployment, identity, data, analytics, network, monitoring, and Fabric-adjacent resource types used by modern Azure platforms.

Special Cases

Not every Azure service can use the hyphenated pattern exactly. CAF is a convention, but Azure resource-name rules still win.

Fabric Artifact Naming

Microsoft Fabric artifacts use a different but complementary convention. Instead of hyphenated Azure resource names, Fabric workspace items use underscore-delimited prefixes that make the artifact type, domain, and medallion layer visible in the workspace list. Common wildcard patterns include lh_*_brz, lh_*_slv, lh_*_gld, and nb_*_dq_*.

Bronze: lh_sales_brz, pl_ing_erp_sales_brz, nb_dq_sales_brz
Silver: lh_sales_slv, pl_tfm_sales_brz_slv, nb_dq_sales_slv
Gold:   lh_sales_gld, dw_sales_gld, sm_sales_performance, rpt_sales_dashboard

Enforcement at the PR Gate

Naming conventions work when they are checked before resources exist. The PR gate should validate IaC names with the Azure Naming Tool, run the Bicep linter, and fail the build when a resource cannot be traced to the expected pattern.

Azure Naming Tool callout: Use the Azure Naming Tool to standardize and automate name generation. Pair it with source-controlled naming rules so reviewers see the same result the pipeline enforces.

Pull request opens
  → bicep build / bicep linter
  → naming-rule validation
  → storage and key-vault special-case checks
  → policy-as-code and deployment preview
  → merge only when names are compliant

This is the operational lesson behind the SPA. The game rewards correct matches immediately; the platform should do the same by catching drift in code review rather than after deployment.