AWS • 2026-06-17

AWS IAM Interview Questions & Answers with Diagrams

Master AWS Identity and Access Management with visual diagrams covering users, roles, policies, groups, and security best practices. Complete guide with authentication flows and permission models.

Q1: What is IAM?

graph TB
    IAM[AWS IAM<br/>Identity & Access Management] --> Auth[Authentication<br/>Who are you?]
    IAM --> Authz[Authorization<br/>What can you do?]
    
    Auth --> SignIn[Sign-in Methods]
    SignIn --> Console[AWS Console<br/>Username + Password]
    SignIn --> API[API Access<br/>Access Keys]
    SignIn --> MFA[MFA<br/>Multi-Factor Auth]
    
    Authz --> Perms[Permissions]
    Perms --> EC2[Access EC2]
    Perms --> S3[Access S3]
    Perms --> RDS[Access RDS]
    
    style IAM fill:#FF9900
    style Auth fill:#4CAF50
    style Authz fill:#2196F3

IAM Fundamentals:

Web service that securely controls access to AWS resources
Authentication: Verifies identity (who you are) through credentials
Authorization: Determines permissions (what you can do) through policies
Console access uses username, password, and optional MFA
Programmatic access uses Access Key ID and Secret Access Key
MFA adds extra security layer with time-based one-time passwords
Centralized control over all AWS resource access
Free service—no additional charges for IAM usage

Q2: IAM Key Components

graph TB
    subgraph Components[IAM Components]
        User[IAM User<br/>Person or Service]
        Group[IAM Group<br/>Collection of Users]
        Role[IAM Role<br/>Temporary Identity]
        Policy[IAM Policy<br/>JSON Permissions]
        Perm[IAM Permission<br/>Action on Resource]
    end
    
    User --> Group
    Policy --> User
    Policy --> Group
    Policy --> Role
    
    Perm --> Identity[Identity-based<br/>User, Role, Group]
    Perm --> Resource[Resource-based<br/>S3, Glacier]
    
    Role --> NoCredentials[No Password<br/>No Access Keys]
    User --> HasCredentials[Has Password<br/>Has Access Keys]
    
    style Components fill:#E3F2FD
    style Policy fill:#FF9900

Component Details:

IAM User: Represents person or application with permanent credentials
IAM Group: Collection of users for easier permission management
IAM Role: Temporary identity assumed by users, applications, or services
IAM Policy: JSON document defining allowed or denied actions on resources
Identity-based Permissions: Attached to users, groups, or roles
Resource-based Permissions: Attached directly to resources like S3 buckets
Roles have no permanent credentials—temporary security tokens issued
Users can belong to multiple groups, inheriting all group policies

Q3: IAM Best Practices

