AWS SAA-C03 Study Guide
for Builders

Instead of only saying that EC2 is a compute service, we compare it to a VPS. Instead of memorizing that a Region contains Availability Zones, we examine how that structure protects an application from infrastructure failure.

Every lesson follows the same working pattern: what problem does this solve, when should I use it, when should I avoid it, what is it confused with, where have we seen it in our own infrastructure, what traps appear on the exam, and what questions should I practice?

The central SAA-C03 question is: which design satisfies the requirements with the least unnecessary operational burden?

What problem does this solve?

A Region is a geographic AWS area. An Availability Zone is an isolated infrastructure location inside a Region. Multi-AZ architecture helps an application survive a zone failure without requiring a full Multi-Region design.

When should I use it?

Use Multi-AZ when the workload needs high availability inside one geographic area: application servers in two AZs, a load balancer in front, and a Multi-AZ database when the data tier must survive a zone outage.

When should I not use it?

Do not jump to Multi-Region when the requirement only says zone-level resilience. Multi-Region adds data replication, failover, latency, governance, and cost complexity.

Commonly confused with

Multi-AZ is not Multi-Region. Multi-AZ protects against a data-center or zone failure. Multi-Region protects against a larger regional failure or improves geographic reach.

Real example from our infrastructure

Our staging architecture preferred af-south-1, the AWS Africa Cape Town Region. AWS currently documents Cape Town as af-south-1 with 3 Availability Zones.

AWS exam traps

• Choosing Multi-Region when Multi-AZ satisfies the availability requirement.
• Assuming every service exists in every Region.
• Forgetting that AZ names can map differently between AWS accounts.

Practice questions

1. A workload must survive one data-center failure inside the same country. Is Multi-AZ or Multi-Region the cleaner first answer?
2. A managed service is unavailable in the chosen Region. What architecture choices do you have before moving sensitive data elsewhere?

What problem does this solve?

It defines who secures what. AWS secures the cloud: facilities, hardware, networking, and virtualization. The customer secures what runs in the cloud: identity, data, configuration, application behavior, and often the operating system.

When should I use it?

Use this model whenever comparing EC2, containers, serverless, and managed databases. The more managed the service, the more underlying operations AWS handles.

When should I not use it?

Do not use it as an excuse to stop caring about configuration. Even on managed services, the customer still owns access control, data classification, encryption choices, and secure application logic.

Commonly confused with

Managed does not mean responsibility-free. It usually means AWS owns more of the lower stack while you still own safe use of the service.

Real example from our infrastructure

For an EC2-style VPS pattern, AWS manages the physical host. We still own patching the OS, selecting security groups, assigning IAM roles, managing secrets, and auditing access.

AWS exam traps

• Assuming AWS patches the guest OS on EC2.
• Assuming AWS writes least-privilege IAM policies for the customer.
• Ignoring that customer data remains the customer responsibility.

Practice questions

1. Who is responsible for security group rules on an EC2 instance?
2. Which service choice reduces OS patching burden: EC2 or a managed database?

What problem does this solve?

EC2 gives you virtual servers. EBS gives those servers persistent block storage. The simplest mental model: EC2 is the computer, EBS is one of its disks.

When should I use it?

Use EC2 when you need OS-level control, custom runtime behavior, or a familiar VPS-style deployment. Use EBS when the server needs storage that survives normal instance stops and replacements.

When should I not use it?

Avoid EC2 when a managed service can satisfy the requirement with less operational burden. Avoid instance store for data that must survive host replacement.

Commonly confused with

EBS is storage, not RAM. RAM is temporary working memory from the EC2 instance type. S3 is object storage, not a block disk attached to a server.

Real example from our infrastructure

For a VPS-like application server, we would treat the EC2 instance as replaceable compute and keep important persistent state outside the instance, either on EBS, in a database, or in S3 depending on the access pattern.

AWS exam traps

• Putting durable data on instance store.
• Confusing EBS volume size with instance memory.
• Keeping application state on one server when stateless scaling is required.

Practice questions

1. A server is terminated and recreated. Which storage type is safest for data that must persist?
2. What AWS resource determines CPU and RAM for EC2?

What problem does this solve?

S3 stores objects such as documents, images, logs, backups, static assets, generated reports, and archives. It is built for durable object storage accessed through buckets, keys, and APIs.

