100 AWS Interview Questions & Answers

AWS is Amazon's cloud computing platform — on-demand compute, storage, databases, networking, and hundreds of higher-level services, billed by usage instead of upfront hardware purchase. Its defining features are elasticity (scale resources up/down on demand), a pay-as-you-go model, global reach across many physical regions, and a huge breadth of managed services that let teams avoid running (and patching) the underlying infrastructure themselves.

A Region is a separate geographic area (us-east-1, eu-west-1…) with its own fully isolated set of data centers — chosen for latency to your users, cost, and data-residency requirements. Each Region contains multiple Availability Zones (AZs) — physically distinct data centers with independent power/networking/cooling, close enough for low-latency replication but far enough apart that one AZ failing shouldn't take down another.

An AMI is a template containing everything needed to launch an EC2 instance — the OS, any pre-installed software, and configuration. AWS provides base AMIs (Amazon Linux, Ubuntu, Windows), the AWS Marketplace has vendor-published ones, and you can create your own "golden image" from a configured instance so every new instance launches already set up, instead of provisioning from scratch every time.

It's the web-based UI for creating, configuring, and monitoring AWS resources by clicking through forms rather than writing code — great for learning, one-off tasks, and visual debugging, but real infrastructure is better managed through the CLI, SDKs, or Infrastructure-as-Code (CloudFormation/Terraform) so changes are repeatable and reviewable.

Elastic computing means capacity grows and shrinks automatically to match actual demand — add instances during a traffic spike, remove them once it passes — instead of provisioning for peak load year-round and paying for idle capacity the rest of the time. Auto Scaling Groups are the concrete mechanism most compute services build this on.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

IAM controls who (users, roles, services) can do what (actions) to which resources — policies like the one above are attached to users, groups, or roles to grant exactly the permissions needed, nothing more. It's foundational to AWS security: nearly every real-world AWS incident traces back to overly broad IAM permissions somewhere in the chain.

The split shifts depending on the service — for EC2 (IaaS) you manage the guest OS and everything above it; for a fully managed service like Lambda or RDS, AWS takes on more of the stack, and your responsibility narrows to configuration, code, and data.

High availability means an application keeps running through individual component failures — spreading instances across multiple Availability Zones, load balancing across them, and using managed services (RDS Multi-AZ, S3's built-in cross-AZ redundancy) that already handle failover internally, so a single AZ outage doesn't take the whole application down.