SAA-C03 Practice Questions

This architecture represents a standard and secure multi-tier design. An internet-facing Application Load Balancer (ALB) must be placed in public subnets (subnets with a route to an Internet Gateway) to be accessible from the internet. The EC2 instances, which form the application tier, do not need direct internet access; they only need to receive traffic from the ALB. Placing them in private subnets minimizes their exposure. Similarly, the RDS database, the data tier, should be isolated from the internet for maximum security and placed in private subnets, accessible only from the application tier (the EC2 instances). This design adheres to the principle of least privilege by exposing only the necessary component (the ALB) to the internet.

A. An internet-facing ALB cannot be placed in private subnets, as it would not be able to receive traffic directly from the internet.

C. Placing EC2 instances in public subnets unnecessarily increases the application's attack surface, violating the requirement to minimize resources routable from the internet.

D. An Application Load Balancer is a resource that must be provisioned within a VPC and associated with specific subnets; it cannot exist "outside the VPC".

1. AWS Documentation: Elastic Load Balancing User Guide: "To create an internet-facing load balancer

you must specify at least two public subnets... A public subnet has a route to an internet gateway." This confirms the required placement for the ALB. (Source: AWS Documentation

Elastic Load Balancing User Guide

"Subnets for your load balancer").

2. AWS Documentation: Amazon VPC User Guide: The guide presents a common scenario

"VPC with public and private subnets (NAT)

" which illustrates this exact architecture. It states

"The main components of this scenario are as follows: ... A public subnet with an elastic load balancer... A private subnet with the web server instances that run your application." (Source: AWS Documentation

Amazon VPC User Guide

"Example: VPC with servers in private subnets and NAT").

3. AWS Well-Architected Framework - Security Pillar: This framework advocates for defense in depth. "You can achieve this by using a virtual private cloud (VPC)... Place resources in a private subnet when they don't require direct access from the internet." This supports placing EC2 and RDS in private subnets. (Source: AWS Well-Architected Framework

Security Pillar

"SEC 04: How do you protect your networks?"

"Protect network and host-level boundaries").

4. AWS Documentation: Amazon RDS User Guide: "A common Amazon RDS scenario is to have a VPC in which you have an EC2 instance with a web server and a DB instance with a database. In this scenario

we recommend that you use private subnets for your DB instance because they have a higher level of security." (Source: AWS Documentation

Amazon RDS User Guide

"Scenarios for accessing a DB instance in a VPC").

The most cost-effective and secure solution is to use VPC endpoints. Interface VPC endpoints, powered by AWS PrivateLink, enable private connections between a VPC and supported AWS services without requiring an internet gateway, NAT gateway, or public IP addresses. Traffic between the VPC and the AWS service does not leave the Amazon network. This directly fulfills the requirements of keeping applications inaccessible from the internet while allowing them to privately and securely access other AWS services. While there are costs associated with interface endpoints (hourly and data processing), this is the only option that meets all technical requirements.

B. A NAT gateway enables instances in a private subnet to connect to the internet. Traffic to AWS services would traverse the public internet, which violates the requirement to not use public IP addresses.

C. An internet gateway is attached to a VPC to enable communication with the internet. Using one would expose the subnets to the internet, violating a core security requirement of the scenario.

D. AWS Direct Connect establishes a dedicated private connection from an on-premises network to AWS. It is not used for communication from a VPC to AWS services within the same region.

1. AWS Documentation - VPC Endpoints: "An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported AWS service... AWS PrivateLink provides private connectivity between VPCs

AWS services

and your on-premises networks

without exposing your traffic to the public internet." (AWS Documentation

VPC User Guide

Section: "VPC endpoints"

Subsection: "Interface endpoints").

2. AWS Documentation - NAT Gateways: "You can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services

but prevent the internet from initiating a connection with those instances." (AWS Documentation

VPC User Guide

Section: "NAT gateways"). This confirms that NAT gateways route traffic over the internet.

3. AWS Whitepaper - AWS Security Best Practices: "To further improve your security posture

you can use AWS PrivateLink to privately access AWS services from your Amazon VPC in a scalable manner... This connection does not traverse the internet." (AWS Whitepaper: AWS Security Best Practices

August 2020

Page 27).

