TenantRole::Marketing makes the separation a compile-and-test invariant rather than an operator's memory: each
provisioner refuses the others' project before the first GCP call, and a dry-run test asserts a marketing run creates no
cluster, network, or documents bucket. A client document cannot land in the project whose buckets are world-readable,
because the command that creates documents buckets will not run there.
The certificates are the part worth dwelling on. A classic Google-managed certificate is validated by a CA calling the
load balancer, so DNS has to point there first — moving a live hostname takes it down for the length of issuance, and
Cloud CDN and the HTTP-to-HTTPS redirect both sit in the validation path. ops gcp marketing setup uses Certificate
Manager with a DNS authorization instead: Google returns a CNAME, the CA reads that record, and the certificate
reaches ACTIVE while the hostname still serves its current site. Publish the CNAME first, wait for ACTIVE, then
move the A record — the cutover carries no TLS gap.
Name the collision before someone discovers it. A hostname serves one thing, and the matrix on the next slide gives
www.neonlaw.com to the neon-law-prod deployment — its NAVIGATOR_PUBLIC_HOST, certificate, and authorized OAuth
redirect URI are all issued for that name. A marketing site held it first, and the conflict was settled by retiring that
site rather than rehoming it: the load balancer and certificate chain are gone, and only the bucket remains, as an
archive nothing routes to. That is the cost worth naming — a static site is cheap to publish and awkward to unpublish,
because the hostname is the part two things want.
www.neonlaw.com was the same collision, and it has since been settled the same way: the Foundation's Navigator
deployment now holds that exact name and serves it, and the marketing site no longer routes there. neonlaw.com
redirects to it and serves nothing itself.