AWS Zero to Hero: Scenario-Based Interview Questions on EC2, IAM, and VPC

Mastering AWS foundations requires moving beyond simple definitions to solve real-world architectural challenges. This chapter breaks down 10 core scenario-based interview questions covering Amazon VPC, subnets, Security Groups, Network ACLs, and AWS IAM, providing production-grade architectural solutions and industry best practices.

1. High-Availability & Scalable 2-Tier VPC Architecture

The Scenario

An interviewer asks you to design a secure, highly available, and scalable 2-tier application architecture inside an Amazon VPC. How do you design this infrastructure?

The Mental Model & Approach

A 2-tier application separates the architecture into a front-end/application layer and a client access layer (with databases deferred to a 3-tier model). Designing for High Availability (HA) and Scalability requires solving two distinct challenges:

1. High Availability: Distribute workloads across multiple Availability Zones (AZs) so that if one physical data center fails, the application remains fully online.
2. Scalability: Automatically adjust compute capacity based on incoming traffic loads.

Architectural Breakdown

• Public Subnet: Hosts the Application Load Balancer (ALB), serving as the single entry point accessible directly from the internet.
• Private Subnet: Hosts the actual application servers (EC2 instances), isolated from direct public inbound traffic.
• Multi-AZ Deployment: Subnets and compute nodes span at least two Availability Zones (e.g., us-east-1a and us-east-1b).
• Auto Scaling Groups (ASG): Automatically scales application server instances up or down based on CPU utilization or request counts.

2. Restricting Outbound Internet Access in Specific Subnets

The Scenario

Your organization manages a VPC with multiple subnets. You need to completely restrict outbound internet access for resources in a specific subnet while maintaining outbound access in other subnets. How do you achieve this?

The Technical Solution

While Security Groups can control outbound access at the instance level, the most efficient and robust architectural control is managing Route Tables:

1. Identify the target subnet whose outbound internet traffic must be restricted.
2. Locate the specific Route Table associated with that subnet.
3. Remove the default route (0.0.0.0/0) pointing to the Internet Gateway (igw-xxxxxxxx).

Note: Without a default route pointing to an Internet Gateway, any outbound traffic destined for the public internet is immediately dropped by the VPC router, successfully isolating the subnet's external reach.

3. Enabling Secure Internet Access for Private Subnet Instances

The Scenario

EC2 instances launched inside a private subnet require occasional internet access to fetch software updates, patches, or external API data. How do you allow outbound internet access while preventing inbound connections?

The Core Analogy & Mechanism: NAT Gateway

Deploying a NAT Gateway (Network Address Translation) in a public subnet solves this challenge securely:

• Outbound Flow: Private instances forward traffic to the NAT Gateway via their subnet route table.
• IP Translation: The NAT Gateway translates the private IP address of the EC2 instance into its own public IP address before forwarding the packet out through the Internet Gateway.
• Security Shield: External endpoints only see the public IP of the NAT Gateway. If an external service is compromised, it has no visibility into or direct access back to the private EC2 instances.

4. Private IP Communication Between EC2 Instances

The Scenario

Two EC2 instances (Foo and Bar) reside within your VPC and need to communicate directly with each other using their private IP addresses. What steps ensure this communication succeeds?

Configuration Checklist

1. Same VPC Membership: Both instances must reside within the same VPC, or across VPCs connected via VPC Peering.
2. Subnet Route Alignment: If Foo and Bar reside in different subnets within the same VPC, the VPC's local route table (10.0.0.0/16 local) automatically permits communication between all subnets inside that VPC without extra gateways.
3. Security Group & NACL Rules: Ensure that inbound security group rules on Bar permit traffic from Foo's security group or IP range on the required ports.

5. Implementing Strict Network Access Control at the Subnet Level

The Scenario

Your security team mandates strict, fine-grained network access control rules at the subnet boundary rather than just the individual instance level. How do you implement this?

Security Groups vs. Network ACLs (NACLs)

Best Practice: Use Security Groups as your primary firewall for application-tier access control, and layer Network ACLs on subnets as an additional defense-in-depth perimeter block.

6. Creating an Isolated Environment Within a VPC

The Scenario

Your organization requires a highly sensitive isolated environment within an existing VPC to run internal workloads that must have zero exposure to the internet. How do you construct this?

