IAM

IAM is the permission model everything else inherits (L262) — the users (the human identities, L262), the roles (the machine identities, L262), the policies (the permission documents: what action on what resource, L262), and the trust (who may assume a role, L262) — the least-privilege model (L262) that the L172 baseline (L172) runs on in the cloud (L262).

The one-sentence interview answer: "IAM is AWS's identity and access management (L262). The identities: users — the humans, with a password or a key (L262); roles — the machine identities, assumed by the Lambda (L266), the ECS tasks (L271), and the humans with the right trust (L262). The permissions: policies — JSON documents that say what action on what resource, e.g. bedrock:InvokeModel on the model (L278) (L262). The trust: the role's trust policy — who may assume it (L262). The model's rule is least privilege (L262): every identity gets exactly the permissions it needs — the Lambda (L266) can invoke the model (L278) and nothing else (L262). The AI shape: the API Gateway (L267) authenticates and invokes the Lambda (L266); the Lambda's role (L262) calls Bedrock (L278), reads the S3 (L265), and writes the logs (L274) — each with the least privilege (L262). The demo uses the root key; the architect uses IAM (L262)."

Think of IAM as the building's badge system. The people (the users, L262) carry badges with their permissions — which floors, which rooms (L262). The machines (the roles, L262) carry service badges — the elevator (the Lambda, L266) may go to the floors its badge allows (L262). The badge rules (the policies, L262) are the printed access lists: what each badge may open (L262). And the trust (L262) is the guard's instructions: who may check out which service badge (L262). The building works because every badge is scoped to exactly what it needs (L262) — the least privilege (L262).

   the badge system (IAM, L262)
   ┌────────────────────────────────────────────────────────┐
   │ the people (the users, L262)                           │
   │ the machines (the roles, L262) — the Lambda (L266)     │
   │ the rules (the policies, L262) — what action, what     │
   │ resource (L262)                                        │
   │ the trust (L262) — who may assume a role (L262)        │
   └────────────────────────────────────────────────────────┘

The mental model is the badge system: the people, the machines, the rules, and the trust (L262).

   the caller (L262)
        │
        ▼
   ┌────────────────────── THE IDENTITY (L262) ───────────────────────┐
   │  the user (the human) or the role (the machine) (L262)          │
   └──────────────────────────┬───────────────────────────────────────┘
                              ▼
   ┌────────────────────── THE TRUST (L262) ─────────────────────────┐
   │  the role's trust policy: who may assume it (L262)              │
   │  the Lambda (L266) assumes the role (L262)                      │
   └──────────────────────────┬───────────────────────────────────────┘
                              ▼
   ┌────────────────────── THE POLICY (L262) ────────────────────────┐
   │  the permission: what action on what resource (L262)            │
   │  e.g. bedrock:InvokeModel on the model (L278)                   │
   └──────────────────────────┬───────────────────────────────────────┘
                              ▼
   ┌────────────────────── THE ACTION (L262) ────────────────────────┐
   │  the call succeeds — or is denied (L262)                        │
   └──────────────────────────────────────────────────────────────────┘

The flow is the permission path: identity → trust → policy → action (L262).

• The users (L262). The human identities — with a password for the console or a key for the API (L262). The humans don't get keys in production (L262); the machines do (L262).
• The roles (L262). The machine identities — assumed by the Lambda (L266), the ECS tasks (L271), the EC2 instances (L264) (L262). The role carries the permissions, not the caller (L262).
• The policies (L262). The permission documents — JSON: Effect, Action, Resource (L262). The policy says what action on what resource — bedrock:InvokeModel on the model (L278), s3:GetObject on the bucket (L265) (L262).
• The trust (L262). The role's trust policy — who may assume it (L262). The Lambda (L266) may assume its role; nothing else may (L262).
• The least privilege (L262). The rule: every identity gets exactly the permissions it needs (L262) — nothing more (L262).

• A serverless AI stack (L283). The API Gateway (L267) authenticates, invokes the Lambda (L266), and the Lambda's role (L262) calls Bedrock (L278), reads the S3 (L265), and writes the logs (L274).
• A data pipeline (L270). The SQS consumer's role (L270) reads the queue (L270), calls the model (L278), and writes the results (L265) — each with the least privilege (L262).
• An admin console (L262). The human users with scoped policies (L262) — the developers, the ops, the auditors (L322).
• A cross-account setup (L262). The roles assumed across accounts (L262) — the central security account (L262).
• Anything AWS (L262). The permission model is IAM (L262) — every service inherits it (L262).

The through-line: the permission model is the map's access — every AWS action runs through IAM (L262).

Say it in four moves:

1. The identities. "Users — the humans; roles — the machines (L262)."
2. The policies. "JSON documents: what action on what resource (L262)."
3. The trust. "The role's trust policy — who may assume it (L262)."
4. The rule. "Least privilege — every identity gets exactly what it needs (L262)."

• The role is the security boundary (L262). The senior answer puts the permissions on the roles (L262), not the callers (L262) — the Lambda's role (L266), the ECS task's role (L271) — scoped and temporary (L262).
• The policy is the review surface (L262). The senior review reads the policies (L262) — the Action and Resource lists are the attack surface (L262). The widest Action: "*" is the red flag (L262).
• The trust is the blast-radius control (L262). The trust policy (L262) limits who may assume the role (L262) — the L314 agency control, IAM-shaped (L262).
• The least privilege is the compliance record (L371). The scoped policies (L262) are the audit's evidence (L322) — who could do what, when (L262).
• The keys are the exception (L275). The long-lived keys that can't be roles (L262) live in Secrets Manager (L275) — rotated and scoped (L275).

