AWS Certified Solutions Architect – Associate (SAA-C03): Certification Essentials

Table of Contents

1. Module 1: The AWS Global Footprint

   • AWS Regions
   • Availability Zones (AZs)
   • Edge Locations and Points of Presence
   • AZ Names vs. AZ IDs — Multi-Account Considerations
   • Global Infrastructure Diagram

2. Module 2: The Shared Responsibility Model and Well-Architected Framework

   • The Shared Responsibility Model
   • The Six Pillars of the Well-Architected Framework
   • The AWS Well-Architected Tool
   • High Availability vs. Fault Tolerance
   • Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
   • HA vs. FT Cheat Sheet

3. Module 3: Installing and Configuring the AWS CLI

   • AWS CLI Version
   • Installation by Operating System
   • Configuring the AWS CLI
   • Working with Named Profiles
   • Verifying Your Identity with STS
   • Credentials File Structure

4. Module 4: What to Expect on the Exam

   • Exam Overview
   • Exam Format and Scoring
   • The Four Exam Domains
   • Domain 1: Design Secure Architectures (30%)
   • Domain 2: Design Resilient Architectures (26%)
   • Domain 3: Design High-Performing Architectures (24%)
   • Domain 4: Design Cost-Optimized Architectures (20%)
   • Exam Strategy and Tips
   • How to Schedule Your Exam
   • Exam Policies and Requirements

5. Appendix A: In-Scope AWS Services and Features

6. Appendix B: Out-of-Scope AWS Services and Features

7. Appendix C: Recommended Hands-On Labs

8. Appendix D: Important Reference Links

Module 1: The AWS Global Footprint

This module covers the fundamental building blocks of the AWS global infrastructure that you must understand before studying for and taking the SAA-C03 exam. The three main concepts are AWS Regions, Availability Zones (AZs), and Edge Locations.

AWS Regions

An AWS Region is a completely separate geographical area that hosts AWS data centers. Each region contains all of the networking gear, power infrastructure, servers, and other equipment needed to run AWS services in the cloud.

Key characteristics of AWS Regions:

• They provide the greatest possible amount of fault tolerance and stability for your workloads.
• They allow you to deploy your workloads closer to your user base anywhere in the world.
• Each region is completely independent from every other region. Data does not automatically replicate between regions unless you configure it to do so.
• Regions are identified by a code such as us-east-1 (US East - N. Virginia), us-west-2 (US West - Oregon), eu-west-1 (Europe - Ireland), etc.
• AWS continuously adds new regions. The current list of active regions and regions coming soon is always growing.
• In addition to standard public regions, AWS also offers GovCloud regions (e.g., us-gov-east-1, us-gov-west-1). These are for extremely specific and strict workloads related to US government applications and services. They are subject to strict compliance and regulatory requirements. For the exam, you primarily need to know about standard regions and AZs; GovCloud regions appear infrequently.

Exam tip: When scenario questions ask about isolating workloads geographically or serving global users, think Regions. Regions are the highest-level isolation boundary in AWS.

Availability Zones (AZs)

An Availability Zone (AZ) is an isolated, independent location within a specific AWS Region. Each AZ has its own:

• Redundant power supply
• Independent networking
• Low-latency connectivity to other AZs in the same Region

AZs are made up of one or more physical data centers clustered in a specific geographic area within a Region. The key design principle is that each AZ is physically separated from others to reduce the impact of localized disasters (floods, fires, hurricanes, etc.). If one AZ is impacted, the others in the same Region should remain fully operational.

Key facts about AZs:

• AWS requires a minimum of three AZs per Region (most Regions have three or more).
• Example: US West (Oregon) — us-west-2 — currently has four AZs: us-west-2a, us-west-2b, us-west-2c, us-west-2d.
• When you design Multi-AZ architectures, you are deploying to two or more AZs within the same Region.
• AZs are connected to each other within a Region via high-bandwidth, low-latency private fiber links, making synchronous replication feasible.

Exam tip: AZs are the primary mechanism for achieving High Availability. Deploying across multiple AZs protects against localized failures. Deploying across multiple Regions is for Fault Tolerance and disaster recovery.

Edge Locations and Points of Presence

Edge Locations are data centers operated by AWS and its telecommunication partners located around the world. They are distinct from standard Regions and AZs and serve a different purpose.

Key characteristics:

• There are far more edge locations than Regions — hundreds globally vs. ~30+ regions.
• They allow you to deploy content and services much closer to end users than Regions and AZs can provide.
• They are used primarily for caching, content delivery, and DNS resolution.
• Edge locations leverage Points of Presence (PoPs) and Regional Edge Caches.

Services that use edge locations include:

• Amazon CloudFront — AWS’s Content Delivery Network (CDN). Caches content at edge locations so users around the world get low-latency responses.
• Amazon Route 53 — AWS’s managed DNS service, which routes user queries at the edge.
• AWS Global Accelerator — Routes traffic through the AWS backbone network using edge locations for improved performance.
• AWS WAF and AWS Shield — Can be applied at edge locations to block threats before they reach your origin.

Exam tip: If a scenario mentions reducing latency for a global user base, think edge locations and CloudFront. If it mentions caching, CDN, or “deliver closer to end users,” edge locations and CloudFront should immediately come to mind.

AZ Names vs. AZ IDs — Multi-Account Considerations

This is a subtle but important concept, especially for multi-account infrastructure design.

AZ Names (e.g., us-west-2a, us-west-2b) are logical abstractions that AWS assigns per account. The same AZ name in two different AWS accounts may map to different physical data centers.

AZ IDs (e.g., usw2-az1, usw2-az2) are consistent physical identifiers that always refer to the same set of data centers, regardless of which account is being used.

Example:

• In Account A: us-west-2b maps to AZ ID usw2-az1
• In Account B: us-west-2b might map to AZ ID usw2-az3

This randomization is done intentionally by AWS to spread resource usage evenly across physical data centers. If all customers defaulted to us-east-1a, that physical data center would be overloaded.

Why this matters: When you need to ensure that resources in two different AWS accounts are physically co-located in the same data center (for example, to minimize latency or for compliance), you must compare AZ IDs, not AZ names.

Exam tip: For most exam scenarios, AZ names are sufficient. However, for multi-account VPC sharing and cross-account networking scenarios, AZ IDs are the authoritative reference.

Global Infrastructure Diagram

graph TB
    subgraph "AWS Global Infrastructure"
        subgraph "Region: us-west-2 (Oregon)"
            subgraph "AZ: us-west-2a"
                DC1[Data Centers]
            end
            subgraph "AZ: us-west-2b"
                DC2[Data Centers]
            end
            subgraph "AZ: us-west-2c"
                DC3[Data Centers]
            end
            subgraph "AZ: us-west-2d"
                DC4[Data Centers]
            end
            DC1 <-->|Low-latency fiber| DC2
            DC2 <-->|Low-latency fiber| DC3
            DC3 <-->|Low-latency fiber| DC4
        end

        subgraph "Region: us-east-1 (N. Virginia)"
            subgraph "AZ: us-east-1a"
                DC5[Data Centers]
            end
            subgraph "AZ: us-east-1b"
                DC6[Data Centers]
            end
            subgraph "AZ: us-east-1c"
                DC7[Data Centers]
            end
        end

        subgraph "Edge Locations (PoPs)"
            EL1[Edge Location - New York]
            EL2[Edge Location - London]
            EL3[Edge Location - Tokyo]
            EL4[Edge Location - Sydney]
        end
    end

    Users["Global End Users"] -->|Low-latency| EL1
    Users -->|Low-latency| EL2
    Users -->|Low-latency| EL3
    Users -->|Low-latency| EL4
    EL1 --> DC5
    EL2 --> DC1