Implementation Strategy

• Subnet Slicing: Carve out a dedicated private CIDR block (e.g., 10.0.3.0/24) from your main VPC IP pool.
• Route Table Isolation: Attach a custom route table to this subnet containing only the local VPC route (10.0.0.0/16). Do not attach an Internet Gateway or NAT Gateway route.
• Result: Complete network isolation. Even if administrative credentials are leaked on an instance within this subnet, no external network route exists to tunnel traffic in or out of the environment.

7. Connecting to AWS Services Securely via VPC Endpoints

The Scenario

Your application running on EC2 instances inside a private subnet needs to access AWS services (like Amazon S3 or DynamoDB) securely without traversing the public internet or requiring a NAT Gateway. How do you achieve this?

Solution: VPC Endpoints (Gateway vs. Interface)

Instead of routing requests over the public internet, you provision a VPC Endpoint:

• Gateway Endpoints: Specifically support Amazon S3 and DynamoDB. You update your private subnet route table to point traffic destined for S3 directly to the Gateway Endpoint within the VPC network fabric.
• Interface Endpoints (AWS PrivateLink): Powered by Elastic Network Interfaces (ENIs) with private IPs, routing traffic to supported AWS services privately inside your VPC.

8. IAM Users, Groups, Roles, and Policies Deep Dive

The Scenario

An interviewer asks you to differentiate between IAM Users, Groups, Roles, and Policies, and explain when to use each.

Core IAM Concepts Summary

• IAM Users: Long-term identities representing individual humans (developers, administrators, testers) requiring access to the AWS Console or CLI.
• IAM Policies: JSON documents defining Permissions (Authorization). Policies specify what actions are allowed on which AWS resources.
• IAM Groups: Collections of IAM users. Instead of attaching policies to 500 individual developer accounts, assign them to a Developers group.
• IAM Roles: Temporary identities assumed by trusted entities—such as an EC2 instance needing access to S3, or cross-account access—eliminating the need to embed long-term access keys in application code.

9. Designing a Bastion Host (Jump Server) Architecture

The Scenario

You have private subnet instances hosting core application servers that must remain isolated from direct internet access. However, systems administrators require secure shell access for maintenance. How do you architect a Bastion Host?

Architectural Workflow

1. Public Subnet Bastion: Deploy a hardened Linux/Windows EC2 instance in the public subnet acting as the Bastion Host (Jump Server).
2. Restricted Inbound Rules: Configure the Bastion's Security Group to allow inbound SSH (Port 22) or RDP (Port 3389) only from corporate static IP ranges (VPN/office IPs).
3. Internal Tunneling: Admins SSH into the Bastion Host first, then securely tunnel or SSH onward to the private application instances.

Admin Workstation (Office IP)
       |
       | SSH (Port 22) - Restricted Security Group
       v
Bastion Host (Public Subnet)
       |
       | Internal SSH (Port 22) across VPC
       v
Private Application Instance (Private Subnet)

10. Summary and Key Takeaways

• Multi-AZ Availability: Always distribute your subnets, load balancers, and Auto Scaling Groups across multiple Availability Zones to ensure high availability.
• Subnet Outbound Control: Control outbound internet access cleanly by modifying subnet route tables to include or exclude Internet Gateway routes (0.0.0.0/0).
• NAT Gateways: Use NAT Gateways in public subnets to provide secure, unidirectional outbound internet access (for patches and updates) to instances in private subnets.
• VPC Local Routing: Instances within the same VPC communicate over private IP addresses automatically via the local route table without external gateways.
• Security Layers: Combine instance-level Security Groups (stateful) with subnet-level Network ACLs (stateless) for robust defense-in-depth network security.
• Isolated Subnets: Achieve absolute workload isolation by provisioning private subnets devoid of any internet or NAT gateway routes.
• VPC Endpoints: Access AWS native services (like S3 and DynamoDB) privately within your VPC without traversing the public internet.
• IAM Best Practices: Use Users and Groups for human management, Policies for fine-grained authorization, and Roles for granting secure, keyless permissions to AWS services like EC2.
• Bastion Hosts: Implement a hardened Bastion Host in a public subnet with strict IP whitelisting to safely administer private subnet resources.