Your nightly job fails writing to another team's object store, yet the same write works from your own session — what do you check first?

## The shape of the bug A nightly reconciliation batch owned by one team writes its output into an object store owned by another team's account. An engineer runs the same write by hand and it succeeds; the scheduled run is denied. Nothing in the code differs. This is the single most common cross-team permission failure, and it has one root cause dressed in two coats: **the two runs are not the same principal**, and **the call crosses an account boundary, so one side of the grant can only be written by somebody else**. ## Step one: name the principal, before touching any permission The interactive run was authenticated as a human principal — your login, carrying whatever your group memberships gave you. The scheduled run was authenticated as the job's workload principal. Those are different identities, so they resolve to different grants, and "it works for me" says nothing about the job. Where to read it: - The **denial itself** normally names the principal it refused and the action it refused, which is usually enough to confirm you were reasoning about the wrong actor. - The **audit trail of management and data calls in the account that owns the store** shows the refused attempt from the resource owner's side, which is the view your own account cannot give you. Until you have the principal in hand, every permission you read is a guess. ## Step two: work out which of the two sides is missing The call crosses an account boundary, so it needs both: | Side | Who can edit it | What it must say | |---|---|---| | Identity-attached, in your account | Your team | The job's principal may perform the write on that resource | | Resource-attached, on the store | The other team | That specific outside principal may write here | Now the reason your own session worked becomes visible: the store's owner had almost certainly named something that covers humans — your group, or the set of engineers — and never named the job, which did not exist when the grant was written. So the identity side is fine for you, fine for the job, and the resource side covers only one of you. The practical check is a subtraction: if your account's grant already permits the job's identity to perform the action, the missing allow is on the other side by elimination, and no edit you can make will supply it. You raise a request naming exactly the principal and the action. ## Step three: rule out a deny, not just a missing allow There is a second possible shape, and it looks identical from the outside. Instead of a missing allow, an **explicit deny** that matches the call may exist, and an explicit deny outranks every allow on either side. The tell is usually in the denial: platforms that support an explicit deny commonly distinguish it from the default refusal, and the fingerprint is that the call keeps failing no matter how much allow is added. If adding a grant changes nothing at all, stop adding grants and go looking for the deny. ## The wrong fixes, and why they are worth naming 1. **Widening your own identity-attached grant.** The instinct is to edit the side you control. Across an account boundary it cannot work, and it leaves a much broader permission behind that nobody will remember to narrow. 2. **Running the job as a human.** Making the schedule use a person's credentials makes the symptom disappear and destroys attribution, ends the moment that person leaves, and gives the batch every permission its author has interactively. 3. **Asking the other team to open the store broadly.** A grant naming everyone solves your case and every future case you did not want solved. Ask for your principal by name. ## What the interviewer is listening for That you diagnose by actor first, that you know a cross-boundary call has two owners and therefore two documents, and that you can say which one you are able to change. Candidates who have not lived this reach straight for the permission document they can edit; candidates who have, ask "what did it run as?" before they open anything.