4. AWS Documentation - AWS Direct Connect: "AWS Direct Connect is a cloud service solution that makes it easy to establish a dedicated network connection from your premises to AWS." (AWS Documentation

AWS Direct Connect User Guide

Section: "What is AWS Direct Connect?"). This clarifies its primary use case is for hybrid connectivity

not intra-AWS communication from a VPC.

AWS security best practices strongly recommend securing the AWS account root user by enabling Multi-Factor Authentication (MFA). The root user has unrestricted access to all resources in the account and should not be used for daily administrative tasks. Instead, individual IAM users with the minimum necessary permissions (the principle of least privilege) should be created for all human and programmatic access. This dual approach of locking down the root user with MFA and delegating daily tasks to IAM users is a foundational security measure for any AWS account.

A. The AWS account root user cannot be disabled. It is required for a small number of specific account and service management tasks.

C. Creating and using root user access keys is strongly discouraged. If compromised, these keys provide unrestricted programmatic access to the entire account.

D. Using the root user for daily tasks, even by a senior architect, violates security best practices and the principle of least privilege.

1. AWS Identity and Access Management User Guide: In the "Security best practices in IAM" section

AWS states

"We strongly recommend that you enable multi-factor authentication (MFA) on your root user." It also advises

"Don't use the root user for your everyday tasks

even the administrative ones. Instead

create an IAM user for each person who needs administrative access." (See section: "Security best practices in IAM").

2. AWS Security Best Practices Whitepaper: This document outlines foundational best practices. In the section "Secure your AWS account root user

" it explicitly recommends: "Enable multi-factor authentication (MFA) for the root user" and "Do not use the root user for day-to-day operations." (aws-security-best-practices.pdf

Page 8).

3. AWS Identity and Access Management User Guide: The guide lists specific "Tasks that require root user credentials

" such as changing account settings or closing an AWS account. This demonstrates that the root user has unique functions and cannot be disabled. (See section: "Tasks that require root user credentials").

The requirement is for a flexible compute solution covering both Amazon EC2 and AWS Fargate, which must be the most cost-effective option without a multi-year commitment. A Compute Savings Plan is the most suitable choice as it provides flexibility across instance families, regions, and compute services, including EC2 and Fargate. Among the payment options for a 1-year term, the All Upfront option provides the highest discount, making it the most cost-effective choice as requested by the question.

A. An EC2 Instance Savings Plan does not apply to AWS Fargate usage, so it fails to meet the requirements of the scenario.

B. The No Upfront option provides the lowest discount for a Savings Plan, making it less cost-effective than the Partial or All Upfront options.

C. The Partial Upfront option offers a lower discount than the All Upfront option, and therefore is not the MOST cost-effective solution.

1. AWS Savings Plans User Guide

"What are Savings Plans?": This document distinguishes between the types of Savings Plans. It states

"Compute Savings Plans provide the most flexibility and help to reduce your costs by up to 66%. These plans automatically apply to EC2 instance usage regardless of instance family

size

AZ

Region

OS or tenancy. These plans also apply to Fargate and Lambda usage." This confirms a Compute Savings Plan is necessary to cover both EC2 and Fargate.

2. AWS Savings Plans User Guide

"Getting started with Savings Plans": Under the "Commitment and payment options" section

the guide explains the payment models: "You can choose to pay for your Savings Plans with No Upfront

Partial Upfront

or All Upfront payment options. The Partial Upfront and All Upfront options provide a larger discount." This confirms that All Upfront is the most discounted

and thus most cost-effective

option.

3. AWS Compute Savings Plans

Official Webpage: The pricing section details the payment options and their corresponding savings. It explicitly shows that for any given term

the All Upfront option yields the highest percentage of savings compared to Partial Upfront and No Upfront.

This solution correctly addresses all requirements. An EC2 Auto Scaling group configured across multiple Availability Zones (AZs) provides both high availability and resilience by ensuring the application can withstand the failure of a single AZ. The Application Load Balancer (ALB) distributes incoming traffic across the instances in all configured AZs. Using an Amazon CloudWatch alarm to trigger horizontal scaling (adding or removing EC2 instances) is the most effective method to handle variable traffic loads. This dynamic scaling approach ensures that compute capacity matches demand, thereby meeting the scalability requirement in the most cost-effective manner by avoiding over-provisioning.

