Amazon S3 Interview Questions
Reviewed by Mark Dickie · Last updated
5 questions on this page you can answer and see marked on the spot. Go to the first one
Amazon S3 is an object storage service that stores data as objects within buckets, accessed over HTTP via a REST API. For interviews, you need to know the storage classes and their durability and availability tradeoffs, how bucket policies and IAM policies interact, and how S3 handles consistency. You should also be comfortable with lifecycle rules, versioning, cross-region replication, and the performance patterns around multipart uploads and prefix limits. Encryption options (SSE-S3, SSE-KMS, SSE-C) and how they differ come up often.
What storage classes does S3 offer?
| Storage Class | Use Case | Retrieval |
|---|---|---|
| S3 Standard | Frequently accessed data | Milliseconds, no fee |
| S3 Standard-IA | Infrequently accessed data | Milliseconds, per-GB fee |
| S3 One Zone-IA | Infrequently accessed, non-critical | Milliseconds, per-GB fee, single AZ |
| S3 Glacier Flexible Retrieval | Archival data | Minutes to hours |
| S3 Glacier Deep Archive | Long-term archival | 12 hours |
| S3 Intelligent-Tiering | Unknown access patterns | Automatic tiering, small monitoring fee |
How do permissions and access control work in S3?
- Bucket policies attach directly to a bucket and apply to all objects in it, written in JSON.
- IAM policies attach to users or roles and can grant or deny S3 actions across resources.
- ACLs are legacy and rarely recommended; bucket policies and IAM policies cover most scenarios.
- S3 Access Points let you create named network endpoints with distinct policies for the same bucket.
- Block Public Access is a bucket-level and account-level setting that overrides any policy granting public read.
What consistency model does S3 use?
Since December 2020, S3 provides strong read-after-write consistency for PUT and DELETE operations on objects in all regions. A successful write returns a 200, and a subsequent GET returns the new object. List operations are also strongly consistent, so listing a bucket after a PUT shows the new key. This replaced the previous eventual consistency model and eliminates a class of bugs where applications retried reads too early.
Key facts
- Tarmac has 13 AWS interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 5,372 job postings asking for AWS in September 2026.
- Roles asking for AWS advertise a median base salary of US$173,425, across 1,898 job postings as of September 2026.
- Tarmac last reviewed these AWS interview questions on 14 September 2026.
At a glance
| Questions | 10 shown · 13 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Flashcard, True / false, Ordering, Fill in the blank, Design exercise, Short answer, Multiple answer |
What you'll review
- s3
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
What is the largest object you can upload to Amazon S3 using a single PUT request (without multipart upload)?#
Options
Show answer
A single PUT request in Amazon S3 can upload an object up to 5 GB. Individual objects can grow to 5 TB, but anything larger than 5 GB must be uploaded with multipart upload, which breaks the object into parts that are uploaded and then assembled.
A single PUT operation in Amazon S3 supports objects up to 5 GB. The maximum size of an individual S3 object is 5 TB, but anything above 5 GB must be uploaded with multipart upload, which splits the object into parts. The 5 TB figure is the object size limit, not the single-PUT limit, which is why it is a tempting distractor.
What is the maximum size of a single object that you can store in Amazon S3?#
Show answer
5 TB (terabytes) per object.
Amazon S3 stores objects of up to 5 TB each. A single PUT request is limited to 5 GB, so larger objects must be uploaded in parts with the multipart upload API. The 5 TB figure is the per-object storage limit, which is the value this card asks for.
Amazon S3 (current, as of 2024) provides strong read-after-write consistency for object PUT and DELETE requests, including overwrites, so a GET or LIST request issued immediately after a successful write returns the latest data.#
Options
Show answer
Amazon S3 is strongly consistent for reads after writes. Since December 2020, a GET or LIST issued right after a successful PUT, overwrite, or DELETE returns the latest object state, with no extra cost or performance penalty.
This is true. Before December 2020, S3 offered read-after-write consistency only for new object PUTs, while overwrite PUTs, DELETEs, and LIST operations could return stale data for a short time. Since then, S3 provides strong read-after-write consistency for all of these operations in every region, so a read that follows a successful write always reflects that write. Applications no longer need workarounds such as retry loops or consistency-check layers for this behavior.
Put these steps for uploading a large object to Amazon S3 with the multipart upload API into the correct order, from first to last.#
Put these in order
Show answer
To upload a large S3 object with multipart upload, first call CreateMultipartUpload to get an upload ID, then call UploadPart for each chunk, then call CompleteMultipartUpload with the part ETags. Only after completion can GetObject read the assembled object.
A multipart upload must first be initiated with CreateMultipartUpload, which returns the upload ID that every subsequent UploadPart call needs. All parts must be uploaded before the upload is finalized with CompleteMultipartUpload, which takes the part numbers and ETags to assemble the object. The object only becomes readable via GetObject after that completion step, so it comes last.
Your service writes a brand-new object to S3 and, a millisecond later, issues a GET for that same key from another instance. What consistency does S3 guarantee for that read today?#
Options
Show answer
S3 guarantees strong read-after-write consistency: a GET issued after a successful PUT always returns the latest object. Since December 2020 this applies automatically to all GET, PUT, LIST, and tag/ACL/metadata operations, in every Region, with no extra cost or configuration. The earlier eventual-consistency model — and the read-your-own-write workarounds built around it — no longer applies. It does not require Versioning and is not limited to one Availability Zone.
Since December 2020, S3 provides strong read-after-write consistency automatically for all GET, PUT, LIST, and tag/ACL/metadata operations, in every Region, at no extra cost. A read issued after a successful write always sees the latest data. The old eventual-consistency model (and the read-your-own-write workarounds people built around it) is gone — but a lot of legacy advice and interview prep still teaches it, which is the trap here. Versioning and AZ scope are unrelated to this guarantee.
An Amazon S3 bucket has versioning enabled. A client sends a DELETE request for an object key without specifying a version ID. S3 does not erase the object's data. Instead, it adds a _____ as the new current version of that key, and every earlier version stays in the bucket and can still be fetched by its _____.#
Show answer
An Amazon S3 bucket has versioning enabled. A client sends a DELETE request for an object key without specifying a version ID. S3 does not erase the object's data. Instead, it adds a delete marker as the new current version of that key, and every earlier version stays in the bucket and can still be fetched by its version ID.
With versioning enabled, a DELETE request that omits a version ID does not remove any stored object version. S3 instead creates a delete marker, which becomes the current version so that a plain GET on the key returns a 404-style not-found response. The earlier versions are untouched and remain retrievable by requesting them explicitly with their version ID. Permanently removing a specific version requires a DELETE that names its version ID.
Design a serverless image-upload and processing pipeline on AWS.#
Show answer
Upload. Clients call a small authenticated endpoint (API Gateway + Lambda) that returns a presigned S3 PUT/POST URL scoped to a per-user key prefix, a max size, an allowed content-type, and a short expiry. The client uploads the original straight to an uploads bucket — the backend never touches the bytes, sidestepping API Gateway/Lambda payload limits and cost.
Trigger & buffer. The uploads bucket emits an ObjectCreated event to SQS (directly or via EventBridge). A processing Lambda consumes the queue. The buffer is deliberate: SQS absorbs spikes and gives us retries and a DLQ, which a direct S3->Lambda wiring wouldn't.
Processing. The Lambda reads the original, generates thumbnail/web/full variants, and writes them to a separate processed bucket (separate bucket avoids recursive event loops). Memory is tuned for 20 MB images; if work outgrew Lambda's 15-minute/resource envelope I'd move to Fargate or AWS Batch pulling the same queue.
Scaling. Lambda scales with queue depth; I set a max/reserved concurrency so a burst can't overwhelm downstream, and set the SQS visibility timeout above the worst-case processing time so messages aren't redelivered mid-flight. 50k uploads in a minute simply queue and drain — nothing is dropped.
Resilience & idempotency. S3 events and SQS are at-least-once, so processing is idempotent: variant keys are deterministic (derived from the source key/hash), so a duplicate event just overwrites identical output. A redrive policy sends repeatedly-failing messages to a DLQ after N attempts; a CloudWatch alarm on DLQ depth pages us, and we can fix and redrive. Poison message: it retries, becomes visible again each time the timeout lapses, and after the threshold lands in the DLQ — without blocking the rest of the queue.
Serving. The processed bucket sits behind CloudFront with Origin Access Control, so the bucket stays private and images are cached at the edge for low global latency. Private images use signed URLs/cookies.
Security. The Lambda role is least-privilege — read on uploads, write on processed, consume on the queue, nothing wildcarded. Both buckets enforce encryption at rest (SSE-S3 or KMS) and block public access; clients get scoped presigned URLs rather than any AWS credentials.
Failure modes. Burst -> SQS buffers. Processor bug -> retries then DLQ + alarm, rest of queue unaffected. Duplicate event -> idempotent keys. AZ issue -> S3/SQS/Lambda/CloudFront are all multi-AZ regional services. Hot serving -> CloudFront cache offloads origin.
The make-or-break instincts: upload directly to S3 via presigned URLs (never proxy big files through Lambda/API Gateway), put a queue between S3 events and the processor so bursts buffer and failures land in a DLQ, make processing idempotent because S3 events and SQS are at-least-once, and serve via CloudFront with OAC instead of a public bucket. Candidates who wire S3 straight to Lambda with no buffer, ignore duplicate delivery, or make buckets public reveal they haven't run an event-driven pipeline in production. The senior signal is naming at-least-once delivery and the DLQ/idempotency response to it.
Amazon S3 supports conditional writes on PutObject. Without using DynamoDB, a lock service, or any other external coordination, describe how a client can (1) create an object only if no object currently exists at that key, and (2) replace an existing object only if its current ETag still matches the ETag the client last read. Name the request header used for each case and the HTTP status code S3 returns when the precondition fails.#
Show answer
(1) Send PutObject with the header If-None-Match: * . S3 stores the object only if the key does not already exist; otherwise the request fails with 412 Precondition Failed. (2) Send PutObject with the header If-Match set to the ETag previously read via GET or HEAD. S3 overwrites the object only if the current ETag equals that value; otherwise it fails with 412 Precondition Failed. The client retries by re-reading the object and reapplying its change, which gives compare-and-swap semantics on a single key with no external lock.
S3 added conditional writes to PutObject: If-None-Match with the value * makes the write succeed only when the key is absent, and If-Match with an ETag makes the write succeed only when the stored object's ETag matches. When the precondition is not satisfied, S3 rejects the request with 412 Precondition Failed and does not modify the object. Together these provide create-if-absent and optimistic compare-and-swap on a single key, so the client can detect concurrent modification by handling the 412 and retrying from a fresh read.
Select ALL statements that are true of Amazon S3's current behavior (as of its strong-consistency model and documented request and upload limits).#
Options
Pick every one that applies.
Show answer
S3 provides strong read-after-write consistency for overwrites, deletes, and LIST, so a GET after an overwrite returns the new version. S3 also supports at least 5,500 GET/HEAD requests per second per key prefix, so spreading keys across prefixes scales reads. A single PUT is capped at 5 GiB, and multipart parts other than the last must be at least 5 MiB.
S3 has provided strong read-after-write consistency for PUT and DELETE operations and for LIST since December 2020, so an overwrite is returned by the next GET and a deleted key is absent from the next LIST; the claim about LIST returning a deleted key is therefore false. S3 documents a baseline of at least 5,500 GET/HEAD requests per second per prefix, so that statement is true and is the basis for spreading keys across prefixes. Multipart upload requires every part except the last to be at least 5 MiB, so the claim that parts can be 1 byte with no minimum is false. A single PUT is capped at 5 GiB; objects up to 5 TiB are possible only through multipart upload, so the 5 TiB single-PUT claim is false.
A telemetry platform writes about 300 million small JSON objects (roughly 2 KB each) per day into one S3 bucket. Keys are built as YYYY-MM-DD/<deviceId>/<epochMillis>.json. During peak hours, the ingest workers and the nightly analytics readers receive HTTP 503 SlowDown responses, and reads for a single day's data are sluggish. Redesign the key layout, object packaging, and client request behavior to remove the throttling while keeping per-device lookups and daily analytics practical. Describe the bucket and key design, how writes and reads are distributed, and how the clients behave under throttling.#
Show answer
The throttling is a per-prefix problem. S3 scales request rates per key prefix, roughly 3,500 writes and 5,500 reads per second per prefix, and the current key starts with the date, so every write for a day shares one prefix and saturates it at peak, producing 503 SlowDown. I would change the key to <shard>/YYYY-MM-DD/<deviceId>/... where shard is a deterministic short hash (for example 2 hex characters of a hash of the device ID, giving 256 prefixes). Writers can compute the shard from the device ID, so ingest load spreads across all prefixes. For lookups, a device's shard is also computable, so a single-device query fetches only that device's prefix. To cut request count, the ingest tier buffers records for a device for a fixed window (for example five minutes or one hour) and writes one batched object, compacted daily into Parquet partitioned by date for analytics. The trade-off is added write latency equal to the buffer window and the need to handle late data and compaction. Clients use the AWS SDK's standard retry with exponential backoff and full jitter, a capped retry count, and they treat 503 SlowDown as a signal to slow down rather than fail immediately. Analytics reads run Athena over the Parquet partitions, which reads far fewer and larger objects than the original per-record layout.
The strongest answer identifies that S3 request-rate limits apply per key prefix, so a date-first key concentrates a whole day's traffic under one prefix; distributing the leading key component fixes the hotspot. Packaging small records into larger batched objects reduces the total request count and makes analytics cheaper, at the cost of buffering latency and compaction work. Clients must back off with jitter on 503 SlowDown rather than retry in lockstep, which would amplify the throttling.
Related interview questions
Job market
See aws salaries and hiring demand from live job postings.
The other 3 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 3 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan