advanced 2 min answer

Design the break-glass access mechanism for production. What are the requirements?

accessincidentcontrols
Show the full answer Hide the answer

What the interviewer is testing

Whether you can design a control that is genuinely fast enough to replace standing access, which is the only way it succeeds.

The requirements

Fast. Seconds, not minutes. If elevation is slow, engineers will retain standing access by any means available and the control fails. This is the binding constraint and it should be stated first.

Time-bounded. One hour by default, automatically revoked. No manual cleanup step, because manual cleanup does not happen.

Reason-linked. Tied to an incident or ticket reference, recorded with the grant.

Conspicuous. Announced to a channel where colleagues see it in real time. Visibility is the control that does most of the work — it is a far stronger deterrent than approval, and it catches misuse quickly.

Fully session-logged, with commands and queries recorded, retained for the audit period.

Notify-and-review, not approve-before-grant, for operational access. An approval gate at 3 AM is either circumvented or it extends the outage. The review happens afterwards, and it must actually happen.

Scoped. Elevation grants the specific access needed, not a full administrator role. Several break-glass roles for different purposes is better than one that grants everything.

The requirement most often missed

It must not depend on the system that is down. If identity, network or the cloud control plane is the failing component, the normal elevation path may be unavailable. A genuinely independent fallback must exist — and be tested, because a path first used during an outage is not a path.

The measure of success

Break-glass usage trending down over time as tooling absorbs the recurring cases. Every repeated use of break-glass for the same task identifies a missing capability that should be built into normal tooling with proper scoping.

What a strong answer adds

The framing that gets engineering support: an engineer with no standing access cannot be blamed for an incident they could not have caused, and is not worth phishing. Positioning it as protection for the individual rather than suspicion of them changes the reception entirely.

Common weak answers

An approval workflow with a service level target. Standing access with better logging.