Before a store can rotate a partner system's credential on a schedule, what must that downstream system itself support?
answer
- ask the downstream, not the store
- a person in a browser blocks it
- who is allowed to make the change
- length, character set, reuse rules
- you must be able to test the result
basics
~20 sFour things from the downstream: a programmatic way to change the credential, an identity allowed to make that change, rules the generated value can satisfy, and a way to test the new value afterwards. Absence of any one forces a runbook.
solid answer
~50 sFour things, and their absence is what forces a human runbook. First, a programmatic way to change the credential that does not require a person in a browser. Second, an identity for the rotating party — an account at the downstream permitted to change that one credential and little else, whose own credential then becomes the long-lived value you have to look after. Third, a value contract the generator can meet: a length and character set the downstream accepts, plus whatever reuse or history rules it enforces. Fourth, a way to verify that the new value actually authenticates, because otherwise you cannot tell a change from a broken change. Whether the downstream will hold a second credential at once decides whether the change is a rotation or a cutover. A portal and a ticket queue supply none of this.
go deeper
Know that whether a credential can be replaced automatically depends on the system that accepts it, not on the store that holds it, and that some systems only allow a person to make the change.
List the four prerequisites and say why each one blocks automation on its own. Be able to explain why the generated value's length and character set are part of the contract.
Bring the operational detail: verification after the change, lockout behaviour under retries, whether existing connections are dropped, and the standing identity the rotating party now needs.
Treat programmatic credential change as a procurement requirement. Decide what you commit to for suppliers who will not offer it, and what narrower rights you buy instead of a shorter lifetime.
## Automation is a property of the downstream, not of the store Teams ask "can our store rotate this?" and the question is almost always answered on the wrong side. A store can generate a value and record a new version any time it likes. What decides whether rotation can happen on a schedule is what the **downstream system** — the thing that accepts the credential — will let something do to it without a person present. Where the answer is "nothing, except through a portal and a ticket", no store feature changes that. ## The four requirements 1. **A programmatic change path.** Something must be able to set a new credential on the account without a browser session and without a human approval in the middle. A change that exists only as a form, a support request or an email thread is not automatable, however good your store is. 2. **An identity permitted to make the change.** The rotating party needs an account at the downstream with the right to change that one credential, and as little else as possible. This is not free: that account's own credential is long-lived, highly privileged, and cannot be rotated by the same run that depends on it. 3. **A value contract the generator can satisfy.** Downstream systems constrain credentials in ways nobody documents until a rotation breaks. 4. **A verification path.** You must be able to authenticate with the new value after setting it. Without that step, the run can only report what it attempted, and cannot distinguish a successful change from a change to something unusable. ## The value contract nobody checks until it breaks - A **maximum length**, sometimes enforced by silent truncation rather than an error. - A **character set**: characters the downstream's own parsing treats specially, or that break the way consumers assemble a connection string. - **Reuse and history rules** that refuse a value resembling a previous one, which a generator will occasionally trip. - **Whether a change disturbs existing connections** — some downstreams drop authenticated sessions on a credential change and some do not. - **Lockout behaviour** on repeated failed attempts, which turns a retrying rotation job into an outage of its own. ## One credential, or two Whether the downstream will hold two credentials for the same identity at once changes the nature of the change entirely. | Downstream holds | The change is | What automation must add | |---|---|---| | Two credentials at once | a rotation: the new value works before the old stops | a later, separate withdrawal of the old value | | Exactly one credential | a cutover: the old value stops at the instant the new one starts | a change window and a verified list of who is affected | With a single credential slot there is no ordering to choose at the downstream — applying the new value **is** the withdrawal of the old one, in the same instant. The only ordering you control is when you record the new value relative to applying it. ## The credential that changes the credential Automating rotation moves the hardest credential rather than removing it. Whatever identity performs the downstream change holds standing rights, and its own value cannot be rotated by the run that uses it. Realistic answers: give it rights over exactly one account, give it a separate and deliberately manual replacement path, and make its use visible so that a change it did not make stands out. An interviewer listening for seniority is listening for whether you noticed this at all. ## When the answer is no If the downstream offers a portal and a ticket queue, the honest answer is not "automate it anyway". It is: - a written runbook with a named owner and a rehearsal, - a lead time booked against the supplier's queue rather than assumed, - narrower rights on the credential so that an older value costs less, - and programmatic change written into the next contract, because that capability is a purchasing decision and not a technical one. Stores differ in how far they will go here — some will perform a downstream change themselves for systems they understand, others only hold what you give them — but neither kind can invent a change path that the downstream does not offer.
- What does the rotating party need at the downstream, and why is that a new problem?An account with the right to change that one credential and nothing else. That account's own credential is now long-lived and highly privileged, and it cannot be rotated by the run that depends on it — so it needs a separate replacement path, usually manual, and tight scope. Automating rotation relocates the hardest credential; it does not remove it.
- The downstream silently truncates any credential longer than 32 characters. What do you see?Authentication fails for every consumer presenting the full value, while the run's record says both sides changed successfully. Nothing in that record distinguishes 'changed' from 'changed to something else'. A verification step that authenticates with exactly the value the store now holds catches it; a generator constrained to the downstream's stated length and character set prevents it.
- The downstream supports programmatic change but holds only one credential. What changes?The change becomes a cutover: the old value stops working at the instant the new one is applied. Automation is still possible, but its blast radius is every consumer at once, so it needs a change window, a known list of who is affected and a back-out — not simply a nightly timer.
saying these in an interview costs you the question
- Any credential can be automated if the store supports rotation
- The generated value can be any length the store produces
- Changing an account's credential needs no separate identity to do it
- A successful change call proves the new value authenticates
- A downstream holding one credential rotates like one holding two
- A scripted ticket to a supplier counts as automation