When should I use it?

Use S3 for document evidence, invoices, delivery tickets, generated reports, backups, and static assets. Keep file metadata in a database and actual file bytes in S3.

When should I not use it?

Do not treat S3 like a normal mounted low-latency block disk. If an application needs a filesystem or block device, EBS or EFS may be the better fit.

Commonly confused with

S3 is not EBS. S3 is object storage. EBS is block storage attached to compute. Instance store is temporary host-attached storage.

Real example from our infrastructure

For document-audit workflows, S3 is the natural place for source documents and audit evidence, while OCR status and document metadata live in a database or report layer.

AWS exam traps

• Selecting EBS for object archives that do not need a block device.
• Forgetting bucket policies, encryption, public-access blocks, and lifecycle rules.
• Assuming storage Region automatically equals processing Region.

Practice questions

1. Where should a document-audit system store PDFs that must be retained durably?
2. Why might metadata belong in a database while files belong in S3?

What problem does this solve?

IAM controls which humans and workloads can access AWS resources. The core building blocks are users, groups, roles, and policies.

When should I use it?

Use roles for applications and AWS workloads so they receive temporary credentials. Use IAM Identity Center and MFA for human access. Grant only the actions and resources required.

When should I not use it?

Do not casually distribute long-lived administrator access keys. Do not give broad permissions to an app that only needs to read a single bucket or parameter.

Commonly confused with

Users are persistent identities. Groups collect users. Roles are assumable identities. Policies define allowed and denied actions.

Real example from our infrastructure

An OCR worker should receive a role with explicit S3 read/write permissions for the approved document bucket and SSM Parameter Store access for only the parameters it needs.

AWS exam traps

• Choosing access keys over roles for workloads running in AWS.
• Granting administrator access when least privilege is possible.
• Forgetting MFA and temporary credentials for human operators.

Practice questions

1. What should an EC2-hosted app use to call S3 without storing permanent keys on disk?
2. What is the least-privilege shape for an app that only reads one bucket prefix?

What problem does this solve?

Data residency keeps sensitive data inside an approved geography or trust boundary. The hard lesson: the place where data is stored is not always the same as the place where a managed service processes it.

When should I use it?

Use explicit regional architecture when documents, regulated data, customer records, or audit evidence have location constraints. Store and process in the approved Region where possible.

When should I not use it?

Do not silently send documents to another Region just because a managed service is convenient there. If cross-Region processing is required, make it an explicit approved design choice.

Commonly confused with

Storage Region is not processing Region. Default SDK Region is not a governance decision. Service availability is not uniform across AWS Regions.

Real example from our infrastructure

We preferred af-south-1 for primary staging, document storage, and infrastructure. As verified against the AWS General Reference on 2026-07-26, the current Amazon Textract endpoint list does not include af-south-1. That means OCR must either run locally, use another approved service, or cross the Region boundary only behind an explicit external_ocr gate.

PRIMARY_REGION=af-south-1
DOCUMENT_STORAGE=af-south-1
LOCAL_OCR=tesseract|pdfplumber
EXTERNAL_OCR=requires explicit approval
DEFAULT_REGION=must not be implicit
GOLDEN_FIXTURE=scanned document test

AWS exam traps

• Assuming a managed AI service is available in the same Region as storage.
• Ignoring data-transfer, latency, compliance, and approval boundaries.
• Letting SDK defaults choose a Region implicitly.

Practice questions

1. If documents must remain in South Africa and OCR is unavailable in the storage Region, what design avoids silent cross-Region processing?
2. Why should an external_ocr flag be explicit instead of inferred from missing local OCR?

1. AWS Foundations: Regions, AZs, and Shared Responsibility
2. EC2, EBS, and S3 Explained Through a VPS
3. IAM Without the Confusion
4. High Availability, Load Balancing, and Auto Scaling
5. VPCs, Subnets, Routes, and Security Groups
6. Databases: RDS, Multi-AZ, Read Replicas, and DynamoDB
7. Caching, Queues, and Decoupled Architecture
8. Data Residency and Our af-south-1 Architecture Decision
9. SAA-C03 Exam Traps and Architecture Questions
10. Final Practice Exam and Weak-Area Review