The AWS Root User: What It Can Do and How to Protect It

The AWS root user is the identity created when an AWS account is opened, signed in with the email address and password used at signup. It has complete, unrestricted access to every resource and service in the account, and its permissions cannot be limited by any policy. Because of that power, AWS best practice is blunt: secure it with multi-factor authentication (MFA), delete any root access keys, and stop using it for everything except the short list of tasks only the root user can perform.

What makes the root user different

Every AWS account has exactly one root user. It is not an IAM (Identity and Access Management) user; it sits above IAM entirely. Three properties define it:

• Unlimited permissions. The root user can do anything in the account, always.
• Unrestrictable permissions. You cannot attach an IAM policy to the root user to trim its access. An explicit Deny that would stop any IAM identity does not stop root. (The one nuance, beyond CLF-C02 depth: in an AWS Organizations setup, service control policies can restrict member-account root users, which is part of why organizations centralize root access.)
• Irreplaceable functions. A handful of account-level operations accept no substitute identity.

Compare that with an IAM administrator user: an admin can be constrained, monitored, and deleted. The root user can only be protected. That asymmetry is the entire reason the best practices exist.

	Root user	IAM admin user
Created	Automatically, at account signup	Deliberately, by an administrator
Sign-in	Account email address + password	IAM username + password
Permissions	Everything, always	Whatever policies grant
Can be limited by IAM policy	No	Yes
Appropriate use	Root-only tasks, rarely	Daily administration

Tasks only the root user can perform

The exam expects you to recognize that some operations are root-exclusive. The notable ones:

• Change the account’s root email address, root password, or account name.
• Close the AWS account.
• Change or cancel the AWS Support plan.
• Activate IAM access to the Billing and Cost Management console (until root flips this switch, even full-admin IAM users cannot see billing data).
• Restore permissions if the only IAM administrator accidentally locks everyone out.
• Register as a seller in the Reserved Instance Marketplace.
• Enable MFA Delete on an Amazon S3 bucket, and edit certain S3 bucket policies that have become invalid.
• Sign up for AWS GovCloud (US).

You do not need to recite the whole list. You need the concept: if a scenario involves closing the account, changing the support plan, or changing the root email, the root user must do it. Everything else belongs to IAM identities.

The best practices themselves

Enable MFA on the root user immediately. MFA requires a second factor beyond the password: a virtual authenticator app, a FIDO security key or passkey, or a hardware TOTP (time-based one-time password) token. AWS allows registering multiple MFA devices on the root user so a lost device does not lock the account. If a CLF-C02 question asks for the single most important step to protect the root user, MFA is the answer.

Do not create root access keys, and delete any that exist. Access keys enable programmatic access through the CLI (Command Line Interface) and APIs. Root access keys are long-term credentials with unlimited power, and no automation legitimately needs them. Any script that “requires” root keys should run under an IAM role instead.

Use a strong, unique password stored securely, and tie the root email to a managed distribution address the organization controls rather than one employee’s personal inbox, so account recovery survives staff turnover.

Do not use the root user for daily work. The first thing to do in a new account is create an administrative identity (an IAM user, or preferably workforce access through AWS IAM Identity Center) and sign in with that from then on. Day-to-day permissions design is covered in the IAM users, groups, roles, and policies article.

Monitor root activity. AWS CloudTrail records every root sign-in and API call. Mature accounts alarm on any root usage at all, because legitimate root activity should be rare and scheduled.

Never share root credentials, and never embed them anywhere: not in code, not in configuration files, not in a wiki.

Why the exam cares

The root user sits inside the “Security and Compliance” domain because it is the purest test of two ideas CLF-C02 keeps returning to. First, least privilege: the identity with the most privilege should be used the least. Second, the customer side of the AWS shared responsibility model: AWS secures the cloud infrastructure, but protecting account credentials, enabling MFA, and managing identities is squarely the customer’s job. A compromised root user is not an AWS failure; it is a customer-side failure the best practices exist to prevent.

How the CLF-C02 exam tests this

• A scenario describes a newly created AWS account and asks for the first security steps. The pattern answer: enable MFA on the root user, delete or avoid root access keys, create IAM identities for daily work.
• A stem asks which task requires the root user. Closing the account, changing the support plan, and changing the root email are the recurring correct answers; launching EC2 instances or creating IAM users are the distractors, since any properly permissioned IAM identity can do those.
• A question asks who is responsible for enabling MFA on the root user under the AWS shared responsibility model. The customer, always.
• A company notices unexpected root sign-ins and asks which service records that activity. CloudTrail.
• An answer choice suggests giving administrators the root password “so they can do everything.” That is always wrong; administrators get IAM permissions, and root credentials are never shared.

Quick reference

• One root user per account, signed in with the account email; full access that no IAM policy can restrict.
• Enable MFA on root first; multiple MFA devices can be registered.
• No root access keys, ever; delete existing ones.
• Use root only for root-exclusive tasks: close account, change support plan, change root email or password, activate IAM billing access, restore lost admin access.
• Daily administration runs under IAM identities or IAM Identity Center, built on least privilege.
• CloudTrail logs root activity; alert on any of it.
• Protecting root credentials is the customer’s responsibility in the AWS shared responsibility model.