AWS Interview Questions and Answers

What interviewers are testing: Whether you understand the Region → Availability Zone hierarchy and why architects spread workloads across AZs rather than treating a Region as one data center.

An AWS Region is a separate geographic area. Each Region contains multiple isolated Availability Zones (AZs)—physically separate failure domains connected by low-latency networking.

Choose a Region for latency, compliance, service availability, and resilience requirements. Production workloads normally span multiple AZs in the chosen Region.

A strong answer is:

An AWS Region is a separate geographic area containing multiple isolated Availability Zones. I choose a Region based on latency, compliance, service availability, and resilience requirements, then normally deploy production workloads across multiple AZs.

What interviewers are testing: Whether you understand where AWS's responsibility for security of the cloud ends and the customer's responsibility for security in the cloud begins—and how that boundary changes between EC2 and managed services.

AWS divides security responsibility:

The boundary shifts by service model:

• EC2 (IaaS) — AWS secures the hardware and virtualization layer; you patch the guest OS, configure security groups, and manage application security.
• Managed services (RDS, S3, Lambda) — AWS operates more of the stack; you still control data classification, IAM access, encryption settings, and network exposure.

Interview trap: saying "AWS handles security" or "the customer handles everything"—both are wrong.

A strong answer is:

AWS secures the cloud infrastructure; I secure what I put in the cloud—data, identities, network access, and application configuration. On EC2 I own the OS and patching; on managed services AWS runs more of the stack but I still control access, encryption, and how the service is exposed.

What interviewers are testing: Whether you understand IAM identities, how policies grant permissions, and why roles with temporary credentials are preferred for workloads and federated users.

IAM separates who is asking from what they are allowed to do:

Users are long-term identities—generally avoid for workforce access when federation is available. Groups contain IAM users and let you assign common permissions to those users. Roles are assumable identities that supply temporary STS credentials—preferred for EC2, Lambda, cross-account access, and federated users.

A policy is a JSON document with Effect, Action, Resource, and optionally Condition. A permission is what AWS ultimately allows or denies after evaluating those policies.

A useful way to remember IAM: identities request access; policies determine what those identities can do.

A strong answer is:

IAM is built around identities such as users and roles, with policies defining their permissions. Groups simplify permissions for multiple users, while roles are assumed to obtain temporary credentials and are preferred for AWS workloads and federated access.

What interviewers are testing: Whether you understand IAM's secure defaults: implicit deny, least privilege, temporary credentials, and protecting the root user.

Important points:

1. A new IAM user has no permissions by default because IAM starts with an implicit deny. An explicit Allow is required, and an applicable explicit Deny overrides an Allow.
2. Creating a user does not automatically create console credentials or access keys.
3. For human workforce access, AWS recommends federation and temporary credentials (such as IAM Identity Center) rather than long-lived IAM users.
4. Access keys are for programmatic API/CLI access—they do not log in to the console.
5. IAM is a global service rather than a Regional service.
6. The root account has full administrative access and should be break-glass only—not daily work.

A strong answer is:

New IAM users have no permissions by default, root is break-glass only, and I prefer federation with temporary credentials over distributing access keys.

What interviewers are testing: Whether you understand that S3 is object storage—not a filesystem or block device—and know the basic bucket/object model, scalability, durability, and common use cases.

Amazon S3 is highly scalable object storage. Data is stored as objects inside buckets, not as filesystem blocks or mounted disks.

Each object has:

• a key (its name within the bucket),
• the data itself,
• and metadata.

A bucket can hold an extremely large number of objects. An individual S3 object can be up to 50 TB (AWS increased the maximum from 5 TB in December 2025). General-purpose S3 bucket names in the shared namespace must be unique within the AWS partition.

Common uses: backups, static assets, logs, data lakes, archives, and application data.

A strong answer is:

S3 is AWS's scalable object storage service. Data is stored as objects inside buckets rather than as blocks on a disk, so I typically use it for files, backups, logs, static assets, and data lakes.

What interviewers are testing: Whether you know what "11 nines" actually measures and do not confuse durability with availability.

Amazon S3 Standard and most multi-AZ S3 storage classes are designed for 99.999999999% (11 nines) object durability over a given year.

