Design Secure Architectures · Topic 1 of 6

IAM Identities and Policies

Learn how AWS Identity and Access Management users, groups, roles and policies work, how permissions are evaluated, and how to apply least privilege.

5 min

In a nutshell

The root user has full power, so protect it with MFA (multi factor authentication), do not create access keys for it, and use it only for the few tasks that need it.
Prefer roles and temporary credentials over long term access keys.
Everything is denied by default, and an explicit deny always wins.

What it is

AWS Identity and Access Management (IAM) decides who can do what on which AWS resource. It is the first layer of security in almost every exam scenario.

IAM has four building blocks. A user is a long lived identity for a person or application, a group is a set of users, and a role is an identity that anyone or anything trusted can assume for a short time. A policy is a JSON document that grants or denies actions.

How it works

Roles over access keys

A role gives temporary credentials, issued by the AWS Security Token Service (STS). Nothing needs to be stored or rotated by hand. For this reason the exam prefers roles to long term access keys.

An Amazon EC2 instance gets a role through an instance profile. A Lambda function has an execution role, and an Amazon ECS task has a task role. Code running there receives credentials automatically, so you never put keys in the code or in an image.

Policy types

Policy type	Attached to	Purpose
Identity based	User, group or role	Says what that identity may do
Resource based	A resource such as an S3 bucket or SQS queue	Says who may use the resource, including other accounts
Permissions boundary	User or role	Sets the maximum permissions that identity policies can give
Service control policy	Organization account or unit	Sets the maximum for a whole account (next page)
Session policy	A temporary session	Narrows the permissions of one assumed role session

An inline policy is embedded in one identity. A managed policy is a standalone policy that you attach to many identities. AWS managed policies are written by AWS, and customer managed policies are written by you.

How a request is evaluated

The order of the logic is simple and the exam tests it often.

Every request starts as denied by default.
An explicit allow in a matching policy can permit the request.
An explicit deny in any policy overrides every allow.
Boundaries and service control policies must also allow the action.

Inside one account, an allow in either the identity policy or the resource policy is enough. For a different account, both sides must allow: the resource policy in the owning account and an identity policy in the calling account.

Anatomy of a policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::example-bucket/reports/*",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}

The elements are the effect, the actions, the resources and optional conditions. Conditions can test the source IP address, the time, whether MFA was used, or the organization that the caller belongs to (aws:PrincipalOrgID).

Cross account access

To let account B reach a bucket in account A, create a role in account A that trusts account B. A user in account B then assumes the role and uses the temporary credentials. For S3 you can also use a bucket policy that names the other account as principal.

Finding and removing excess access

IAM Access Analyzer reports resources that are shared outside your account or organization. It can also build a least privilege policy from the activity recorded in AWS CloudTrail. The IAM credential report and the "last accessed" data show unused users, keys and permissions.

Exam tip

When a question says "least operational overhead" for granting an application access to AWS, the answer is almost always an IAM role, not an access key stored in a file or in Secrets Manager.

What to remember for the exam

The root user has full power, so protect it with MFA (multi factor authentication), do not create access keys for it, and use it only for the few tasks that need it.
Prefer roles and temporary credentials over long term access keys.
Everything is denied by default, and an explicit deny always wins.
Cross account access needs permission on both sides, unless a role in the target account is assumed.
A permissions boundary and a service control policy limit permissions but never grant them.
Use groups to manage permissions for many users, and grant the minimum permissions needed (least privilege).
Use aws:PrincipalOrgID in a resource policy to allow every account in your organization without listing them.
Use IAM Access Analyzer to find external access and to generate policies from real usage.

Common mistakes

Putting access keys on an EC2 instance. An instance role removes the need for keys and rotates credentials by itself.

Thinking a boundary grants access. A permissions boundary only caps what an identity policy can allow. The user still needs an identity policy that allows the action.

Forgetting the resource side in cross account access. An allow in the calling account is not enough for most services when the resource lives in another account and no role is assumed.

Using wildcards for speed. An Action of * on Resource * breaks least privilege, and exam answers with it are almost always wrong.

Watch out

Do not use the root user for daily work. If a scenario describes an administrator using root credentials or shared keys, the fix is federated access or IAM roles, with MFA on any user.

Check yourself

Which identity should an application on an EC2 instance use to call S3?
An IAM role attached through an instance profile, which supplies temporary credentials with no stored keys.
A user has an Allow in an identity policy and an explicit Deny in another applicable policy. What is the result?
The request is denied, because an explicit deny overrides every allow.
What does a permissions boundary do?
It sets the maximum permissions an identity can have but does not grant any permission itself.

Topic 1 of 6 in Design Secure Architectures

Test yourself on Design Secure Architectures

The full AWS SAA-C03 question bank has 823 questions, with timed practice exams and an explanation for every answer.

Subscribe Try Sample Exam

This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.