A city clerk still signs in with the AWS account root user for everyday console work. What should the architect recommend for day-to-day access while protecting root?
Select an answer to reveal the explanation.
Short Explanation
Root is the master key to city hall—you do not carry it to grab coffee every morning. Day-to-day work should use Identity Center or IAM identities, with MFA on root and the root credentials locked away. Root stays for rare break-glass moments, not routine clicks.
Full Explanation
Day-to-day municipal console work must not use the AWS account root user. Root is the account owner identity with unrestricted access that bypasses ordinary IAM denials; sharing it for routine clerk tasks violates least privilege, destroys individual accountability, and turns every phishing or shoulder-surfing incident into a full-account compromise. The architect should move clerks to AWS IAM Identity Center (successor to AWS SSO) or to IAM users and roles for ordinary work, enable multi-factor authentication on the root user, securely store root credentials, and reserve root for rare break-glass tasks such as initial billing setup, restoring critical IAM lockouts, or account closure workflows. That pattern mirrors how a city clerk keeps the master vault key in a sealed pouch rather than on the everyday keyring.
Sharing the root password among clerks and rotating it in a spreadsheet fails on confidentiality, non-repudiation, and operational safety: multiple humans share one principal, MFA is awkward or skipped, and spreadsheets leak. Creating long-lived root access keys for scripts is explicitly discouraged by AWS; root keys are high-value standing credentials that should not exist for automation. Disabling the root user permanently is not a supported or advisable design—you cannot eliminate the root principal, and removing break-glass recovery paths can strand the account during emergencies.
Exam caveat: root MFA is necessary but not sufficient; also remove any root access keys if they exist, use a hardware MFA device for root when policy requires it, and ensure break-glass procedures are documented and tested. Identity Center permission sets or IAM roles should map to job functions (clerk read/write scopes), not AdministratorAccess by default. Operational check: confirm root cannot sign in without MFA; verify clerks authenticate via Identity Center or IAM and that CloudTrail shows distinct principals for their actions; attempt a routine S3 or console task as root only in a controlled drill and otherwise keep root offline.