Durability is about protection against data loss—not uptime or service availability SLAs.

A strong answer is:

S3 Standard targets 11 nines durability across AZs—that is protection against loss, separate from availability or uptime SLAs.

What interviewers are testing: Whether you are relying on outdated S3 knowledge or understand S3's current strong-consistency model.

Older interview material sometimes claims S3 has eventual consistency for some operations. That is outdated.

Amazon S3 now provides strong read-after-write consistency. After a successful PUT, overwrite, or DELETE, subsequent reads and relevant list operations reflect the latest state without an eventual-consistency window.

A strong answer is:

S3 provides strong read-after-write consistency—after a successful PUT, overwrite, or DELETE, subsequent reads and list operations reflect the latest state without an eventual-consistency window.

What interviewers are testing: Whether you can choose an S3 storage class based on access frequency, retrieval requirements, resilience, and cost—not simply list their names.

Current S3 Glacier storage classes:

S3 Reduced Redundancy Storage (RRS) still exists, but AWS recommends S3 Standard instead.

Lifecycle note: AWS removed the former 30-day minimum wait before transitioning objects from S3 Standard to Standard-IA or One Zone-IA (July 2026).

A strong answer is:

I match storage class to access pattern—Standard for hot data, IA tiers for infrequent access, Glacier classes for archive, Intelligent-Tiering when access is unpredictable.

What interviewers are testing: Whether you know when multipart upload is required and why it improves parallelism and retry behavior on large objects.

Use multipart upload. Instead of one large request, the file is split into parts uploaded independently and in parallel. If one part fails, only that part needs to be retried. After all parts are uploaded, the client completes the multipart upload and S3 creates the final object.

Current limits:

• Maximum S3 object size: 50 TB
• Maximum single PUT: 5 GB
• AWS recommends considering multipart upload around 100 MB and larger
• Multipart upload is required once the object exceeds the 5 GB single-PUT limit

A strong answer is:

I'd use S3 multipart upload. It splits the object into independently uploaded parts, which improves parallelism and retry behavior. AWS recommends considering it around 100 MB, and it is required once the object exceeds the 5 GB single-PUT limit.

What interviewers are testing: Whether you understand that DELETE behaves differently when S3 Versioning is enabled and know the difference between a delete marker and permanent deletion.

A strong answer is:

In an unversioned bucket, DELETE removes the object. In a versioned bucket, deleting without a version ID normally creates a delete marker, so previous versions remain recoverable; specifying a version ID permanently deletes that version.

What interviewers are testing: Whether you know versioning can be suspended but not returned to a truly unversioned state.

No—you cannot disable versioning on a bucket that has ever had it enabled. You can only suspend versioning.

Suspending versioning does not delete old versions. Future PUTs receive a null version ID, and a later PUT of the same key replaces the existing null version.

A strong answer is:

You cannot return an enabled bucket to an unversioned state—you can only suspend versioning. Existing versions remain, while new objects are stored using the null version behavior.

What interviewers are testing: Whether you know when replication is an architectural requirement—DR, compliance, account isolation, or Regional processing—and when a CDN is the correct solution instead.

Cross-Region Replication (CRR) copies objects asynchronously from a source bucket to a destination bucket in another Region. Both buckets need versioning enabled.

Main use cases:

1. Compliance / data sovereignty — copies in required geographic Regions
2. Regional resilience / DR — secondary Region copy for failover workflows
3. Cross-account copies — replicate to a bucket in another account
4. Data aggregation or distribution — consolidate or fan out across Regions
5. Regional processing — place data closer to compute in another Region

For end-user content delivery latency, CloudFront is usually the primary answer—not CRR alone. CRR is for durable Regional copies; CloudFront handles edge caching.

A strong answer is:

CRR copies objects asynchronously for compliance, DR, and multi-Region aggregation—CloudFront handles edge latency; CRR is for durable Regional copies.

What interviewers are testing: Whether you know CRR's versioning prerequisite—a short factual question that should stay short.

No—both source and destination buckets must have versioning enabled before Cross-Region Replication will work.

A strong answer is:

No—both source and destination buckets need versioning enabled before Cross-Region Replication will work.

What interviewers are testing: Whether you distinguish transition (change storage class) from expiration (remove the object).