A. Vertical scaling (changing instance size) is less agile for handling traffic spikes than horizontal scaling and can lead to service interruptions during resizing.

B. Provisioning a fixed number of nine instances from the start is not cost-effective, as it leads to paying for unused capacity during periods of low traffic.

C. Placing all instances in the same Availability Zone fails the resilience requirement, as a single AZ failure would cause a complete application outage.

1. AWS EC2 Auto Scaling User Guide: "To improve the availability of your applications

you can configure your Auto Scaling group to launch new instances into multiple Availability Zones. If one Availability Zone becomes unavailable

Amazon EC2 Auto Scaling launches new instances in an unaffected Availability Zone." (Source: AWS Documentation

Amazon EC2 Auto Scaling User Guide

"What is Amazon EC2 Auto Scaling?"

Section: Availability).

2. AWS Elastic Load Balancing User Guide: "When you enable an Availability Zone for your load balancer

Elastic Load Balancing creates a load balancer node in the Availability Zone. ... This increases the fault tolerance of your applications." (Source: AWS Documentation

User Guide for Application Load Balancers

"How Elastic Load Balancing works"

Section: Load balancers and Availability Zones).

3. AWS Well-Architected Framework - Reliability Pillar: "Scale horizontally to increase aggregate workload availability. Replace one large resource with multiple small resources to reduce the impact of a single failure. Distribute requests among the multiple

smaller resources to ensure that they don't share a common point of failure." (Source: AWS Whitepaper

AWS Well-Architected Framework

Reliability Pillar

Design Principles

Page 5).

4. AWS Well-Architected Framework - Cost Optimization Pillar: "Use a demand-based approach to provision resources. For example

with Amazon EC2 Auto Scaling

you can add or remove EC2 instances automatically to match the demand of your workload. This stops you from provisioning for peak load and paying for idle resources." (Source: AWS Whitepaper

AWS Well-Architected Framework

Cost Optimization Pillar

Design Principles

Page 6).

Amazon Route 53 is the appropriate service for directing traffic to multiple AWS Regions. The multivalue answer routing policy allows Route 53 to respond to DNS queries with up to eight healthy records selected at random. By creating a record for the endpoint in each Region (e.g., the regional Application Load Balancer) and associating a Route 53 health check with each record, the requirements are met. This configuration distributes traffic across both Regions. If the health check for one Region fails, Route 53 will stop returning that Region's record in DNS responses, effectively routing traffic away from the unhealthy endpoint and providing disaster recovery.

A. A simple routing policy routes traffic to a single resource. While you can specify multiple values, it does not perform health checks to remove unhealthy endpoints from responses.

C. An Application Load Balancer is a regional service. Its target groups cannot contain EC2 instances that reside in a different AWS Region.

D. An Application Load Balancer is regional and cannot have targets in another Region. This design also introduces a single point of failure in the primary Region.

1. Amazon Route 53 Developer Guide: In the section "Choosing a routing policy

" it states

"Multivalue answer routing: Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random." It further clarifies

"If you associate a health check with a multivalue answer record

Route 53 responds to DNS queries with only the records that are healthy." (See section: "Choosing a routing policy

" subsection: "Multivalue answer routing").

2. AWS Documentation - What is Elastic Load Balancing?: This document describes the scope of load balancers. "Elastic Load Balancing distributes incoming application traffic across multiple targets

such as Amazon EC2 instances... in a single Availability Zone or across multiple Availability Zones." This confirms the regional nature of the service. (See section: "Elastic Load Balancing components

" paragraph on "Load balancer").

3. Elastic Load Balancing User Guide: When registering targets

the documentation specifies they must be within the load balancer's VPC. "You can register targets by instance ID or by IP address. Your target group can include targets from different Availability Zones

but they must be in the same VPC as the load balancer." This explicitly prohibits registering instances from another Region. (See section: "Target groups for your Application Load Balancers

" subsection: "Register targets").

The core issue is performance degradation on the primary RDS database due to heavy read operations from reporting and ML workloads. The most effective and standard AWS solution for scaling read-intensive workloads on an RDS database is to create a read replica. A read replica is an asynchronously replicated, read-only copy of the primary database. By directing the reporting queries to this replica, the read load is isolated from the primary instance, which can then dedicate its resources to the main application's transactions, thus improving its performance. Creating the replica in the same region (us-east-1) is the most cost-effective option as it minimizes data transfer costs and network latency compared to a cross-Region solution.

