Protecting the root user, and handling access keys, password policies and stored credentials

Why this matters

Every AWS account starts life with one identity that can do anything: the root user. Whoever holds its email address and password can read every bucket, delete every server, change the billing details and close the account. Small businesses often sign up, keep using that first login for everything, and never think about it again. Then a reused password leaks, or someone gets into the email inbox, and the attacker owns the whole account rather than a corner of it.

The same pattern repeats with the credentials that programs use. A developer pastes an access key into a script to get something working, the script is pushed to a shared repository, and within hours the key is being used by someone else. A database password written into an application's configuration file is read by everyone who can read that file.

None of this needs deep engineering knowledge to prevent. A manager should know that root sign-ins are a red flag, a salesperson should be able to explain why AWS offers a service just for storing secrets, and a junior engineer should know the first five minutes of work on any new account. This lesson covers all three.

The lesson

Why the root user matters so much

The root user is the identity created when an AWS account is opened. It signs in with the account's email address and a password, and it has complete, unrestricted access to every resource, every setting and the billing information in that account. There is exactly one root user per account.

What makes it dangerous is that IAM policies inside the account cannot limit it. In lesson 9 you met IAM users, groups, roles and policies, which let you grant each person only what they need. The root user sits outside that system: you cannot attach a policy to it that takes permissions away, and you cannot turn it off from inside the account. So if its credentials are stolen, the compromise is total. Nothing else in the account can stop it.

Note what the root user is not. It is not the only identity that can launch Amazon EC2 instances, create IAM users or create Amazon S3 buckets; any IAM identity with the right permissions can do those things. Its credentials do not expire each day, and it is not shared between customers. Each account has its own, and it stays valid until someone changes it.

Access keys, password policies and somewhere safe to store secrets

Access keys are how an IAM user proves its identity to AWS from a program rather than a browser. An access key has two parts: an access key ID, which identifies the key, and a secret access key, which is used to sign each request. A developer who runs AWS Command Line Interface (AWS CLI) commands from a laptop as an IAM user configures those two values, and the CLI signs every call with them. A console password, even one protected with MFA, is a different credential: it signs a person in to the AWS Management Console and is not what the CLI uses. Lesson 12 covers the console, the CLI and the SDKs in more detail.

Access keys are long-term credentials. They stay valid until someone deactivates or deletes them, so a leaked key is useful to an attacker for as long as nobody notices. That is why AWS recommends IAM roles wherever possible. When a role is assumed, AWS issues temporary credentials that expire automatically after a limited period, so a leaked one gives an attacker only a short window. Temporary credentials are not more powerful than an access key; they carry exactly the permissions the role allows.

If access keys are exposed, for example pasted into source code in a shared repository, treat them as compromised. Deactivate them, issue new ones, and remove the secret from the code, ideally replacing it with a role. Adding MFA to the user does not help here: API calls signed with access keys do not ask for MFA unless a policy specifically requires it, so the leaked keys keep working.

To see the state of every user's credentials at once, generate an IAM credential report. It is a downloadable list of every IAM user in the account, showing the status of each user's password, access keys and MFA devices, including when keys were last rotated or used. Do not confuse it with AWS Artifact, which provides AWS's own compliance reports (lesson 7), not information about your users.

An IAM account password policy sets the rules that IAM users' console passwords must meet: minimum length, required character types such as symbols, how often passwords expire, and whether old passwords can be reused. Two limits matter for the exam:

• It applies to IAM users only. It does not govern the root user's password, and it says nothing about access keys.
• Users of AWS IAM Identity Center follow the rules of that service's own identity source, not the IAM password policy.

An AWS Config rule can report whether a suitable password policy exists, but the password policy itself is what enforces the rules.

Applications also need secrets: database passwords, API keys for third-party services, tokens. Writing these into code or configuration files exposes them to anyone who can read the files, and putting them in a public S3 object exposes them to the whole internet. AWS offers two places to keep them instead.