Module 2: The Shared Responsibility Model and Well-Architected Framework

This module covers two of the most important conceptual frameworks you need to master for the SAA-C03 exam: the Shared Responsibility Model and the AWS Well-Architected Framework.

The Shared Responsibility Model

Security and compliance in AWS is a shared responsibility between AWS and the customer. AWS has clearly divided ownership into two categories:

• AWS is responsible for security of the cloud
• You (the customer) are responsible for security in the cloud

The key phrase to remember: “of the cloud” vs. “in the cloud.”

graph LR
    subgraph "Shared Responsibility Model"
        subgraph "CUSTOMER Responsibility — Security IN the Cloud"
            C1[Data Encryption at Rest]
            C2[Data Backup and Recovery]
            C3[Access Control and Authorization]
            C4[OS, Network Config, Firewall Rules]
            C5[Application-level Security]
            C6[Identity and Access Management - IAM]
        end

        subgraph "AWS Responsibility — Security OF the Cloud"
            A1[Software running AWS services]
            A2[Physical security of data centers]
            A3[Hardware maintenance and replacement]
            A4[Global Infrastructure - Regions, AZs, Edge Locations]
            A5[Network infrastructure redundancy]
            A6[Hypervisor and virtualization layer]
        end
    end

Customer Responsibilities (Security IN the Cloud)

As the customer, you are responsible for everything you put inside AWS and every configuration choice you make:

1. Encryption of data at rest — AWS provides the tools (AWS KMS, S3 server-side encryption, EBS encryption, etc.), but you must enable and configure them. Simply having data in AWS does not mean it is encrypted.

2. Backing up your data — AWS’s infrastructure is highly available and redundant, but this does not replace a backup strategy. You are responsible for enabling and testing backups using services like AWS Backup, S3 versioning, RDS automated backups, etc.

3. Controlling access and authorization — You must configure and manage IAM policies, roles, users, and groups. You must understand and enforce the principle of least privilege. You must know the difference between:

   • Authentication — Who are you? (verifying identity)
   • Authorization — What are you allowed to do? (controlling permissions)
   • Access control — The mechanisms that enforce authorization

4. Managing operating systems, network configurations, and firewall controls — For services like Amazon EC2, you are responsible for the guest OS, patching, security group rules, network ACLs, and any software running on the instance. For managed services (RDS, Lambda, etc.), AWS takes on more of this responsibility.

AWS Responsibilities (Security OF the Cloud)

AWS is responsible for the foundational infrastructure that makes cloud services possible:

1. Software infrastructure — Maintaining, controlling, and updating all software that runs the underlying AWS services (hypervisors, managed service software, etc.).

2. Physical security of data centers — Strictly controlling physical access to data centers. Only authorized AWS personnel can enter. AWS data centers have extensive physical security controls.

3. Hardware maintenance — Replacing failed hardware, maintaining servers, networking equipment, and storage systems. When hardware fails, AWS handles it transparently.

4. Global infrastructure — The Regions, Availability Zones, and Edge Locations themselves are owned and operated by AWS. AWS ensures these remain available, connected, and secure at the infrastructure level.

The Spectrum of Responsibility

The customer’s responsibility shifts depending on the service type:

Exam tip: When you see a question about who is responsible for something, identify whether it’s about the physical infrastructure and underlying services (AWS’s job) or about the configuration, data, and access control within those services (your job). The boundary shifts depending on the service model.

Official Reference

• AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/

The Six Pillars of the Well-Architected Framework

The AWS Well-Architected Framework is a set of principles and best practices that you should apply to all AWS-based workloads. It serves as the guiding framework for every single scenario on the SAA-C03 exam. Every question will relate to one or more of these pillars.

There are six pillars:

mindmap
  root((Well-Architected Framework))
    Operational Excellence
      Operations as code
      Small frequent changes
      Managed services
      Gain operational insights
    Security
      Implement traceability
      Layered security
      Encrypt data in transit and at rest
      Least privilege access
    Cost Optimization
      Consumption model
      Measure efficiency
      Use managed services
      Right-size resources
    Reliability
      Automate recovery
      Test recovery procedures
      Scale horizontally
      Auto Scaling Groups
    Performance Efficiency
      Serverless architectures
      Deploy globally
      Experiment often
      Remove bottlenecks
    Sustainability
      Reduce energy consumption
      Scale appropriately
      Maximize utilization
      Minimize resources needed

Pillar 1: Operational Excellence

Core question: Does your architecture work and will it continue to work as things evolve?

Operational Excellence means you have the capability to:

• Support development of your applications and infrastructure over time. Your operational model can evolve as your application evolves.
• Run workloads effectively — you’re not wasting compute, money, or time. You’re using the right services for the right workloads.
• Gain insights into operations — collect metrics, monitor performance, and understand whether you’re running efficiently.
• Continuously improve your processes, procedures, and team practices to deliver more business value over time.

Design principles and examples for the exam:

• Operations as code — Use infrastructure-as-code tools like AWS CloudFormation to define your operational procedures and infrastructure in code, making them repeatable and testable.
• Make small and frequent changes — Deploy small, incremental changes rather than large, risky batches. This minimizes failure impact and makes rollbacks easier.
• Use managed services — Don’t reinvent the wheel. If a managed service (like RDS instead of running your own database on EC2) can do the job, use it. This reduces operational burden.
• Anticipate failure — Design for failure by testing failure scenarios and having runbooks for common failure modes.
• Learn from operational failures — Post-incident reviews and refinement of procedures.

Pillar 2: Security

Core question: Does your system work only as intended?

The Security pillar encompasses three major areas:

1. Protecting your data — Are you encrypting sensitive data at rest (using KMS, S3 SSE, EBS encryption) and in transit (using TLS/HTTPS via ACM)?

2. Protecting your systems — Are you securing the underlying infrastructure, not just the user-facing parts? Are you applying security groups, NACLs, and network segmentation?

3. Protecting your assets — Are you using appropriate technologies to protect the intellectual property, customer data, and business assets that live in your cloud environment?

Design principles and examples for the exam:

• Implement traceability — Use AWS CloudTrail to log all API activity. Know who did what, when, and from where.
• Apply security at all layers (defense in depth) — Think of security like an onion with multiple layers. Even if an attacker gets past one layer, they face more. Use VPCs, security groups, NACLs, WAF, Shield, and IAM together.
• Automate security best practices — Use AWS Config rules and Security Hub to automatically detect deviations from security baselines.
• Encrypt data in transit and at rest — Use TLS (via AWS Certificate Manager) for data in transit and AES-256 encryption (via KMS) for data at rest.
• Keep people away from data — Apply the principle of least privilege. Use IAM to ensure that no person or service has more access than they need. Use VPC endpoints to keep traffic private.
• Enable MFA — Always protect root and privileged accounts with multi-factor authentication.

Relevant services: IAM, AWS KMS, AWS ACM, Amazon Cognito, Amazon GuardDuty, Amazon Macie, AWS WAF, AWS Shield, Amazon Inspector, AWS Secrets Manager.

Pillar 3: Cost Optimization

Core question: Are you spending only what you need to?

Cost Optimization means you have the ability to run your systems to deliver business value at the lowest possible price point. You’re not wasting money on over-provisioned or idle resources.

