Root user protection and break-glass access: SCS-C03 study notes and practice questions
What to know about Root user protection and break-glass access for the SCS-C03 exam, from the Security Foundations and Governance domain (14% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a root user that is shared, has access keys, or has no MFA, plus a requirement to use it only for emergencies. The right answer removes everyday root use, locks down what remains, and makes any root activity visible.
What decides the answer
The root user can do a few things no IAM policy can grant, such as changing the account’s root email address and closing the account. Those tasks are rare, so treat root as a last resort.
MFA on the root user is required. Use a hardware or passkey option where possible, and register more than one device so that losing one does not lock you out.
No root access keys. Delete any that exist. Programmatic work should use roles, which issue temporary credentials.
Centralized root access management lets the management account of an organization delete the root credentials of member accounts (password, access keys, MFA and signing certificates) and perform the few privileged root tasks through a short-lived root session. You need trusted access enabled for it.
SCPs apply to member-account root users, so an SCP deny can block root actions in those accounts. They cannot restrict the root user of the management account.
Break-glass access is an IAM role or IAM Identity Center permission set that requires MFA, is used only in an emergency, and triggers an alert whenever it is assumed.
Detection comes from CloudTrail. Root sign-ins and API calls appear with a user identity type of Root. Send them to Amazon EventBridge and an SNS topic so the security team learns of each use.
Storage: the root password belongs in a controlled vault with restricted access, not in a shared document.
How to choose
Scenario wording
Pick
Remove root credentials from hundreds of member accounts
Centralized root access management from the management account
Alert the security team whenever root is used
EventBridge rule on CloudTrail root events
An on-call engineer needs admin access during an incident
IAM role or Identity Center permission set with MFA, used as break-glass
Stop member-account root users from taking an action
SCP deny, which applies to member-account root
A CI pipeline needs AWS access without stored keys
IAM role with OIDC federation, not root or IAM user keys
Common traps
Leaving root access keys in place “for scripts.” Scripts should use roles.
Expecting a policy to restrict root in the management account. No SCP or RCP applies there.
Sharing one root login among a team. Shared use removes accountability.
A break-glass path nobody tests. An emergency role that fails when needed is no protection.
Alerting only on console sign-in and missing root API calls made with root credentials.
Using root to fix an IAM mistake when a role with the right permissions could do the job. Use root only when the task requires it.
Read the centralized root access guide and the root user overview. The first explains root sessions and which tasks they allow, and the second lists the tasks that still need the root user.
A logistics group has 60 member accounts in one AWS organization. Many of the accounts were created years ago, and their root users still have passwords and MFA devices held by former staff. The security team wants to remove root credentials from every member account, and still be able to perform the few root-only tasks that sometimes arise.
The team does not want the management account root user used for routine work, and it does not want to share any root password.
Which solution meets these requirements?
Choose one answer.
AA. Create a shared password for the root user of each member account, store it in the company password vault, and limit vault access to the security team. Rotate the passwords every 90 days and log each retrieval.
BB. Create an access key for the root user of each member account, and store the keys in a secrets manager that automation can read. Delete the root password, so that the access keys become the only root credential.
CC. Turn on centralized root access management, delete the root credentials of the member accounts, and start a short-lived root session from the management account when a root-only task is needed.
DD. Enable MFA on the root user of each member account with a hardware key, and keep the root password in a sealed envelope in a safe. Ask the security team to check the safe every quarter.
Show the answer and explanation
Answer: C
A. Wrong: A shared root password keeps the full root power in every account, and the team forbids sharing root passwords. Rotation and vault logging do not remove the risk of an unknown holder.
B. Wrong: Root access keys give unlimited programmatic access, and they are long-term credentials that automation would expose. Deleting the password does not reduce the root user power, so this creates a larger risk.
C. Right: Correct. Removing member root credentials leaves no standing root access, and short-lived root sessions are issued only for approved tasks. The management account root user is not used for routine work. Learn more: Root user (opens in a new tab)
D. Wrong: MFA and a sealed password reduce misuse, but they keep standing root access in every account. The quarterly check is manual work, and the root credentials still exist in every account.
Explanation
Centralized root access management removes root credentials from member accounts, so no one holds standing root access there. Root-only tasks run through short, controlled sessions started from the management account. Shared passwords, root access keys, and MFA with a sealed password each keep standing root power.
Want more on Root user protection and break-glass access? The 5 full-length practice sets have 5 more Root user protection and break-glass access questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →