A developer asks for permanent admin on the production cluster 'to debug faster.' What do you offer?
Short answer
Least privilege plus just-in-time access: grant the minimum permissions needed, time-boxed and logged, so debugging is possible without standing admin that becomes a permanent risk and audit gap. Permanent cluster-admin violates least privilege and widens the blast radius of any compromise. A blanket denial blocks legitimate work and invites risky shadow workarounds. Sharing the common admin service-account credential destroys accountability — actions can't be traced to a person.
This is a least-privilege judgment call dressed up as a help request. The candidate must balance enabling the developer against the standing risk that permanent admin creates — and find the option that does both.
Why just-in-time access is the right answer
Standing privilege is the problem; access on demand is the solution. Just-in-time (JIT) access grants the specific permissions the developer needs, only for the window they need them, with every action logged. When the timer expires, the access evaporates — there's no dormant super-account waiting to be phished, leaked, or abused months later. Combined with scoping (only the namespaces, verbs, or resources relevant to the debugging task), it satisfies least privilege while still unblocking the work. The developer debugs; the org carries almost none of the long-term risk.
Why the distractors are wrong
- Grant permanent cluster-admin. This is the textbook least-privilege violation. A standing god-mode credential dramatically widens the blast radius: compromise that one account and the attacker owns production. It also rots — granted "temporarily," forgotten forever.
- Deny all access; file tickets for everything. Security theater that punishes legitimate work. When the sanctioned path is too slow, people build shadow workarounds — copied creds, side channels, disabled controls — which are less safe than a governed JIT flow.
- Share the admin service-account credentials. The worst option for forensics. Shared credentials mean actions can't be attributed to an individual, so you lose accountability, break audit trails, and can't revoke one person without disrupting everyone.
What the interviewer is probing
They want to see that you reflexively reach for least privilege and reject standing admin, but also that you're pragmatic — you don't just say "no," you offer a workable path. The signal is JIT plus scoping plus audit logging, and the explicit recognition that shared credentials and blanket denials both fail in their own way.
Likely follow-ups
- How would you implement JIT access approval and automatic expiry in practice?
- How do you scope permissions to a real debugging task without over-granting?
- Why is a shared service-account credential an accountability and forensics problem?