Design principles and examples for the exam:

• Adopt a consumption model — Only pay for what you use. Use on-demand resources, auto-scaling, and serverless architectures (Lambda, Fargate) to align cost with actual usage.
• Take advantage of volume discounts — Use Reserved Instances or Savings Plans for predictable, steady-state workloads. Use Spot Instances for interruptible, fault-tolerant batch workloads.
• Measure overall efficiency — Use AWS Cost Explorer, AWS Budgets, and AWS Cost and Usage Reports to understand where money is being spent and where savings are possible.
• Let AWS handle undifferentiated heavy lifting — Don’t pay to run and maintain infrastructure that AWS can manage for you at lower cost (e.g., use RDS instead of running your own database on EC2).
• Right-size resources — Use AWS Compute Optimizer to identify over- or under-provisioned resources. Don’t run a large instance type when a small one will do.
• Use appropriate storage tiers — Store infrequently accessed data in cheaper storage classes (S3 Glacier for archival, S3 Infrequent Access for less-frequently accessed data).

Relevant services: AWS Cost Explorer, AWS Budgets, AWS Cost and Usage Report, Savings Plans, Reserved Instances, Spot Instances, AWS Compute Optimizer, S3 Intelligent-Tiering.

Pillar 4: Reliability

Core question: Does your system work consistently, and if it breaks, can it recover quickly?

Reliability means your workload performs its intended function correctly and consistently. This includes the ability to:

• Operate correctly and consistently — no unexpected errors, intermittent failures, or degraded performance.
• Be easily tested — you can run chaos experiments, load tests, and stress tests against your infrastructure without it completely falling over.
• Automatically recover from failure — the system detects failures and either self-heals or initiates a recovery procedure without manual intervention.

Design principles and examples for the exam:

• Test recovery procedures — Don’t just assume your failover works. Actually test it regularly. Verify that your multi-AZ failover, cross-region replication, and backup restoration work as expected.
• Automatically recover from failure — Use Auto Scaling Groups to replace failed instances, Route 53 health checks with failover routing policies, and RDS Multi-AZ for automatic database failover.
• Scale horizontally to increase aggregate system availability — Add more smaller instances rather than making one instance bigger. This distributes risk. If one instance fails, others absorb the load.
• Stop guessing capacity — Use auto-scaling to match capacity to actual demand. Don’t overprovision for peak loads that only occur occasionally.
• Manage change in automation — Use CloudFormation and AWS Systems Manager for controlled, automated change management.

Key services: Amazon EC2 Auto Scaling, Elastic Load Balancing (ELB), Amazon Route 53, Amazon RDS Multi-AZ, Amazon Aurora Global Database, AWS Backup.

Pillar 5: Performance Efficiency

Core question: Are you using computing resources efficiently and removing bottlenecks?

Performance Efficiency means you’re able to use the correct computing resources efficiently to meet system requirements and maintain that efficiency as demand changes.

This pillar is closely related to Reliability and Cost Optimization but focuses specifically on matching the right resource to the right workload.

Design principles and examples for the exam:

• Use the correct computing resources — Select instance types and sizes based on actual workload characteristics. A compute-optimized instance (C family) is better for CPU-intensive tasks; a memory-optimized instance (R or X family) is better for in-memory databases.
• Maintain efficiency as demand scales — Use auto-scaling to dynamically adjust capacity. Use serverless (Lambda) for event-driven workloads that have unpredictable traffic patterns.
• Use serverless architectures — AWS Lambda can scale very quickly and concurrently to handle bursts of requests (e.g., thousands of simultaneous invocations) without pre-provisioning infrastructure.
• Deploy globally — Place workloads closer to end users by using multiple regions and edge locations. Deploying only in us-east-1 while serving users in Asia will result in high latency.
• Experiment often — Load test your applications, try different instance types, benchmark different database configurations. Use the results to continuously optimize.
• Use managed and purpose-built services — Services like ElastiCache for caching, CloudFront for content delivery, and DynamoDB for low-latency key-value access are purpose-built for their use cases and provide better performance than generic alternatives.

Key services: AWS Lambda, Amazon CloudFront, Amazon ElastiCache, AWS Auto Scaling, Amazon EC2 (correct instance families), Amazon DynamoDB Accelerator (DAX).

Pillar 6: Sustainability

Core question: Are you minimizing the environmental impact of your workloads?

Sustainability is the newest of the six pillars. It focuses on reducing the environmental footprint of your cloud workloads by maximizing the use of resources you provision.

Key aspects:

• Reduce energy consumption — Right-size your workloads. Running a large, mostly idle server wastes energy. Scale down or use serverless to run only what you need.
• Increase efficiency across all components — Use auto-scaling to ensure that compute resources are active only when needed. Remove idle or underutilized resources.
• Maximize the benefits of provisioned resources — Before scaling up or out, ask whether you’re actually using what you already have. Are your existing instances at a reasonable utilization level?
• Minimize total resources required — Sometimes a simpler architecture (a monolith instead of a complex microservices mesh) is more efficient and sustainable given your actual scale.
• Use managed services — AWS manages its own infrastructure with sustainability in mind. By using managed services, you inherit AWS’s sustainability optimizations.

Design principles for the exam:

• Understand your impact — Measure workload utilization and energy consumption. Use Amazon CloudWatch metrics to identify inefficiencies.
• Maximize utilization — Target higher utilization rates for your compute before growing your fleet.
• Use demand and supply planning tools — Auto Scaling ensures resources scale with demand rather than running at full capacity all the time.

The AWS Well-Architected Tool

The AWS Well-Architected Tool is a free service available in the AWS Management Console that helps you evaluate your existing architectures against the six pillars.

What it does:

• Documents your architectural decisions — Why did you choose this database type? Why this compute size? The tool helps you formalize and record these decisions.
• Provides recommendations for improving workloads — After you answer questions about your architecture, the tool identifies areas where you could better align with best practices.
• Measures your alignment with best practices — It produces a report showing how closely your workloads align with the Well-Architected Framework.
• Helps design reliable, secure, efficient, and cost-effective solutions — These keywords map directly to the pillars.

At a high level: the Well-Architected Tool is an automated reviewer that asks you questions about your architecture and tells you where you’re doing well and where you can improve.

Exam tip: If a scenario asks “how can a company assess whether their workload meets AWS best practices,” the AWS Well-Architected Tool is the answer.

High Availability vs. Fault Tolerance

These two terms are often confused, but they have a very specific and important distinction on the SAA-C03 exam.

High Availability (HA)

Definition: Designing systems to remain operational for long periods of time, where failures result in minimal downtime and brief interruptions. Systems are designed to recover quickly.

Key characteristics:

• Failures do cause a brief interruption — a short outage or performance degradation occurs, but recovery is fast.
• Typically achieved through redundancy and automatic failover mechanisms.
• Can be thought of as “self-healing” — the system detects a failure and brings a replacement online.
• Target SLA: Approximately 99.9% to 99.99% uptime (roughly 8.7 hours to 52 minutes of downtime per year).
• Scope: Primarily achieved within a single Region across multiple Availability Zones.

Example: A web application with an Application Load Balancer distributing traffic across EC2 instances in an Auto Scaling Group spread across three AZs. If one AZ fails, the load balancer stops sending traffic there and the remaining instances absorb the load. There may be a brief dip in performance during the transition.

Fault Tolerance (FT)

