Objective: begin with the access interface
After the compute lesson, choose storage by how an application needs to access data, then evaluate retrieval and recovery conditions. S3 stores objects and metadata identified by bucket and key, with a version ID when applicable. EBS provides block storage volumes attached to EC2. EFS provides shared file storage using NFS. All can hold useful information, but that fact does not make their interfaces interchangeable. A program written for one interface does not gain another merely because the service is described as storage.
Worked example: a media workshop’s three contracts
Fictional teaching case: a workshop has an upload catalog that retrieves independent clips by key, a single EC2 editing application that expects an attached block volume, and several Linux render workers that share the same files through NFS. First write the three access contracts without product names: object lookup, block device, shared NFS files. Match S3 to the object catalog, EBS to the attached block requirement, and EFS to shared NFS access. This is an interface comparison, not a complete design. Check it by asking whether the editing application can simply treat an object key as a block device without a change in its contract; the stated requirements do not establish that.
Lifecycle conditions matter after the interface
The workshop also keeps old clips for a long period. A storage-class decision needs access frequency, performance requirements, retrieval behavior, and relevant minimum-duration or retrieval tradeoffs. Do not assume every archive-labeled class requires the same restoration process. Glacier Instant Retrieval supports real-time access; Glacier Flexible Retrieval and Deep Archive involve archive retrieval workflows. If a collection accepts a retrieval workflow, that can support considering an appropriate archive class. If a new requirement demands immediate access, the earlier rationale must be reconsidered. No current price or guaranteed saving is needed to explain the distinction.
Recovery is a separate requirement
Durable live storage and recovery from an unintended change are different concerns. EBS snapshots are point-in-time backups that persist independently of their source volume. S3 Versioning, when configured appropriately, preserves versions that can support recovery from unintended actions or application failures. AWS Backup can centralize configured backup policies and activity for supported resources, but does not govern every backup created outside it. None of these facts is an absolute recovery guarantee. The relevant question is what state must be recovered, from which event, and which configuration actually retains that state.
Transfer check and check basis
Try before reading the explanation: a fictional editing club says its live storage is durable, so an accidental replacement of a file cannot require a recovery plan. What is missing? Check basis: durability does not itself identify a retained earlier version or recovery copy suitable for undoing that action. Evaluate a configured recovery mechanism against the event, rather than assuming live persistence answers it. Also check an archive proposal that groups all Glacier classes under “must restore before reading”: it incorrectly includes Instant Retrieval. Use aws-clf-q-029–032 and cards aws-clf-card-22–24 to practice separating interface, access timing, and recovery.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
What is AWS Backup? - AWS BackupWhat is Amazon Elastic Block Store? - Amazon EBSWhat is Amazon Elastic File System? - Amazon Elastic File SystemWhat is Amazon S3? - Amazon Simple Storage ServiceUnderstanding and managing Amazon S3 storage classes - Amazon Simple Storage Service