AWS Secrets Manager stores secrets encrypted with AWS Key Management Service (AWS KMS) keys. Access to each secret is controlled with IAM policies, so Secrets Manager works alongside IAM rather than replacing it. Applications, including AWS Lambda functions, fetch the secret through an API call at run time, so it never sits in source code. Its standout feature is automatic rotation: it can change a credential on a schedule with no one doing it by hand, with built-in support for Amazon RDS database credentials.

AWS Systems Manager Parameter Store, a capability of AWS Systems Manager, stores configuration data as parameters, either as plain text or encrypted, organised in a hierarchy of names. It suits values such as feature flags, database endpoints and settings that differ between test and production. It can hold an encrypted secret, but it has no built-in automatic rotation.

The exam usually separates the two on a single word. "Rotate automatically" or "database credentials on a schedule" points to Secrets Manager. "Configuration values", "feature flags" or "a hierarchy" points to Parameter Store. AWS Certificate Manager is a distractor here: it issues and manages TLS certificates, not general secrets or configuration.

The tasks only the root user can do

Because the root user should be used rarely, it helps to know the short list of jobs that genuinely require it. The ones worth remembering are:

• Changing account settings, such as the account name, the root user's email address and password, and the root user's own access keys.
• Closing the AWS account, for a standalone account that is not managed through AWS Organizations.
• Restoring IAM permissions when the only administrator has accidentally removed their own access and no other IAM identity can manage IAM. The root user's access cannot be taken away by IAM policies, so it can reattach the administrator's permissions. AWS CloudTrail will have recorded the change, but CloudTrail is a log; it cannot undo anything.
• Turning on MFA Delete for an S3 bucket, which requires MFA before object versions in a versioned bucket can be permanently deleted. Only the root user of the account that owns the bucket, using its own MFA device, can enable it. An IAM user with full Amazon S3 permissions still cannot.
• Activating IAM access to the billing console, so that IAM users can be given permission to see billing information at all.
• Registering as a seller in the Reserved Instance Marketplace.
• Editing or deleting an S3 bucket policy that denies all principals, the way out when a badly written policy has locked everyone out of a bucket.

The exam pattern is simple. If a scenario describes everyday work, such as creating users, launching instances or creating buckets, an IAM identity is the answer. If it describes changing the account itself, closing it, MFA Delete or recovering from a lock-out, the root user is.

How to protect the root user

Protection starts the moment an account is created, and it comes down to a handful of actions:

1. Enable MFA on the root user straight away. Multi-factor authentication means a stolen password alone is not enough to sign in; the attacker also needs the physical or virtual device.
2. Do not create access keys for the root user, and delete any that exist. A root access key is a permanent credential with full access that can be copied into a file and leaked. Creating one does the opposite of protecting the account.
3. Use a strong, unique password, and keep it somewhere safe rather than sharing it.
4. Secure and monitor the account's email address. The root user signs in with that address, and a root password reset is sent to that inbox, so whoever controls the mailbox can take over the root user. Protecting the mailbox is part of protecting the account.
5. Stop using the root user for daily work. Create administrative users, preferably in IAM Identity Center, for everyday tasks, and keep the root user for the short list above.

A small business that has run everything as root should therefore create administrative users and move its daily work to them. It cannot fix the problem with an IAM policy that restricts root, because no such policy exists inside the account, and it cannot create a second root user to share the load. AWS Trusted Advisor includes a security check that flags a root user without MFA (lesson 11).

What the exam is really asking

Most questions in this area test one of three instincts. First, the root user is powerful and rare: protect it with MFA, give it no access keys and keep it out of daily work. Second, long-term credentials are a liability: prefer roles and temporary credentials, and treat any exposed key as compromised. Third, secrets belong in a service built for them: Secrets Manager when rotation matters, Parameter Store for configuration. When an answer adds a permanent credential or uses the root user for routine work, it is almost always the wrong one.