skip to content

Your artifact registry and log destination serve both environments after the account split — where should each live, and what keeps the split real?

level: seniorimportance: nice to knowfreq 32%

answer

  1. shared things belong in neither
  2. which direction does each grant run?
  3. environments read in, write in, never called back
  4. delegate a subdomain, don't share the zone
  5. the shared account is now a correlated dependency

basics

~20 s

A service both environments genuinely share belongs in neither: put it in a third account with every grant pointing inward — environments pull artifacts and append logs they cannot delete. A grant back out rejoins what you split.

solid answer

~50 s

Some things legitimately cross the split: the registry holding the artifact you promote, the destination logs and audit records are written to, and the parent name zone. Hosting them inside production gives non-production a standing grant into production, which is the boundary you just paid for; hosting them in non-production makes production depend on your least-guarded account. The usual answer is a third account for shared services, with the **direction of every grant pointing inward**: environments read artifacts from it, environments write logs into it, and it holds no standing credential into production. For the name zone, delegate a subdomain to each environment rather than sharing edit rights to one zone. Then accept the consequence — both environments now depend on that account, so keep it off the serving path and hold it to production's operational standard.

code

json · 12 lines
json
{
  "sharedAccount": "artifact-registry",
  "allowedGrants": [
    { "from": "buildPipeline",  "to": "sharedAccount", "action": "publishArtifact" },
    { "from": "nonProduction", "to": "sharedAccount", "action": "readArtifact" },
    { "from": "production",    "to": "sharedAccount", "action": "readArtifact" }
  ],
  "noStandingGrant": [
    { "from": "sharedAccount", "to": "production" },
    { "from": "nonProduction", "to": "production" }
  ]
}

go deeper

for a junior

Recognise that a few things — the artifact registry, where logs go, the name zone — are genuinely shared, and that putting them inside one environment gives the other a way in.

for a middle

Explain the third-account arrangement and the direction rule: environments reach into the shared account, and it holds no standing credential back into either.

for a senior

Show the compromise-reach reasoning for each shared service, insist that records cannot be deleted by the environment that produced them, and name the delegation model for the name zone.

for a principal

Own the consequence: a shared account is a correlated dependency with production's importance, so decide its operational standard, its owner, and which services are allowed to live there at all.

## Which services genuinely cross the split After production moves into its own account, a short list of things resists being duplicated — not because duplication is hard, but because duplicating them would defeat their purpose: - **The artifact registry.** The whole point of promoting one built artifact is that both environments run the same bytes. Two registries means two artifacts and the promotion argument collapses. - **The destination for logs and audit records.** Correlating an incident across environments, and keeping a record an environment cannot tamper with, both want one destination. - **The name zone.** The organisation publishes one parent domain; each environment needs names under it. - **The source of human identities.** People exist once, whatever access they hold in each account. Everything else — the network, the baseline, the workloads, the data — should be separate, and an argument for sharing it is usually an argument that the split has not really happened. ## Three placements, and what each implies | placement | what it forces | verdict | |---|---|---| | Inside production | non-production needs a standing grant into the production account to pull artifacts or write logs | re-opens the boundary you paid for | | Inside non-production | production depends at deploy time on your least-guarded, most-changed account | inverts the risk | | In a third shared account | each environment holds a narrow grant *into* the shared account, and the shared account holds none back out | the usual answer | The third row is not magic — it is the first two with the grant direction fixed. What makes it work is that the shared account is a *sink and a source of read-only content*, never a caller into either environment. ## Rules that keep the split real 1. **Every grant points inward.** Each environment reaches into the shared account; the shared account holds no standing credential into either environment. If something in the shared account needs to act on production, that is a pipeline with its own short-lived credential, not a permanent grant. 2. **No path from non-production to production, however indirect.** Ask of each shared service: if this account were compromised, what does it reach? A registry that only serves reads answers "nothing"; a deployment agent with standing production access answers "everything". 3. **Write-only where the record matters.** Each environment should be able to append logs and audit records to the shared destination and unable to delete or rewrite them, so an incident inside one environment cannot erase its own trail. 4. **Delegate the name zone, do not share it.** Give each environment authority over a subdomain rather than edit rights to the parent zone, so a mistake in one environment cannot repoint a production name. 5. **Publishing is separate from reading.** The build publishes artifacts; the environments read them. Nothing that runs in an environment should be able to overwrite the artifact another environment is about to run. ## What you have just created A shared account is a **shared dependency**, and that is a real cost of the arrangement rather than a flaw to hide: - Both environments now depend on it, so an outage there is correlated across the split. Keep it off the serving path: not being able to deploy is very different from not being able to serve. - It inherits production's importance. If production cannot deploy a fix without it, the shared account is production-grade infrastructure and gets production's change control, access review and monitoring — not the looser posture of a utility nobody owns. - It needs an owner. Shared accounts drift into being everyone's and no-one's, which is how a temporary standing grant into production gets added at 2 a.m. and never removed. ## Where the honest disagreement is Organisations genuinely differ on whether the log destination should be a third account or should live with production's, and both positions are defensible: a third account keeps the record outside the environment being investigated, while co-locating it reduces the number of accounts to operate. What is not defensible is either environment being able to delete its own records, and that constraint decides the design more than the account count does. The test to apply at the end is simple: list every grant that crosses the split, and for each one say which direction it runs and what it would let a compromise reach. If any of them lets something in the non-production side name a production resource, the split is decorative again — and it will be discovered the same way the original shared account was.

  • Which direction should the grants run between the shared account and production, and why does it matter?
    Inward only: production reads artifacts from the shared account and writes records into it, while the shared account holds no standing credential into production. The reason is compromise reach — a shared account that can act on production turns any weakness there into a production incident, and non-production can usually reach the shared account too, so an outward grant quietly rebuilds the path between environments that the split removed.
  • What new risk does introducing a shared account create?
    A correlated dependency: both environments now fail together if it does. Keep it off the serving path so an outage blocks deploys rather than traffic, and hold it to production's standard for change control, access review and monitoring, because production depends on it. It also needs a named owner — unowned shared accounts accumulate temporary grants that nobody removes.
  • How do you handle the organisation's name zone across the split?
    Keep the parent zone in the shared account and delegate a subdomain to each environment, so each one has authority over its own names and none over the others'. Sharing edit rights on the parent zone would let a change made in non-production repoint a production name, which is exactly the cross-environment reach the account split was bought to remove.

saying these in an interview costs you the question

  • Puts the shared registry inside production because production is the important account.
  • Gives the shared account a standing administrative credential into every environment.
  • Says a shared log destination is fine when the producing environment can delete from it.
  • Treats the shared account as low-importance because nothing serves traffic from it.
  • Assumes sharing one service cannot re-couple environments that were just separated.
  • Shares edit rights on the parent name zone instead of delegating a subdomain.