Definition: Designing systems to continue operating even when one or more components fail, with no interruption to the user experience. Failover happens automatically and seamlessly.

Key characteristics:

• Failures are handled transparently — users should not notice that a failure occurred.
• Requires active-active configurations or extremely fast automatic failover (sub-second).
• Significantly more complex and expensive to build and maintain than HA.
• Target SLA: 100% uptime — zero tolerance for interruption.
• Scope: Typically requires multi-Region deployment with synchronous replication.

Example: A mission-critical database running Amazon Aurora Global Database with multi-region synchronous replication. If an entire Region becomes unavailable, traffic is automatically routed to the secondary Region with no data loss and near-zero downtime.

Key Comparison Table

Exam memory aid:

• AZs = High Availability
• Regions = Fault Tolerance

Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

These are two critical metrics for disaster recovery planning that appear frequently on the exam.

Recovery Time Objective (RTO)

Definition: The maximum acceptable amount of time it should take to restore your system or service after an outage or disruption.

In plain English: “How quickly do we need the system back online?”

• Measured in units of time (seconds, minutes, hours).
• A lower RTO means faster recovery is required, which typically requires more investment in redundancy and automation.
• Example: “Our RTO is 5 minutes” means that after any outage, the system must be restored and operational within 5 minutes.

Recovery Point Objective (RPO)

Definition: The maximum acceptable amount of data loss measured in time — specifically, the age of the most recent backup or replicated data that you can afford to lose if a system fails.

In plain English: “How much data can we afford to lose?”

• Measured in units of time (seconds, minutes, hours, days).
• A lower RPO means less data loss is acceptable, which requires more frequent backups or synchronous replication.
• Example: “Our RPO is 1 hour” means that in a worst-case scenario, we can accept losing up to 1 hour of data (i.e., we’re comfortable restoring from a backup that is at most 1 hour old).

RTO and RPO in AWS Disaster Recovery Strategies

The AWS disaster recovery strategies, ordered from lowest cost/highest RTO+RPO to highest cost/lowest RTO+RPO:

Exam tip: RTO and RPO questions are scenario-based. Identify the stated RTO/RPO requirement, then select the DR strategy that satisfies it at the lowest cost. Don’t over-engineer — if an RPO of 4 hours is acceptable, you don’t need synchronous multi-region replication.

HA vs. FT Cheat Sheet

graph TB
    subgraph "High Availability Architecture (Multi-AZ)"
        ALB[Application Load Balancer]
        subgraph "AZ A"
            EC2A[EC2 Instance]
        end
        subgraph "AZ B"
            EC2B[EC2 Instance]
        end
        subgraph "AZ C"
            EC2C[EC2 Instance]
        end
        ALB --> EC2A
        ALB --> EC2B
        ALB --> EC2C
        RDS_Primary[(RDS Primary\nAZ A)]
        RDS_Standby[(RDS Standby\nAZ B)]
        RDS_Primary -.->|Synchronous replication| RDS_Standby
        EC2A --> RDS_Primary
        EC2B --> RDS_Primary
        EC2C --> RDS_Primary
    end

    subgraph "Fault Tolerant Architecture (Multi-Region)"
        R53[Route 53 Active-Active DNS]
        subgraph "Region: us-east-1"
            APP1[Application Stack]
            DB1[(Aurora Primary)]
        end
        subgraph "Region: eu-west-1"
            APP2[Application Stack]
            DB2[(Aurora Replica)]
        end
        R53 --> APP1
        R53 --> APP2
        DB1 <-->|Aurora Global DB\nSynchronous Replication| DB2
    end

Module 3: Installing and Configuring the AWS CLI

The AWS Command Line Interface (AWS CLI) is an essential tool for interacting with AWS services from your terminal. In the context of the SAA-C03 learning path, the CLI is used extensively in hands-on demonstrations and labs.

AWS CLI Version

Always use AWS CLI Version 2, which is the current major version. Version 2 offers improved performance, better error messages, and new features compared to Version 1.

To verify your installed version:

aws --version

Expected output:

aws-cli/2.x.x Python/3.x.x Darwin/... botocore/2.x.x

Installation by Operating System

The official AWS CLI installation documentation is available at: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

macOS (Command Line — Recommended)

# Step 1: Download the installer package
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

# If you encounter SSL verification errors, you can bypass (not recommended for production):
curl --insecure "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

# Step 2: Run the installer (requires sudo)
sudo installer -pkg AWSCLIV2.pkg -target /

# Step 3: Verify the installation
aws
aws --version
which aws

Linux (Recommended for learning cloud)

Linux is the preferred platform for learning the AWS CLI because Linux drives the cloud. Familiarity with Linux commands sets you up for success in both real-world cloud environments and on the exam.

# Download the installer
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# Unzip
unzip awscliv2.zip

# Install
sudo ./aws/install

# Verify
aws --version

Windows

Follow the official installer instructions at the documentation link above. The Windows installer provides a .msi package for graphical installation.

Recommendation: Whether you’re on Windows or macOS, consider using a Linux VM or a cloud-based environment for CLI practice. Linux is the standard OS in cloud environments, and proficiency with it is a significant advantage.

Configuring the AWS CLI

Before you can use the CLI to run AWS commands, you must configure it with credentials. AWS credentials for CLI access consist of:

• Access Key ID — A public identifier (analogous to a username)
• Secret Access Key — A private secret (analogous to a password)

These are generated in the IAM console (for IAM users) or provided by cloud sandbox environments.

Basic Configuration (Default Profile)

aws configure

You will be prompted for four values:

AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: json

• Region: For sandbox/playground environments, use us-east-1 as it has the fewest restrictions. For production, choose the region closest to your users.
• Output format options: json (default, most compatible), yaml, text, table. The json format is most common in demonstrations and scripts.

Working with Named Profiles

If you work with multiple AWS accounts (common in professional environments and multi-account architectures), you can configure named profiles so you can switch between accounts easily.

Create a Named Profile

aws configure --profile cloud_user

This will prompt you for the same four values (Access Key ID, Secret Key, Region, Output) but store them under the profile name cloud_user.

Use a Named Profile

Append --profile <profile-name> to any AWS CLI command:

aws s3 ls --profile cloud_user
aws ec2 describe-instances --profile cloud_user

Switch Between Profiles Using Environment Variables

export AWS_PROFILE=cloud_user
aws s3 ls  # Now uses cloud_user profile automatically

Verifying Your Identity with STS

After configuring your credentials, verify that you’re authenticated correctly using the AWS Security Token Service (STS):

aws sts get-caller-identity

If you have SSL verification issues on a fresh installation:

aws sts get-caller-identity --no-verify-ssl

Expected JSON output:

{
    "UserId": "AIDAIOSFODNN7EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/cloud_user"
}

This confirms:

• Which IAM user or role you are currently acting as
• Which AWS account you are in
• The ARN (Amazon Resource Name) of the identity

Credentials File Structure

The AWS CLI stores credentials and configuration in two files in your home directory under the .aws/ directory:

~/.aws/credentials

Stores Access Key IDs and Secret Access Keys for each profile:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[cloud_user]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

~/.aws/config

Stores region and output format preferences for each profile:

[default]
region = us-east-1
output = json

[profile cloud_user]
region = us-east-1
output = json

To view these files on macOS/Linux:

cat ~/.aws/credentials
cat ~/.aws/config

Security note: The ~/.aws/credentials file contains sensitive secrets. Protect it with appropriate file permissions (chmod 600 ~/.aws/credentials). Never commit this file to version control (Git). Add .aws/ to your .gitignore.

