Design Secure Access to AWS Resources

Core Idea

Security is the earliest design consideration: who/what can access which AWS services, how, and when. This task statement is really "IAM fundamentals + account structure + traceability," and the lesson repeatedly returns to fundamentals rather than advanced policy writing — the exam wants you to read and interpret policies, not author complex ones.

Fundamentals Checkpoints (from the transcript's own quiz beats)

• IAM is a global service — its data is replicated across all Regions, not zonal/regional.
• A new AWS account starts with a single root user with unrestricted, unmodifiable permissions — this is the single biggest risk in a fresh account.
• New IAM identities start with zero permissions; access is additive by default (implicit deny).

Root User Risk & Mitigation

• Root permissions cannot be scoped down — if compromised, the entire account is compromised.
• Mitigations: enable MFA on root, stop using root for daily work, create individual IAM users/roles with least privilege instead.

Identities: Users, Groups, Roles

• Decide between user/group/role based on who is authenticating (a person vs. a service vs. a federated identity) and whether access should be long-lived or temporary.
• Roles are the mechanism for temporary, assumable access — used for EC2/Lambda-to-service access, cross-account access, and federation.
• AWS STS (Security Token Service) issues the temporary credentials behind role assumption, both within an account and across accounts.

Federation

• Corporate identities (e.g., Active Directory) that need AWS access shouldn't get native IAM users — federate them into an IAM role instead.
• Know how to design AD → IAM role federation for both AWS Console and programmatic access.

Application Credentials — the one hard rule

• Never hard-code credentials into application code. Use roles (EC2 instance roles, Lambda execution roles) or federation instead. This is presented as an absolute, not a trade-off.

Policies — read-level understanding is enough

• A policy is an object attached to an identity or a resource that defines permissions.
• Identity-based policies (attached to user/group/role): define what that identity can do.
• Resource-based policies (attached to S3 buckets, SQS queues, VPC endpoints, KMS keys, etc.): define who can access that resource and what they can do to it.
  • The structural difference is the Principal element — resource policies must state which principal(s) the policy applies to; identity policies don't.
• Know IAM decision logic: how AWS evaluates when an identity has multiple applicable policies (explicit deny anywhere wins; otherwise default deny unless an explicit allow exists).

Traceability at Scale (multi-account)

• Design for visibility into who/what accessed which resources, in real time, across many accounts.
• Key services: AWS Control Tower (landing zone / guardrails at scale), AWS Organizations (multi-account management), Service Control Policies (org-wide permission ceilings).
• Traceability isn't just logging — it should feed automated investigation/remediation (integration with monitoring/alerting pipelines).

Exam Angle

Expect scenario questions that hinge on:

1. Choosing user vs. group vs. role for a described actor.
2. Reading a policy JSON snippet and identifying what it allows/denies, or whether it's identity- vs. resource-based (spot the Principal key).
3. Picking the federation path for an on-prem/third-party identity.
4. Picking Organizations/Control Tower/SCPs for a "manage many accounts safely" scenario.

Practical Examples

Root user + MFA: You create a brand-new AWS account for a startup. Day one, before doing anything else: log in as root, enable MFA (a hardware key or virtual MFA app), then immediately create an IAM user (or better, set up IAM Identity Center) with AdministratorAccess for daily work. Lock the root credentials away and never use them again except for the ~20 tasks that require root (e.g., closing the account, changing support plan).

Role instead of hardcoded keys: An EC2 instance runs an app that needs to read/write objects in an S3 bucket. Wrong way: bake an IAM user's access key/secret into the app config. Right way: create an IAM role with an S3 read/write policy, attach it as the EC2 instance profile — the SDK picks up temporary credentials automatically via the instance metadata service, no secrets to leak or rotate.

Cross-account access via STS: Your company has a Prod account and a Security account. An auditing Lambda function in Security needs to read CloudTrail logs sitting in Prod. Solution: create an IAM role in Prod with a trust policy naming the Security account as a trusted principal; the Lambda's execution role in Security calls sts:AssumeRole to get temporary credentials scoped to that Prod role. No long-lived cross-account keys anywhere.

Federation with AD: A 500-person company already manages employees in on-prem Active Directory. Instead of creating 500 IAM users, they set up IAM Identity Center (or a SAML federation to IAM roles) so employees log in with their existing AD credentials and get mapped to appropriate IAM roles based on AD group membership — engineers get a Developer role, finance gets a Billing-ReadOnly role.

Identity policy vs. resource policy, side by side: An IAM policy attached to UserA says "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*" — that's an identity policy, granting UserA permission. A bucket policy on my-bucket says "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::123456789012:user/UserA"}, "Action": "s3:GetObject" — that's a resource policy, and the presence of "Principal" is the tell. For cross-account S3 access, you typically need both: the identity policy in the requester's account AND the resource policy on the bucket granting that external principal access.

Explicit deny wins: DevGroup has a policy granting AdministratorAccess. A separate policy attached to the same group explicitly denies iam:* and ec2:TerminateInstances. Result: group members can do almost anything except touch IAM or terminate EC2 instances — the explicit deny always overrides the broad allow, regardless of which policy is "more specific" or attached where.

Traceability at scale: A company with 40 AWS accounts under AWS Organizations wants to know instantly if anyone disables CloudTrail logging or opens a security group to 0.0.0.0/0 on port 22. Setup: AWS Control Tower enforces guardrail SCPs (e.g., deny disabling CloudTrail) org-wide, AWS Config rules flag the open security group, and an EventBridge rule routes the Config finding to a Lambda function that auto-remediates or pages the security team.