🔐 AWS IAM — Full DevOps Interview Deep Dive

✅ Part 1 — Core IAM Entities (Interview Foundation)

✅ Q1 — What are IAM Users, Roles, Groups — real difference?

User = long-term identity for a human or system (username + credentials). Group = permission container for users only — cannot be assumed. Role = temporary identity that can be assumed by users, services, or accounts.

Modern best practice: minimize users, maximize roles. Roles are safer because they use temporary credentials.

✅ Q2 — Why are IAM Users discouraged in modern production setups?

Because they rely on long-lived credentials (access keys/passwords). Long-lived secrets are high risk. Modern design uses SSO + role assumption + short-lived tokens. Users are mostly replaced by federated identities.

✅ Part 2 — IAM Policies (Where Most Interviews Go Deep)

✅ Q3 — What is an IAM policy really?

A policy is a JSON document defining Allow or Deny for actions on resources with optional conditions. Policies don’t attach to resources alone — they attach to identities or resources depending on type. Policy = permission logic, not identity.

✅ Q4 — Types of IAM policies interviewers expect you to know

• Identity-based policies (attached to user/role/group)
• Resource-based policies (attached to resource like S3 bucket)
• Trust policies (who can assume role)
• Permission boundaries
• SCPs (org-level guardrails)

If you miss trust vs permission — senior interview red flag.

✅ Q5 — How AWS evaluates permissions (critical interview topic)

Evaluation logic:

1. Explicit Deny always wins
2. Then Allow
3. If no Allow → implicit deny

Multiple policies are combined. One deny anywhere blocks access. This is how guardrails are enforced.

✅ Part 3 — Roles Deep Dive (High Importance)

✅ Q6 — What is IAM Role assumption flow?

An identity calls sts:AssumeRole. AWS checks the trust policy of the role. If allowed, temporary credentials are issued. Those creds carry the role’s permission policy. Access is time-limited.

✅ Q7 — Trust policy vs Permission policy — difference?

Trust policy = who can assume the role Permission policy = what the role can do after assumption

Trust answers “who enters.” Permission answers “what they can touch.” Interviewers love this distinction.

✅ Q8 — Service roles vs execution roles — what’s the difference?

Service role = role assumed by AWS service. Execution role = role used while service runs.

Example: Lambda execution role — permissions Lambda code uses at runtime. Confusing them is common interview mistake.

✅ Part 4 — Cross-Account Access (Senior-Level Topic)

✅ Q9 — How do you design cross-account access safely?

Create role in target account with trust policy allowing source account role/user. Source assumes role via STS. No sharing of keys. External ID used for third-party access. Access is temporary and auditable.

✅ Q10 — Why use External ID in cross-account roles?

Prevents confused deputy problem. Ensures third party assumes role only when correct external ID is provided. Common fintech vendor integration requirement.

✅ Part 5 — Permission Boundaries & SCP (Advanced Guardrails)

✅ Q11 — What is a permission boundary?

A boundary limits the maximum permissions a role/user can ever get — even if a policy grants more. It’s a ceiling. Used in self-service environments where teams can create roles but within limits.

✅ Q12 — SCP vs Permission Boundary — difference?

SCP = org-level guardrail across accounts. Permission boundary = identity-level ceiling. SCP applies before identity policy. SCP cannot grant — only restrict.

✅ Part 6 — Conditions & Least Privilege

✅ Q13 — How do IAM conditions strengthen security?

Conditions restrict when/how access is allowed — IP, MFA, time, tags, VPC, TLS. Example: allow S3 only from VPC endpoint. Conditions convert broad allow into contextual allow.

✅ Q14 — Tag-based access control — why powerful?

Permissions based on resource tags. Enables scalable least-privilege by environment/team tags. Used heavily in platform automation.

✅ Part 7 — Real DevOps IAM Design Patterns

✅ Q15 — CI/CD IAM design best practice

CI pipeline uses dedicated role — not user keys. Role has scoped permissions only for required resources. Separate roles per environment. No wildcard admin for pipelines.

✅ Q16 — EKS workload IAM best practice

Use IRSA (IAM Roles for Service Accounts). Pod assumes IAM role directly. Avoid node-role over-permission. Pod-level least privilege.

✅ Q17 — Lambda IAM best practice

Each Lambda gets its own execution role. Only required permissions. No shared “lambda-admin” role.

✅ Part 8 — Limits & Quotas

✅ Q18 — IAM limits interviewers may ask

• policy size limits
• number of policies per role
• role count per account
• inline vs managed policy limits

Large orgs hit these — module design matters.

✅ Part 9 — Common Real-World IAM Mistakes

✅ Q19 — Biggest IAM mistake in DevOps teams

Using *:* admin policies for speed and never fixing later. This becomes permanent risk. Least privilege must be enforced early.

✅ Q20 — Second biggest mistake

Using user access keys in apps instead of roles. Key leakage incidents are very common breach vector.

✅ Part 10 — When Interviewers Push Further

Expect follow-ups like:

• explain policy evaluation with SCP + boundary + identity policy
• debug “access denied” step-by-step
• design IAM for multi-team platform
• design least privilege for Terraform
• design IAM for cross-account CI/CD