Module 4: What to Expect on the Exam

This module covers everything you need to know about the SAA-C03 exam itself — its structure, domains, scoring, and strategies for success.

Exam Overview

The AWS Certified Solutions Architect - Associate (SAA-C03) exam is designed to validate your ability to:

1. Design solutions that incorporate AWS services to meet both current business requirements and future projected needs.
2. Design architectures that are secure, resilient, high-performing, and cost-optimized — the four qualities that map directly to the four exam domains.
3. Review existing solutions and determine how to improve them based on given requirements.

The exam tests your ability to act as a solutions architect — someone who can evaluate a business scenario and select the appropriate AWS services, configurations, and architectural patterns to address it.

Target candidate: Someone with at least 1 year of hands-on experience designing cloud solutions using AWS services. Hands-on practice is strongly recommended. Reading and watching alone is significantly less effective than actually building things in AWS.

Exam Format and Scoring

About Unscored Questions

AWS includes 15 unscored “experimental” questions in every exam to gather data for potential future use. These questions look identical to scored questions. Since you cannot tell which ones are unscored, you must treat all 65 questions as if they count toward your grade. Do not try to guess which ones are experiments — just answer every question as thoroughly as you can.

About the Scoring Scale

The 720/1000 passing score is a scaled score. This means:

• You do not need to get exactly 72% of questions correct.
• The scaling accounts for slight differences in difficulty between exam versions.
• You receive a score on the 100–1,000 scale regardless of whether you pass or fail.
• Your score report will include section-level performance indicators, but you only need to pass the overall exam — not each individual domain.

About Extended Time for English as a Second Language

If English is not your first language, you can request Extended Time when registering for the exam, adding 30 minutes (total: 160 minutes). This must be requested before scheduling — you cannot add it on exam day.

The Four Exam Domains

The exam content is divided into four domains with specific percentage weights:

pie title SAA-C03 Exam Domain Weights
    "Domain 1: Design Secure Architectures" : 30
    "Domain 2: Design Resilient Architectures" : 26
    "Domain 3: Design High-Performing Architectures" : 24
    "Domain 4: Design Cost-Optimized Architectures" : 20

Domain 1: Design Secure Architectures (30%)

This is the largest domain and carries the most weight. Security is the top priority on the exam.

Task 1.1: Design Secure Access to AWS Resources

Knowledge areas:

• Access controls and management across multiple accounts
• AWS federated access and identity services (IAM, AWS IAM Identity Center / SSO)
• AWS global infrastructure (Availability Zones, Regions) in a security context
• AWS security best practices, especially the principle of least privilege
• The AWS Shared Responsibility Model

Skills required:

• Applying security best practices to IAM users and root users (e.g., enabling MFA on all accounts, never using root for daily tasks)
• Designing a flexible authorization model using IAM users, groups, roles, and policies
• Designing a role-based access control (RBAC) strategy using:
  • AWS Security Token Service (AWS STS) for temporary credentials
  • Role switching and cross-account access (IAM Roles)
• Designing a security strategy for multiple AWS accounts using:
  • AWS Control Tower (landing zone setup and governance)
  • AWS Organizations and Service Control Policies (SCPs) to enforce guardrails
• Determining the appropriate use of resource-based policies vs. identity-based policies
• Knowing when to federate a directory service (e.g., Active Directory) with IAM Roles using SAML or OIDC

Task 1.2: Design Secure Workloads and Applications

Knowledge areas:

• Application configuration and credentials security (AWS Secrets Manager, AWS Systems Manager Parameter Store)
• AWS service endpoints (VPC endpoints to avoid public internet)
• Controlling ports, protocols, and network traffic on AWS
• Secure application access patterns
• Security services with appropriate use cases:
  • Amazon Cognito — User authentication for web and mobile apps
  • Amazon GuardDuty — Intelligent threat detection using ML
  • Amazon Macie — Automatically discovers and protects sensitive data in S3
• Threat vectors external to AWS:
  • DDoS attacks — Use AWS Shield (Standard free, Advanced paid) and AWS WAF
  • SQL injection / XSS — Use AWS WAF

Skills required:

• Designing VPC architectures with security components:
  • Security Groups (stateful, instance-level firewall)
  • Network ACLs (stateless, subnet-level firewall)
  • Route tables
  • NAT Gateways (allow private subnet outbound internet access without exposure)
• Determining network segmentation strategies using public subnets (for ALBs, NAT gateways, bastion hosts) and private subnets (for application servers, databases)
• Integrating security services:
  • AWS Shield for DDoS protection
  • AWS WAF for web application firewall rules
  • IAM Identity Center for SSO
  • AWS Secrets Manager for credential rotation
• Securing external connections:
  • AWS Site-to-Site VPN — encrypted tunnel between on-premises and AWS
  • AWS Direct Connect — dedicated private network connection (not encrypted by default; combine with VPN for encryption)

Task 1.3: Determine Appropriate Data Security Controls

Knowledge areas:

• Data access and governance
• Data recovery procedures
• Data retention and classification policies
• Encryption and key management

Skills required:

• Aligning AWS technologies to compliance requirements (HIPAA, PCI-DSS, SOC2, GDPR)
• Encrypting data at rest using AWS Key Management Service (AWS KMS) — customer managed keys (CMK) or AWS managed keys
• Encrypting data in transit using TLS/HTTPS certificates from AWS Certificate Manager (ACM)
• Implementing access policies for encryption keys (key policies, grants)
• Implementing data backups and replications (S3 Cross-Region Replication, RDS snapshots, AWS Backup)
• Implementing lifecycle policies for data access and retention (S3 Lifecycle rules, Object Lock)
• Rotating encryption keys and renewing certificates (automatic rotation in KMS and ACM)

Domain 2: Design Resilient Architectures (26%)

Task 2.1: Design Scalable and Loosely Coupled Architectures

Loose coupling means components are independent — if one fails, others are not directly affected.

Knowledge areas:

• API creation and management: Amazon API Gateway, REST APIs, HTTP APIs
• AWS managed services: AWS Transfer Family, Amazon SQS, AWS Secrets Manager
• Caching strategies: ElastiCache (Redis/Memcached), DynamoDB Accelerator (DAX), CloudFront
• Microservices design principles: stateless vs. stateful workloads
• Event-driven architectures: SNS (pub/sub), SQS (message queuing), EventBridge (event bus)
• Horizontal vs. vertical scaling:
  • Horizontal: Add more instances (scale out) — preferred for cloud
  • Vertical: Increase instance size (scale up) — limited by max instance size, causes downtime
• Edge accelerators: CloudFront (CDN), AWS Global Accelerator
• Containerization: When to migrate applications into containers
• Load balancing: Application Load Balancer (Layer 7 / HTTP/HTTPS), Network Load Balancer (Layer 4 / TCP/UDP), Gateway Load Balancer (Layer 3 / network appliances)
• Multi-tier architectures: Web tier (public), application tier (private), data tier (private)
• Queuing and messaging: SNS for push/subscribe, SQS for decoupled queue-based processing
• Serverless: AWS Lambda (event-driven functions), AWS Fargate (serverless containers)
• Storage types:
  • Object: Amazon S3 (unstructured data, files, backups)
  • File: Amazon EFS (shared NFS file system), Amazon FSx
  • Block: Amazon EBS (attached to EC2, like a hard drive)
