Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What's the difference between block, file and object storage?

They're testing: knowing which storage fits which job.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Block storage is a raw disk attached to one server, good for databases and anything needing fast small random writes. File storage is a shared filesystem with folders and files, good when several servers need a familiar file interface. Object storage stores whole objects by key with metadata over HTTP, in a flat namespace, replaced whole rather than edited; it scales to practically unlimited size cheaply and suits images, videos, backups and logs.
3
4**Counter-questions:**
5- *"Can you run a database on object storage?"* → Not directly as its working disk; databases need block storage. But many databases send backups and logs to object storage, and some analytics engines read data files straight from it.
6
7**Trap:** describing object storage as "a big filesystem".

Q2. Why not store images in the database?

They're testing: practical design judgement.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It bloats the most expensive storage, slows backups, restores and replication, pushes useful rows out of memory, and makes the app serve every byte. The standard pattern is files in object storage, with the key and metadata in the database, served through a CDN.
3
4**Counter-questions:**
5- *"Ever OK to store files in the database?"* → For a small number of small files where transactional consistency with the row matters, it can be simpler. It's a scale question.
6
7**Trap:** "databases can't store files".

Q3. How would you let users upload large files?

They're testing: presigned URLs and multipart.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The client asks my API for permission; the API checks authorisation and returns a short-lived presigned URL (or a set of URLs for multipart parts) for a specific key. The client uploads directly to object storage, in parts for large files, retrying failed parts. When storage reports the upload complete, I record the key and metadata, and kick off any processing through a queue.
3
4**Counter-questions:**
5- *"How do you stop someone uploading a 50 GB file to the photo URL?"* → Use upload conditions that limit content type and size where the store supports them (for example S3's presigned POST policies), and validate after upload.
6- *"What if the client never confirms?"* → Rely on the storage event, not the client, and clean up orphaned objects with a lifecycle rule.
7
8**Trap:** streaming every upload through the app servers.

Q4. What is a presigned URL, and what can go wrong?

They're testing: security understanding.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It's a storage URL carrying a signature made with server-side credentials that authorises one specific action, like GET or PUT, on one key, until an expiry time. Anyone holding it can use it, so keep the expiry short, sign everything that matters (method, key, expiry, and conditions), and generate it only after checking the user's permissions. If the signature doesn't cover the expiry, users can extend links indefinitely.
3
4**Counter-questions:**
5- *"Can you revoke one?"* → Not individually in most stores; it's valid until expiry unless you rotate the credentials that signed it. Hence short expiries.
6
7**Trap:** treating presigned URLs as private once shared.

Q5. How does object storage achieve high durability?

They're testing: depth on replication and erasure coding.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** By storing data redundantly across machines and availability zones, using full replicas or erasure coding, which splits data into pieces plus parity so it can be rebuilt from a subset, at much lower overhead than full copies. Background checksums detect and repair silent corruption. Providers publish design targets, like S3 Standard's eleven nines.
3
4**Counter-questions:**
5- *"Does that protect against a bug that deletes files?"* → No. Use versioning, restricted delete permissions and copies in another region or account.
6
7**Trap:** confusing durability with availability or with backup.

Q6. When would you use multipart upload?

They're testing: practical limits.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** For large files, roughly 100 MB and up per AWS's guidance, so parts upload in parallel and a failure only resends one part. On S3, parts are 5 MiB to 5 GiB and up to 10,000 parts. I'd also set a lifecycle rule to clean up incomplete uploads.
3
4**Counter-questions:**
5- *"How do you resume an upload after the app restarts?"* → Keep the upload ID and the completed part numbers on the device, then upload only the missing parts.
6
7**Trap:** not knowing incomplete uploads still cost storage.

Q7. How do you keep storage costs down as data grows?

They're testing: lifecycle thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Use lifecycle rules to move data to cheaper classes as it cools and delete it when no longer needed; delete temporary files and incomplete uploads; compress where it makes sense; avoid storing many sizes you don't serve; and put a CDN in front of hot content to cut egress, often the biggest cost.
3
4**Counter-questions:**
5- *"What's the catch with archive classes?"* → Retrieval can take minutes to hours and costs extra, and there are minimum storage durations, so archiving something you need back soon can cost more.
6
7**Trap:** only mentioning "use a cheaper class".

Q8. How would you serve private files, like paid downloads?

They're testing: access control on blobs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keep them in a private bucket. When a user requests a download, the API checks they bought it, then returns a short-lived presigned GET URL (or a CDN signed URL or cookie for heavy traffic). Log downloads, and rate-limit link generation per user to discourage sharing.
3
4**Counter-questions:**
5- *"How do you stop users sharing the link?"* → Short expiry limits it; for stronger protection, tie links to the session through signed cookies and watch for unusual download patterns. You can't fully stop someone sharing the file itself.
6
7**Trap:** a public bucket with "unguessable" names.

Q9. How would you process uploaded images or videos?

They're testing: asynchronous pipelines.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Upload the original, have the store emit an event onto a queue, and let workers create the derived versions and write them to separate keys, then update the database. Workers scale on queue length, jobs are safe to retry, and outputs go under a different prefix so they don't re-trigger the pipeline. The UI shows a placeholder until processing finishes.
3
4**Counter-questions:**
5- *"A job keeps failing on one corrupted file."* → After a few retries, move it to a dead-letter queue and alert, so it doesn't block others (Chapter 22).
6
7**Trap:** resizing inside the upload request.

Q10. Is object storage strongly consistent?

They're testing: up-to-date knowledge and caution.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Amazon S3 has provided strong read-after-write consistency for writes, overwrites and deletes since December 2020, so a read after a successful write returns the latest data. Other providers have their own guarantees, so check their documentation. CDN caches in front of storage can still serve old copies until they expire or are purged, which is why versioned keys help.
3
4**Counter-questions:**
5- *"So why might a user still see an old cover?"* → A CDN or browser cache; use versioned keys or purge the CDN (Chapter 26).
6
7**Trap:** repeating old "S3 is eventually consistent" advice.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 11.1 Block, file, object | Level 1B.1, Q1 |
18| 11.2 Not in the database | Level 1A, Q2 |
19| 11.3 Buckets, keys, metadata | Level 3, Level 5.1 |
20| 11.4 Presigned URLs | Level 1B.3, Level 3, Level 4, Q3, Q4 |
21| 11.5 Multipart | Level 2.2, Level 3, Q6 |
22| 11.6 Durability | Level 1B.2, Level 2.1, Level 5.5, Q5, Q10 |
23| 11.7 Storage classes, lifecycle | Level 1A.5, Level 5.5, Q7 |
24| 11.8 Serving files | Level 2.3, Level 5.3, Level 5.4, Q8 |
25| 11.9 Processing pipelines | Level 5.4, Q9 |
26
27---

11. Object / Blob Storage