AWS Identity and Access Management (Task 2.3)

AWS Identity and Access Management

Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html

IAM answers two questions for every action: authentication (who are you?) and authorization (what may you do?). It is free, global (not per-Region), and enabled on every account. Senior engineers design identity FIRST — most breaches are identity failures, not compute failures.

IAM Building Blocks

How a policy is read (senior skill): every statement has Effect (Allow/Deny), Action (service operations), Resource (which ARNs), and optionally Condition. Example — the payments microservice needs to read one DynamoDB table:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:Scan"],
    "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Payments"
  }]
}

That is least privilege in four lines: three read actions, ONE table, nothing else. NOT AdministratorAccess "because it was faster to set up."

Policy Evaluation Logic (Know the Order)

Brief: When a request is made, AWS evaluates all applicable policies in a strict order:

1. Explicit Deny always wins — any Deny anywhere (identity policy, resource policy, SCP, boundary, session policy) blocks the request. No override exists.
2. Explicit Allow — at least one Allow must exist covering the exact action + resource.
3. Default (implicit) deny — silence is denial. Nothing said = not allowed.

How cross-account differs: when Account A's role assumes into Account B, BOTH sides must allow: B's role trust policy must admit A, and A's identity policy must permit sts:AssumeRole. One-sided permission = denial (a classic exam trap and real-world support ticket).

Real use-case: An org denies all Regions except us-east-1 and eu-west-1 via SCP. A developer's identity policy grants ec2:* — they still cannot launch in Singapore, because SCP denies trump identity allows. Nobody "broke" anything; the evaluation order did its job.

Gotchas & interview notes: memorize "deny > allow > default deny." Permission boundaries cap what an identity CAN ever get (even AdministratorAccess granted to a bounded user is capped); SCPs cap what an entire account/OU can do; neither GRANTS anything alone — they only shrink the envelope of what other allows can do.

Principle of Least Privilege

Brief: Grant only the permissions required for a task — nothing more.

How it works in practice: start from zero and add measured permissions (or start from AWS managed read-only and add write access per task); review with IAM Access Analyzer's unused-access findings and the credential report; scope resources by ARN, never Resource: "*" when a single resource is meant; add conditions (source IP, MFA present, TLS) to tighten further.

Real use-case: An access review finds the CI/CD user holds PowerUserAccess from 2021. Access Analyzer shows it uses 9 actions across 3 services in a year. The replacement policy is 30 lines; the blast radius if that key leaks drops from "entire account" to "one deploy pipeline."

Gotchas & interview notes: over-privileged identities are the #1 amplifier of cloud breaches (see Capital One in the Shared Responsibility topic). Exam phrasing "the MOST secure approach" almost always means: role instead of user, scoped resource ARNs, and MFA conditions.

Managed vs Inline Policies

• AWS managed policies: maintained by AWS, updated as services evolve (AmazonS3ReadOnlyAccess) — zero maintenance, broad strokes.
• Customer managed policies: your own reusable documents, versioned, attachable to many identities — the right home for least-privilege policies under review.
• Inline policies: embedded in ONE identity, deleted with it — for strict one-to-one relationships you want to guarantee disappear with the principal.
• AWS Secrets Manager: store database credentials, API keys; automatic rotation for RDS/Aurora/Redshift via a rotation Lambda; pay per secret ($0.40/secret/month).
• AWS Systems Manager Parameter Store: free tier for configuration values; SecureString for secrets with KMS; the pragmatic choice when you do not need rotation automation.
• Never hardcode credentials in code or bake them into AMIs — the exam always rejects this, and so does every code review you will ever face.
• Root: MFA-enabled, credentials in a safe, used twice a year.
• Groups: Admins, Developers, Finance with least-privilege customer-managed policies.
• Developers federate from Google Workspace via IAM Identity Center — temporary STS credentials, no passwords stored in AWS.
• The CI/CD pipeline assumes a role to deploy — no access keys in environment variables.
• RDS master password lives in Secrets Manager with 30-day rotation; the app fetches it at boot.
• IAM credential report (monthly) flags any access key unused for 90 days → deactivate.

Senior guidance: groups + customer-managed policies for humans; roles + scoped policies for workloads; AWS managed policies only as temporary scaffolding with a cleanup date.

The Root User

Brief: The identity that created the account — unrestricted power, and therefore a target.

How it works: root cannot be limited by IAM policies (SCPs CAN constrain it in Organizations). Protection: enable MFA (virtual/hardware/passkey), strong unique password, no root access keys ever, no daily use. Best practice: break-glass process — credentials sealed, use logged and alerted, reviewed quarterly.

Tasks that REQUIRE root (exam list): change account name/email/root password; change sensitive account settings (e.g., IAM users seeing billing); view certain tax documents; close the account; enable/change the AWS Support plan; restore permissions for a locked-out IAM user. Everything else: IAM roles.

Real use-case: A company's root has hardware-MFA and lives in a safe; quarterly, security verifies root activity in CloudTrail is EMPTY except their own scripted check. Any root login fires an immediate alert to the CISO — because the only valid use is an emergency.

Gotchas & interview notes: "Enable MFA on root" is the single most repeated best-practice answer on the CLF exam. Root access keys are never acceptable; if they exist, deactivate immediately and rotate.

Authentication Methods

Console: password + MFA

Password policies enforce complexity, rotation, reuse limits. MFA adds "something you have" — mandatory for root, best practice for all admins.

Programmatic: access keys

Access key ID + secret for CLI/SDK. Rules that are always correct: rotate (90 days), never embed in code/AMI/env files committed to git, never share between people. The modern answer: avoid long-term keys entirely.

The modern pattern: federation + roles (no IAM users for humans)

Brief: Users authenticate in your existing identity provider (Active Directory, Okta, Google Workspace, Entra ID) and receive temporary AWS credentials via AWS STS — no IAM users, no passwords stored in AWS, access ends automatically with the session.

How it works: IAM Identity Center (successor to AWS SSO) is the hub: it federates your IdP (SAML 2.0 or OIDC) and maps users/groups to permission sets per AWS account in your Organization. Each sign-in calls STS APIs behind the scenes, returning session credentials valid 1–12 hours that expire by themselves.

Real use-case: A 40-person company onboards a new engineer: IT adds her to the "Developers" group in Okta. She is in AWS two minutes later with correct permissions across 4 accounts — no IAM user created, no password to manage, and the day she leaves Okta, AWS access dies with her account.

Gotchas & interview notes: temporary credentials via STS = the exam answer whenever the scenario says "without creating IAM users" or "no long-term keys." Roles for compute (EC2 instance roles, Lambda execution roles, ECS task roles) deliver the same property to applications — credentials rotate automatically via the metadata service.

Cross-account IAM roles

Account A trusts Account B's identity to assume a role in A — temporary credentials, no key sharing, full CloudTrail attribution on both sides. This is THE standard for multi-account access (and for third-party/SaaS access to your resources via an external ID).

Credential Storage & Secrets

• AWS managed policies: maintained by AWS, updated as services evolve (AmazonS3ReadOnlyAccess) — zero maintenance, broad strokes.
• Customer managed policies: your own reusable documents, versioned, attachable to many identities — the right home for least-privilege policies under review.
• Inline policies: embedded in ONE identity, deleted with it — for strict one-to-one relationships you want to guarantee disappear with the principal.
• AWS Secrets Manager: store database credentials, API keys; automatic rotation for RDS/Aurora/Redshift via a rotation Lambda; pay per secret ($0.40/secret/month).
• AWS Systems Manager Parameter Store: free tier for configuration values; SecureString for secrets with KMS; the pragmatic choice when you do not need rotation automation.
• Never hardcode credentials in code or bake them into AMIs — the exam always rejects this, and so does every code review you will ever face.
• Root: MFA-enabled, credentials in a safe, used twice a year.
• Groups: Admins, Developers, Finance with least-privilege customer-managed policies.
• Developers federate from Google Workspace via IAM Identity Center — temporary STS credentials, no passwords stored in AWS.
• The CI/CD pipeline assumes a role to deploy — no access keys in environment variables.
• RDS master password lives in Secrets Manager with 30-day rotation; the app fetches it at boot.
• IAM credential report (monthly) flags any access key unused for 90 days → deactivate.

Real use-case: An app's RDS master password lives in Secrets Manager with 30-day rotation; the app fetches it at boot and on a refresh signal. A leaked application repository contains zero usable credentials — rotation happened 4 days ago.

Worked Example: Secure Access Design (the whole topic in one architecture)

A 40-person company, one AWS account:

• AWS managed policies: maintained by AWS, updated as services evolve (AmazonS3ReadOnlyAccess) — zero maintenance, broad strokes.
• Customer managed policies: your own reusable documents, versioned, attachable to many identities — the right home for least-privilege policies under review.
• Inline policies: embedded in ONE identity, deleted with it — for strict one-to-one relationships you want to guarantee disappear with the principal.
• AWS Secrets Manager: store database credentials, API keys; automatic rotation for RDS/Aurora/Redshift via a rotation Lambda; pay per secret ($0.40/secret/month).
• AWS Systems Manager Parameter Store: free tier for configuration values; SecureString for secrets with KMS; the pragmatic choice when you do not need rotation automation.
• Never hardcode credentials in code or bake them into AMIs — the exam always rejects this, and so does every code review you will ever face.
• Root: MFA-enabled, credentials in a safe, used twice a year.
• Groups: Admins, Developers, Finance with least-privilege customer-managed policies.
• Developers federate from Google Workspace via IAM Identity Center — temporary STS credentials, no passwords stored in AWS.
• The CI/CD pipeline assumes a role to deploy — no access keys in environment variables.
• RDS master password lives in Secrets Manager with 30-day rotation; the app fetches it at boot.
• IAM credential report (monthly) flags any access key unused for 90 days → deactivate.

The senior summary: humans federate, workloads assume roles, secrets rotate, root sleeps in a safe with MFA, and every permission fits the task it serves. If you can draw that on a whiteboard, you can both pass Task 2.3 and run identity for a real company.