Design Secure Access to AWS Resources (Task 1.1)

Design Secure Access to AWS Resources

Access design at the associate level is no longer "make an IAM user" — it is designing an identity architecture: where humans authenticate, how workloads get credentials, how accounts are governed, and how permission evaluation composes across layers. Every pattern below: brief, how it works, real use-case, gotchas.

Identity Strategy: Users, Groups, Roles, Policies

Brief: The exam expects a role-based, least-privilege design: humans federate into roles, workloads assume roles, and policies attach to groups/roles — never to individuals.

How it works: Three layers compose the effective permission: identity policies (what the principal is allowed), resource policies (what the resource admits), and guardrail policies (SCPs and permission boundaries that CAP the maximum). Evaluation order: explicit Deny anywhere wins → an Allow must exist → else implicit deny. Permission boundaries cap one identity; SCPs cap an entire account/OU — neither grants anything by itself.

Real use-case: A payments team's role has s3: on its bucket, but the account's SCP denies s3:DeleteBucket, and the role's boundary caps it to S3+KMS. An attacker who escalates the identity policy to :* still gets: no bucket deletion (SCP), nothing beyond S3/KMS (boundary), and no cross-account assumption (trust policy). Layered caps are why "effective permission" is plural.

Gotchas & interview notes: the SCP/boundary question is always "what is the MAXIMUM possible," never "what is granted." For cross-account resource access, BOTH the trusting account's resource policy AND the trusted identity's policy must allow — one-sided allows are silent denials.

Cross-Account Access Pattern (Exam Favorite)

Brief: Account A lets Account B's identity use a role — temporary STS credentials, no keys shared, fully auditable in both accounts' CloudTrail.

How it works: Account A creates AuditorRole with a trust policy naming Account B's principal (sts:AssumeRole) and a permissions policy (s3:GetObject on one bucket). Auditors in B call AssumeRole, receive credentials valid 15 minutes–12 hours, and every action is logged in BOTH accounts. For third parties (SaaS vendors), add an external ID — a shared secret in the trust policy condition that prevents the "confused deputy" attack where another customer of the vendor invokes your role.

Real use-case: A CI/CD account's pipeline assumes DeployRole in prod, scoped by a trust policy that admits only the pipeline's exact role ARN plus a condition on the external ID. A compromised developer laptop in the same CI/CD account cannot assume the role — it is not the trusted principal.

Gotchas & interview notes: "share access between accounts" → role + trust policy, NEVER IAM users or access keys (the exam rejects key-sharing answers on sight). Resource policies (bucket policies, KMS key policies) are the alternative when the other account's user must access a resource WITHOUT assuming a role — and then BOTH sides still must allow. MFA can be required in trust policies (aws:MultiFactorAuthPresent) for sensitive roles.

Federated Identity (No IAM Users for Humans)

How it works: The user authenticates at the IdP; the IdP issues a signed assertion (SAML) or token (OIDC); AWS STS exchanges it for temporary credentials mapped to an IAM role. IAM Identity Center sits on top: it federates your IdP ONCE and then manages per-account access via permission sets (reusable role templates) — a user's access across 20 accounts is one group membership, and joining/leaving the company is an IdP operation, not 20 IAM cleanups.

Real use-case: A contractor's engagement ends: IT disables the Okta account at 5 p.m. At 5:01, every AWS session across all accounts is either expired or un-renewable — access died with the identity, with zero IAM surgery.

Gotchas & interview notes: "employees use existing corporate credentials" → federation (SAML/Identity Center); "mobile app users sign in with Google" → Cognito/OIDC. The exam's phrase "without creating IAM users" always points at federation + STS.

Multi-Account Security Strategy

Brief: Accounts are the strongest security boundary AWS offers — blast-radius isolation, billing separation, and permission caps per environment. Govern them centrally.

How it works: AWS Organizations groups accounts into OUs; SCPs attach to OUs as guardrails (deny unapproved Regions, deny disabling CloudTrail, restrict instance types). AWS Control Tower is the landing-zone factory on top: it sets up the multi-account structure, central logging (CloudTrail + Config to a log-archive account), and preventive/detective guardrails, with a compliance dashboard. Standard topology: log-archive (immutable logs), security tooling (aggregates GuardDuty/Security Hub org-wide), workloads OUs per environment.

Real use-case: A developer in the dev account tries to launch an expensive GPU instance in an unapproved Region. The SCP denies the launch before it starts — the guardrail enforced itself at the API, no review meeting required. Meanwhile the audit team reads org-wide findings ONLY from the security account, because GuardDuty is organized as a delegated administrator there.

Gotchas & interview notes: "automate multi-account setup with guardrails" → Control Tower (it BUILDS on Organizations — do not confuse them). SCPs affect every principal in the account INCLUDING root (root cannot exceed an SCP, though some actions are exempt). Account isolation is also the answer to "limit the blast radius of compromised credentials."

Root User and MFA

• Root: enable MFA, delete root access keys, use only for the few tasks requiring root
• Enforce MFA for privileged users via policy conditions ("aws:MultiFactorAuthPresent": "true" on sensitive actions)
• Best practice: centralize humans in IAM Identity Center with MFA at the IdP; roles in each account
• Control Tower landing zone provisions accounts: security, log-archive, dev, stage, prod
• SCP on the org root denies leaving allowed Regions and denies un-tagged resource creation
• Developers federate from Okta via IAM Identity Center: permission set DeveloperView (read-only) in prod, DeveloperPowerUser in dev
• Prod deployment pipelines in the cicd account assume a cross-account role in prod (trust policy scoped to the pipeline's role ARN + external ID) — temporary credentials, CloudTrail-audited
• Break-glass: two senior admins hold credentials to a sealed root with hardware MFA in a safe

Worked Example: 30-Account Company Design

• Root: enable MFA, delete root access keys, use only for the few tasks requiring root
• Enforce MFA for privileged users via policy conditions ("aws:MultiFactorAuthPresent": "true" on sensitive actions)
• Best practice: centralize humans in IAM Identity Center with MFA at the IdP; roles in each account
• Control Tower landing zone provisions accounts: security, log-archive, dev, stage, prod
• SCP on the org root denies leaving allowed Regions and denies un-tagged resource creation
• Developers federate from Okta via IAM Identity Center: permission set DeveloperView (read-only) in prod, DeveloperPowerUser in dev
• Prod deployment pipelines in the cicd account assume a cross-account role in prod (trust policy scoped to the pipeline's role ARN + external ID) — temporary credentials, CloudTrail-audited
• Break-glass: two senior admins hold credentials to a sealed root with hardware MFA in a safe