A. A cross-Region read replica solves the read-scaling problem but incurs higher data transfer costs and network latency than an in-Region replica, making it not the most cost-effective solution.

B. A standard Multi-AZ deployment is for high availability and automatic failover, not for scaling read performance. The standby instance in a Multi-AZ DB instance deployment cannot be used to serve read traffic.

C. Using AWS DMS is overly complex and expensive for this use case. It requires provisioning and managing a separate replication instance and is designed for migrations, not for simple read scaling of an existing RDS database.

1. Amazon RDS User Guide

"Working with Amazon RDS read replicas": This document states

"You can reduce the load on your primary DB instance by routing read queries from your applications to the read replica. Read replicas allow you to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads." This directly supports using a read replica to solve the performance issue.

2. Amazon RDS User Guide

"High availability (Multi-AZ) for Amazon RDS": The documentation clarifies the purpose of Multi-AZ: "In a Multi-AZ DB instance deployment

Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone... The standby replica can't serve read requests." This confirms that option B is incorrect for a standard Multi-AZ DB instance.

3. Amazon RDS Pricing

"Data Transfer" section: AWS pricing details show that data transfer "In from internet" is free

but data transfer "Out to internet" (which includes inter-region traffic) is priced per GB. Data transfer within the same AWS Region between Availability Zones has a lower cost. This supports the cost-effectiveness of an in-region replica (Option D) over a cross-region one (Option A).

4. AWS Database Migration Service User Guide

"What is AWS Database Migration Service?": The guide describes AWS DMS as a service for migrating databases to AWS quickly and securely

supporting both homogeneous and heterogeneous migrations. This highlights that its primary purpose is migration

making it a more complex and less direct solution than a native read replica for read scaling.

Amazon Route 53 Resolver is a fully managed AWS service designed specifically for hybrid cloud DNS resolution. By creating a Route 53 Resolver outbound endpoint in the VPC, you enable DNS queries to be sent to an on-premises network. A conditional forwarding rule is then configured to direct queries for the specific on-premises domain (e.g., corp.example.com) to the on-premises DNS servers' IP addresses over the Direct Connect connection. This approach is highly available, scalable, and requires minimal configuration and no ongoing server management, thereby meeting the requirement for the least administrative overhead.

A. This solution requires manually provisioning, configuring, patching, and managing EC2 instances and DNS software, which incurs significant administrative overhead compared to a managed service.

B. An Amazon Route 53 private hosted zone is used for authoritative DNS resolution for a domain within a VPC, not for forwarding queries to an external network.

D. Deploying a new Active Directory domain controller and configuring a trust is a complex solution for identity management and authentication, representing excessive administrative overhead for a DNS resolution requirement.

1. Amazon Route 53 Developer Guide

"Resolving DNS queries between VPCs and your network": This section details the use of Route 53 Resolver for hybrid DNS. It states

"To forward DNS queries from your VPCs to your on-premises network

you create a Route 53 Resolver outbound endpoint and forwarding rules." This directly supports the chosen answer.

2. Amazon Route 53 Developer Guide

"Forwarding outbound DNS queries to your network": This page provides a step-by-step guide

explaining

"When you create a rule

you specify the domain name that you want to forward queries for... and the IP addresses of the DNS resolvers on your network that you want to forward the queries to." This confirms the mechanism described in option C.

3. AWS Whitepaper

"Hybrid Cloud DNS Solutions for Amazon VPC": This document outlines architectural patterns for hybrid DNS. In the section "Outbound DNS Resolution from an Amazon VPC

" it recommends using Route 53 Resolver outbound endpoints and forwarding rules as the primary

managed solution for resolving on-premises domain names from within a VPC.

This solution directly addresses the core requirements of scalability and high availability for a web application. An Application Load Balancer (ALB) is designed to handle HTTP/HTTPS traffic and can perform path-based routing, which matches the application's needs. An Auto Scaling group (ASG) automatically adjusts the number of EC2 instances based on traffic demand, providing the necessary elasticity to handle unpredictable surges. By launching instances from a pre-configured Amazon Machine Image (AMI) and setting a minimum capacity of two, the architecture ensures both consistent application deployment and immediate high availability across multiple instances.

