AWS Interview Questions

A curated set of AWS interview questions, from core trade-offs to specific service knowledge.

Q: What's the trade-off between running your application on EC2 versus using Lambda (serverless)? EC2 gives you a persistent virtual server you fully control — any runtime, any long-running process, any custom configuration — but you pay for it whether it's handling traffic or sitting idle, and you're responsible for patching, scaling, and availability yourself. Lambda runs your code only in response to an event (an HTTP request, a queue message, a schedule), scales automatically from zero to many concurrent invocations, and you pay only per invocation and execution time — but each invocation has a maximum runtime limit, cold starts can add latency, and it's a poor fit for long-running or stateful processes. EC2 suits steady, predictable workloads or anything needing full control; Lambda suits spiky, event-driven, or infrequent workloads where paying for idle capacity would be wasteful.

Q: What are common real-world use cases for S3? Serving static assets for a website (images, video, CSS/JS bundles), often through a CDN in front of the bucket; storing backups and disaster-recovery snapshots, typically moved to a cheaper storage class after an initial retention window; acting as the input/output storage layer for data analytics and machine learning pipelines; and hosting an entire static website directly from a bucket with no server involved at all. The common thread is durable, scalable storage of discrete files, accessed by key, rather than a mounted filesystem or a database.

Q: What's the difference between a public and a private subnet, and why does it matter? A public subnet has a route to an Internet Gateway, so resources in it can be reached from (and reach out to) the public internet directly — appropriate for load balancers or bastion hosts. A private subnet has no inbound route from the internet at all (outbound-only access, if any, via a NAT Gateway) — appropriate for application servers and databases that should never be reached directly from outside your network. Structuring a VPC this way means a resource's exposure to the internet is a property of which subnet it's placed in, not something you have to get right in a security group rule every single time — a second, structural layer of protection alongside security groups.

Q: Why would a team choose RDS over installing and managing MySQL or PostgreSQL on an EC2 instance themselves? RDS takes over the operationally heavy, easy-to-underinvest-in parts of running a database: automated patching, scheduled backups with point-in-time recovery, Multi-AZ failover to a synchronously replicated standby, and one-command read replica provisioning. Running the same engine on EC2 yourself means building and testing all of that from scratch, and it's common for teams to discover gaps (an untested backup, no real failover plan) only during an actual incident. The trade-off is cost — RDS costs more than an equivalently-sized EC2 instance — and less low-level control over the database engine's configuration; for most teams without a dedicated DBA, the operational savings outweigh that cost.

Q: What is the difference between an AWS Region and an Availability Zone, and why does it matter for reliability? A Region is an independent geographic area (e.g. us-east-1); an Availability Zone is one of several physically separate data centers within a Region, each with independent power and networking but connected by low-latency links. Deploying redundant infrastructure across multiple AZs within one Region protects against a single data center failure without the added latency of spreading across distant Regions — it's the baseline reliability practice for any production system, whereas spreading across multiple Regions is typically reserved for disaster recovery or serving geographically distant user bases with lower latency.

Q: What is the principle of least privilege, and how does it apply to IAM policies? It means granting an identity — a user, a role, an application — exactly the permissions it needs to do its job, and nothing more. In IAM terms, that means scoping an Action to the specific API calls actually used (s3:GetObject, s3:PutObject) rather than a wildcard (s3:*), and scoping Resource to the specific ARN(s) actually needed rather than "*". The payoff shows up when credentials leak or a policy is misapplied: a narrowly scoped policy limits the damage to exactly what it grants, while a broad one turns any single compromise into an account-wide incident.

Q: Why would a Lambda function use an IAM role instead of storing AWS access keys directly? An execution role is assumed automatically by the Lambda service at invocation time, handing the function temporary, auto-rotating credentials with no key stored anywhere in code, environment variables, or a deployment package. Long-lived access keys embedded in code or configuration don't expire on their own and are a common way credentials end up leaked — in a public repository, a build log, or a container image. The same reasoning applies to EC2 instance profiles: assume a role, don't embed a key.

Q: What's the difference between a CloudWatch metric and a CloudWatch alarm? A metric is just a stream of numeric data points over time — CPU utilization, request count, queue depth — collected automatically for most AWS services or published manually by an application. An alarm is a rule layered on top of a metric: it watches for the metric to cross a defined threshold for a configured number of consecutive evaluation periods, and changes state to ALARM when it does, which can then trigger a notification (commonly via SNS) or an automated action. A metric on its own doesn't notify anyone of anything; an alarm is what turns a metric into something actionable.

Q: What's the practical difference between Reserved Instances/Savings Plans and Spot Instances, and when would you use each? Both offer a significant discount off On-Demand pricing in exchange for a trade-off: Reserved Instances/Savings Plans require a 1- or 3-year commitment to pay for that capacity regardless of use, and in return AWS guarantees it's never interrupted — the right fit for a steady-state, predictable baseline workload like a production database. Spot Instances have no commitment at all and a much steeper discount, but AWS can reclaim the capacity with only a two-minute warning whenever it's needed elsewhere — appropriate only for fault-tolerant, interruptible workloads like batch processing or CI build runners, never for a stateful, single-point-of-failure system.