Lock the front door

The master key

Opening an AWS account creates the root user: the account's email address and password, with complete, unrestricted access to every service, resource and billing setting. No permission policy can limit it inside its own account. If someone steals it, they own the account. So you lock it away and use it only for the few jobs that require it.

Priya: The root user is the master key to the whole building. You don't carry it to lunch.

Protecting the root user

These steps achieve root user protection. They come up on the exam as "which actions protect the root user?"

• Use a long, unique password
• Turn on multi-factor authentication (MFA): a second proof, such as a code from an authenticator app or a hardware security key
• Don't create root access keys; delete any that exist
• Create an administrator for daily work (in AWS IAM Identity Center or AWS Identity and Access Management (IAM)) and stop using root
• Keep the account email and contact details current so recovery works

Jobs only the root user can do

A short list of tasks needs root credentials: account-level and last-resort jobs.

• Change the account's root email address, root password or root access keys
• Close the AWS account (or reopen it shortly after)
• Restore permissions when the only IAM administrator locked themselves out
• Activate IAM access to the Billing and Cost Management console, and some other billing and tax tasks
• Register as a seller in the Reserved Instance Marketplace; turn on MFA Delete for an Amazon Simple Storage Service (Amazon S3) bucket
• Edit or delete an S3 bucket policy that denies everyone

Exam tip Creating users, launching servers and reading bills (once IAM access is on) do NOT need root. If a task is everyday work, root is the wrong answer.

Who's who in IAM

AWS Identity and Access Management (IAM) controls who can sign in (authentication) and what they can do (authorization) in an account.

• IAM user: one person or app with long-term credentials (password and/or access keys)
• IAM group: a set of users that share permissions, such as "warehouse-staff". Groups can't be signed in to.
• IAM role: an identity with no long-term password; whoever is allowed to assume it gets temporary credentials. Used by AWS services (an EC2 instance), users and other accounts
• Policy: a JavaScript Object Notation (JSON) document that allows or denies actions on resources

Reading a policy

A policy statement says Effect (Allow or Deny), Action (which application programming interface (API) calls), Resource (which things) and optionally Condition (when). Everything is denied until something allows it, and an explicit Deny always beats an Allow.

{
 "Effect": "Allow",
 "Action": "s3:GetObject",
 "Resource":
  "arn:aws:s3:::kibbleco-orders-example/*"
}

Exam tip The long name in Resource is an Amazon Resource Name (ARN), AWS's unique ID for a resource.

Managed, custom and inline policies

AWS managed policies are written and updated by AWS for common jobs (for example, read-only access). Customer managed policies are custom policies you write once and attach to many users, groups or roles. Inline policies are embedded in one identity and die with it. Attach policies to groups, not to each user, so a new hire just joins a group.

Least privilege

The principle of least privilege means granting only the permissions needed for a task, for only as long as needed. It limits the damage from a stolen login or a mistake. Review permissions regularly and remove what nobody uses; IAM shows when each permission was last used.

Exam tip Exam pattern: "most secure way to give access" almost always = least privilege, a role or group, never root or AdministratorAccess.

Passwords, password policies and MFA

A password policy sets rules for IAM users' passwords: minimum length, required character types, expiry and reuse limits. Add MFA so a stolen password isn't enough. MFA options include passkeys and security keys (hardware or built into a phone or laptop), virtual authenticator apps that show a code, and hardware tokens that show a time-based one-time password (TOTP).

You: My help desk MFA tickets finally make sense. It was all training.

Access keys

Access keys let programs call AWS from the AWS Command Line Interface (AWS CLI), software development kits (SDKs) or application programming interfaces (APIs). A key pair is an access key ID plus a secret access key. Never put them in code or share them; rotate them; delete unused ones. Better still, give apps an IAM role, which hands out short-lived credentials automatically.

Storing secrets: Secrets Manager vs Parameter Store

Apps need database passwords and API keys. Don't hard-code them. AWS Secrets Manager stores secrets encrypted and can rotate them automatically on a schedule, such as a database password every 30 days. AWS Systems Manager Parameter Store (part of AWS Systems Manager) stores configuration values and secrets as encrypted parameters, simply and at low or no cost, but without built-in automatic rotation.

Exam tip Need automatic rotation of database credentials? Secrets Manager. Need a simple place for config values and a few secrets? Parameter Store.

AWS IAM Identity Center

AWS IAM Identity Center (formerly AWS Single Sign-On) is the recommended way to give a workforce access to AWS. Staff sign in once at one portal and get the AWS accounts and business apps they're assigned. Access comes from permission sets, not IAM groups: a permission set bundles policies, and Identity Center turns it into an IAM role in each account it is assigned to. It can use its own user directory or connect to an existing one.

Federated identity

With federation, users sign in with an identity provider (IdP) the company already uses, such as Microsoft Active Directory or another company directory. AWS trusts the IdP and hands out temporary credentials, so nobody needs a separate IAM user. Standards like Security Assertion Markup Language (SAML) 2.0 and OpenID Connect (OIDC) carry the trust. AWS Directory Service can run a managed Microsoft Active Directory in AWS.

Cross-account roles and customer logins

A cross-account IAM role lets a trusted user in one AWS account assume a role in another account, with temporary credentials and no extra password. For the shop's customers (not staff), Amazon Cognito adds sign-up and sign-in to web and mobile apps.

Exam tip Staff into AWS accounts = IAM Identity Center. Customers into your app = Amazon Cognito. Another AWS account's users = cross-account role.

Authentication options

Each way of signing in fits a different kind of user.

• Root user: the email that created the account. Turn on MFA, don't use it day to day, and lock away its credentials
• IAM users: long-term username/password and access keys (for CLI/SDK); prefer to avoid for people
• Multi-factor authentication (MFA): a second factor such as an authenticator app, a passkey/security key or a hardware token
• AWS IAM Identity Center: single sign-on for many accounts with one sign-in; the recommended way for workforce users
• IAM roles: temporary credentials; apps on EC2 or Lambda assume a role instead of storing keys
• Cross-account IAM roles: a user in account A assumes a role in account B, so nobody needs a second username

Remember

Temporary credentials (roles, Identity Center) beat long-term access keys. Rotate any access keys that must exist, and never put them in code.

Exam tip App on EC2 needs to read S3: attach an IAM role to the instance, don't store access keys on it.

Where identities live

IAM identities are created and stored in AWS. Federated identities live in an outside identity provider (IdP) such as Microsoft Entra ID, Okta or Google Workspace, and AWS trusts that IdP. Users sign in once with their company account (single sign-on) and get temporary AWS access.

• Workforce federation: IAM Identity Center connected to your IdP (SAML 2.0 / SCIM)
• Customer (app user) identities: Amazon Cognito handles sign-up and sign-in for your web and mobile apps, including social logins

Why federate

One place to add and remove people: when someone leaves, disabling their company account removes their AWS access too. No separate AWS passwords to manage.

Exam tip Employees: IAM Identity Center. Your app's customers: Amazon Cognito.

What it does

AWS Resource Access Manager shares AWS resources you own with other AWS accounts or your whole organization instead of duplicating them: for example VPC subnets, Transit Gateways, Route 53 Resolver rules or License Manager configurations. The owner keeps control; other accounts can use the shared resource.

Exam tip Several accounts need to launch instances into one central VPC's subnets = share the subnets with AWS RAM.