Two main lifecycle action types:

1. Transition actions — move an object to a different storage class on a schedule (for example, a rule you define might transition Standard → Standard-IA after 60 days and then to a Glacier class after 180 days).
2. Expiration actions — delete an object (or noncurrent versions) when it reaches a defined age.

A strong answer is:

Lifecycle rules transition objects between storage classes on a schedule or expire them—transition for tiering, expiration for automatic deletion.

What interviewers are testing: Whether you think about S3 security in layers—prevent public exposure, authorize access, encrypt data, and audit activity.

Think of S3 security in layers: prevent public exposure → authorize access → encrypt data → audit activity.

Modern mechanisms (see the S3 bucket tutorial for hands-on coverage):

1. Block Public Access — account- and bucket-level guardrails against accidental public exposure
2. Bucket policies and IAM policies — primary access control for most designs
3. S3 Object Ownership — make the bucket owner own uploaded objects and, with Bucket owner enforced, disable ACL-based access control
4. Encryption — SSE-S3, SSE-KMS, or SSE-C; enforce TLS in transit
5. Access Points — scoped endpoints for shared buckets or multi-tenant patterns
6. Logging and audit — CloudTrail data events and S3 server access logging where required

ACLs are a legacy mechanism in many modern designs—prefer bucket policies, IAM, and Object Ownership unless you have a specific ACL requirement.

A strong answer is:

I lead with Block Public Access, bucket policies and IAM, Object Ownership, encryption in transit and at rest, and audit logging—not legacy ACLs by default.

What interviewers are testing: Whether you know when to archive data and how Glacier classes trade retrieval time against cost.

For long-term archival, teach the S3 Glacier storage classes rather than the older standalone Glacier vault API:

Use cases: compliance retention, backups, log archives, and infrequently accessed historical data.

For WORM / compliance on S3 objects, S3 Object Lock (with versioning) is the modern answer.

A strong answer is:

S3 Glacier storage classes archive infrequently accessed data at lower cost—Instant, Flexible, and Deep Archive trade retrieval time against price.

What interviewers are testing: Whether you understand that CloudFront's main win is serving cached content closer to users so fewer requests travel all the way to the origin.

The main performance improvement comes from serving cached content closer to users, so fewer requests travel all the way to the origin. See how to use CloudFront with S3 for a practical origin setup.

Supporting mechanisms:

• Edge caching — copies of content at locations near viewers
• Regional edge caches — larger intermediate caches before origin fetch
• Persistent connections — reuse connections to the origin where helpful
• Protocol optimizations — TLS, HTTP/2, and TCP tuning at the edge

A strong answer is:

CloudFront caches content at edge locations closer to users—reducing latency and origin load through caching, persistent connections, and protocol optimizations at the edge.

What interviewers are testing: Whether you understand the role of Regional Edge Cache in CloudFront's caching architecture—not a fixed request path every viewer request follows.

Regional Edge Caches are an additional caching layer between many edge locations and origins. They can retain objects longer than individual edge caches, increasing cache-hit opportunities and reducing requests to the origin.

Pair with the CloudFront and S3 guide when you need hands-on origin configuration.

A strong answer is:

Regional Edge Cache sits between global edge and origin—holding larger, longer-lived copies so popular objects do not always hit the origin.

What interviewers are testing: Whether you know which edge compute option fits lightweight request manipulation versus heavier custom logic.

Choose CloudFront Functions for simple, high-volume edge manipulations. Choose Lambda@Edge when you need richer logic, Node.js/Python runtimes, or more complex request/response customization. See CloudFront with S3 and the Lambda tutorial for deeper practice.

A strong answer is:

I use CloudFront Functions for lightweight, high-scale edge manipulations like headers and URL rewrites. I use Lambda@Edge when I need Node.js or Python and more complex request/response logic close to viewers.

What interviewers are testing: Whether you understand Lambda@Edge runs application logic at CloudFront locations—CloudFront itself handles CDN delivery; Lambda@Edge customizes requests and responses.

CloudFront reduces delivery latency by caching at the edge. Lambda@Edge lets you run Lambda functions at CloudFront locations in response to viewer or origin request/response events. AWS replicates the function globally for you.