graph TB
    Root[Root User<br/>Email + Credit Card] --> RootBest[Root Best Practices]
    
    RootBest --> MFA[Enable MFA<br/>Google Authenticator]
    RootBest --> NoDaily[Don't Use Daily<br/>Create IAM Users]
    
    IAMUser[IAM Users] --> UserBest[User Best Practices]
    UserBest --> LeastPriv[Least Privilege<br/>Minimum Permissions]
    UserBest --> Groups[Use Groups<br/>Not Individual Policies]
    UserBest --> Rotate[Rotate Credentials<br/>Regular Updates]
    UserBest --> Monitor[Monitor Activity<br/>CloudTrail Logs]
    
    style Root fill:#FF5252
    style MFA fill:#4CAF50
    style LeastPriv fill:#2196F3

Security Best Practices:

Root User: Enable MFA immediately, lock away credentials, use only for account management
Never share root credentials or use for daily operations
Least Privilege: Grant only permissions needed for specific tasks
Start with minimal permissions, add more as needed
Use Groups: Assign policies to groups, add users to groups for easier management
Credential Rotation: Regularly rotate passwords and access keys (90 days recommended)
Monitor Activity: Enable CloudTrail to log all IAM actions for auditing
Use IAM Access Analyzer to identify unintended resource access

Q4: EC2 Access to S3 - Role Assignment

sequenceDiagram
    participant EC2 as EC2 Instance
    participant Role as IAM Role
    participant Policy as IAM Policy
    participant S3 as S3 Bucket
    
    Note over EC2,S3: Step 1: Create Role
    Role->>Role: Create IAM Role
    
    Note over EC2,S3: Step 2: Attach Policy
    Policy->>Role: Attach S3 Access Policy
    
    Note over EC2,S3: Step 3: Assign Role
    Role->>EC2: Attach Role to Instance
    
    Note over EC2,S3: Step 4: Access S3
    EC2->>Role: Request Credentials
    Role-->>EC2: Return Temp Credentials
    EC2->>S3: Access Bucket
    S3-->>EC2: Success
    
    Note over EC2: Cannot assign policies<br/>directly to resources!

Role Assignment Process:

Cannot assign policies directly to AWS resources like EC2 instances
Must create IAM Role as intermediary between resource and permissions
Attach policies to role defining what actions are allowed
Assign role to EC2 instance (can be done at launch or after)
EC2 automatically requests temporary credentials from role
Credentials rotate automatically—no manual key management needed
Policies can only be assigned to Users, Groups, and Roles
Roles provide secure, auditable access without embedding credentials in code

Q5: Purpose of Groups

graph TB
    subgraph Without[Without Groups - 100 Users]
        U1[User 1] --> P1[Policy 1]
        U2[User 2] --> P2[Policy 2]
        U3[User 3] --> P3[Policy 3]
        Dots1[...] --> Dots2[...]
        U100[User 100] --> P100[Policy 100]
    end
    
    subgraph With[With Groups - 100 Users]
        DevGroup[Dev Group<br/>50 Users] --> DevPolicy[Dev Policy]
        QAGroup[QA Group<br/>30 Users] --> QAPolicy[QA Policy]
        OpsGroup[Ops Group<br/>20 Users] --> OpsPolicy[Ops Policy]
    end
    
    NewUser[New User] --> DevGroup
    LeftUser[User Leaves] -.Remove.-> QAGroup
    
    style Without fill:#FFCDD2
    style With fill:#C8E6C9

Group Benefits:

Simplifies permission management for large organizations
Instead of 100 individual policies, manage 3 group policies
Create groups based on job function (Developers, QA, Operations, Admins)
New employees automatically get correct permissions by joining appropriate group
Departing employees easily removed from groups
Policy changes apply to all group members instantly
Users can belong to multiple groups (e.g., Developer + Database-Admin)
Maximum 10 groups per user, unlimited users per group

Q6: S3 Public Read - Bucket Policy

graph TB
    Question[S3 Bucket for Public Web Assets] --> Options[Two Approaches]
    
    Options --> A[A: Bucket Policy<br/>Set All Objects Public]
    Options --> B[B: IAM Roles<br/>Set Bucket Public]
    
    A --> AFlow[Bucket Policy Flow]
    AFlow --> Upload1[Upload Object 1]
    AFlow --> Upload2[Upload Object 2]
    AFlow --> Upload3[Upload Object 3]
    AFlow --> Auto[All Automatically Public]
    
    B --> BFlow[IAM Role Flow]
    BFlow --> Manual1[Set Object 1 Public]
    BFlow --> Manual2[Set Object 2 Public]
    BFlow --> Manual3[Set Object 3 Public]
    BFlow --> Tedious[Manual Each Object]
    
    A --> Correct[✓ Correct Answer]
    B --> Wrong[✗ Wrong Approach]
    
    style A fill:#4CAF50
    style B fill:#FF5252

Bucket Policy Approach:

Correct Answer: Configure bucket policy to set all objects to public read
Bucket policy applies to all current and future objects automatically
Single policy statement makes entire bucket public
No need to set permissions on individual objects
IAM roles control who can perform actions, not object accessibility
Bucket policies are resource-based, attached to bucket itself
More efficient for public-facing websites or content distribution
Can combine with CloudFront for better performance and security

Q7: Third-Party S3 Access

sequenceDiagram
    participant Third as Third-Party Software
    participant IAM as Custom IAM User
    participant Policy as Limited Policy
    participant S3 as myorg-backup Bucket
    participant Other as Other Buckets
    
    Note over Third,Other: Limit access to<br/>myorg-backup only
    
    IAM->>Policy: Create Custom Policy
    Policy->>Policy: Allow: S3 API Actions
    Policy->>Policy: Resource: myorg-backup
    
    Third->>IAM: Use IAM Credentials
    IAM->>Policy: Check Permissions
    
    Third->>S3: Access myorg-backup
    Policy->>S3: ✓ Allowed
    S3-->>Third: Success
    
    Third->>Other: Try Other Buckets
    Policy->>Other: ✗ Denied
    Other-->>Third: Access Denied

Granular Access Control:

Create custom IAM user specifically for third-party software
Policy limits access to only "myorg-backup" bucket
Third-party cannot access other S3 buckets or AWS resources
Follows principle of least privilege—minimum necessary permissions
Specify exact S3 API actions allowed (GetObject, PutObject, etc.)
Use resource ARN to restrict to specific bucket
Easy to revoke access by deleting IAM user or removing policy
Audit access through CloudTrail logs for compliance

Q8: External Consultancy Management

graph TB
    Start[Consultancy Hired] --> Create[Create devops Group]
    Create --> AddUsers[Add Team Members]
    AddUsers --> AttachPolicies[Attach Policies]
    
    AttachPolicies --> Work[Setup Infrastructure]
    Work --> Complete[Project Complete]
    
    Complete --> Decision{What to Do?}
    
    Decision --> Wrong1[✗ Delete Group<br/>Lose Policies]
    Decision --> Wrong2[✗ Keep Users<br/>Security Risk]
    Decision --> Correct[✓ Remove Users<br/>Keep Group]
    
    Correct --> Remove[Remove Users]
    Remove --> Delete[Delete Accounts]
    Remove --> Keep[Keep devops Group]
    
    Keep --> Future[Hire Permanent Staff]
    Future --> Reuse[Add to Existing Group]
    Reuse --> Benefit[Reuse Policies]
    
    style Wrong1 fill:#FF5252
    style Wrong2 fill:#FF5252
    style Correct fill:#4CAF50

User Management Strategy:

Remove consultancy users from group immediately after project completion
Delete user accounts to eliminate security risk
Keep the devops group with attached policies intact
Preserves carefully crafted permissions for future use
When hiring permanent staff, add them to existing group
No need to recreate policies from scratch
Maintains consistency in permissions across team changes
Demonstrates proper IAM lifecycle management