Identity and Access Management is the single largest domain on the AWS Certified Security – Specialty (SCS-C02) exam at roughly 20% of your score, and it is also the domain candidates most consistently underestimate. Most people can write a basic Allow policy. Far fewer can answer the questions the exam actually asks: A user has an IAM policy that allows an action, but the call is still denied — why? An account is in an Organization with an SCP; how does that interact with the user’s permissions? A role has a permission boundary — what can it actually do? Those questions are decided by policy evaluation logic, and that logic is what this guide makes mechanical.
If you can reason through how an explicit deny beats an allow, how a permission boundary intersects with an identity policy, and how a cross-account AssumeRole request is authorised on both sides, you will convert the hardest 20% of the exam into reliable points. This is a deep dive for the Identity and Access Management portion of the blueprint.
The IAM Building Blocks
Start by getting the vocabulary exact, because the exam writes distractors that swap these terms:
| Concept | What it is | Attaches to |
|---|---|---|
| IAM user | A long-lived identity with credentials | A person or app (avoid for humans; prefer federation) |
| IAM group | A collection of users for shared policies | Users only — you cannot make a role a member |
| IAM role | An identity assumed temporarily, no long-lived credentials | Anyone the trust policy allows |
| Identity-based policy | Permissions attached to a user, group, or role | An identity |
| Resource-based policy | Permissions attached to a resource, with a Principal | S3 buckets, SQS queues, KMS keys, etc. |
| Permission boundary | A ceiling on what an identity policy can grant | A user or role |
| Service Control Policy (SCP) | An Organizations guardrail on an account’s max permissions | OUs and accounts |
The two you must never confuse are identity-based and resource-based policies. An identity-based policy has no Principal — it is already attached to the identity, so the principal is implied. A resource-based policy requires a Principal because it is attached to a resource and must state who is allowed.
Anatomy of a Policy
Every JSON policy statement is built from the same fields. Know each one cold:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadOnlyBucket",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports",
"arn:aws:s3:::reports/*"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}
}
]
}EffectisAlloworDeny.Actionis the API operation(s), namespaced by service (s3:GetObject).Resourceis the ARN(s) the statement applies to. Note thats3:ListBuckettargets the bucket ARN, whiles3:GetObjecttargets the object ARN (/*) — mixing these up is a classic exam trap.Conditionadds guardrails using condition keys. The high-value ones for SCS-C02 areaws:SourceIp,aws:PrincipalOrgID,aws:MultiFactorAuthPresent,aws:SecureTransport, andaws:PrincipalTag.
The Policy Evaluation Logic (The Heart of the Domain)
This is the concept the exam tests more than any other. When a principal makes a request, AWS evaluates all applicable policies and reaches a single decision using a strict order of precedence:
- Explicit
Deny— if any policy (SCP, boundary, identity, resource, session) denies, the request is denied. Full stop. An explicit deny cannot be overridden. - Explicit
Allow— if no deny applies, the request needs at least one applicableAllow. - Implicit (default)
Deny— if nothing explicitly allows it, the request is denied by default.
Put simply: everything is denied unless explicitly allowed, and an explicit deny always wins.
The subtlety the exam probes is which policy types must allow the request. Within a single account, a request is allowed if it is permitted by an identity-based policy or a resource-based policy (and no deny applies). Across accounts, the request must be allowed by a policy in both accounts — the identity policy in the calling account and the resource/trust policy in the target account.
When guardrails are present, they narrow the result further. The effective permission is the intersection of every layer:
Effective permissions =
(SCP allows) AND (Permission boundary allows)
AND (Identity-based policy allows)
AND no explicit Deny anywhere
[ OR a resource-based policy allows, in the same account ]A memory hook: guardrails (SCPs and permission boundaries) can only take permissions away, never add them. A user with AdministratorAccess inside an OU whose SCP allows only s3:* can do nothing but S3 — the SCP caps the account regardless of how generous the identity policy is.
Permission Boundaries in Practice
A permission boundary is a managed policy attached to a user or role that sets the maximum permissions an identity-based policy can grant to that principal. It does not grant anything on its own — it is purely a ceiling.
The effective permission of a boundaried identity is the intersection of the boundary and the identity policy:
| Identity policy allows | Boundary allows | Effective result |
|---|---|---|
s3:*, ec2:* | s3:* | s3:* only |
s3:GetObject | s3:* | s3:GetObject only |
dynamodb:* | s3:* | Nothing — no overlap |
The exam’s favourite use case is delegated administration: you let a developer create IAM roles, but you attach a permission boundary requirement so any role they create can never exceed a safe ceiling. That prevents privilege escalation — a developer cannot mint a role more powerful than themselves. If a scenario mentions “allow a team to create roles without letting them escalate privileges,” the answer is a permission boundary enforced via a condition like iam:PermissionsBoundary.
Service Control Policies and Organizations
SCPs are Organizations-level guardrails applied to Organizational Units (OUs) or accounts. Like permission boundaries, they do not grant permissions — they define the maximum available permissions for every principal in the affected accounts, including the root user of member accounts.
Key exam facts that are easy to miss:
- SCPs affect member accounts only. The management (payer) account is not restricted by SCPs, which is one reason you should run no workloads there.
- SCPs do not apply to service-linked roles.
- The default
FullAWSAccessSCP allows everything; you tighten by attaching deny-based SCPs or by switching to an allow-list model. - A permission is only granted if it is allowed at every level: SCP and identity policy (and boundary, if present).
A common guardrail SCP denies any action outside approved regions or blocks disabling security services:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLeaveOrg",
"Effect": "Deny",
"Action": [
"organizations:LeaveOrganization",
"cloudtrail:StopLogging",
"guardduty:DeleteDetector"
],
"Resource": "*"
}
]
}That pattern — using an explicit Deny to make security controls tamper-proof even against account admins — is a recurring SCS-C02 theme that overlaps with the threat detection and incident response domain.
Cross-Account Access and STS
The secure, exam-preferred way to grant access across accounts is a role with a trust policy, assumed via AWS STS. There are always two sides to authorise:
- The trust policy (resource-based, on the role) says who may assume the role — the
Principal. - The identity policy (in the caller’s account) says the caller is allowed to call
sts:AssumeRoleon that role ARN.
Both must allow the request. The trust policy on the target role looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "unique-shared-secret" }
}
}
]
}The ExternalId deserves attention because the exam loves it. It defends against the confused deputy problem: when a third-party SaaS vendor assumes a role in your account, the ExternalId ensures the vendor can only do so on your behalf, not on behalf of another of its customers who might guess your role ARN. If you see “third-party vendor” plus “prevent confused deputy,” the answer is sts:ExternalId.
AssumeRole returns temporary credentials — an access key, secret key, and session token — that expire (from 15 minutes up to 12 hours). Temporary credentials are the reason roles are more secure than long-lived IAM user keys and are the mechanism behind EC2 instance profiles, Lambda execution roles, and IAM Roles for Service Accounts (IRSA) on EKS.
Federation: Bringing External Identities In
Federation lets users authenticate with an external identity provider and receive temporary AWS credentials — no IAM user required. Know the three flavours and which STS call powers each:
| Federation type | Use case | STS action |
|---|---|---|
| SAML 2.0 | Corporate directory (e.g. Active Directory) to AWS console/CLI | AssumeRoleWithSAML |
| Web identity / OIDC | Consumer logins (Google, Cognito) or Kubernetes/IRSA | AssumeRoleWithWebIdentity |
| IAM Identity Center | Central workforce access across many accounts (successor to AWS SSO) | Managed by Identity Center |
The exam-relevant takeaways: IAM Identity Center is the modern recommendation for workforce access across an Organization; SAML federation suits an existing corporate IdP; and web identity federation (often via Amazon Cognito identity pools) suits mobile and web apps so you never embed AWS keys in a client. In all cases the user ends up assuming a role and operating with temporary credentials — a unifying theme worth internalising.
Troubleshooting “Access Denied”
When a request is unexpectedly denied, walk the layers in precedence order — this is exactly the reasoning the exam wants:
- Is there an explicit
Denyanywhere? Check SCPs, the permission boundary, the identity policy, and any resource-based policy. An explicit deny beats everything. - Does an SCP omit the action? If the account’s SCP does not allow the service, no identity policy can grant it.
- Does the permission boundary allow it? The effective permission is the intersection of boundary and identity policy.
- Is this cross-account? Confirm both the identity policy (caller side) and the resource/trust policy (target side) allow it.
- Does a
Conditionfail? An MFA, SourceIp, or SecureTransport condition can silently block an otherwise valid allow.
The IAM Policy Simulator and IAM Access Analyzer are the tools AWS expects you to name here. Access Analyzer flags resources shared outside your account or Organization and can generate least-privilege policies from CloudTrail activity — a favourite “how would you right-size permissions” answer.
Where IAM Meets the Rest of SCS-C02
IAM is not an island. Encryption via KMS is enforced with key policies — resource-based policies that follow the exact evaluation logic above, which is why the KMS and data protection domain leans on everything here. Detective controls depend on IAM roles for cross-account log aggregation. Even network security uses IAM condition keys like aws:SourceVpce to restrict access to VPC endpoints. Treating identity as the connective tissue of the whole exam is the mindset that lifts a borderline score into a confident pass. For the full weighting of every domain, review the SCS-C02 exam topics breakdown.
Turn Theory Into Exam-Ready Reflexes
The IAM domain is not tested with definitions — it is tested with scenarios that force you to trace a request through multiple policy layers under time pressure. The only way to build that speed is by working through realistic questions and reading the reasoning behind every answer, so the evaluation logic becomes automatic rather than something you re-derive each time.
The Sailor.sh AWS Security Specialty (SCS-C02) Mock Exam Bundle is built for exactly that: eight full-length mock exams with 520+ questions that mirror the real blueprint’s weighting, including a heavy dose of IAM evaluation, permission boundary, SCP, and cross-account scenarios — each with a detailed explanation of why the correct answer wins and the distractors fail. Pair it with a structured 30-day study plan and drill until tracing policy precedence feels like second nature. If you want to gauge where you stand first, try a round of free practice questions.
Frequently Asked Questions
What is the order of IAM policy evaluation?
AWS evaluates all applicable policies together. First, any explicit Deny wins and the request is denied. If there is no explicit deny, the request must have at least one explicit Allow from an applicable policy. If nothing explicitly allows it, the default implicit deny applies. In short: deny by default, an explicit allow is required, and an explicit deny always overrides an allow.
How is a permission boundary different from an SCP?
A permission boundary is an IAM feature attached to a single user or role that caps what that identity’s policies can grant. An SCP is an AWS Organizations feature attached to an OU or account that caps the maximum permissions for every principal in that account (including root). Both are guardrails that only remove permissions — neither grants anything on its own. Effective permissions are the intersection of all guardrails and the identity policy.
Does an SCP restrict the management account?
No. SCPs apply only to member accounts in an Organization. The management (payer) account is never restricted by SCPs, which is a key reason AWS recommends running no workloads and storing no sensitive resources in the management account.
When do I need to configure policies in two accounts?
For cross-account access. The caller’s account needs an identity-based policy allowing sts:AssumeRole (or the relevant action), and the target account needs a resource-based or trust policy that names the caller as an allowed Principal. Both sides must allow the request; a single-account request only needs one allowing policy.
What is the ExternalId used for?
The sts:ExternalId condition in a role’s trust policy prevents the “confused deputy” problem when a third party assumes a role in your account. It is a shared secret that ties the assume-role request to your specific engagement, so the third party cannot be tricked into accessing your account on behalf of a different customer.
Which STS action does SAML federation use?
AssumeRoleWithSAML. Web identity and OIDC federation (including Cognito and EKS IRSA) use AssumeRoleWithWebIdentity, while standard cross-account role assumption uses AssumeRole. All three return temporary credentials with a session token and a limited lifetime.