7 min read · about 1 h 15 min with practice3 quick checks≈3% of the testCore: Core: tested on most papers
Reading is free. Sign in to tick off lessons, keep your place and track your mastery.
IAM underpins almost every Domain 1 question. SAA-C03 rarely asks for definitions. It states a requirement such as “without long-term credentials” or “developers must not escalate privileges” and offers four ways to grant or restrict access. You need to know which policy types grant, which only limit, and how AWS combines them.
By the end you’ll be able to
Apply root user and IAM user best practices: MFA, no root access keys, temporary credentials over long-term keys
Distinguish identity-based, resource-based, permissions boundary, session and SCP/RCP policies and state which ones grant and which only limit
Trace the policy evaluation logic (explicit deny > allow > implicit deny) for a request
Design a flexible authorization model with groups, roles, managed and inline policies, and condition keys (aws:SourceIp, aws:PrincipalOrgID, aws:RequestedRegion, tags for ABAC)
Use IAM Access Analyzer and last-accessed data to move toward least privilege
What the exam asks
Task statement 1.1 (design secure access to AWS resources) produces these recurring patterns:
Root user hygiene: MFA on the root user, no root access keys, and root used only for the few tasks that require it.
Choosing the identity: an IAM group for people who share permissions, an IAM role for anything that runs code, and federation for workforce sign-in.
Which policy type solves it: identity-based, resource-based, permissions boundary, SCP/RCP or session policy.
Evaluation puzzles: you get a short policy or a set of policies and must predict whether a request is allowed or denied.
Least privilege at scale: customer managed policies, attribute-based access control (ABAC) with tags, condition keys and IAM Access Analyzer.
Core ideas
Identities
Identity
Credentials
Use it for
Root user
Email + password (+ MFA)
Only root-only tasks: changing account settings, closing the account, changing the support plan, restoring locked-out IAM admin access
IAM user
Password and/or long-term access keys
Legacy or break-glass cases. Humans should federate instead
IAM group
None (a container)
Attaching the same policies to many IAM users. Not a principal and cannot be nested
Root best practice: enable MFA, never create root access keys (delete any that exist), and lock the credentials away. You cannot attach an IAM policy to the root user. In a standalone account the only way to limit root is not to use it. In a member account, SCPs also restrict it.
Policy types: which grant, which only limit
Policy type
Attached to
Grants access?
vii.Check your understanding
3 questions on IAM identities, policies and least privilege. Every option is explained once you answer.
Sign in to try the quick check
Answers are checked on our side, every option is explained, and your result feeds your mastery for this topic. It’s free.
Managed vs inline. AWS managed policies are maintained by AWS and cannot be edited. Customer managed policies can be reused across many identities, keep up to five versions, and roll back when you set an older version as the default. An inline policy lives inside one identity and is deleted with it. Use inline only when the permissions must never be reused.
How AWS evaluates a request
Explicit deny in any applicable policy → denied. Nothing overrides it.
Guardrails (SCPs, RCPs, permissions boundary, session policy): if any of them applies and does not allow the action → denied.
Grants: an allow in an identity-based policy or in a resource-based policy (same account) → allowed.
Otherwise → implicit deny, the default.
Effective permissions = (identity-based ∪ resource-based allows) ∩ every guardrail, minus explicit denies. For a cross-account request, the caller’s identity policy and the resource-based policy (or the role trust policy) must both allow it.
Bucket-level actions (s3:ListBucket) need the bucket ARN. Object-level actions (s3:GetObject, s3:PutObject) need the object ARN ending in /*. Hard items often test this difference.
Condition key
Typical use
aws:SourceIp
Allow API calls only from corporate public IPs (requests through VPC endpoints carry no public IP, so use aws:SourceVpce there)
aws:MultiFactorAuthPresent
Require MFA. In Deny statements use BoolIfExists, because requests signed with long-term access keys do not include the key
aws:RequestedRegion
Restrict Regions
aws:PrincipalOrgID
Allow every account in your organization in a resource policy
aws:SecureTransport
Deny requests that do not use TLS
aws:PrincipalTag, aws:ResourceTag, aws:RequestTag
ABAC
ABAC: one policy for many projects
Role-based access control (RBAC) writes one policy per job function and lists resource ARNs, so every new project means editing a policy. ABAC tags both principals and resources, and the policy compares the tags:
When a new project starts, you tag its resources and people and leave the policy unchanged. IAM Identity Center can pass attributes from your identity provider as session tags for this purpose.
Delegating safely: permissions boundaries and PassRole
To let developers create roles without escalating their own privileges:
Write a boundary policy.
Allow iam:CreateRole, iam:AttachRolePolicy and iam:PutRolePolicy only when the iam:PermissionsBoundary condition equals that boundary.
Deny any change to the boundary itself.
To give an existing role to a service (Lambda, EC2, ECS), a user needs iam:PassRole on that role’s ARN, ideally with an iam:PassedToService condition.
Tools for least privilege
IAM Access Analyzer: external access findings for resources shared outside your zone of trust (S3 buckets, IAM roles, KMS keys, SQS queues, Lambda functions, secrets and more), unused access findings (roles, keys, passwords, permissions), policy validation, and policy generation from CloudTrail activity.
Last accessed information shows which services a user or role has actually used. The credential report lists every user’s MFA status and key age.
Worked examples
Exam technique
Sort the options into “grants” and “limits”. If someone cannot do something they need to do, the fix is an identity-based or resource-based allow. If someone must be prevented from doing something, the fix is a deny, a boundary or an SCP.
Read the qualifier. “LEAST operational overhead” points to groups, customer managed policies, ABAC and managed tools such as Access Analyzer. “MOST secure” points to temporary credentials and the narrowest list of actions and resources.
Rule out AdministratorAccess, "Resource": "*" and long-term access keys when the stem mentions least privilege. They usually work, which is why they are traps.
In evaluation items, look for a matching explicit deny first.
Common mistakes
Quick recap
Root user: MFA on, no access keys, and only for root-only tasks.
Humans federate or use groups, workloads use roles, and nothing should use long-term keys.
Only identity-based and resource-based policies grant. Boundaries, SCPs, RCPs and session policies only limit.
An explicit deny beats every allow. With no allow, the request is implicitly denied.
A cross-account request needs an allow on both sides.
Customer managed policies are reusable and versioned. ABAC scales across projects with one policy.
IAM Access Analyzer finds external and unused access and generates least-privilege policies.