Forty developers share one service account to access a partner API because the partner charges per credential. What do you do?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can solve an attribution problem when the external constraint cannot be changed.
The problems with the current state
No attribution. Every call looks identical, so misuse, mistakes and compromise are indistinguishable, and several controls collapse at once — segregation of duties, access review, and incident forensics.
No revocation granularity. When someone leaves, the only option is rotating a credential used by forty people and every automated process, which is disruptive enough that it does not happen.
Wide exposure. The credential is in forty developers' local configuration, and likely in a shared document.
The fix
Interpose a proxy service that holds the partner credential. Developers and applications authenticate to the proxy with their own identity; the proxy authenticates to the partner with the single shared credential.
This gives everything the partner's pricing model denied:
- Per-user attribution in the proxy's logs
- Authorisation — who may call which partner endpoints, and with what parameters
- Revocation by disabling an individual's access to the proxy, with no partner credential rotation
- Rate limiting and quota management per caller, protecting the shared quota from one caller consuming it
- A single place to rotate the partner credential
- Caching, which frequently reduces partner cost enough to fund the proxy
The shared credential now lives in one place — the secret manager — accessible only to the proxy's workload identity, with no human holding it.
The additional benefits worth mentioning
The proxy is also where you put the circuit breaker, the timeout policy and the retry behaviour for a third-party dependency, which are needed regardless.
What a strong answer adds
Raising the commercial angle in parallel: partners charging per credential often have an enterprise tier with per-user identity, and the security and audit requirement is a legitimate procurement argument. Solve it technically now, and pursue the commercial fix for the longer term.
Common weak answers
Accepting it because the partner's pricing forces it. Rotating the credential frequently, which does not address attribution.