Typical uses: redirects, authentication logic, header manipulation, URL rewriting, A/B testing, and dynamic request/response customization. Lambda@Edge supports Node.js and Python.

See the Lambda tutorial and CloudFront with S3 for hands-on follow-up.

A strong answer is:

Lambda@Edge runs Node.js or Python functions in response to CloudFront viewer or origin events, letting me customize requests and responses close to users without deploying servers globally.

What interviewers are testing: Whether you can map CloudFront's four hook points along the request path.

Think of the request path as:

viewer → CloudFront edge → origin → CloudFront edge → viewer

That produces four hook points:

Lambda@Edge can use viewer and origin request/response events. CloudFront Functions are limited to viewer request and viewer response events.

A strong answer is:

Lambda@Edge supports four CloudFront event points: viewer request, origin request, origin response, and viewer response. CloudFront Functions support only viewer request and viewer response.

What interviewers are testing: Whether you understand the difference between detecting viewer geography and actually varying cached content by that geography.

CloudFront can determine viewer location and expose geographic information such as the viewer's country through headers. Your application can use that information for localized content, access rules, redirects, or regional experiences.

If different geographic responses need separate caching, configure the relevant cache behavior and origin request policy accordingly.

A strong answer is:

CloudFront can pass viewer country headers to the origin or edge logic so I can serve localized content—but I must design cache keys and behaviors if responses should be cached separately by geography.

What interviewers are testing: Whether you understand CloudFront as more than a static CDN—caching, origin protection, security, and edge customization.

Modern CloudFront capabilities interviewers expect you to name:

• Global edge caching / CDN
• Cache behaviors and cache keys
• Multiple / custom origins
• HTTPS / TLS
• Origin Access Control for private S3 origins
• AWS WAF / Shield integration
• Signed URLs / cookies for private content
• CloudFront Functions and Lambda@Edge
• Origin failover
• Logging, metrics, and invalidation

A strong answer is:

CloudFront is AWS's global CDN. Its main capabilities include edge caching, configurable cache behaviors, multiple origins, HTTPS, WAF integration, private-content controls, origin protection, and edge logic through CloudFront Functions or Lambda@Edge.

What interviewers are testing: Whether you frame designs with six pillars and explicit trade-offs—not buzzwords without HA, security, or cost reasoning.

Six pillars guide architecture reviews:

1. Operational Excellence
2. Security
3. Reliability
4. Performance Efficiency
5. Cost Optimization
6. Sustainability

Interview use: frame answers with trade-offs ("we chose multi-AZ for reliability; cost impact is X"). You do not need every whitepaper memorized—know the pillars and one example each. For example: multi-AZ increases reliability but costs more.

A strong answer is:

Well-Architected has six pillars—operational excellence, security, reliability, performance, cost, and sustainability—and I frame designs with explicit trade-offs across them.

What interviewers are testing: Whether you choose compute based on workload characteristics rather than saying serverless is always better.

Senior follow-ups: cold starts, 15-minute max timeout, concurrency limits, and whether the workload needs a custom OS or persistent local state.

A strong answer is:

I pick Lambda for event-driven, short, stateless bursts; EC2 when I need custom OS, long-running processes, GPUs, or full network control—watching cold starts and the 15-minute limit on Lambda.

What interviewers are testing: Whether you know both the scope and state model—not merely that one is stateful and one is stateless.

A security group is stateful: if inbound traffic is allowed, return traffic is automatically permitted. Security groups attach to network interfaces (ENIs) and contain allow rules only.

A NACL is stateless: inbound and outbound rules are evaluated separately. NACLs operate at the subnet boundary and support ordered allow and deny rules.

Security groups are normally the primary workload firewall. NACLs add optional coarse-grained subnet controls when the architecture needs them—they are not mandatory in every design.

A strong answer is:

Security groups are stateful firewalls attached to ENIs and contain allow rules. NACLs are stateless subnet-level filters with ordered allow and deny rules. I normally use security groups for workload access and NACLs when I need an additional subnet-level control.

What interviewers are testing: Whether you prefer temporary credentials and federation over long-lived IAM user keys for humans.

Modern pattern: humans federate through Identity Center; applications and EC2/Lambda use roles; long-lived access keys are rare and tightly scoped.