B: A Network Load Balancer (NLB) operates at Layer 4 (TCP/UDP) and is not ideal for the application's Layer 7 (HTTP) path-based routing requirement. An ALB is the correct choice.

C: This is a manual, static solution. It does not automatically scale in response to traffic changes and relies on DNS round-robin, which is not a robust method for load balancing or health checking.

D: This solution adds a load balancer and an alarm but fails to add any scaling capability. The single EC2 instance remains the bottleneck, and an alarm only provides notification, not remediation.

1. AWS Documentation - What is an Application Load Balancer?: "An Application Load Balancer functions at the application layer

the seventh layer of the Open Systems Interconnection (OSI) model. ... After the load balancer receives a request

it evaluates the listener rules in priority order to determine which rule to apply

and then selects a target from a target group for the rule action. You can configure listener rules to route requests to different target groups based on the content of the application traffic

such as ... path patterns in the URL." This supports the use of an ALB for path-based routing.

Source: AWS Elastic Load Balancing User Guide

"What is an Application Load Balancer?".

2. AWS Documentation - What is Amazon EC2 Auto Scaling?: "Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application. ... You can use dynamic scaling and predictive scaling policies to scale your EC2 capacity in response to changing traffic patterns." This confirms that an Auto Scaling group is the correct service for handling unpredictable traffic surges.

Source: AWS Amazon EC2 Auto Scaling User Guide

"What is Amazon EC2 Auto Scaling?".

3. AWS Well-Architected Framework - Performance Efficiency Pillar: "Use an automated solution to scale your workload based on demand. For example

you can use Auto Scaling to add and remove servers based on a schedule or in response to changing load." This document recommends the exact pattern described in the correct answer for achieving performance efficiency and elasticity.

Source: AWS Well-Architected Framework

Performance Efficiency Pillar whitepaper

PER 4: "How do you select the best performing architecture?"

Section: "Use elasticity to meet demand".

Amazon DynamoDB global tables provide a fully managed, multi-Region, and multi-active database solution. By converting the existing single-Region table into a global table and adding a replica in the new Region, the company can achieve low-latency reads and writes for users in both locations. This is the most operationally efficient method because DynamoDB handles the complex work of replicating data between Regions automatically, ensuring that changes made to any replica table are propagated to all other replicas, typically within a second. This native feature eliminates the need to build and maintain a custom replication solution.

A: A Global Secondary Index (GSI) is for creating an alternate query pattern, not for multi-Region replication. The steps described for converting the table are also incorrect and overly complex.

B: This describes a custom, self-managed replication solution using DynamoDB Streams and Kinesis. It introduces significant operational overhead for development, deployment, and maintenance compared to the managed global tables feature.

D: Similar to option B, this is a custom replication solution using DynamoDB Streams and AWS Lambda. While serverless, it still requires writing and maintaining custom code, which is less operationally efficient than the native global tables feature.

1. AWS DynamoDB Developer Guide

"Global Tables: How they work": "Amazon DynamoDB global tables provide a fully managed solution for deploying a multi-region

multi-active database... When you create a global table

you specify the AWS Regions where you want the table to be available. DynamoDB performs all of the necessary tasks to create identical tables in these Regions and propagate ongoing data changes to all of them."

2. AWS DynamoDB Developer Guide

"Creating a global table": This section details the process for creating a global table from an existing table. It states

"You can create a global table from an existing DynamoDB table. The process involves enabling DynamoDB Streams on the source table and then adding replicas in other AWS Regions." This confirms the simplicity and managed nature of the process described in option C.

3. AWS Whitepaper

"Build a multi-Region

active-active architecture with Amazon DynamoDB": This paper explicitly states

"DynamoDB global tables eliminate the difficult work of replicating data between Regions and resolving update conflicts

enabling you to focus on your application’s business logic." This highlights the operational efficiency of the service over custom solutions.

4. AWS DynamoDB Developer Guide

"Change data capture for DynamoDB Streams": This page describes how DynamoDB Streams can be used with AWS Lambda to create cross-Region replication solutions

but it presents this as a use case that requires custom implementation

implicitly making it less operationally efficient than the managed global tables service.