Storage: Block, Object, and Archive
What this domain covers
Storage questions ask you to match a workload to block, object, or archive storage and to reason about durability, retrieval, and cost. The exam favors access pattern over brand names: mounted filesystem, HTTP object API, or long-term retention.
Core rules
- Block storage is a virtual disk attached to a server in the same zone. You format it with a filesystem; latency is low; it is not a shared filesystem unless you build clustering. Use snapshots and backups for recovery.
- Object storage stores objects in buckets and is accessed over HTTP(S), commonly with an S3-compatible API. It is good for static assets, backups, logs, and data lakes. Objects are not mounted as disks.
- Archive storage is for data accessed rarely, with lower storage cost and retrieval latency or cost. It suits compliance copies and long-term backups, not active databases.
- Plan lifecycle: hot object data to archive; expire old versions; retain snapshots per policy.
- Encryption, access policies, and versioning or object lock where offered protect integrity and compliance.
- Capacity planning includes snapshots, replicas, and retrieval fees, not just primary GB.
Worked example
A team keeps 30 TB of application logs for seven years and searches them once a year. Put raw logs in archive storage, keep a searchable index and the recent 30 days in object storage, and keep the active database on block storage. Reasoning: archive matches rare access; object storage supports the index and recent queries; block storage provides database latency. Deleting the block volume after a snapshot without testing restore is not a backup.
Traps
Using archive storage for a boot volume; assuming block storage is shared by multiple servers; forgetting retrieval charges; deleting snapshots before the retention period; and treating object storage as a POSIX filesystem.