Secure Access to AWS Resources

Every AWS API call is evaluated against four layers of policy, in a fixed order. Understanding the order is the difference between debugging access in five minutes and three hours.

Layer 1 — Service Control Policy (SCP). Attached at AWS Organizations root, OU, or account. Applies to every principal in the account, including the root user. If an SCP denies the action, evaluation stops — no further layer can grant it. SCPs are deny-by-default in spirit: an Allow SCP doesn't grant; it only widens what the account could do if downstream layers also allow. A missing SCP is permissive (no restriction).

Layer 2 — Permission boundary. Attached to an individual IAM user or role. Acts as a ceiling on the maximum permissions the principal can have. The boundary itself grants nothing. If the boundary Allow doesn't list the action, the call is denied even if the identity policy says yes.

Layer 3 — Identity policy. Attached to the user / role / group performing the action. Must contain an explicit Allow for the API action and resource. Identity policies are additive — multiple attached policies are unioned.

Layer 4 — Resource policy. Attached to the target resource (S3 bucket, KMS key, SQS queue, etc.). For cross-account access, the resource policy must explicitly allow the calling principal (or its account). For same-account access, a resource policy Allow can substitute for an identity-policy Allow only for resources that support it.

Decision algorithm (simplified):

1. Any explicit Deny in any layer? → DENY.
2. SCP missing required Allow? → DENY.
3. Permission boundary missing required Allow? → DENY.
4. Cross-account? → Both identity policy AND resource policy must Allow.
5. Same-account? → Identity policy Allow is sufficient (resource policy Allow is optional unless required by service).
6. All else? → DENY (default).

Common failure modes:

• 'Admin user can't access S3 bucket': resource policy on bucket explicitly denies their principal. Explicit Deny beats anything.
• 'New developer with PowerUser permissions can't create role': SCP at OU level denies iam:CreateRole for that OU.
• 'Lambda execution role has admin but still can't decrypt KMS key': KMS key policy doesn't grant the role; KMS treats key policy as the primary access mechanism.

Exam shortcut: when a question lists multiple policies and asks what happens, evaluate from outer (SCP) to inner (resource) and stop at the first hard Deny. See the official IAM policy evaluation reference^[13] for the canonical algorithm.

A trust policy is the resource-based policy on an IAM role that controls who can assume it. Getting it right is the most common cross-account exam topic.

Anatomy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-tenant-id-xyz" },
      "Bool": { "aws:MultiFactorAuthPresent": "true" }
    }
  }]
}

Principal forms:

• "AWS": "arn:aws:iam::222222222222:root" — any IAM principal in account 222... (broadest; account-level trust)
• "AWS": "arn:aws:iam::222222222222:role/Build" — only this specific role
• "Federated": "cognito-identity.amazonaws.com" — Cognito Identity Pool
• "Federated": "arn:aws:iam::111...:oidc-provider/token.actions.githubusercontent.com" — GitHub Actions OIDC
• "Federated": "arn:aws:iam::111...:saml-provider/Okta" — SAML
• "Service": "lambda.amazonaws.com" — AWS service (for service roles)

Critical conditions:

• sts:ExternalId^[12] — required defence against the confused deputy problem. When a third-party SaaS assumes your role, only pinning the principal ARN is unsafe: another customer of the same SaaS could be tricked into assuming your role. The SaaS supplies a per-customer ExternalId; your trust policy validates it.
• aws:MultiFactorAuthPresent — require MFA on the assuming session. For human-assumed roles (break-glass, admin elevation), this is the right default.
• aws:SourceIp / aws:SourceVpc — restrict where the assume can originate (e.g. only from your VPN's IP range).
• aws:PrincipalOrgID — require the caller's account to be in your Organization^[15]. Cleaner than listing individual account ARNs.

OIDC for GitHub Actions — full pattern (uses the sts:AssumeRoleWithWebIdentity^[6] API):

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
    }
  }
}

The sub claim restricts to a specific repo + branch. Wildcards (repo:my-org/*) let any repo in the org assume the role — sometimes desired, often a foot-gun.

Exam traps:

• Principal: "*" in a trust policy = anyone in any AWS account can assume your role. Almost always wrong unless paired with restrictive conditions (and even then, suspect).
• Forgetting sts:ExternalId for third-party integrations.
• Long MaxSessionDuration (12h) when human elevation should be 1h or less.

Both permission boundaries^[9] and Service Control Policies^[10] restrict what a principal can do. Both are ceilings, never grants. The difference is the unit of governance.

Aspect	Permission boundary	Service Control Policy
Attaches to	Individual IAM user or IAM role	OU, account, or Organization root
Affects	The single principal it's attached to	Every principal in every account in scope (including root user)
Use case	Delegating role creation safely — "developer can create roles, but not above this ceiling"	Organization-wide guardrail — "no IAM user with console access anywhere"
Set by	Account admin	Organization management account
Bypassable by root user?	N/A (boundary scope is per-principal)	NO — SCPs apply to root too
Default if absent	No ceiling — identity policy + resource policy determine access	Implicit Allow * at root (no restriction)

Pattern 1 — Boundary for developer delegation:

Team X wants developers to create their own IAM roles for their Lambda functions, without granting full iam:*. Solution:

1. Define a boundary policy DevBoundary that allows only the actions developer-created roles should be able to use (e.g. S3 read-only on team buckets, DynamoDB CRUD on team tables, CloudWatch Logs).
2. Grant developers a policy that includes iam:CreateRole + iam:PutRolePolicy with the condition iam:PermissionsBoundary = arn:.../DevBoundary — they must attach the boundary when creating roles.
3. Now the developer can iam:CreateRole a Lambda role, but every role they create is capped by DevBoundary. They can't accidentally grant themselves admin.

Pattern 2 — SCP for organization-wide guardrail:

Company policy: no IAM user with console access can exist anywhere in the organization. Solution:

1. SCP attached at organization root:

{ "Effect": "Deny", "Action": "iam:CreateLoginProfile", "Resource": "*" }

2. Now no IAM user in any member account can have a console password — even the management account's root user can't override it.

Pattern 3 — Combining both:

SCP at OU 'Production' denies ec2:TerminateInstances for any principal except the role EmergencyAdmin. Inside one production account, a developer needs to manage their team's instances. Their role has a permission boundary that allows ec2:Start*, ec2:Stop*, ec2:Reboot* but NOT Terminate* — boundary reinforces the SCP, and even if their identity policy granted ec2:*, both layers deny Terminate.

Common exam distractor: the question presents a scenario where central security wants to restrict an entire OU, and the option offering 'Permission boundary on every role in the OU' is plausible but wrong — boundaries don't propagate; SCP is the right tool. The reverse is also tested: 'delegate role creation to one team' is a permission-boundary scenario, not SCP.

IAM Identity Center (formerly AWS SSO) is the modern primitive for workforce access. It replaces per-account IAM federation with centralised user + group management.

Core concepts:

• Identity source. Where the users live. Three options:
  • Identity Center directory (built-in; OK for small teams).
  • Active Directory (on-prem AD via AWS Managed Microsoft AD or AD Connector).
  • External IdP (Okta, Entra ID, Google Workspace, OneLogin, etc.) via SAML 2.0 + SCIM for user/group sync.
• Permission set. A blueprint of IAM policies that defines a role identity-center will create in target accounts when assigned. Think of it as 'reusable role template'.
• Account assignment. Binding: (Group X) + (Account Y) + (Permission Set Z). When a user logs in, the user picks one of their assigned account + permission-set combinations; Identity Center provisions a temporary session via AssumeRole into the target.

Architecture:

IdP (Okta) ──SAML──> IAM Identity Center
                            │
                            │  (SCIM for user/group sync)
                            │
                            ▼
   ┌────────────────────────────────────────────┐
   │  Account assignments (group × account ×   │
   │  permission set)                          │
   └────────────────────────────────────────────┘
                            │
                            │  on user click in portal
                            ▼
   AssumeRole into target account → temporary creds (1-12h)

Where Identity Center lives:

• One region per organization — pick carefully; can't be moved post-setup.
• Must be enabled from the management account of the AWS Organization.
• Requires AWS Organizations (cannot run standalone).

Permission set scoping:

• Up to 50 managed policies + 1 customer-managed policy + inline policy per permission set.
• Session duration: 1 to 12 hours (controlled at permission-set level).
• Permission sets can include a permissions boundary — adds another ceiling on top of the policies.

Common patterns:

• Just-in-time admin elevation: regular users have read-only permission set; on-call engineer gets a 'BreakGlassAdmin' permission set assigned for a 1-hour shift. Trail logs every assumption.
• Multi-account access: one user account in Identity Center; assignments to 30 AWS accounts with role-appropriate permission sets in each. No per-account IAM users to manage.
• Audit access: read-only permission set assigned to the audit team across all accounts; no production write capability ever.

Anti-patterns the exam will probe:

• Creating IAM users in each member account 'for the developer to log in' — wrong; permission set + account assignment is the answer.
• Using Identity Center for application end-user authentication — wrong; that's Cognito User Pools. Identity Center is for workforce (employees) accessing AWS.
• Trying to enable Identity Center from a non-management account — fails by design; must be management account. See What is IAM Identity Center?^[7] for the canonical setup walkthrough.

Workload identity = how a non-human process (container, Lambda, on-prem CI runner) gets temporary AWS credentials without storing a long-lived secret.

1. EC2 — Instance Metadata Service (IMDS).

The EC2 instance has an instance profile (an IAM role^[1]); the AWS SDK on the instance fetches temp credentials from 169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>. Credentials rotate automatically.

IMDSv1 vulnerability: Server-Side Request Forgery (SSRF) attacks can trick a vulnerable app into requesting credentials from the metadata service and leaking them.

Fix — enforce IMDSv2^[2]: requires a session token (PUT request) before any credentials fetch. SSRF can't follow the multi-step protocol. Enforce via:

• New instances: launch template / RunInstances with HttpTokens=required.
• Existing instances: aws ec2 modify-instance-metadata-options --http-tokens required.
• Org-wide: SCP denying instance launches without HttpTokens=required.

2. ECS — Task Role^[4].

Every task in a task definition can have an IAM role. The ECS agent fetches temp credentials and exposes them at a task-local endpoint (169.254.170.2/v2/credentials/<id>). The SDK auto-discovers via env var AWS_CONTAINER_CREDENTIALS_RELATIVE_URI.

Distinct from execution role:

• Execution role: ECS agent uses this to pull container images from ECR, write logs to CloudWatch. Operational.
• Task role: the application inside the container uses this to call AWS APIs. App-specific.

Common mistake: putting app-needed permissions on execution role. Wrong layer.

3. EKS — IAM Roles for Service Accounts (IRSA)^[5].

Kubernetes pods can have an IAM role mapped via the pod's service account. The pod gets a projected token; the AWS SDK exchanges it for temp credentials via sts:AssumeRoleWithWebIdentity^[6].

Setup:

1. Enable OIDC provider on the EKS cluster (eksctl utils associate-iam-oidc-provider).
2. Create IAM role with trust policy permitting the OIDC provider + a specific service account namespace.
3. Annotate the Kubernetes service account: eks.amazonaws.com/role-arn: arn:aws:iam::...:role/MyRole.
4. Pods using that SA automatically get credentials.

Much better than the alternative: kube2iam or instance-profile inheritance (which means every pod on the node has the same permissions — least-privilege violation).

4. GitHub Actions — OIDC web-identity.

GitHub Actions runners can request a JWT from GitHub's OIDC provider. AWS trusts that provider via an IAM OIDC identity provider in your account, then runners call sts:AssumeRoleWithWebIdentity directly.

Setup:

1. In your AWS account, create an OIDC identity provider for https://token.actions.githubusercontent.com (thumbprint and audience pre-known).
2. Create an IAM role with a trust policy pinning the OIDC issuer + audience + sub (repo + branch).
3. In the Actions workflow, use aws-actions/configure-aws-credentials@v4 with role-to-assume — no AWS access keys in repo secrets.

Result: short-lived credentials (default 1h) bound to a specific repo + branch. Compromised workflow = limited blast radius.

5. Lambda — execution role^[3].

Triviall the simplest: set role at function creation. Credentials available via env vars and the SDK auto-discovers. Rotated per invocation by the Lambda runtime.

The pattern across all five: AWS trusts the issuer (IMDS, EKS OIDC, GitHub OIDC) and the workload identity is validated against that trust. No long-lived secret ever lives in the workload.

Antipattern 1 — Sharing an IAM user's access keys across accounts.

Wrong: 'Developer needs to deploy to dev and prod, so we put their keys in both.' This violates the IAM security best practices^[17] recommendation against long-lived credentials.

Right: Create roles DeployDev in dev account, DeployProd in prod account. Trust policies permit the developer's IAM principal in their home account. They aws sts assume-role to switch context. Audit trails show which role was used in which account.

Antipattern 2 — Principal: * in bucket policies for 'partner' access.

Wrong: 'Partner needs to upload to our S3 bucket, so we made it public for writes.'

Right: Resource policy permits the partner's specific account (or role):

{ "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::PARTNER_ACCOUNT:root" },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::our-bucket/uploads/*",
  "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } }
}

The bucket-owner-full-control condition ensures uploaded objects are owned by us, not the partner — otherwise we can't read what they upload.

Antipattern 3 — Forgetting sts:ExternalId for third-party SaaS roles.

Wrong: SaaS vendor (monitoring, backup, security) gives you a CloudFormation template that creates a role with trust policy Principal: arn:aws:iam::VENDOR:root. Anyone at the vendor with your role ARN can assume it.

Right: Trust policy includes Condition: { StringEquals: { sts:ExternalId: "your-unique-id" } }. Vendor supplies a per-tenant ExternalId; impossible to assume your role without it.

Antipattern 4 — Listing individual partner account ARNs in 50 places.

Wrong: 'We have 30 partner accounts; we maintain a list in every bucket policy and trust policy.'

Right: If partners are all in the same AWS Organization, use aws:PrincipalOrgID:

"Condition": {
  "StringEquals": { "aws:PrincipalOrgID": "o-abc123def4" }
}

New partner joins the org → automatically covered.

Antipattern 5 — Granting full IAM admin to developers 'for convenience'.

Wrong: 'Developers need to make IAM roles for their Lambdas, so they have iam:*.'

Right: Developers have iam:CreateRole / iam:PutRolePolicy but their identity policy includes a condition requiring iam:PermissionsBoundary on every role they create:

"Condition": {
  "StringEquals": {
    "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/DevBoundary"
  }
}

Now they can create roles, but every role they create has DevBoundary capping its powers.

Antipattern 6 — 'Centralised security account' that uses a hand-rolled cross-account scheme.

Wrong: Custom Lambda + custom roles + custom rotation script.

Right: AWS Organizations auto-creates OrganizationAccountAccessRole in every member account at the time they join the org. The management account (and any account given the right SCP scope) can assume it directly. Use this; don't build your own.