A strong answer is:

Humans federate through IAM Identity Center for SSO; workloads assume IAM roles for temporary credentials—I avoid long-lived IAM user keys for daily access.

What interviewers are testing: Whether you can trace how traffic actually reaches the internet from a VPC and understand the roles of route tables, IGWs, public IPs, and NAT gateways.

Public vs private is fundamentally about routing—not what workload happens to be inside the subnet.

Typical three-tier: ALB in public subnets; app/DB in private subnets; NAT for patch/egress only where needed. IPv6 uses different mechanisms (for example an egress-only internet gateway where applicable). For a hands-on VPC layout, see setup Kubernetes cluster on AWS EC2.

A strong answer is:

A public subnet has a route to an Internet Gateway, while a private subnet has no direct internet route. Private IPv4 workloads typically use a NAT Gateway for outbound access. Route tables decide the next hop for both. A common pattern is public ALBs with application and database tiers in private subnets.

What interviewers are testing: Whether you distinguish Layer 7 HTTP semantics from Layer 4 connection handling.

ALB understands HTTP. NLB operates primarily on connections and protocols at Layer 4. See the ALB tutorial for practical architecture.

A strong answer is:

ALB is Layer 7 and understands HTTP, so I use it for host- and path-based routing, redirects, and WAF integration. NLB is Layer 4 and is better for TCP/UDP/TLS workloads requiring very high performance, static IPs, or source-IP behavior.

What interviewers are testing: Whether you distinguish high availability from read scaling—and know that modern RDS Multi-AZ DB clusters can have readable instances.

The interviewer is usually contrasting high availability with read scaling:

AWS also offers Multi-AZ DB clusters with a writer and two readable standby instances across three AZs. Those readers can serve read traffic while participating in failover—so "Multi-AZ is never readable" is no longer universally true.

See the RDS tutorial for hands-on follow-up.

A strong answer is:

Multi-AZ is primarily for high availability and automatic failover, while read replicas are primarily for read scaling. With a traditional Multi-AZ DB instance the standby isn't used for reads; newer Multi-AZ DB clusters can also provide readable instances.

What interviewers are testing: Whether you recognize three different messaging patterns: queued work, broadcast fan-out, and rule-based event routing.

SQS for job queues; SNS for broadcast notifications; EventBridge for event-driven routing and integration.

A strong answer is:

SQS is for queueing and buffering work that consumers pull, SNS is for pushing the same message to multiple subscribers, and EventBridge is an event bus that routes matching events to targets using rules.

What interviewers are testing: Whether you answer two different operational questions: Is the system healthy? and Who did what?

Use both: CloudWatch for operations; CloudTrail for security and compliance auditing.

A strong answer is:

CloudWatch answers whether the system is healthy with metrics and logs; CloudTrail audits who called which AWS API—I use both for operations and security investigations.

What interviewers are testing: Whether you understand why applications use data keys instead of sending every large payload to KMS for encryption.

Encrypting large amounts of application data directly with KMS would be inefficient.

Envelope encryption works like this:

1. A data key encrypts the actual payload.
2. A KMS key encrypts that data key.
3. The encrypted data key is stored alongside the encrypted data.
4. When needed, the application sends the encrypted data key to KMS for decryption, then uses the returned plaintext data key to decrypt the payload.

AWS KMS protects the KMS key; IAM and key policies control who can use it. This pattern limits KMS API calls while keeping centralized key control. Integrates with S3 SSE-KMS, EBS, RDS, and Secrets Manager.

A strong answer is:

Envelope encryption uses a data key to encrypt the actual payload, then protects that data key with a KMS key. This lets applications encrypt large amounts of data efficiently while KMS controls access to the key-encryption key.

What interviewers are testing: Whether you can choose the appropriate compute abstraction based on runtime control, workload duration, scaling model, operational overhead, and Kubernetes requirements.

The choice is not about which service is "best"; it is about how much infrastructure control and orchestration the workload actually needs. Many systems combine them. For Kubernetes depth, see the Kubernetes tutorial.

A strong answer is:

EC2 for full control and steady workloads, Lambda for event-driven bursts, ECS for managed containers without Kubernetes, EKS when I need the Kubernetes API and ecosystem.