troubleshooting
Here are some scenario-based AWS VPC interview questions with answers, tailored for your DevOps Consultant interview at Infosys:
Scenario 1: Public & Private Subnets for a Web Application
Question:
Your company is deploying a web application on AWS. The frontend should be publicly accessible, while the backend (database) should remain private. How would you design the AWS VPC for this?
Answer:
A
VPC Setup:
Create a VPC (e.g., 10.0.0.0/16).
Create two subnets:
Public Subnet (e.g., 10.0.1.0/24) → For web servers (EC2 with Nginx).
Private Subnet (e.g., 10.0.2.0/24) → For backend servers and database (RDS).
Routing & Internet Access:
Attach an Internet Gateway (IGW) to the VPC.
Update the route table for the public subnet → Direct internet-bound traffic (
0.0.0.0/0) to IGW.For the private subnet, use a NAT Gateway (placed in the public subnet) to allow outbound internet access.
Security Best Practices:
Security Groups:
Web servers: Allow inbound HTTP/HTTPS (
80, 443) from0.0.0.0/0.Database: Allow inbound only from the web servers.
NACLs:
Deny access to non-required IPs.
High Availability:
Deploy EC2 instances in multiple AZs for redundancy.
Use an Application Load Balancer (ALB) to distribute traffic.
Enable Multi-AZ RDS for failover.
✅ This architecture ensures security, scalability, and high availability.
Scenario 2: Connecting Two VPCs in Different AWS Accounts
Question:
You need to connect two VPCs in different AWS accounts for secure communication between microservices. What are the possible solutions, and which one would you recommend?
Answer:
A
Solution 1: VPC Peering
Pros:
Simple, low-latency connection.
No additional cost except for data transfer.
Cons:
No transitive peering (VPC A cannot talk to VPC C through B).
Complex if multiple VPCs need to communicate.
Solution 2: AWS Transit Gateway (Recommended for multiple VPCs)
Pros:
Centralized routing for multiple VPCs.
Supports transitive routing.
Cons:
Higher cost compared to VPC Peering.
Implementation Steps for Transit Gateway:
Create a Transit Gateway in Account A.
Attach VPC A and VPC B to the Transit Gateway.
Configure route tables to direct traffic through the gateway.
Ensure Security Groups & NACLs allow required traffic.
✅ Recommendation: If only two VPCs need to communicate, use VPC Peering. If multiple VPCs need connectivity, use AWS Transit Gateway.
Scenario 3: Troubleshooting Private EC2 Without Internet Access
Question:
An EC2 instance in a private subnet cannot access the internet. What are the possible causes, and how would you troubleshoot?
A
Answer:
Possible causes and solutions:
No NAT Gateway →
Solution: Ensure the NAT Gateway is deployed in a public subnet and associated with the route table of the private subnet.
Route Table Misconfiguration →
Solution: The private subnet should have a route:
Missing Internet Gateway (for NAT Gateway) →
Solution: The NAT Gateway itself must be in a public subnet with a route to the Internet Gateway.
Security Group Restrictions →
Solution: Ensure the EC2 instance’s security group allows outbound traffic (e.g., to port 80 for HTTP).
Network ACL Blocking Traffic →
Solution: Check if the NACL is blocking outbound traffic (
0.0.0.0/0).
✅ Approach: Use traceroute and VPC Flow Logs to debug network traffic.
Scenario 4: VPC Design for Hybrid Cloud (On-Prem + AWS)
Question:
A company has an on-premises data center and wants to securely extend it to AWS. What are the best options, and how would you implement them?
A
Answer:
Option 1: AWS Site-to-Site VPN
Pros:
Quick and cost-effective.
Uses IPSec tunnels over the internet.
Cons:
Higher latency compared to Direct Connect.
Bandwidth limited to 1.25 Gbps per tunnel.
Option 2: AWS Direct Connect (Recommended for Low Latency)
Pros:
Dedicated fiber connection (1 Gbps, 10 Gbps options).
More secure and lower latency than VPN.
Cons:
Higher setup cost.
Implementation Steps for Direct Connect:
Set up Direct Connect in the nearest AWS Direct Connect location.
Create a Private VIF to connect the on-prem network to AWS VPC.
Configure BGP Peering for route exchange.
Implement AWS Transit Gateway for multi-VPC connectivity.
Use AWS Route 53 Resolver for DNS resolution between AWS & on-prem.
✅ Recommendation: Use Direct Connect if low latency is needed; otherwise, VPN is cost-effective for backup.
Scenario 5: Securing Sensitive Data in AWS VPC
Question:
You are handling sensitive healthcare data in AWS. How would you ensure a secure VPC architecture?
Answer:
A
Key Security Measures:
Use Private Subnets for Data Storage
Deploy databases (RDS, S3) in private subnets.
Disable public access for sensitive resources.
Implement IAM & Least Privilege Access
Use IAM roles for EC2 and services instead of root accounts.
Restrict S3 bucket policies (avoid
s3:*permissions).
Network Security Controls
Enable VPC Flow Logs for monitoring.
Use AWS GuardDuty for anomaly detection.
Configure WAF (Web Application Firewall) for protection against attacks.
Data Encryption
Enable RDS Encryption using KMS keys.
Use TLS (HTTPS) for all application communication.
DDoS Protection & Compliance
Enable AWS Shield for DDoS protection.
Maintain compliance (HIPAA, PCI DSS) using AWS Audit Manager.
✅ Outcome: A highly secure, HIPAA-compliant AWS VPC architecture.
Scenario 1: Connecting VPCs Across Regions
Q: Your company has workloads in two AWS regions (us-east-1 and ap-south-1). The application needs secure, low-latency communication between VPCs across these regions. How would you design this?
A
For VPC-to-VPC connectivity across regions, AWS provides two options:
Inter-Region VPC Peering
Direct, private connectivity between VPCs in different regions.
Simple setup, low latency.
Limitation: no transitive routing (each peering must be point-to-point).
AWS Transit Gateway (TGW) with inter-region peering
Acts as a hub-and-spoke for multiple VPCs across regions.
Supports transitive routing, centralized management.
Better for multi-account, multi-VPC architectures.
Answer (Interview-Ready): 👉 “To connect VPCs across regions, I would use either Inter-Region VPC Peering if it’s a small setup, or Transit Gateway peering if we have multiple VPCs and accounts. TGW provides centralized routing and easier scaling, while VPC peering is simpler but limited to point-to-point connectivity. For production and future scalability, TGW is usually the better choice.”
Scenario 2: Designing Workloads That Need to Access S3/DynamoDB Without Using Public Internet
Q: Your application runs in private subnets and needs to access S3 and DynamoDB, but security requirements say no traffic should go through the public internet. How would you design this?
A
Use VPC Endpoints:
Gateway Endpoint (for S3 and DynamoDB)
Add a route in the route table pointing S3/DynamoDB traffic to the endpoint.
Traffic stays inside AWS private network, not the internet.
No extra cost for data processed through endpoints (only EC2 ↔ S3 traffic charges).
Interface Endpoint (PrivateLink) for other AWS services.
Creates ENIs in subnets that privately connect to AWS services without internet exposure.
Answer (Interview-Ready): 👉 “For workloads in private subnets that need S3/DynamoDB access without internet, I would configure a VPC Gateway Endpoint. This keeps traffic within the AWS backbone, improving both security and performance. For other services beyond S3/DynamoDB, I’d use Interface Endpoints (PrivateLink) so the application never needs to go through the public internet.”
🔥 Final Tips for the Infosys Interview
✅ Prepare real-world VPC scenarios like hybrid cloud, microservices, and security best practices. ✅ Use AWS Well-Architected Framework as a reference. ✅ Be confident and explain trade-offs between different VPC solutions.
Would you like a mock interview session to practice these scenarios? 🚀
Last updated