Every site gets a clean boundary

1. Zone mandate The apex site is authorized for https://{zone} and optional preview.{zone}. That authority does not grant broader Azure roles.
2. Another public site www receives another repository, prefix, and uploader. It does not speak for the zone apex.
3. Redirect where useful Basic redirect mode sends the whole host to one destination with no origin fallback. Intermediate/Dedicated may run reviewed 307 rules first and forward unmatched requests to origin.
4. Protect inventory No FQDN may be reused. A preview collision is an onboarding failure, never a silent takeover.

Apex authority is a product decision

Authorization to maintain a zone apex means the owner has a mandate over its canonical web URL and optional preview hostname. It does not mean the uploader receives DNS, certificate, route, or purge power. A team authorized for www.example.tld cannot infer authority over example.tld.

Related names may still be separate sites

www.xyz.tld and xyz.tld remain separate repositories, project prefixes, and uploader identities. A redirect-only www leaf can use the proposed Basic whole-host 307 mode; it has no served origin content. A second source such as www-preview.xyz.tld needs another Basic envelope or an Intermediate reservation. Combining static content with path-specific redirects is also Intermediate/Dedicated.

Under the proposed CDN placement model, Basic permits only one fixed redirect shape: one optional live FQDN, one unconditional whole-host 307, no preview/content. Custom redirects use a guaranteed Intermediate reservation or the maximum Dedicated reservation. A site can begin there or migrate later without moving blobs: the platform probes target, rehearses preview when present, schedules live, verifies and soaks, then frees source. Unsupported declarations remain inactive with a migration-required warning.

Changing redirect behavior has a different cache consequence from publishing content. The redirect apply purges the source tree—often /*—whereas a normal deploy purges only stable paths on the site that just published.

Environments are peers inside one site

A production hostname and its provisioned preview hostname are different Front Door domains with different public/ and state/ subtrees beneath the same project id. They are separate caches, but not separate security principals. Once route inventory proves both exact origin paths, the trusted platform purge job may authorize a production-triggered purge of preview or the reverse; the uploader itself never receives Front Door permission.

One-to-one relationships make change boring

Keeping repository, uploader client id, and project prefix together reduces the surface area of onboarding, ownership transfer, and teardown. It does not physically partition the shared storage account or Front Door profile. Storage path conditions protect writes. The steward invalidation job protects the shared edge by intersecting GitHub's real caller repository, the one requested FQDN, and platform-owned route inventory; knowing a project id or creating a matching blob folder grants nothing.

Back to the owner overview, then read why hostname inventory matters or how the project prefix joins the pieces.