• Container orchestration: Amazon ECS (AWS-native), Amazon EKS (Kubernetes)
• Read replicas: for offloading read traffic from primary databases
• Workflow orchestration: AWS Step Functions (coordinate distributed components)

Skills required:

• Designing event-driven, microservice, and multi-tier architectures
• Determining scaling strategies for each component
• Determining when to use containers vs. serverless vs. traditional EC2
• Recommending appropriate compute, storage, networking, and database services based on scenario requirements

Task 2.2: Design Highly Available and/or Fault-Tolerant Architectures

Knowledge areas:

• AWS global infrastructure in the context of HA/FT design
• Disaster recovery strategies:
  • Backup and restore: Lowest cost, highest RTO/RPO
  • Pilot light: Core components always running, scale on failure
  • Warm standby: Scaled-down copy always running
  • Active-active multi-site failover: Full capacity in 2+ regions
• Distributed design patterns
• Failover strategies
• Immutable infrastructure (replace instead of patch)
• Load balancing
• Proxy concepts (Amazon RDS Proxy — manages database connection pooling)
• Service quotas and throttling
• Storage options: durability, replication
• Workload visibility: AWS X-Ray for distributed tracing

Skills required:

• Automating infrastructure integrity (CloudFormation, Systems Manager)
• Providing HA/FT across Regions and AZs
• Identifying metrics to measure availability requirements
• Implementing designs that eliminate single points of failure
• Implementing data durability strategies (backups, cross-region replication)
• Selecting the appropriate DR strategy given RTO/RPO requirements
• Improving reliability of legacy applications using AWS services without application changes

Domain 3: Design High-Performing Architectures (24%)

Task 3.1: High-Performing and Scalable Storage

Knowledge areas:

• Hybrid storage solutions (AWS Storage Gateway, AWS DataSync)
• Storage services:
  • Amazon S3 — Object storage, virtually unlimited scale, 11 9s durability
  • Amazon EFS — Elastic NFS file system, shared access, auto-scaling
  • Amazon EBS — Block storage attached to EC2 instances
• Storage types (object, file, block) and their characteristics

Skills: Selecting the right storage service and configuration based on performance demands and scalability requirements.

Task 3.2: High-Performing and Elastic Compute

Knowledge areas:

• AWS compute services:
  • AWS Batch — for batch computing jobs
  • Amazon EMR — for big data (Hadoop/Spark) processing
  • AWS Fargate — serverless containers
  • AWS Lambda — serverless functions
• Distributed computing concepts
• Scalability capabilities:
  • Amazon EC2 Auto Scaling — automatically adjust EC2 fleet size
  • AWS Auto Scaling — scaling for multiple resource types
• Container orchestration: ECS, EKS

Skills:

• Decoupling workloads so components scale independently
• Identifying the right EC2 instance type and size for a workload:
  • General purpose: M, T families
  • Compute optimized: C family (CPU-intensive)
  • Memory optimized: R, X, Z families (in-memory databases, big data)
  • Storage optimized: I, D, H families (high IOPS, large data sets)
  • Accelerated computing: P, G, F families (GPU, machine learning, FPGA)
• Selecting the appropriate Lambda memory/timeout configuration

Task 3.3: High-Performing Database Solutions

Knowledge areas:

• Caching strategies:
  • Amazon ElastiCache — Redis (persistent, pub/sub, sorted sets) or Memcached (simple, multi-threaded)
  • DynamoDB Accelerator (DAX) — in-memory cache specific to DynamoDB
• Data access patterns: read-heavy vs. write-heavy (influences caching and read replica strategy)
• Database capacity planning: capacity units, instance types, Provisioned IOPS
• Database connections and proxies (Amazon RDS Proxy for connection pooling)
• Database engines: MySQL, PostgreSQL, Oracle, SQL Server, MariaDB
• Database replication: read replicas (async, for read scaling), Multi-AZ standby (sync, for HA)
• Database types:
  • Relational/SQL: Amazon RDS, Amazon Aurora
  • Non-relational/NoSQL: Amazon DynamoDB (key-value/document)
  • In-memory: Amazon ElastiCache
  • Graph: Amazon Neptune
  • Ledger: Amazon QLDB
  • Time-series: Amazon Timestream
  • Document: Amazon DocumentDB (MongoDB-compatible)
  • Wide-column: Amazon Keyspaces (Cassandra-compatible)

Skills:

• Choosing between Amazon Aurora and Amazon RDS:
  • Aurora: AWS-built, 5x faster than MySQL, 3x faster than PostgreSQL, auto-storage scaling to 128TB, 6-way replication across 3 AZs, better HA
  • RDS: Managed but standard database engines, simpler use cases
• Choosing between relational and non-relational databases
• Integrating caching layers to reduce database load and latency

Task 3.4: High-Performing Network Architectures

Knowledge areas:

• Edge networking services:
  • Amazon CloudFront — Global CDN; cache content at edge locations; reduces origin load
  • AWS Global Accelerator — Routes traffic through AWS backbone for improved global latency; uses Anycast IPs
• Network architecture design: subnet tiers, routing, IP addressing
• Load balancing: ALB (HTTP/HTTPS, Layer 7), NLB (TCP/UDP, Layer 4), GLB (Layer 3, network appliances)
• Network connections:
  • AWS Site-to-Site VPN — IPSec encrypted tunnel, over public internet, quick to set up
  • AWS Direct Connect — Dedicated private fiber connection, consistent latency, not encrypted by default
  • AWS PrivateLink — Private connectivity to services without internet exposure, uses VPC endpoints

Skills:

• Creating appropriate network topologies for global, hybrid, and multi-tier architectures
• Placing resources in the correct subnets (public vs. private)
• Selecting the right load balancing strategy for the workload
• Designing network architecture that scales with demand

Task 3.5: High-Performing Data Ingestion and Transformation

Knowledge areas:

• Data analytics and visualization:
  • Amazon Athena — Serverless SQL queries directly on S3 data
  • AWS Lake Formation — Build, secure, and manage data lakes
  • Amazon QuickSight — Business intelligence dashboards and visualizations
  • Amazon Redshift — Petabyte-scale data warehouse
• Data ingestion patterns: batch vs. streaming, frequency
• Data transfer services:
  • AWS DataSync — Automated data transfer between on-premises and AWS (or between AWS services)
  • AWS Storage Gateway — Hybrid storage integration between on-premises and AWS
• Data transformation:
  • AWS Glue — Serverless ETL (Extract, Transform, Load) service with data catalog
• Streaming data:
  • Amazon Kinesis Data Streams — Real-time data streaming
  • Amazon Kinesis Data Firehose — Loads streaming data into S3, Redshift, Elasticsearch, Splunk
  • Amazon MSK (Managed Streaming for Apache Kafka) — Managed Kafka service

Skills:

• Building and securing data lakes on S3 with Lake Formation
• Designing data streaming architectures using Kinesis or MSK
• Implementing ETL pipelines with Glue
• Selecting correct compute for data processing (EMR for Spark/Hadoop)
• Transforming data between formats (e.g., .csv to .parquet for columnar efficiency)

Domain 4: Design Cost-Optimized Architectures (20%)

Task 4.1: Cost-Optimized Storage

Knowledge areas:

• S3 access options: Requester Pays, Transfer Acceleration
• AWS cost management tools:
  • AWS Cost Explorer — Visualize and analyze costs over time
  • AWS Budgets — Set budget alerts and thresholds
  • AWS Cost and Usage Report (CUR) — Most detailed billing data
