Pair your devices with a code and playback position follows you: pause on this device, hit resume on the other. Position is saved to the site every minute and on pause.
Open this panel on your other device and enter the same code.
Starts this lesson and continues through 28 more to the end of certification prep.
The exam guide's task statements are all about designing. But a design decision is made of facts, and the exam's wrong answers are built by violating them. Before you weigh a trade-off, you run a filter: is this option even possible? The FAQs are the answer key for that filter.
This lesson covers EC2 and S3. Two documents, and the highest-value facts in each are numbers.
⚠️ A caveat about this lesson's sourcing. The AWS FAQ pages are long, partly marketing, and they render dynamically. My fetches returned substantial answers but not the complete pages. Every quote below is verbatim from what I actually retrieved on 2026-09-21; where I know a topic is examinable and I did not get it, I say so rather than filling the gap from memory. Those gaps are your reading list.
What it is, verbatim:
"Amazon EC2 is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers."
The SLA — a hard number worth having:
"Our SLA guarantees a Monthly Uptime Percentage of at least 99.99% for Amazon EC2 and Amazon EBS within a Region."
Note the scope: within a Region, and it covers EC2 and EBS together. If a question asks what availability a single-Region EC2 deployment is designed for, that's your figure — and it is a Region-level commitment, which is why a single-AZ design doesn't inherit it.
Root device and persistence — this is the one that trips people up, because the answer depends on a choice made at launch:
"When you launch your Amazon EC2 instances you have the ability to store your root device data on Amazon EBS or the local instance store. By using Amazon EBS, data on the root device will persist independently from the lifetime of the instance."
And the contrast, verbatim: "the local instance store only persists during the life of the instance."
| EBS-backed root | Instance store | |
|---|---|---|
| Persists beyond the instance | Yes — "independently from the lifetime of the instance" | No — "only persists during the life of the instance" |
| Survives a stop/start | Yes | No (data is lost) |
| Use for | anything you need to keep | scratch, cache, buffers, replicated data |
⚠️ "Instance store is faster, so use it for the database" is a wrong answer unless the data is replicated elsewhere. The exam likes this one because instance store genuinely is faster, which makes the distractor plausible.
Purchasing options. The FAQ names On-Demand Instances, Reserved Instances, Spot Instances, Dedicated Hosts, and Savings Plans.
⚠️ I did not retrieve the FAQ's explanations of how each option works, or the mechanics of Spot
interruption (the interruption notice and its warning period, the interruption behaviours). Those are
squarely examinable in Domain 4. Read the purchasing-options section of the EC2 FAQ and
docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html before the exam — and do not
trust a half-remembered number for the Spot notice period.
What you can reason about without those specifics, and what the exam mostly tests:
| Requirement in the stem | Purchasing option |
|---|---|
| Steady-state, predictable, 1–3 year commitment, lowest cost | Reserved Instances or Savings Plans |
| Spiky, unpredictable, short-lived | On-Demand |
| Fault-tolerant / interruptible / batch / stateless | Spot |
| Licensing tied to physical sockets or cores; compliance needs a dedicated physical server | Dedicated Hosts |
⚠️ Spot requires the workload to tolerate interruption. If the stem describes a stateful, uninterruptible process, Spot is wrong however cheap it is — and "most cost-effective" in the stem does not license you to break the functional requirement.
⚠️ I also did not retrieve anything on placement groups (cluster, spread, partition) from this
page, and they are examinable for Domain 3. Read
docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html.
Durability — the eleven nines:
"99.999999999% durability (11 nines) for your authoritative dataset in your S3 bucket."
Availability, by storage class — these are design targets and they differ, which is the point:
| Storage class | Designed for availability |
|---|---|
| S3 Standard | 99.99% |
| S3 Standard-IA | 99.9% |
| S3 Intelligent-Tiering | 99.9% |
| S3 Glacier Instant Retrieval | 99.9% |
| S3 One Zone-IA | 99.5% |
| S3 Glacier Flexible Retrieval | 99.99% "and an SLA of 99.9%" |
| S3 Glacier Deep Archive | 99.99% "and an SLA of 99.9%" |
⚠️ One Zone-IA's 99.5% is the number to remember, because the reason for it is the exam question: it stores data in a single Availability Zone. So it's cheaper, and it's the wrong answer for anything where losing an AZ must not lose the data. It's right for re-creatable data — derived datasets, thumbnails, secondary copies of something replicated elsewhere.
Note also the distinction the Glacier rows make between designed-for availability and the contractual SLA. Those are different numbers on the same row, and the exam occasionally leans on the difference.
Consistency — no longer a trade-off:
"Amazon S3 delivers strong read-after-write consistency automatically, without changes to performance or availability."
And: after a successful write, "any subsequent read request immediately receives the latest version of the object."
⚠️ This invalidates a large amount of older study material. S3 used to be eventually consistent for overwrites and deletes, and plenty of courses still teach that, along with workaround patterns. Any exam option whose justification is "because S3 is eventually consistent" is now wrong.
Object size:
| Value | |
|---|---|
| Minimum object size | 0 bytes |
| Maximum object size | 50 TB |
Largest single PUT |
5 GB — above this, use multipart upload |
⚠️ The 5 GB single-PUT limit versus the 50 TB object limit is a classic pair. Uploading a 200 GB object is entirely possible; doing it in one PUT is not. An option that says "the object is too large for S3" is wrong; one that says "use multipart upload" is right. (The maximum object size has increased over time — it was 5 TB for years. Another place to check your source's date.)
Storage classes, as the FAQ lists them: S3 Standard, S3 Standard-IA, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, and S3 Intelligent-Tiering.
S3 Intelligent-Tiering:
it "automatically optimizes costs based on access patterns, without performance impact or operational overhead."
"Without … operational overhead" is doing real work in that sentence. Intelligent-Tiering is the answer when the stem says access patterns are unknown, unpredictable, or changing — because the alternative is you guessing, and lesson 1's first design principle says stop guessing. If the stem tells you the access pattern precisely, a specific class plus a lifecycle rule is usually cheaper.
⚠️ I did not retrieve the minimum storage durations per class (the 30-day, 90-day and 180-day figures commonly cited for Standard-IA, Glacier Flexible Retrieval and Deep Archive) from the page I fetched. They matter for Domain 4 cost questions and for the lifecycle-transition trap in SAA1 lesson 6 — read the S3 pricing page or the storage-class documentation and get them from the source.
Nor did I retrieve retrieval times for the Glacier tiers (expedited / standard / bulk). Same instruction: get those from the docs, not from memory.
The most examinable pairing across these two FAQs is durability versus availability, because the words get used interchangeably in conversation and mean different things here.
One Zone-IA is the clean illustration: same durability design, lower availability, because the copies are in one AZ. If a stem says "we can tolerate re-creating this data but not paying for it", that's One Zone-IA. If it says "we cannot lose this data", the AZ count is the thing to look at.
And the EC2 counterpart: the 99.99% EC2/EBS SLA is a Regional commitment. Both services express resilience in terms of how many Availability Zones are involved, which is the single idea carrying through to Domain 2.
PUT, which is capped at 5
GB. Use multipart upload.