Day-to-day operators use the cloud provider's browser console, while emergency break-glass accounts are reserved for outages. How should IAM treat these paths?
Select an answer to reveal the explanation.
Short Explanation
Everyday console logins need normal badges; the glass-break axe behind the alarm stays locked, logged, and rare. Both paths are IAM—break-glass just gets tighter controls, not a wiki password.
Full Explanation
Both day-to-day browser console access and emergency break-glass accounts fall under IAM governance. Apply IAM controls to both paths, with stricter protection, limited standing time, and heightened auditing on break-glass accounts reserved for outages. Municipal cloud estates need reliable emergency entry without turning break-glass into an unmonitored backdoor.
Leaving break-glass accounts with shared passwords on a wiki and no monitoring invites abuse. Disabling the browser console entirely because only break-glass should ever be used is operationally unrealistic. Allowing break-glass permanent standing admin without review because "emergencies never end" defeats the purpose of emergency-only access.
Exam caveat: break-glass should be tightly controlled, monitored, and reviewed after each use; console users still need least privilege and MFA. Shared passwords are never an acceptable break-glass design.
Operational check: vault break-glass credentials, require dual control or check-out, alert on any login, review usage post-incident, and keep normal operators on federated console roles with MFA. Document the procedure in the city’s incident runbook.
After any break-glass use, require a retrospective note in the incident ticket describing why normal console roles were insufficient, then rotate credentials so emergency municipal access cannot become standing shadow admin.