• The root key in the app (L262). The root credentials in the code (L262) — the whole account exposed (L321).
• The widest policy (L262). Action: "*" everywhere (L262) — the least privilege lost (L262).
• The keys in the image (L262). The credentials baked into the container (L301) — the image is public (L293).
• The trust too open (L262). The role assumable by anything (L262) — the L314 agency (L314) unchecked.
• The users for machines (L262). The long-lived user keys for the Lambda (L262) — the role is the production identity (L262).

• Use roles, not keys (L262) — the Lambda (L266), the ECS tasks (L271), the EC2 (L264).
• Scope every policy (L262) — the action and the resource (L262).
• Write the trust narrowly (L262) — who may assume the role (L262).
• Review the policies (L262) — the audit's evidence (L322).
• Keep the exception keys in Secrets Manager (L275) — rotated and scoped (L275).

Q: Walk me through IAM.

A: The permission model (L262). The identities: users — the humans; roles — the machines (L262). The policies: JSON documents — what action on what resource (L262). The trust: who may assume a role (L262). And the rule: least privilege (L262).

Q: Why roles and not keys?

A: Because the keys are long-lived and unscoped (L262). The role is temporary and scoped (L262): the Lambda (L266) assumes its role, gets the credentials for the session, and the permissions are exactly the policy's (L262). The long-lived keys are the exception — they live in Secrets Manager (L275), rotated (L275).

Q: How does the Lambda get its permissions?

A: Through its execution role (L262). The Lambda (L266) is configured with an IAM role (L262); the role's policy says what the Lambda may do — invoke the model (L278), read the S3 (L265), write the logs (L274) — and the trust policy says the Lambda service may assume it (L262).

Q: What's least privilege?

A: Every identity gets exactly the permissions it needs — nothing more (L262). The Lambda (L266) may call the model (L278) and nothing else (L262); the reader role may read the bucket (L265) and nothing else (L262). Least privilege is the L172 baseline, IAM-shaped (L262).

• What are the identities (L262)?
• What's in a policy (L262)?
• What's the trust policy (L262)?
• Why roles and not keys (L262)?
• How does the Lambda get its permissions (L262)?

The senior read: the right column is the production identity — temporary, scoped, and assumed (L262).

// The least-privilege role for a Lambda (L262, L266).
// THE ROLE (L262) — the machine identity the Lambda assumes (L266).
const lambdaRole = {
  AssumeRolePolicyDocument: {
    Statement: [{
      Effect: 'Allow',
      Principal: { Service: 'lambda.amazonaws.com' },   // the trust (L262)
      Action: 'sts:AssumeRole',
    }],
  },
};

// THE POLICY (L262) — what action on what resource (L262).
const permissions = {
  Statement: [
    // The model access (L278) — nothing else.
    { Effect: 'Allow', Action: 'bedrock:InvokeModel',
      Resource: 'arn:aws:bedrock:us-east-1::foundation-model/*' },
    // The data access (L265) — the one bucket, the one prefix.
    { Effect: 'Allow', Action: 's3:GetObject',
      Resource: 'arn:aws:s3:::docs/*' },
    // The logs (L274) — the write, not the delete.
    { Effect: 'Allow', Action: 'logs:CreateLogStream',
      Resource: '*' },
  ],
};

// The result: the Lambda (L266) may invoke the model (L278),
// read the docs (L265), and write the logs (L274) — nothing else (L262).

What the reader must SEE — the least privilege, declared:

  lambda.amazonaws.com → the trust — who may assume the role (L262)
  bedrock:InvokeModel  → the model access — nothing else (L278)
  s3:GetObject         → the data access — one bucket (L265)
  logs:CreateLogStream → the logs — the write, not the delete (L274)

  The role is the boundary; the policy is the scope (L262).

• The permission check is cached (L262). IAM's decision is fast (L262) — the auth path (L237) isn't slowed (L151).
• The temporary credentials are cheap (L262). The role assumption (L262) adds no meaningful latency (L262) — the Lambda's cold start (L266) dominates (L266).
• The policy review is the maintenance cost (L262). The scoped policies (L262) are the review surface (L322) — the wider the policy, the more the audit (L262).
• The secrets are the exception's cost (L275). The keys in Secrets Manager (L275) — the rotation (L275) is a small recurring cost (L275).

• IAM = the permission model (L262): the users, the roles, the policies, the trust.
• The users: the humans (L262).
• The roles: the machines (L262) — the Lambda (L266), the ECS tasks (L271).
• The policies: what action on what resource (L262).
• The rule: least privilege (L262).

IAM = the permission model everything else inherits

THE IDENTITIES (L262)
  users — the humans: password / key
  roles — the machines: temporary, assumed (L262)
  the production shape: roles, not keys (L262)

THE POLICIES (L262)
  JSON: Effect · Action · Resource
  e.g. bedrock:InvokeModel on the model (L278)
       s3:GetObject on the bucket (L265)

THE TRUST (L262)
  who may assume the role — the Principal
  e.g. lambda.amazonaws.com (L266)

THE RULE (L262)
  least privilege — exactly what each identity needs
  the L172 baseline, IAM-shaped (L172, L262)

INTERVIEW, 4 MOVES
  1 identities "users — the humans; roles — the machines (L262)"
  2 policies  "what action on what resource (L262)"
  3 trust     "who may assume the role (L262)"
  4 rule      "least privilege (L262)"

You now hold the permission model: the users, the roles, the policies, and the trust — with least privilege as the rule. The map has access control — and every service inherits it (L262).

Next: the network everything runs on — VPC & Networking (L263).