Once a scenario has settled on Amazon EFS, the SAA-C03 stops asking which storage service and starts asking how to tune it. The distractors are no longer S3 or EBS — they are other EFS settings, each plausible, only one matching the requirement. The two axes the exam turns on are throughput mode and performance mode, with storage-class lifecycle and mount targets rounding out the common scenarios. The diagram lays those axes out side by side.
Throughput modes: match the pattern
EFS offers three throughput modes, and the requirement sentence picks one. Bursting ties baseline throughput to how much data is stored and earns burst credits for short spikes — fine for a general file system that grows over time, but a small file system gets a small baseline. Provisioned sets a fixed throughput independent of size, so it is the answer when a few gigabytes must sustain heavy, steady throughput. Elastic scales throughput up and down automatically and bills on what is used — the answer for spiky or unknown patterns where you do not want to size anything at all. The recurring trap is offering Provisioned at the peak (wasteful) where Elastic fits, or Bursting where the dataset is too small to burst enough.
The performance mode is a different lever. General Purpose is the low-latency default and the right call for almost everything. Max I/O trades slightly higher per-operation latency for far greater aggregate throughput and operations across very large numbers of concurrent clients — the pick when thousands of instances mount one file system and total throughput outweighs single-op speed. When a stem stresses massive parallelism, Max I/O is in play; otherwise General Purpose wins. Note that a throughput mode and a performance mode are independent choices — the exam plants one where the other belongs to see if you conflate them.
Storage classes and lifecycle
Cost tuning lives in the storage classes. Standard is the Regional default, stored redundantly across multiple Availability Zones. Infrequent Access and Archive are progressively cheaper tiers for colder files, and lifecycle management transitions files to them automatically after a set idle window — all without changing how applications mount the file system. For re-creatable data where AZ-level redundancy is not needed, One Zone keeps data in a single Availability Zone at a lower price. The lever you choose depends on how the data is accessed and how much redundancy it truly needs.
Scaling and mount targets
Two facts settle several scenarios outright. EFS scales storage automatically and is multi-AZ by design on the Standard class, so there is no capacity to pre-provision and no manual standby to build for AZ resilience — an answer that proposes reserving peak capacity is describing EBS, not EFS. And instances reach the file system through a mount target in their own Availability Zone: if one AZ has no mount target, instances there simply cannot connect. Create one mount target per AZ in use, and reachability problems from a single zone disappear.
How to use the seven scenarios
Answer each before opening the explanation, then find the requirement word that decided it — “unpredictable”, “small dataset”, “thousands of clients”, “cheapest”, “cold files”, “one AZ can’t connect”. Every explanation names that constraint and takes the distractors apart, because the miss is almost always a real EFS setting answering a different question than the one asked. For the wider domain, see Design High-Performing Architectures; to revisit when EFS is the right service in the first place, see EBS vs S3 vs EFS.
Updated for SAA-C03 (July 2026). The sample questions above are our own work
in the style of the exam — not real exam items. The exam itself is set and marked
by the certification body.