• Storage services by cost profile:
  • S3 Standard — Frequent access, highest cost
  • S3 Standard-IA (Infrequent Access) — Lower storage cost, retrieval fee
  • S3 One Zone-IA — Single AZ, lower cost, less durability
  • S3 Glacier Instant Retrieval — Archive, millisecond retrieval
  • S3 Glacier Flexible Retrieval — Archive, minutes to hours retrieval
  • S3 Glacier Deep Archive — Lowest cost, 12-hour retrieval
  • S3 Intelligent-Tiering — Auto-moves objects between tiers based on access patterns
  • Amazon FSx — Managed Windows File Server or Lustre
  • Amazon EFS — Elastic NFS, pay for what you use
  • Amazon EBS — gp3 (SSD general purpose), io2 (provisioned IOPS SSD), st1 (throughput-optimized HDD), sc1 (cold HDD)
• Backup strategies and data lifecycle policies
• Hybrid storage: DataSync, Transfer Family, Storage Gateway

Skills:

• Selecting appropriate S3 storage class for each use case
• Implementing S3 Lifecycle policies to automatically transition objects to cheaper tiers
• Right-sizing EBS volumes
• Choosing the most cost-effective migration path to AWS storage

Task 4.2: Cost-Optimized Compute

Knowledge areas:

• AWS purchasing options:
  • On-Demand Instances — Pay per second/hour, no commitment, highest per-unit cost
  • Reserved Instances (RIs) — 1 or 3 year commitment, up to 75% discount vs. on-demand. Standard RI (highest discount, can’t change instance type) vs. Convertible RI (can change instance type)
  • Savings Plans — Flexible commitment to $/hour spend, covers EC2, Lambda, Fargate
  • Spot Instances — Bid on unused AWS capacity, up to 90% discount, can be interrupted with 2-minute warning. Best for fault-tolerant, stateless, batch workloads
• Instance types, families, and sizes
• Scaling strategies: Auto Scaling (horizontal), EC2 hibernation
• Hybrid compute: AWS Outposts (AWS hardware in your data center), AWS Snowball Edge

Skills:

• Choosing the right load balancer type for cost:
  • ALB (Layer 7) — Best for HTTP/HTTPS web applications, rules-based routing
  • NLB (Layer 4) — Best for TCP/UDP, extreme performance, static IPs
  • GLB (Layer 3) — For network appliances (firewalls, IDS/IPS)
• Selecting appropriate scaling methods: horizontal (add instances) vs. vertical (bigger instance)
• Choosing cost-effective compute:
  • Lambda — Best for short-lived, event-driven functions (max 15 minutes)
  • Fargate — Serverless containers, pay per vCPU/memory per second
  • EC2 — Best when you need full control or long-running processes
• Understanding availability requirements: production (higher availability = more cost) vs. non-production (can tolerate more downtime = lower cost)

Task 4.3: Cost-Optimized Database Solutions

Knowledge areas:

• Cost management for databases
• Caching to reduce database query load (ElastiCache, DAX)
• Data retention policies (set TTL, archive old data to S3/Glacier)
• Database capacity planning: DynamoDB on-demand vs. provisioned capacity
• Database connections: RDS Proxy to reduce connection overhead
• Database types and cost profiles:
  • DynamoDB — Pay per request (on-demand) or provisioned capacity units. No infrastructure to manage.
  • Amazon RDS — Pay for instance type + storage + I/O. Multi-AZ doubles instance cost.
  • Aurora Serverless — Scales compute capacity up and down automatically, pay per ACU-second
  • Aurora Standard — Fixed instance cost, better for predictable workloads

Skills:

• Choosing DynamoDB vs. RDS based on cost requirements (DynamoDB is often cheaper for variable, spiky workloads; RDS is often cheaper for steady-state relational workloads)
• Designing backup policies that balance retention with cost (snapshot frequency, lifecycle)
• Migrating database schemas and data using AWS DMS (Database Migration Service) for cost savings (e.g., migrating from expensive commercial DB to open-source)

Task 4.4: Cost-Optimized Network Architectures

Knowledge areas:

• NAT gateways:
  • NAT Gateway — Managed, highly available, charged per hour + per GB processed
  • NAT Instance — Self-managed EC2, cheaper but requires management, single AZ by default
  • For multi-AZ cost optimization: deploy one NAT Gateway per AZ (avoids cross-AZ data transfer charges)
• Network connectivity options and costs:
  • Internet — Free incoming, pay for outgoing data transfer
  • VPN — Low cost, encrypted, variable latency
  • Direct Connect — Higher setup cost, lower per-GB data transfer costs at scale, consistent latency
• Network routing to minimize data transfer costs:
  • Data transfer within the same AZ via private IP: free
  • Data transfer between AZs in the same Region: small charge per GB
  • Data transfer between Regions: higher charge per GB
  • Data transfer out to the internet: per GB charge
• VPC endpoints (Gateway endpoints for S3/DynamoDB are free; Interface endpoints via PrivateLink have per-hour + per-GB charges)
• AWS Transit Gateway vs. VPC peering:
  • VPC Peering — Simple 1:1 connection, no additional charge per hour (pay only data transfer), non-transitive
  • Transit Gateway — Hub-and-spoke, connects many VPCs and on-premises networks, attachment fee per hour + data processing

Skills:

• Configuring NAT gateway placement appropriately for cost and availability
• Selecting between Direct Connect, VPN, and internet for external connectivity based on cost and performance requirements
• Using VPC endpoints to avoid internet gateway charges for S3 and DynamoDB
• Minimizing cross-AZ and cross-Region data transfer to reduce costs
• Leveraging CloudFront to reduce origin data transfer costs (edge caching)

Exam Strategy and Tips

Tip 1: Get Hands-On Practice

Practical experience is the single most effective preparation method. Reading and watching videos builds familiarity, but hands-on labs build deep understanding. When you actually deploy infrastructure and encounter errors, you learn far more than from passive study.

Use hands-on labs covering key services and concepts like:

• IAM roles and policies
• VPC design with public and private subnets
• EC2 Auto Scaling Groups behind an ALB
• S3 bucket policies, versioning, and replication
• RDS Multi-AZ and read replicas
• Lambda functions triggered by SQS
• CloudFormation stacks
• CloudTrail and CloudWatch monitoring

Tip 2: Use Keyword Indicators to Eliminate Wrong Answers

Every exam scenario contains specific keyword clues that tell you which services and concepts apply. Train yourself to spot these:

Tip 3: Eliminate Obviously Wrong Answers First

For every question, immediately eliminate answers that you know are clearly incorrect. This narrows your choices and increases the probability that your final answer is correct.

Example: If a question asks for a NoSQL solution, immediately eliminate any answer that mentions Amazon RDS (a relational database). If a question requires a managed service with no server management, eliminate answers involving EC2 instances.

Tip 4: Flag Difficult Questions and Revisit

Do not get stuck on a hard question. The strategy that works best:

1. Read the question carefully.
2. If you know the answer confidently, select it and move on.
3. If you’re unsure, make your best guess, flag the question for review, and move on immediately.
4. After answering all 65 questions, go back and review flagged questions.
5. This ensures you don’t run out of time before answering easy questions just because a hard one slowed you down.

Never leave a question blank. There is no penalty for guessing — wrong and blank answers both score zero. An educated guess gives you at least a chance.

Tip 5: Hold Yourself Accountable — Schedule and Commit

The most effective preparation strategy:

