USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. How do you design a highly available architecture on AWS?
Short answer: Multi-AZ, load balancing, autoscaling, managed data stores, no single points of failure.
Strong answer: Spread compute across Availability Zones behind an ELB, use Auto Scaling groups, put data in multi-AZ RDS/Aurora or DynamoDB, and front with Route 53 health checks. Add caching (CloudFront/ElastiCache) and decouple with SQS/SNS. Design so any one AZ or instance can fail without downtime.
Likely follow-up: How would you extend this to multi-region?
What the interviewer is checking: Well-Architected reliability thinking.
Common mistake: Single-AZ deployments called "highly available".
Q2. Explain IAM roles vs users vs policies.
Short answer: Users = long-term creds; roles = assumable temporary creds; policies = permissions.
Strong answer: IAM users hold long-term credentials; roles grant temporary credentials assumed by services or federated identities (preferred, no static keys); policies (JSON) define allowed/denied actions. Best practice: least privilege, roles over users for workloads, and no root usage.
Likely follow-up: Why prefer roles over access keys for EC2 workloads?
What the interviewer is checking: Security model understanding.
Common mistake: Baking access keys into instances or code.
Q3. When would you use S3 vs EBS vs EFS?
Short answer: S3 = object storage; EBS = block volume for one instance; EFS = shared file system.
Strong answer: S3 for durable object storage (assets, backups, data lakes) via API; EBS for low-latency block storage attached to a single EC2 instance; EFS for a shared POSIX file system across many instances. Choose by access pattern, sharing, and latency needs.
Likely follow-up: Which fits a shared upload directory across many app servers?
What the interviewer is checking: Storage selection judgment.
Common mistake: Using EBS where shared access (EFS/S3) is needed.
Q4. How do Lambda and serverless change architecture?
Short answer: Event-driven, auto-scaling functions with no servers to manage; pay per use.
Strong answer: Lambda runs code in response to events, scaling automatically and billing per invocation. It suits event processing, APIs (with API Gateway), and glue logic. Watch cold starts, execution limits, and statelessness; use Step Functions for orchestration. It shifts ops burden to design and observability.
Likely follow-up: What are the trade-offs vs always-on containers?
What the interviewer is checking: Serverless design awareness.
Common mistake: Using Lambda for long-running, heavy, stateful workloads.
Q5. How would you optimize AWS costs without hurting reliability?
Short answer: Right-size, autoscale, savings plans, storage tiers, and kill idle resources.
Strong answer: Right-size from real metrics, autoscale to demand, buy Savings Plans/Reserved for steady load, use Spot for fault-tolerant work, move cold data to cheaper S3 tiers, and clean up unattached EBS/idle resources. Tag and monitor with Cost Explorer/budgets.
Likely follow-up: Where would Spot instances be risky?
What the interviewer is checking: Cost-vs-reliability judgment.
Common mistake: Over-provisioning "just in case" and never reviewing spend.
Q6. Explain VPC basics: subnets, route tables, and security groups.
Short answer: A VPC is your private network; subnets segment it; SGs are stateful instance firewalls.
Strong answer: A VPC is an isolated network; public/private subnets segment it by route table (public routes to an internet gateway, private via NAT). Security groups are stateful, instance-level allow rules; NACLs are stateless subnet-level rules. Good design keeps databases in private subnets.
Likely follow-up: Why put your database in a private subnet?
What the interviewer is checking: Networking fundamentals.
Common mistake: Exposing databases in public subnets.
Q7. How do you build a decoupled, event-driven system on AWS?
Short answer: Use SQS/SNS/EventBridge between producers and consumers.
Strong answer: Producers publish to SNS/EventBridge; consumers process from SQS queues with retries and dead-letter queues for failures. This decouples components, absorbs spikes, and improves resilience. Idempotency and DLQ handling are essential for correctness.
Likely follow-up: Why do you need a dead-letter queue?
What the interviewer is checking: Distributed-systems reliability.
Common mistake: Synchronous tight coupling that fails under load.