Multiple-choice
Question type with one correct answer from several options.
Getting Started: Exam Essentials
Free knowledge base
AWS Certified Solutions Architect – Associate (SAA-C03) — key terms, tricks & tips
Everything from the course in one searchable place: 219 entries. Use it to review before a practice test or look up a word you forgot.
219 results
Multiple-response
Question type requiring selection of two or more correct answers.
Getting Started: Exam Essentials
Passing score
The minimum score (720) required to pass the SAA-C03 exam.
Getting Started: Exam Essentials
Exam domain
A major topic area covered by the exam, with specific weighting.
Getting Started: Exam Essentials
Retake policy
Rules governing reattempting an exam after a failed attempt.
Getting Started: Exam Essentials
Proctored exam
An exam supervised by an authorized individual (in-person or online).
Getting Started: Exam Essentials
Score report
Document detailing overall score and performance by domain.
Getting Started: Exam Essentials
Understanding the SAA-C03 Exam Format
To remember the domain weights: Secure (30) is the Big Boss. Resilient (26) is Right Behind. High-Performing (24) is Hot on the Heels. Cost-Optimized (20) is Catching Up.
Getting Started: Exam Essentials
Understanding the SAA-C03 Exam Format
The SAA-C03 exam has 65 questions, a 130-minute duration, and a passing score of 720. Memorize the four domains and their approximate weightings.
Getting Started: Exam Essentials
Understanding the SAA-C03 Exam Format
Not reading multiple-response questions carefully and only selecting one answer.
Getting Started: Exam Essentials
Understanding the SAA-C03 Exam Format
Not managing time effectively, leading to rushed answers or unanswered questions.
Getting Started: Exam Essentials
Understanding the SAA-C03 Exam Format
Ignoring the domain weightings and spending too much time on less impactful topics.
Getting Started: Exam Essentials
AWS Well-Architected Framework
A set of best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud.
Getting Started: Exam Essentials
AWS Free Tier
Allows new AWS customers to explore and try out AWS services free of charge up to certain limits.
Getting Started: Exam Essentials
S3 Lifecycle Policies
Rules to automate the movement of objects between S3 storage classes or their expiration.
Getting Started: Exam Essentials
Availability Zone (AZ)
One or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.
Getting Started: Exam Essentials
Application Load Balancer (ALB)
Distributes incoming application traffic across multiple targets, such as EC2 instances.
Getting Started: Exam Essentials
AWS Skill Builder
AWS's online learning center offering digital training and certification preparation.
Getting Started: Exam Essentials
Effective Study Strategies & Resources for SAA-C03
To remember the Well-Architected Framework pillars, think 'SCOOP-R': Security, Cost Optimization, Operational Excellence, Performance Efficiency, Reliability.
Getting Started: Exam Essentials
Effective Study Strategies & Resources for SAA-C03
The SAA-C03 exam heavily tests your understanding of the AWS Well-Architected Framework's five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. Memorize these pillars and be ready to identify solutions that align with each one.
Getting Started: Exam Essentials
Effective Study Strategies & Resources for SAA-C03
Only memorizing definitions without understanding how services interact.
Getting Started: Exam Essentials
Effective Study Strategies & Resources for SAA-C03
Neglecting hands-on practice in favor of purely theoretical study.
Getting Started: Exam Essentials
Effective Study Strategies & Resources for SAA-C03
Not reviewing the official AWS Exam Guide and whitepapers.
Getting Started: Exam Essentials
IAM User
An entity representing a person or application with permanent credentials.
Module 1: Designing Secure Architectures
IAM Group
A collection of IAM users that share the same permissions.
Module 1: Designing Secure Architectures
IAM Role
An identity with temporary permissions for AWS services or federated users.
Module 1: Designing Secure Architectures
IAM Policy
A JSON document defining permissions for AWS actions and resources.
Module 1: Designing Secure Architectures
AWS Organizations
Service for centrally managing and governing multiple AWS accounts.
Module 1: Designing Secure Architectures
Service Control Policy (SCP)
A policy that defines the maximum permissions for accounts in an OU.
Module 1: Designing Secure Architectures
Principle of Least Privilege
Granting only the necessary permissions to perform a task.
Module 1: Designing Secure Architectures
Multi-Factor Authentication (MFA)
An extra layer of security requiring two or more verification factors.
Module 1: Designing Secure Architectures
IAM, Organizations & Account Security Best Practices
Users Get Roles, Policies Rule! (Users go into Groups, assume Roles, and Policies define what they can do and rule over everything).
Module 1: Designing Secure Architectures
IAM, Organizations & Account Security Best Practices
The exam frequently tests the difference between IAM Users, Groups, and Roles, and when to use each. Pay close attention to scenario questions involving temporary vs. permanent credentials and service-to-service communication. Remember that SCPs are preventative and apply to all entities in an account, including the root user, but do not grant permissions themselves.
Module 1: Designing Secure Architectures
IAM, Organizations & Account Security Best Practices
Using the root account for daily administrative tasks instead of a dedicated IAM user.
Module 1: Designing Secure Architectures
IAM, Organizations & Account Security Best Practices
Embedding AWS access keys directly into application code, leading to potential security breaches if the code is exposed.
Module 1: Designing Secure Architectures
IAM, Organizations & Account Security Best Practices
Granting overly broad permissions (e.g., AdministratorAccess) when only specific actions are needed, violating the principle of least privilege.
Module 1: Designing Secure Architectures
VPC
Logically isolated section of the AWS Cloud where you launch resources.
Module 1: Designing Secure Architectures
Subnet
A range of IP addresses in your VPC; can be public or private.
Module 1: Designing Secure Architectures
Security Group
Stateful, instance-level virtual firewall controlling traffic.
Module 1: Designing Secure Architectures
NACL
Stateless, subnet-level virtual firewall controlling traffic.
Module 1: Designing Secure Architectures
Stateful Firewall
Remembers connection state; return traffic is automatically allowed.
Module 1: Designing Secure Architectures
Stateless Firewall
Does not remember connection state; both directions must be explicitly allowed.
Module 1: Designing Secure Architectures
AWS WAF
Web Application Firewall protecting web applications from common exploits.
Module 1: Designing Secure Architectures
Network Security: VPC, Security Groups, NACLs, WAF
VPC: 'V'ery 'P'rivate 'C'loud. NACL: 'N'o 'A'llow 'C'onnections 'L'ightly (stateless). Security Group: 'S'ecure 'G'uard (stateful).
Module 1: Designing Secure Architectures
Network Security: VPC, Security Groups, NACLs, WAF
The exam frequently tests the difference between Security Groups and NACLs. Remember: Security Groups are stateful and instance-level; NACLs are stateless and subnet-level. Pay attention to keywords like 'instance-specific' vs. 'subnet-wide' and 'allow only' vs. 'allow and deny rules'.
Module 1: Designing Secure Architectures
Network Security: VPC, Security Groups, NACLs, WAF
Confusing Security Groups (stateful, instance) with NACLs (stateless, subnet).
Module 1: Designing Secure Architectures
Network Security: VPC, Security Groups, NACLs, WAF
Not configuring both inbound and outbound rules for NACLs, leading to unexpected traffic blocks.
Module 1: Designing Secure Architectures
Network Security: VPC, Security Groups, NACLs, WAF
Over-permissive Security Group rules (e.g., allowing all traffic from 0.0.0.0/0 on all ports) which creates security vulnerabilities.
Module 1: Designing Secure Architectures
Encryption
Transforming data into an unreadable format to protect confidentiality.
Module 1: Designing Secure Architectures
Client-Side Encryption
Data encrypted by the client before sending to an AWS service.
Module 1: Designing Secure Architectures
Server-Side Encryption
Data encrypted by the AWS service before writing to disk.
Module 1: Designing Secure Architectures
AWS KMS
Managed service for creating and controlling encryption keys using HSMs.
Module 1: Designing Secure Architectures
Customer Master Key (CMK)
Primary logical encryption key in KMS, managed by the customer.
Module 1: Designing Secure Architectures
AWS CloudHSM
Dedicated, FIPS 140-2 Level 3 validated hardware security modules (HSMs).
Module 1: Designing Secure Architectures
Symmetric Key
Same key used for both encryption and decryption.
Module 1: Designing Secure Architectures
Asymmetric Key
Different keys (public/private) for encryption and decryption.
Module 1: Designing Secure Architectures
Data Encryption & Key Management (KMS, CloudHSM)
KMS is 'Key Management Simplicity' (managed, easy). CloudHSM is 'Cloud Hardware, So Much Management' (dedicated, complex).
Module 1: Designing Secure Architectures
Data Encryption & Key Management (KMS, CloudHSM)
The exam often tests the difference between KMS and CloudHSM. Remember that KMS is a managed service with shared HSMs (FIPS 140-2 Level 2), while CloudHSM provides dedicated HSMs (FIPS 140-2 Level 3) where you have exclusive control and management responsibility.
Module 1: Designing Secure Architectures
Data Encryption & Key Management (KMS, CloudHSM)
Confusing KMS with CloudHSM: KMS is a managed service, CloudHSM gives you direct control over dedicated HSMs.
Module 1: Designing Secure Architectures
Data Encryption & Key Management (KMS, CloudHSM)
Assuming all AWS services encrypt data by default: Many services offer encryption options, but it's often not enabled by default or requires configuration.
Module 1: Designing Secure Architectures
Data Encryption & Key Management (KMS, CloudHSM)
Underestimating the operational overhead of CloudHSM: It requires significant management effort compared to KMS.
Module 1: Designing Secure Architectures
AWS CloudTrail
Records API calls and events in your AWS account for auditing.
Module 1: Designing Secure Architectures
Amazon CloudWatch
Monitors AWS resources and applications; collects logs, metrics, events.
Module 1: Designing Secure Architectures
Amazon GuardDuty
Managed threat detection service using machine learning and threat intelligence.
Module 1: Designing Secure Architectures
Management Events
Operations performed on resources in your AWS account (e.g., creating an EC2 instance).
Module 1: Designing Secure Architectures
Data Events
Operations performed on data within a resource (e.g., S3 object-level API activity).
Module 1: Designing Secure Architectures
VPC Flow Logs
Captures information about IP traffic going to and from network interfaces in a VPC.
Module 1: Designing Secure Architectures
CloudWatch Alarms
Triggers actions when a metric crosses a predefined threshold.
Module 1: Designing Secure Architectures
Security Finding
An alert generated by GuardDuty indicating potential malicious activity.
Module 1: Designing Secure Architectures
Logging, Monitoring & Auditing (CloudTrail, CloudWatch, GuardDuty)
To remember the core functions: 'C'loudTrail for 'C'hanges (audit trail), 'C'loudWatch for 'C'onditions (metrics/alarms), 'G'uardDuty for 'G'uarding (threat detection).
Module 1: Designing Secure Architectures
Logging, Monitoring & Auditing (CloudTrail, CloudWatch, GuardDuty)
The exam frequently tests your ability to choose the correct service for a given scenario. Remember: CloudTrail is for 'who did what,' CloudWatch is for 'what is happening now' (metrics, logs, alarms), and GuardDuty is for 'is there a threat.'
Module 1: Designing Secure Architectures
Logging, Monitoring & Auditing (CloudTrail, CloudWatch, GuardDuty)
Confusing CloudTrail with CloudWatch Logs: CloudTrail generates the logs of API calls; CloudWatch Logs is a destination for those logs (among others) for storage and analysis.
Module 1: Designing Secure Architectures
Logging, Monitoring & Auditing (CloudTrail, CloudWatch, GuardDuty)
Assuming GuardDuty replaces other security services: GuardDuty enhances security by detecting threats, but it doesn't replace the need for firewalls (Security Groups/NACLs) or vulnerability scanning.
Module 1: Designing Secure Architectures
Logging, Monitoring & Auditing (CloudTrail, CloudWatch, GuardDuty)
Not enabling CloudTrail in all regions: For a comprehensive audit trail, CloudTrail should be configured to log events across all regions, even those not actively used, to catch unauthorized activity.
Module 1: Designing Secure Architectures
Scalability
Ability to handle increasing workload by adding resources.
Module 2: Designing Resilient Architectures
Elasticity
Automatic adjustment of resources to match current demand.
Module 2: Designing Resilient Architectures
Auto Scaling Group (ASG)
Collection of EC2 instances for automatic scaling and management.
Module 2: Designing Resilient Architectures
Elastic Load Balancing (ELB)
Distributes incoming traffic across multiple targets.
Module 2: Designing Resilient Architectures
Network Load Balancer (NLB)
ELB type for high-performance TCP/UDP/TLS traffic, layer 4.
Module 2: Designing Resilient Architectures
Target Tracking Policy
ASG scaling policy maintaining a target metric value.
Module 2: Designing Resilient Architectures
Scalability & Elasticity: Auto Scaling, Load Balancers
Think of a 'Rubber Band' for Elasticity – it stretches and shrinks back. 'Staircase' for Scalability – you can add more steps, but it doesn't move on its own.
Module 2: Designing Resilient Architectures
Scalability & Elasticity: Auto Scaling, Load Balancers
For the exam, distinguish between ALB (HTTP/HTTPS, path/host-based routing) and NLB (TCP/UDP/TLS, extreme performance, static IP). Remember Auto Scaling groups automatically replace unhealthy instances and scale based on policies.
Module 2: Designing Resilient Architectures
Scalability & Elasticity: Auto Scaling, Load Balancers
Confusing scalability (ability to grow) with elasticity (automatic growth and shrinkage).
Module 2: Designing Resilient Architectures
Scalability & Elasticity: Auto Scaling, Load Balancers
Not configuring health checks for instances within an Auto Scaling Group, leading to traffic being sent to unhealthy servers.
Module 2: Designing Resilient Architectures
Scalability & Elasticity: Auto Scaling, Load Balancers
Using an ALB when an NLB is required for extremely low latency or static IP addresses, or vice-versa.
Module 2: Designing Resilient Architectures
High Availability (HA)
System design ensuring continuous operation with minimal downtime.
Module 2: Designing Resilient Architectures
Multi-AZ Deployment
Distributing resources across multiple AZs for redundancy.
Module 2: Designing Resilient Architectures
Redundancy
Having duplicate components to take over in case of failure.
Module 2: Designing Resilient Architectures
Failover
Automatic switch to a standby or redundant system upon failure.
Module 2: Designing Resilient Architectures
Elastic Load Balancer (ELB)
Distributes incoming application traffic across multiple targets.
Module 2: Designing Resilient Architectures
Auto Scaling Group
Manages EC2 instance fleets, scaling and replacing unhealthy instances.
Module 2: Designing Resilient Architectures
Recovery Time Objective (RTO)
Maximum acceptable time for an application to be down.
Module 2: Designing Resilient Architectures
High Availability: Multi-AZ, Redundancy Patterns
Think 'AZ' for 'Always Zavailable' – if you deploy across multiple AZs, your services are always available!
Module 2: Designing Resilient Architectures
High Availability: Multi-AZ, Redundancy Patterns
For the SAA-C03 exam, remember that Multi-AZ deployments are primarily for high availability within a single AWS Region, protecting against AZ-level failures. They are not a disaster recovery strategy against region-wide outages.
Module 2: Designing Resilient Architectures
High Availability: Multi-AZ, Redundancy Patterns
Confusing Multi-AZ with Multi-Region: Multi-AZ protects against AZ failures; Multi-Region protects against entire region failures.
Module 2: Designing Resilient Architectures
High Availability: Multi-AZ, Redundancy Patterns
Assuming all services are Multi-AZ by default: Many services require explicit configuration (e.g., RDS Multi-AZ, launching EC2 in multiple AZs).
Module 2: Designing Resilient Architectures
High Availability: Multi-AZ, Redundancy Patterns
Not testing failover mechanisms: An untested HA setup is not a reliable HA setup.
Module 2: Designing Resilient Architectures
Decoupling
Separating components so they can operate independently.
Module 2: Designing Resilient Architectures
Asynchronous Communication
Sender doesn't wait for receiver's immediate response.
Module 2: Designing Resilient Architectures
Amazon SQS
Fully managed message queuing service for decoupling.
Module 2: Designing Resilient Architectures
Standard Queue
SQS queue type with high throughput, best-effort ordering.
Module 2: Designing Resilient Architectures
FIFO Queue
SQS queue type guaranteeing exact order and exactly-once delivery.
Module 2: Designing Resilient Architectures
Amazon SNS
Fully managed publish/subscribe messaging service.
Module 2: Designing Resilient Architectures
SNS Topic
A communication channel for publishing messages.
Module 2: Designing Resilient Architectures
Dead-Letter Queue (DLQ)
Queue for messages that cannot be processed successfully.
Module 2: Designing Resilient Architectures
Fault Tolerance: Decoupling Services with SQS and SNS
SQS is like a 'Super Quiet Storage' for messages, holding them until they're ready. SNS is for 'Sending Notifications Swiftly' to many listeners.
Module 2: Designing Resilient Architectures
Fault Tolerance: Decoupling Services with SQS and SNS
For the SAA-C03 exam, distinguish between SQS Standard and FIFO queues based on ordering and delivery guarantees. Remember SNS is for fan-out (one-to-many) and SQS is for queueing (one-to-one or many-to-one with workers).
Module 2: Designing Resilient Architectures
Fault Tolerance: Decoupling Services with SQS and SNS
Using SQS when strict ordering and exactly-once processing across multiple consumers is required, instead of SQS FIFO.
Module 2: Designing Resilient Architectures
Fault Tolerance: Decoupling Services with SQS and SNS
Trying to use SNS for point-to-point communication where a single consumer needs to process a message.
Module 2: Designing Resilient Architectures
Fault Tolerance: Decoupling Services with SQS and SNS
Not configuring Dead-Letter Queues (DLQs) for SQS queues, leading to lost messages or blocked queues.
Module 2: Designing Resilient Architectures
RTO
Recovery Time Objective: Max acceptable downtime after a disaster.
Module 2: Designing Resilient Architectures
RPO
Recovery Point Objective: Max acceptable data loss after a disaster.
Module 2: Designing Resilient Architectures
Backup & Restore
Copying data to a separate location for recovery.
Module 2: Designing Resilient Architectures
Pilot Light
Minimal core resources running in DR region, data replicated.
Module 2: Designing Resilient Architectures
Warm Standby
Scaled-down but functional environment in DR region.
Module 2: Designing Resilient Architectures
Multi-Site Active/Active
Application runs simultaneously in multiple active regions.
Module 2: Designing Resilient Architectures
AWS Backup
Centralized, managed service to automate backups across AWS.
Module 2: Designing Resilient Architectures
Disaster Recovery: RTO/RPO, Backup & Restore
RTO is 'Time' to get Running. RPO is 'Point' of data you can lose. Think of it like a clock and a data timeline!
Module 2: Designing Resilient Architectures
Disaster Recovery: RTO/RPO, Backup & Restore
The exam often presents scenarios where you need to choose the most cost-effective disaster recovery strategy that meets specific RTO and RPO requirements. Remember that lower RTO/RPO generally means higher cost and complexity.
Module 2: Designing Resilient Architectures
Disaster Recovery: RTO/RPO, Backup & Restore
Confusing RTO with RPO: RTO is about time to recover, RPO is about data loss.
Module 2: Designing Resilient Architectures
Disaster Recovery: RTO/RPO, Backup & Restore
Underestimating the cost of achieving very low RTO/RPO targets.
Module 2: Designing Resilient Architectures
Disaster Recovery: RTO/RPO, Backup & Restore
Not regularly testing disaster recovery plans, leading to failures during actual events.
Module 2: Designing Resilient Architectures
EBS
Persistent block storage for EC2 instances.
Module 3: Designing High-Performing Architectures
EFS
Scalable, shared file storage for AWS and on-premises.
Module 3: Designing High-Performing Architectures
S3
Object storage with extreme durability and scalability.
Module 3: Designing High-Performing Architectures
Storage Gateway
Hybrid cloud service connecting on-premises to AWS storage.
Module 3: Designing High-Performing Architectures
IOPS
Input/Output Operations Per Second; a performance metric.
Module 3: Designing High-Performing Architectures
Block Storage
Data stored in fixed-size blocks, accessed like a disk.
Module 3: Designing High-Performing Architectures
File Storage
Data stored in a hierarchical file system, shared access.
Module 3: Designing High-Performing Architectures
Object Storage
Data stored as objects with metadata, accessed via API.
Module 3: Designing High-Performing Architectures
High-Performance Storage: EBS, EFS, S3, Storage Gateway
Remember 'BEFS' for the main storage types: Block (EBS), Elastic File (EFS), and S3 (Object).
Module 3: Designing High-Performing Architectures
High-Performance Storage: EBS, EFS, S3, Storage Gateway
On the exam, understand the core access pattern: EBS for single EC2 block storage, EFS for shared file access across multiple EC2s, and S3 for object storage (web, backup, data lakes). Keywords like 'shared access,' 'operating system boot volume,' or 'static website' are strong clues.
Module 3: Designing High-Performing Architectures
High-Performance Storage: EBS, EFS, S3, Storage Gateway
Using S3 for an EC2 instance's boot volume; EBS is required for this.
Module 3: Designing High-Performing Architectures
High-Performance Storage: EBS, EFS, S3, Storage Gateway
Trying to mount an EBS volume to multiple EC2 instances simultaneously (unless using a specific multi-attach feature for io2 volumes, which is not general purpose).
Module 3: Designing High-Performing Architectures
High-Performance Storage: EBS, EFS, S3, Storage Gateway
Selecting EFS for archival data that is rarely accessed, which would be more cost-effective in S3 Glacier.
Module 3: Designing High-Performing Architectures
EC2
Virtual servers offering resizable compute capacity with full control.
Module 3: Designing High-Performing Architectures
Lambda
Serverless compute service for running code in response to events.
Module 3: Designing High-Performing Architectures
ECS
Managed container orchestration service for Docker containers.
Module 3: Designing High-Performing Architectures
EKS
Fully managed Kubernetes service for container orchestration.
Module 3: Designing High-Performing Architectures
Fargate
Serverless compute engine for containers, used with ECS/EKS.
Module 3: Designing High-Performing Architectures
Serverless
Cloud execution model where AWS manages servers; you pay for usage.
Module 3: Designing High-Performing Architectures
Container
Standard unit of software packaging code and dependencies.
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
Remember 'CLEE' for Compute options: Control (EC2), Lambda (Serverless), ECS (Containers), EKS (Kubernetes).
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
The exam often presents scenarios where you must choose the most appropriate compute service. Keywords like 'full control,' 'legacy application,' or 'specific OS' point to EC2. 'Event-driven,' 'intermittent,' 'no server management,' or 'microservices' suggest Lambda. 'Docker,' 'container orchestration,' or 'microservices' point to ECS/EKS. If 'Kubernetes' is mentioned, EKS is the answer.
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
Over-provisioning EC2 instances for intermittent workloads, leading to unnecessary costs.
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
Trying to run long-running, stateful applications directly on Lambda, which is designed for short, stateless functions.
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
Choosing EKS for a simple containerized application when ECS (especially with Fargate) would offer less operational overhead.
Module 3: Designing High-Performing Architectures
Optimizing Compute: EC2, Lambda, ECS, EKS
Ignoring the cost implications of each service; serverless doesn't always mean cheapest for every workload.
Module 3: Designing High-Performing Architectures
AWS Direct Connect
Dedicated private network connection from on-premises to AWS.
Module 3: Designing High-Performing Architectures
Transit Gateway (TGW)
Network transit hub connecting VPCs and on-premises networks centrally.
Module 3: Designing High-Performing Architectures
Global Accelerator
Service improving global application performance using AWS network.
Module 3: Designing High-Performing Architectures
Hybrid Cloud
Environment combining on-premises infrastructure with cloud resources.
Module 3: Designing High-Performing Architectures
Virtual Private Cloud (VPC)
Isolated virtual network within an AWS region.
Module 3: Designing High-Performing Architectures
Edge Location
AWS data centers used by services like Global Accelerator and CloudFront.
Module 3: Designing High-Performing Architectures
Static IP Addresses
Fixed IP addresses provided by Global Accelerator for application entry.
Module 3: Designing High-Performing Architectures
Networking Performance: Direct Connect, TGW, Global Accel.
Remember 'DTG': Direct Connect is for Dedicated pipes, Transit Gateway is for centralizing Topology, and Global Accelerator is for Global users.
Module 3: Designing High-Performing Architectures
Networking Performance: Direct Connect, TGW, Global Accel.
The exam often presents scenarios where you need to choose the best connectivity option. Look for keywords like 'dedicated connection,' 'consistent throughput,' or 'reduced latency to AWS' for Direct Connect. For Transit Gateway, 'simplify network topology,' 'centralized routing,' or 'connect many VPCs/on-prem' are clues. For Global Accelerator, 'global users,' 'improve performance for distant users,' or 'static entry point' are key indicators.
Module 3: Designing High-Performing Architectures
Networking Performance: Direct Connect, TGW, Global Accel.
Confusing Direct Connect with a VPN: Direct Connect is a dedicated physical connection, while a VPN uses the public internet.
Module 3: Designing High-Performing Architectures
Networking Performance: Direct Connect, TGW, Global Accel.
Using Transit Gateway for simple VPC peering: For just two VPCs, direct peering might be simpler, but TGW scales better.
Module 3: Designing High-Performing Architectures
Networking Performance: Direct Connect, TGW, Global Accel.
Assuming Global Accelerator replaces CloudFront: Global Accelerator optimizes network path, CloudFront caches content.
Module 3: Designing High-Performing Architectures
Amazon RDS
Managed relational database service.
Module 3: Designing High-Performing Architectures
Amazon Aurora
High-performance, MySQL/PostgreSQL compatible relational database.
Module 3: Designing High-Performing Architectures
Amazon DynamoDB
Fully managed, serverless NoSQL database with single-digit millisecond performance.
Module 3: Designing High-Performing Architectures
DynamoDB Accelerator (DAX)
In-memory cache for DynamoDB, microsecond reads.
Module 3: Designing High-Performing Architectures
Amazon ElastiCache
Managed in-memory caching service (Memcached, Redis).
Module 3: Designing High-Performing Architectures
Read Replicas
Copies of a database to offload read traffic.
Module 3: Designing High-Performing Architectures
Provisioned IOPS (PIOPS)
Predictable I/O performance for RDS storage.
Module 3: Designing High-Performing Architectures
Database Performance: RDS, DynamoDB, Aurora, ElastiCache
R-A-D-E: Relational-Aurora-DynamoDB-ElastiCache. Remember the core services for database performance.
Module 3: Designing High-Performing Architectures
Database Performance: RDS, DynamoDB, Aurora, ElastiCache
The exam often tests your ability to choose the right database for a given workload. Look for keywords like 'relational,' 'high transaction rate,' 'complex queries' for Aurora/RDS, and 'key-value,' 'document,' 'serverless,' 'millisecond latency at any scale' for DynamoDB. 'Read-heavy,' 'session management,' 'leaderboard' points to ElastiCache.
Module 3: Designing High-Performing Architectures
Database Performance: RDS, DynamoDB, Aurora, ElastiCache
Choosing a relational database (RDS) for a workload that is better suited for a NoSQL database (DynamoDB), leading to scalability and performance issues.
Module 3: Designing High-Performing Architectures
Database Performance: RDS, DynamoDB, Aurora, ElastiCache
Not utilizing Read Replicas or caching (ElastiCache/DAX) for read-heavy workloads, resulting in database bottlenecks and slow application response times.
Module 3: Designing High-Performing Architectures
Database Performance: RDS, DynamoDB, Aurora, ElastiCache
Under-provisioning capacity for DynamoDB (RCUs/WCUs) or not monitoring performance metrics, leading to throttled requests and errors.
Module 3: Designing High-Performing Architectures
S3 Standard
Default S3 class for frequently accessed data.
Module 4: Designing Cost-Optimized Architectures
S3 Standard-IA
For infrequently accessed data requiring rapid retrieval.
Module 4: Designing Cost-Optimized Architectures
S3 One Zone-IA
Infrequently accessed data, stored in a single AZ.
Module 4: Designing Cost-Optimized Architectures
S3 Glacier
Low-cost archival storage, retrieval in minutes/hours.
Module 4: Designing Cost-Optimized Architectures
S3 Glacier Deep Archive
Lowest-cost archival, retrieval typically within 12 hours.
Module 4: Designing Cost-Optimized Architectures
S3 Intelligent-Tiering
Automatically optimizes costs based on access patterns.
Module 4: Designing Cost-Optimized Architectures
Lifecycle Policy
Automates object transitions or expirations.
Module 4: Designing Cost-Optimized Architectures
Cost-Optimized Storage: S3 Tiers, Glacier, Lifecycle
Think of S3 storage classes like a library: 'Standard' is the main shelf (frequent access). 'IA' is the back room (infrequent, but still quick to get). 'Glacier' is the deep archive in the basement (long retrieval time). 'Intelligent-Tiering' is the librarian who moves books automatically!
Module 4: Designing Cost-Optimized Architectures
Cost-Optimized Storage: S3 Tiers, Glacier, Lifecycle
The SAA-C03 exam frequently tests your ability to choose the MOST cost-effective S3 storage class for a given scenario. Pay close attention to keywords like 'frequently accessed,' 'infrequently accessed,' 'archival,' 'unknown access patterns,' and required 'retrieval time.' Memorize the typical retrieval times for Glacier and Deep Archive.
Module 4: Designing Cost-Optimized Architectures
Cost-Optimized Storage: S3 Tiers, Glacier, Lifecycle
Not using Lifecycle Policies: Manually moving data is inefficient and often forgotten, leading to higher costs.
Module 4: Designing Cost-Optimized Architectures
Cost-Optimized Storage: S3 Tiers, Glacier, Lifecycle
Using S3 Standard for archival data: This is a common and expensive mistake; Glacier is far more cost-effective for long-term archives.
Module 4: Designing Cost-Optimized Architectures
Cost-Optimized Storage: S3 Tiers, Glacier, Lifecycle
Confusing S3 Standard-IA with S3 One Zone-IA: Remember One Zone-IA offers less durability but is cheaper.
Module 4: Designing Cost-Optimized Architectures
On-Demand Instances
Pay-as-you-go compute with no commitment; highest cost.
Module 4: Designing Cost-Optimized Architectures
Spot Instances
Bid on unused EC2 capacity; up to 90% savings, interruptible.
Module 4: Designing Cost-Optimized Architectures
Reserved Instances (RIs)
Commitment for 1 or 3 years for EC2; up to 75% off.
Module 4: Designing Cost-Optimized Architectures
Savings Plans
Commitment to spend (USD/hour); applies to EC2, Fargate, Lambda.
Module 4: Designing Cost-Optimized Architectures
EC2 Instance Savings Plan
Savings Plan for specific EC2 instance family in a region.
Module 4: Designing Cost-Optimized Architectures
Compute Savings Plan
Flexible Savings Plan for any EC2, Fargate, Lambda usage.
Module 4: Designing Cost-Optimized Architectures
Compute Cost Optimization: Spot, Reserved, Savings Plans
SPOT the savings for FLexible workloads. RIght for STABLE. SAVINGS PLANS are the most FLEXIBLE commitment.
Module 4: Designing Cost-Optimized Architectures
Compute Cost Optimization: Spot, Reserved, Savings Plans
The exam often presents scenarios requiring you to choose the most cost-effective compute option. Look for keywords like 'fault-tolerant,' 'interruptible,' or 'batch processing' for Spot Instances. For 'stable,' 'long-running,' or 'predictable,' think Savings Plans or Reserved Instances.
Module 4: Designing Cost-Optimized Architectures
Compute Cost Optimization: Spot, Reserved, Savings Plans
Using Spot Instances for critical, stateful, or non-interruptible workloads, leading to service disruptions.
Module 4: Designing Cost-Optimized Architectures
Compute Cost Optimization: Spot, Reserved, Savings Plans
Over-provisioning Reserved Instances or Savings Plans, committing to more capacity than actually needed, leading to wasted spend.
Module 4: Designing Cost-Optimized Architectures
Compute Cost Optimization: Spot, Reserved, Savings Plans
Not understanding the difference between EC2 Instance Savings Plans and Compute Savings Plans, leading to less optimal flexibility or discounts.
Module 4: Designing Cost-Optimized Architectures
Data Transfer Out
Data moving from AWS to the internet, typically charged.
Module 4: Designing Cost-Optimized Architectures
Inter-AZ Data Transfer
Data moving between Availability Zones in a region, incurring costs.
Module 4: Designing Cost-Optimized Architectures
Cross-Region Data Transfer
Data moving between different AWS regions, incurring high costs.
Module 4: Designing Cost-Optimized Architectures
Amazon CloudFront
A Content Delivery Network (CDN) that caches content at edge locations.
Module 4: Designing Cost-Optimized Architectures
VPC Endpoint
Allows private connection to AWS services from a VPC.
Module 4: Designing Cost-Optimized Architectures
Gateway Endpoint
VPC Endpoint type for S3 and DynamoDB, routing traffic privately.
Module 4: Designing Cost-Optimized Architectures
Interface Endpoint
VPC Endpoint type powered by PrivateLink for most AWS services.
Module 4: Designing Cost-Optimized Architectures
Networking Cost Reduction: Data Transfer, VPC Endpoints
To cut networking costs, remember 'C-V-P-E': CloudFront for public content, VPC Endpoints for private service access, and Plan for data Egress.
Module 4: Designing Cost-Optimized Architectures
Networking Cost Reduction: Data Transfer, VPC Endpoints
Memorize that data transfer OUT of AWS to the internet is generally charged, while data transfer IN is generally free. Also, inter-AZ data transfer is charged. VPC Gateway Endpoints are specifically for S3 and DynamoDB.
Module 4: Designing Cost-Optimized Architectures
Networking Cost Reduction: Data Transfer, VPC Endpoints
Forgetting that inter-AZ data transfer incurs costs, leading to inefficient resource placement.
Module 4: Designing Cost-Optimized Architectures
Networking Cost Reduction: Data Transfer, VPC Endpoints
Not utilizing CloudFront for public content delivery, resulting in high S3 or EC2 egress costs.
Module 4: Designing Cost-Optimized Architectures
Networking Cost Reduction: Data Transfer, VPC Endpoints
Routing traffic to S3 or DynamoDB over the public internet when a cost-free and more secure VPC Gateway Endpoint is available.
Module 4: Designing Cost-Optimized Architectures
Aurora Serverless
An on-demand, auto-scaling configuration for Amazon Aurora.
Module 4: Designing Cost-Optimized Architectures
DynamoDB On-Demand
DynamoDB capacity mode where you pay per request, no provisioning.
Module 4: Designing Cost-Optimized Architectures
DynamoDB Provisioned
DynamoDB capacity mode where you specify read/write units.
Module 4: Designing Cost-Optimized Architectures
RDS Reserved Instance
Commitment to use an RDS instance for 1 or 3 years for a discount.
Module 4: Designing Cost-Optimized Architectures
Serverless Database
Database that automatically scales and manages capacity.
Module 4: Designing Cost-Optimized Architectures
On-Demand Capacity
Pay-as-you-go model, scales with usage, no upfront commitment.
Module 4: Designing Cost-Optimized Architectures
Provisioned Capacity
Fixed capacity allocated in advance, charged whether used or not.
Module 4: Designing Cost-Optimized Architectures
Database Cost Management: Serverless, Reserved Instances
To remember when to use which: 'Serverless' for 'Spikes' and 'Surprises'; 'Reserved' for 'Regular' and 'Reliable'.
Module 4: Designing Cost-Optimized Architectures
Database Cost Management: Serverless, Reserved Instances
The exam often presents scenarios asking you to choose the most cost-effective database solution. Keywords like 'unpredictable traffic,' 'sporadic usage,' or 'development environment' point to serverless options (Aurora Serverless, DynamoDB On-Demand). Keywords like '24/7 operation,' 'stable workload,' or 'long-term commitment' indicate RDS Reserved Instances or DynamoDB Provisioned Capacity.
Module 4: Designing Cost-Optimized Architectures
Database Cost Management: Serverless, Reserved Instances
Using RDS Reserved Instances for highly variable or short-term databases, leading to wasted capacity costs.
Module 4: Designing Cost-Optimized Architectures
Database Cost Management: Serverless, Reserved Instances
Over-provisioning DynamoDB capacity for unpredictable workloads instead of using On-Demand mode.
Module 4: Designing Cost-Optimized Architectures
Database Cost Management: Serverless, Reserved Instances
Not reviewing database usage patterns before selecting a cost model, missing potential savings.
Module 4: Designing Cost-Optimized Architectures