1. Set an exam date first. This creates a deadline and prevents indefinite preparation without taking the exam.
2. Plan your study schedule around that date. Work backward from the exam date to create a realistic study plan.
3. Stick to your schedule. Don’t reschedule unless absolutely necessary. Repeated rescheduling often leads to exam avoidance.

130 minutes for 65 questions = approximately 2 minutes per question. This is sufficient time if you manage it well, but reading long scenario paragraphs takes time. Pace yourself.

How to Schedule Your Exam

Step-by-Step Process:

2. Sign in using your AWS Builder ID (create one if you don’t have one). This is separate from your AWS Management Console credentials.
3. Under Exam Registration, click Schedule an exam.
4. Find SAA-C03 in the list and click Schedule.
5. Review the exam information and select your delivery method:
   • Pearson OnVUE (Online) — Take the exam at home or a quiet location using your own computer.
   • Test Center (In Person) — Take the exam at a Pearson VUE authorized testing center near you.
6. Select your preferred language (English or other available languages).
7. Review and accept the exam policies (read these carefully).
8. Choose your proctor language preference.
9. Select your time zone, date, and time slot.
10. Review your cart and proceed to checkout (~$150 USD).

Online vs. In-Person: Recommendation

In-person at a test center is generally recommended because:

• The environment is consistently set up for test-taking (quiet, correct hardware, reliable internet).
• No need to prepare your home environment to meet strict requirements.
• Lower risk of technical issues (internet drops, camera failures, background interruptions).

Online proctoring requirements (if you take it remotely):

• A working webcam (required — proctors must see your face throughout)
• A working microphone (required — proctors must be able to communicate with you)
• Your screen is recorded for the duration of the exam
• Single monitor only (additional monitors must be disconnected)
• Clear desk — nothing else on your desk
• Quiet, private room with no other people present

Exam Policies and Requirements

When scheduling online:

• Enable MFA on your AWS Builder ID account for security.
• Read all the exam policies during the scheduling process — they cover data processing, recording consent, and testing space requirements.
• Arrive (or log in) at least 15 minutes early.
• Have a valid government-issued photo ID ready.

Appendix A: In-Scope AWS Services and Features

The following services are in scope for the SAA-C03 exam. This list should guide your study priorities.

Analytics

• Amazon Athena
• AWS Data Exchange
• AWS Data Pipeline
• Amazon EMR
• AWS Glue
• Amazon Kinesis
• AWS Lake Formation
• Amazon Managed Streaming for Apache Kafka (Amazon MSK)
• Amazon OpenSearch Service
• Amazon QuickSight
• Amazon Redshift

Application Integration

• Amazon AppFlow
• AWS AppSync
• Amazon EventBridge
• Amazon MQ
• Amazon Simple Notification Service (Amazon SNS)
• Amazon Simple Queue Service (Amazon SQS)
• AWS Step Functions

AWS Cost Management

• AWS Budgets
• AWS Cost and Usage Report
• AWS Cost Explorer
• Savings Plans

Compute

• AWS Batch
• Amazon EC2
• Amazon EC2 Auto Scaling
• AWS Elastic Beanstalk
• AWS Outposts
• AWS Serverless Application Repository
• VMware Cloud on AWS
• AWS Wavelength

Containers

• Amazon ECS Anywhere
• Amazon EKS Anywhere
• Amazon EKS Distro
• Amazon Elastic Container Registry (Amazon ECR)
• Amazon Elastic Container Service (Amazon ECS)
• Amazon Elastic Kubernetes Service (Amazon EKS)

Database

• Amazon Aurora
• Amazon Aurora Serverless
• Amazon DocumentDB (with MongoDB compatibility)
• Amazon DynamoDB
• Amazon ElastiCache
• Amazon Keyspaces (for Apache Cassandra)
• Amazon Neptune
• Amazon Quantum Ledger Database (Amazon QLDB)
• Amazon RDS
• Amazon Redshift

Developer Tools

• AWS X-Ray

Front-End Web and Mobile

• AWS Amplify
• Amazon API Gateway
• AWS Device Farm
• Amazon Pinpoint

Machine Learning

• Amazon Comprehend
• Amazon Forecast
• Amazon Fraud Detector
• Amazon Kendra
• Amazon Lex
• Amazon Polly
• Amazon Rekognition
• Amazon SageMaker
• Amazon Textract
• Amazon Transcribe
• Amazon Translate

Management and Governance

• AWS Auto Scaling
• AWS CloudFormation
• AWS CloudTrail
• Amazon CloudWatch
• AWS Command Line Interface (AWS CLI)
• AWS Compute Optimizer
• AWS Config
• AWS Control Tower
• AWS Health Dashboard
• AWS License Manager
• Amazon Managed Grafana
• Amazon Managed Service for Prometheus
• AWS Management Console
• AWS Organizations
• AWS Proton
• AWS Service Catalog
• AWS Systems Manager
• AWS Trusted Advisor
• AWS Well-Architected Tool

Media Services

• Amazon Elastic Transcoder
• Amazon Kinesis Video Streams

Migration and Transfer

• AWS Application Discovery Service
• AWS Application Migration Service
• AWS Database Migration Service (AWS DMS)
• AWS DataSync
• AWS Migration Hub
• AWS Snow Family
• AWS Transfer Family

Networking and Content Delivery

• AWS Client VPN
• Amazon CloudFront
• AWS Direct Connect
• Elastic Load Balancing (ELB)
• AWS Global Accelerator
• AWS PrivateLink
• Amazon Route 53
• AWS Site-to-Site VPN
• AWS Transit Gateway
• Amazon VPC

Security, Identity, and Compliance

• AWS Artifact
• AWS Audit Manager
• AWS Certificate Manager (ACM)
• AWS CloudHSM
• Amazon Cognito
• Amazon Detective
• AWS Directory Service
• AWS Firewall Manager
• Amazon GuardDuty
• AWS IAM Identity Center (AWS Single Sign-On)
• AWS Identity and Access Management (IAM)
• Amazon Inspector
• AWS Key Management Service (AWS KMS)
• Amazon Macie
• AWS Network Firewall
• AWS Resource Access Manager (AWS RAM)
• AWS Secrets Manager
• AWS Security Hub
• AWS Shield
• AWS WAF

Serverless

• AWS AppSync
• AWS Fargate
• AWS Lambda

Storage

• AWS Backup
• Amazon Elastic Block Store (Amazon EBS)
• Amazon Elastic File System (Amazon EFS)
• Amazon FSx (for all types)
• Amazon S3
• Amazon S3 Glacier
• AWS Storage Gateway

Appendix B: Out-of-Scope AWS Services and Features

The following services are explicitly out of scope for the SAA-C03 exam. You do not need to study these.

Appendix C: Recommended Hands-On Labs

The following hands-on labs are recommended to build practical experience aligned with the SAA-C03 exam domains. Working through these labs will reinforce concepts covered throughout this course and the broader learning path.

Appendix D: Important Reference Links

Document compiled from the SAA-C03 Certification Essentials course. Covers: Module 1 — The AWS Global Footprint; Module 2 — The Shared Responsibility Model and Well-Architected Framework; Module 3 — Installing and Configuring the AWS CLI; Module 4 — What to Expect on the Exam. Exam Guide Version 1.1 SAA-C03.

Search Terms

aws · certified · architect · associate · saa-c03 · certification · essentials · core · services · amazon · web · task · architectures · design · exam · high-performing · pillar · cost-optimized · security · domain · recovery · availability · cli · cloud