Free SAA-C03 Practice Test Questions and Answers (2026)

Amazon DynamoDB global tables provide a fully managed, multi-region, and multi-active database solution. This configuration directly meets the requirement for an active-active setup, allowing write operations in both the primary and secondary AWS Regions. DynamoDB automatically propagates writes between regions, with replication typically completing in under one second. This satisfies the sub-second recovery point objective (RPO) and is ideal for globally distributed applications like gaming that require low-latency data access and high availability.

A. An Amazon ElastiCache for Redis global datastore uses a primary cluster for writes and read-only secondary clusters, which is an active-passive configuration, not active-active for writes.

B. Using DynamoDB Streams with AWS Lambda is a custom, complex solution. A fully managed service like DynamoDB global tables is a more reliable and operationally simple way to achieve the same goal.

C. Amazon Aurora Global Database supports writes only in the primary Region. The secondary Regions contain read-only replicas, making it an active-passive solution for disaster recovery, not active-active.

1. Amazon DynamoDB Developer Guide - Global tables: "Global tables build on the global Amazon DynamoDB footprint to provide you with a fully managed

multi-region

and multi-active database... You can write data to any of your replica tables in any of the Regions." and "When an application writes data to a replica table in one Region

DynamoDB propagates the write to the other replica tables in the other AWS Regions automatically... a replicated write is completed in under one second."

Source: AWS Documentation

Amazon DynamoDB Developer Guide

Section: "Global tables".

2. Amazon Aurora User Guide - Overview of Amazon Aurora global databases: "An Aurora global database consists of one primary AWS Region where your data is mastered

and up to five read-only

secondary AWS Regions... You issue write operations directly to the primary cluster in the primary AWS Region."

Source: AWS Documentation

Amazon Aurora User Guide

Section: "Working with Amazon Aurora global databases"

Subsection: "Overview of Amazon Aurora global databases".

3. Amazon ElastiCache for Redis User Guide - Replication across AWS Regions using global datastores: "A global datastore is a collection of one primary and one or more secondary clusters that are replicated to one another... Write to your primary cluster and have the data available for reads from your secondary clusters to enable low-latency local reads."

Source: AWS Documentation

Amazon ElastiCache for Redis User Guide

Section: "Replication across AWS Regions using global datastores".

The most appropriate solution is to use AWS WAF (Web Application Firewall) with an IP set match rule. AWS WAF is designed to protect web applications from common exploits and can filter traffic based on various conditions, including the source IP address. A solutions architect can create one or more IP sets containing the 20,000+ registered IP addresses. This IP set is then used in a rule within a web ACL, which is associated directly with the Application Load Balancer (ALB). This approach efficiently filters traffic at the edge, allowing only requests from known retail locations to reach the application, fulfilling the security requirement in a scalable and manageable way.

B: AWS Firewall Manager is a service for centrally managing security policies (like WAF rules) across multiple accounts and resources, not the primary tool for creating the IP filtering logic itself for a single application.

C: This proposes a complex, custom-built solution using Lambda and DynamoDB. AWS WAF provides a native, more performant, and cost-effective managed service for this exact IP filtering use case.

D: Network ACLs have a very low limit on the number of rules (40 maximum per ACL), making it impossible to add rules for over 20,000 distinct IP addresses.

1. AWS WAF Developer Guide - IP set rule statement: "The IP set rule statement inspects the IP address of a web request's origin against a set of IP addresses and address ranges. ... You associate a web ACL with an AWS resource

to protect the resource. The resource can be an Amazon CloudFront distribution

an Amazon API Gateway REST API

an Application Load Balancer..."

Source: AWS WAF

AWS Firewall Manager

and AWS Shield Advanced Developer Guide

"Rule statement list

" section "IP set rule statement."

2. AWS WAF Developer Guide - Working with IP sets: "An IP set can hold up to 10

000 IP addresses or IP address ranges that you specify in CIDR notation." (Note: To accommodate over 20

000 IPs

multiple IP sets can be created and combined within a web ACL rule group).

Source: AWS WAF

AWS Firewall Manager

and AWS Shield Advanced Developer Guide

"Working with IP sets."

3. Amazon VPC User Guide - Network ACL quotas: "Rules per network ACL: 20 (default)

40 (maximum)". This hard limit makes NACLs unsuitable for the scale required in the scenario.

Source: Amazon VPC User Guide

"Quotas for your VPCs

" table entry for "Network ACLs."

4. AWS Firewall Manager Developer Guide - What is AWS Firewall Manager?: "AWS Firewall Manager is a security management service that allows you to centrally configure and manage firewall rules across your accounts and applications in AWS Organization." This highlights its role as a central management tool

not the direct implementation mechanism for a single ALB.

Source: AWS WAF

AWS Firewall Manager

and AWS Shield Advanced Developer Guide

"What is AWS Firewall Manager?".

The requirement is to prevent traffic originating from Application A from reaching Application B. Network Access Control Lists (NACLs) are the appropriate tool for this scenario as they operate at the subnet level and support explicit deny rules. By adding an outbound deny rule to the NACL associated with Application A's subnet, with the destination being the CIDR block of Application B's subnet, all traffic from A to B is blocked before it leaves the source subnet. NACLs are stateless, so this single rule effectively prevents the communication as requested.

A. Security groups do not support explicit deny rules. Furthermore, an outbound rule on Application B's security group would not block inbound traffic.

B. Security groups do not have explicit deny rules; they only support allow rules. Any traffic not matching an allow rule is implicitly denied.

C. An outbound rule on Application B's subnet NACL controls traffic leaving that subnet, not traffic entering it from Application A's subnet.

1. AWS Documentation: VPC User Guide - Network ACLs. This document states

"A network access control list (ACL) is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets." It also specifies under "Network ACL rules" that rules can either "ALLOW" or "DENY" traffic. The solution in option D correctly applies a DENY rule to the outbound traffic of the source subnet.

Source: AWS VPC User Guide

Section: "Control traffic to subnets using network ACLs"

Sub-section: "Network ACL rules".

2. AWS Documentation: VPC User Guide - Security groups. This document clarifies the function of security groups

stating

"A security group acts as a virtual firewall for your EC2 instances to control incoming and outgoing traffic." Under "Security group rules

" it specifies

"Security group rules are always permissive; you can't create rules that deny access." This directly invalidates options A and B.

Source: AWS VPC User Guide

Section: "Control traffic to resources using security groups"

Sub-section: "Security group rules".

3. AWS Documentation: VPC User Guide - Compare security groups and network ACLs. This comparison table explicitly highlights the key differences. It shows that Security Groups operate at the instance level and support "Allow rules only

" while Network ACLs operate at the subnet level and support "Allow and deny rules." This confirms that a NACL is the correct tool for a deny action and that applying it to the source subnet's outbound traffic (as in option D) is the correct implementation.

Source: AWS VPC User Guide

Section: "Control traffic to resources using security groups"

Sub-section: "Compare security groups and network ACLs".

Amazon ElastiCache for Redis Global Datastore is a feature specifically designed to meet these requirements. It provides a fully managed, fast, and secure solution for replicating a Redis cluster across multiple AWS Regions. This feature enables low-latency global reads and disaster recovery by allowing a secondary cluster in another Region to be promoted to primary with minimal downtime. All cross-Region traffic within a Global Datastore is encrypted, fulfilling the security requirement. This managed service approach represents the least operational effort compared to manual replication or backup-and-restore methods.

A. Using AWS Database Migration Service (AWS DMS) for cache replication is not a standard pattern and introduces significant operational complexity, contradicting the "least effort" requirement.

C. This option is incorrect for the same reason as option A; AWS DMS is not the appropriate tool for low-latency cache replication and adds unnecessary operational overhead.

D. A snapshot-and-restore strategy is a valid disaster recovery method but does not provide low-latency replication. This approach leads to a higher Recovery Point Objective (RPO).

1. AWS ElastiCache User Guide for Redis: "Replication Across AWS Regions Using Global Datastore" - This section details that Global Datastore is designed for "fully managed

fast

reliable

and secure cross-region replication." It explicitly states its use for "low latency global reads and disaster recovery."

2. AWS ElastiCache User Guide for Redis: "Disaster Recovery with Global Datastore" - This page describes the process of promoting a secondary cluster to primary in a disaster recovery scenario

highlighting the managed failover capability. It notes

"In the unlikely event of regional degradation

one of the healthy secondary clusters can be promoted to become the new primary with full read/write capabilities."

3. AWS ElastiCache User Guide for Redis: "Encryption in Transit" - This section confirms that for Global Datastore

"All inter-region traffic between the clusters is encrypted." This directly addresses the security requirement in the question.

Amazon RDS Read Replicas are designed specifically for offloading read-heavy workloads, such as business reporting queries, from the primary (source) DB instance. By creating a read replica, you get a read-only copy of your database that is updated asynchronously from the source. Directing the reporting queries to the read replica isolates this workload, ensuring that the performance of write operations on the primary DB instance is not affected. This solution directly addresses the requirement to separate read and write traffic to maintain performance.

B: You cannot place a standard RDS DB instance behind an Elastic Load Balancer to scale it horizontally. This architecture is not supported and does not solve the read/write workload separation issue.

C: Scaling up (vertical scaling) provides more resources to a single instance but does not isolate workloads. An intensive reporting query can still consume shared resources and impact write performance.

D: A standby DB instance is part of a Multi-AZ deployment for high availability and disaster recovery. It is not accessible for read traffic and only becomes active if the primary instance fails.

1. AWS Documentation - Amazon RDS User Guide: "Working with Amazon RDS read replicas" - This document states

"You can reduce the load on your source 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." It also explicitly mentions

"One common use for read replicas is for business intelligence (BI) reporting."

2. AWS Documentation - Amazon RDS User Guide: "High availability (Multi-AZ) for Amazon RDS" - This guide clarifies the purpose of a standby instance: "The primary benefit of a Multi-AZ deployment is high availability... You can't use a standby replica to serve read traffic." This directly refutes the solution proposed in option D.

3. AWS Documentation - Amazon RDS User Guide: "DB instance classes" - This section describes modifying an instance class (scaling up). While this increases capacity

it does not provide the workload isolation required by the question

making it a less suitable solution than read replicas for this specific use case.

AWS IAM Identity Center (formerly AWS SSO) is designed for centrally managing Single Sign-On (SSO) access to multiple AWS accounts and applications. It integrates with AWS Organizations to provide a single point of administration. By configuring the existing on-premises Active Directory as the identity source (typically via AWS Directory Service AD Connector), the company can allow employees to use their current credentials. IAM Identity Center has built-in capabilities to enforce multi-factor authentication (MFA). Permissions are managed centrally by creating permission sets and assigning Active Directory groups to these sets for specific AWS accounts, fulfilling all the stated requirements in a streamlined and recommended manner.

A. This approach is decentralized and inefficient. Managing IAM identity providers and roles in each account separately defeats the purpose of central management, which is a core benefit of IAM Identity Center.

B. This solution creates a new, separate directory instead of using the existing on-premises Active Directory, which directly violates a primary requirement of the company.

D. This describes a complex, custom synchronization solution that creates duplicate IAM users. This is an anti-pattern that increases management overhead and security risks compared to using federation with IAM Identity Center.

1. AWS IAM Identity Center User Guide - How it works: "IAM Identity Center is integrated with AWS Organizations

which helps you to centrally manage the billing

apply policies

and simplify access management across multiple AWS accounts... You can choose to manage your users and groups in IAM Identity Center

or manage them in a connected directory

including AWS Directory Service

or an external identity provider." This supports the central management and identity source aspects of option C.

Source: AWS IAM Identity Center User Guide

"What is AWS IAM Identity Center?"

"How it works" section.

2. AWS IAM Identity Center User Guide - Choose your identity source: "When you use Active Directory as your identity source

your users can sign in to the AWS access portal with their Active Directory credentials. You can connect to your self-managed Active Directory in your on-premises data center..." This confirms the ability to use an existing on-premises AD.

Source: AWS IAM Identity Center User Guide

"Manage your identity source"

"Choose your identity source" section.

3. AWS IAM Identity Center User Guide - Multi-factor authentication: "You can enable multi-factor authentication (MFA) for your users in IAM Identity Center... When MFA is enabled

users are prompted for an MFA code from their authenticator app when they sign in to the AWS access portal." This confirms the MFA enforcement capability.

Source: AWS IAM Identity Center User Guide

"Security"

"Multi-factor authentication" section.

4. AWS Directory Service Administration Guide - AD Connector: "AD Connector is a directory gateway with which you can redirect directory requests to your on-premises Microsoft Active Directory without caching any information in the cloud." This explains the mechanism for connecting the on-premises AD.

Source: AWS Directory Service Administration Guide

"What is AWS Directory Service?"

"AD Connector" section.

This solution provides the most operationally efficient and automated method to meet the requirements. When a user requests data deletion, an event triggers an AWS Lambda function. This function updates the specific user's item in the DynamoDB table by adding or updating a TTL attribute with a timestamp set for one month in the future. With TTL enabled on the table, DynamoDB's managed background process automatically checks for and deletes items whose TTL timestamp has passed. This approach is serverless, requires no custom scheduling or scanning logic, and leverages a built-in DynamoDB feature designed for this exact purpose, ensuring the least operational overhead.

A. DynamoDB TTL expirations do not natively emit events to Amazon EventBridge. This architecture proposes a non-existent trigger mechanism.

B. A DynamoDB stream is populated after an item is deleted by TTL. The Lambda function's described purpose—to delete the data—is redundant as the deletion has already occurred.

D. AWS Config is a service for assessing and auditing resource configurations (e.g., table settings), not for tracking or reacting to item-level data plane operations like TTL deletions.

1. AWS DynamoDB Developer Guide

"Expiring Items by Using DynamoDB Time to Live (TTL)": This document explains the core mechanism. It states

"Time to Live (TTL) for Amazon DynamoDB automatically deletes expired items from your tables... You can set a specific timestamp for an item to be deleted... DynamoDB deletes expired items on a best-effort basis... at no extra cost." This directly supports the use of TTL as the deletion mechanism in option C.

2. AWS DynamoDB Developer Guide

"TTL and DynamoDB Streams": This section clarifies the interaction between TTL and other services. It notes

"Each item deleted by TTL is removed from the table. If you have DynamoDB Streams enabled on the table

a delete stream record is generated for each item that is deleted by the TTL process." This confirms that the deletion happens first

making the logic in option B incorrect.

3. AWS Lambda Developer Guide

"Using AWS Lambda with Amazon DynamoDB": This guide details how to trigger Lambda functions from user actions or API calls to interact with DynamoDB. Section "Tutorial: Using an API Gateway REST API to access DynamoDB" shows a common pattern where an API call (like a user request) invokes a Lambda function that then performs an action on a DynamoDB table

which aligns with the workflow in option C.

4. AWS Config Developer Guide

"AWS Resource and Property Types Reference": Under the AWS::DynamoDB::Table resource type

the trackable properties are listed. These include AttributeDefinitions

KeySchema

and TimeToLiveSpecification

but not individual item deletions. This confirms that AWS Config is not the correct tool for this task

invalidating option D.

To decrease latency for a global user base, an edge-optimized API endpoint is the best choice. This endpoint type leverages the Amazon CloudFront content delivery network (CDN) to route requests to the nearest edge location, minimizing network latency. Enabling API caching serves frequently requested data from the cache at the edge, further reducing latency by avoiding calls to the backend Lambda function. Additionally, enabling content encoding compresses the API payload, which reduces the amount of data transferred over the network. This smaller payload size decreases transfer time, directly contributing to lower overall latency for the end-user.

B. A Regional API endpoint is not suitable for a global user base as it does not use the CloudFront CDN, leading to higher latency for users geographically distant from the deployment region.

C. Reserved concurrency for Lambda manages execution capacity and prevents throttling; it does not directly reduce network transfer latency, which is the primary concern for a global audience.

D. This option combines two suboptimal choices: a Regional endpoint, which increases network latency for global users, and reserved concurrency, which does not address the core issue of transfer latency.

1. AWS API Gateway Developer Guide

"Choosing an API endpoint type to set up": This document states

"An edge-optimized API endpoint is best for geographically distributed clients. API requests are routed to the nearest CloudFront Point of Presence (POP)." This supports the choice of an edge-optimized endpoint for a worldwide user base.

2. AWS API Gateway Developer Guide

"Enable payload compression for an API": This guide explains

"When a client enables compression

the client can receive the API's response with a compressed payload... This can reduce the size of the response payload

which can reduce the latency of your API." This validates the use of content encoding.

3. AWS API Gateway Developer Guide

"Enabling API caching to enhance responsiveness": This source details how caching works: "You can enable API caching in Amazon API Gateway to cache your endpoint's responses. With caching

you can reduce the number of calls made to your endpoint and also improve the latency of requests to your API."

4. AWS Lambda Developer Guide

"Configuring reserved concurrency": This document clarifies the purpose of reserved concurrency: "To guarantee that a specific function can scale to a certain number of concurrent executions without being throttled

you can configure reserved concurrency." This shows it's for performance and availability

not network latency reduction.

The scenario requires distributing static media files (videos, images) from an Amazon S3 bucket to a large, global user base while reducing the load on the S3 origin. Amazon CloudFront is a Content Delivery Network (CDN) specifically designed for this purpose. It caches copies of the S3 content at edge locations worldwide, physically closer to the users. When a user requests a file, it is served from the nearest edge location, which significantly reduces latency and improves performance. This caching mechanism also minimizes direct requests to the S3 bucket, thereby reducing origin load and often lowering data transfer costs.

A. AWS Global Accelerator improves network pathing to application endpoints but does not cache content. It would not reduce the request load on the S3 origin.

C. Amazon ElastiCache (Redis OSS) is an in-memory caching service used to accelerate applications and databases, not for distributing static web content globally to end-users.

D. Amazon ElastiCache (Memcached) is also an in-memory cache for application-level data. It is not a CDN and is unsuitable for this use case.

1. Amazon CloudFront Developer Guide: "Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content

such as .html

.css

.js

and image files

to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations... If the content is not in that edge location

CloudFront retrieves it from an origin that you've defined—such as an Amazon S3 bucket..." (Source: AWS Documentation

"What is Amazon CloudFront?"

Introduction).

2. AWS Global Accelerator Developer Guide: "AWS Global Accelerator and Amazon CloudFront are separate services that use the AWS global network and its edge locations... CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content... Global Accelerator improves performance for a wide range of applications over TCP or UDP..." (Source: AWS Documentation

"Comparing AWS Global Accelerator and Amazon CloudFront"

Section: "When to use Global Accelerator or CloudFront").

3. Amazon ElastiCache User Guide: "Common use cases for ElastiCache include caching database query results

sessions

and other data that is accessed frequently to improve application performance. It is not designed to serve as a content delivery network (CDN) for static assets like images and videos to end-users." (Source: AWS Documentation

"What is Amazon ElastiCache?"

Section: "Common Use Cases").

4. AWS Well-Architected Framework

Performance Efficiency Pillar (Dec 2023): "For static assets that are accessed frequently

use a content delivery network (CDN). A CDN places your content in multiple locations worldwide

which reduces the latency to retrieve these assets. It also reduces the load on your origin servers because requests are served from the cache in the CDN." (Source: AWS Whitepaper

"AWS Well-Architected Framework

Performance Efficiency Pillar"

Page 26

Section: "Use caching to reduce latency").

Predictive scaling is the optimal solution as it is designed for workloads with recurring, cyclical patterns, such as the weekly batch jobs described. It uses machine learning to analyze historical CloudWatch metrics (like CPU utilization) to forecast future capacity needs. This allows it to proactively launch the required number of instances in advance of the anticipated demand, directly meeting the requirement to provision capacity 30 minutes before the jobs run. This approach is fully automated, handles the variable transaction load by adjusting its forecast, and requires the least operational overhead as it eliminates the need for manual trend analysis and configuration.

A. A dynamic scaling policy is reactive. It would only scale out after CPU utilization has already reached 60%, failing the requirement to provision capacity 30 minutes in advance.

B. A scheduled scaling policy requires manually setting a fixed desired capacity. This is inefficient for a variable workload and contradicts the requirement of having no resources to analyze capacity trends.

D. This custom solution using EventBridge and Lambda is reactive, triggering only after high CPU usage. It also introduces significantly more development and maintenance overhead compared to a native Auto Scaling feature.

1. AWS Auto Scaling User Guide

"Predictive scaling for Amazon EC2 Auto Scaling": This document states

"Predictive scaling is well suited for applications that have recurring load patterns... It predicts future traffic... and provisions the right number of EC2 instances in advance of predicted changes." This directly supports the proactive and automated nature of the correct answer.

2. AWS Auto Scaling User Guide

"Scaling policy types": This section compares scaling policies. It describes dynamic scaling as a reactive method

while highlighting predictive scaling's ability to "proactively scale your Auto Scaling group." This contrast clarifies why option A is incorrect.

3. AWS Auto Scaling User Guide

"Scheduled scaling for Amazon EC2 Auto Scaling": This guide explains that for scheduled actions

you must specify the new values for minimum

maximum

and desired size. This confirms the manual input required

making it less suitable than predictive scaling for this scenario

as explained for option B.

4. AWS Auto Scaling User Guide

"Target tracking scaling policies for Amazon EC2 Auto Scaling": The documentation describes how target tracking works to keep a metric at or close to a specified target value. This confirms its reactive nature

as it adjusts capacity based on current

not future

load.

AWS IAM Identity Center (formerly AWS SSO) is the recommended service for centrally managing workforce access to multiple AWS accounts and applications. It integrates seamlessly with AWS Organizations, allowing for scalable management. IAM Identity Center can connect to an external identity provider (IdP), enabling employees to use their existing corporate credentials to sign in. Users and groups can be provisioned from the IdP into IAM Identity Center, and then permission sets are used to grant role-based access to the various AWS accounts within the organization. This solution directly meets all the requirements for centralized, federated access for thousands of users across multiple accounts.

A. Creating individual IAM users for thousands of employees across 10 accounts is not scalable and is a significant management overhead. Federation provides temporary credentials to assume roles, not to authenticate IAM users.

B. Using the root user for regular access is a major security anti-pattern. The root user should be highly secured and used only for specific account management tasks, not for general employee access.

D. AWS Resource Access Manager (AWS RAM) is used for sharing specific AWS resources (e.g., subnets, Transit Gateways) across accounts, not for managing user identities or providing federated access to accounts.

1. AWS IAM Identity Center User Guide

"What is AWS IAM Identity Center?": "AWS IAM Identity Center (IAM Identity Center) helps you to securely create or connect your workforce identities and manage their access centrally across AWS accounts and applications." This document also details connecting to an external identity provider under the "Choose your identity source" section.

2. AWS IAM Identity Center User Guide

"Manage access to AWS accounts": This section explains how IAM Identity Center uses permission sets to control access to AWS accounts within an AWS Organization

which is the core of the solution required by the question.

3. AWS IAM User Guide

"Identity providers and federation": This guide explains that federation allows you to manage user identities outside of AWS and grant them temporary credentials to access AWS resources by assuming IAM roles. This contrasts with creating permanent IAM users.

4. AWS Security Best Practices Whitepaper

"AWS Identity and Access Management" section: This whitepaper emphasizes using IAM Identity Center for managing human user access

stating

"For human users that require access to your AWS accounts and workloads

we recommend that you use AWS IAM Identity Center to provide a single sign-on experience." (Page 10).

5. AWS Resource Access Manager User Guide

"What is AWS Resource Access Manager?": "AWS Resource Access Manager (RAM) is a service that enables you to easily and securely share AWS resources with any AWS account or within your AWS Organization." This confirms RAM's purpose is resource sharing

not identity federation.

Amazon Elastic File System (EFS) is the ideal solution for this scenario. It provides a fully managed, scalable, and high-performance Network File System (NFS) that can be concurrently mounted by thousands of Amazon EC2 instances. EFS is a regional service, meaning it stores data across multiple Availability Zones (AZs) for high availability. By creating EFS mount targets in the subnets of each AZ where the EC2 instances are running, all instances can share the same file system seamlessly. All data traffic between the EC2 instances and the EFS file system remains within the Virtual Private Cloud (VPC), satisfying the security requirement.

A. Amazon S3 is an object storage service, not a file system. Accessing data via API calls is fundamentally different from a mounted file system and may not be suitable or performant for applications expecting POSIX-compliant file access.

B. Amazon S3 cannot be natively mounted as a volume on EC2 instances. This would require a third-party utility or a service like AWS Storage Gateway, which adds unnecessary complexity for this use case.

C. An Amazon EBS volume is block-level storage that is zonal; it can only be attached to instances within the same single Availability Zone. It cannot be mounted across instances in multiple AZs.

1. Amazon EFS User Guide

"What is Amazon EFS?": This document states

"Amazon EFS is a regional service

storing data within and across multiple Availability Zones (AZs) for high availability and durability... It provides massively parallel shared access to thousands of Amazon EC2 instances." This directly supports the use of EFS for shared access across multiple AZs.

2. Amazon EC2 User Guide for Linux Instances

"Amazon EBS volumes": This guide clarifies the limitation of EBS

stating

"EBS volumes are specific to an Availability Zone and can only be attached to instances in that same Availability Zone." This confirms why option C is incorrect.

3. Amazon EFS User Guide

"Mounting EFS file systems": This section explains how EFS works within a VPC: "You access your Amazon EFS file system from your VPC by connecting to a mount target... Traffic from your EC2 instance to the mount target is routed according to the VPC routing rules

" which ensures data stays within the VPC.

4. Amazon S3 User Guide

"What is Amazon S3?": This document defines S3 as "an object storage service" and notes that data is accessed via "the Amazon S3 REST API." This highlights the difference between S3's object-based access and the file-system access required by the scenario

making options A and B less suitable.

This solution correctly addresses both secure connectivity and granular access control with minimal operational overhead. A gateway VPC endpoint for Amazon S3 allows EC2 instances to access S3 using private IP addresses, keeping traffic within the AWS network and avoiding the public internet. This is more secure and cost-effective than using a NAT gateway.

An IAM instance profile attached to the EC2 instances is the standard method for granting permissions. The associated IAM policy can be configured to grant access only to specific S3 buckets, enforcing the principle of least privilege. By using wildcards in the bucket ARN (e.g., arn:aws:s3:::company-customer-), the policy can automatically apply to new customer buckets without modification, thus ensuring low operational overhead.

B: A NAT gateway routes traffic over the public internet to reach S3, which is less secure than a VPC endpoint. It also fails to specify how access control to specific buckets would be enforced.

C: While a gateway endpoint is correct, this option describes an incomplete policy. A Deny policy acts as a guardrail but does not grant permissions. An explicit Allow action is still required for the instances to access any buckets.

D: Using a NAT gateway is inefficient for this use case. Furthermore, managing individual bucket policies for every customer bucket creates significant operational overhead compared to managing a single IAM role policy.

1. AWS Documentation - VPC Endpoints for Amazon S3: "A gateway endpoint is a gateway that you specify as a target for a route in your route table for traffic destined to a supported AWS service... Gateway endpoints are supported for Amazon S3 and DynamoDB." This confirms the use of a gateway endpoint for private S3 access. (Source: AWS VPC User Guide

"Gateway VPC endpoints").

2. AWS Documentation - IAM Roles for Amazon EC2: "Applications must sign their API requests with AWS credentials. Therefore

if you are an application developer

you need a strategy for managing credentials for your applications that run on EC2 instances... We recommend that you use IAM roles for Amazon EC2." (Source: AWS IAM User Guide

"IAM roles for Amazon EC2").

3. AWS Documentation - Policies and Permissions in Amazon S3: "You can use wildcards () as part of the resource ARN... For example

you can use the following Resource element to grant permission to objects in a specific bucket where the object keys are prefixed with logs/." This supports using wildcards in an IAM policy for low-overhead management. (Source: Amazon S3 User Guide

"Policies and permissions in Amazon S3"

section on "Specifying resources in a policy").

4. AWS Documentation - aws:ResourceAccount Condition Key: "Use this key to compare the AWS account ID of the resource in the request with the account ID that you specify in the policy." While this key is valid for creating account-level guardrails

option C's reliance solely on a Deny policy makes it an incomplete solution for granting access. (Source: AWS IAM User Guide

"AWS global condition context keys").

This solution correctly addresses all requirements with the least operational effort. AWS Glue is a fully managed ETL service, which significantly reduces operational overhead compared to managing an Amazon EMR cluster. Creating a separate Glue job for each customer ensures logical separation. The requirement to encrypt data where it is processed and before storing it in Amazon S3 points to a client-side encryption strategy. Using client-side encryption with AWS KMS managed keys (CSE-KMS) allows the Glue job (the "client") to encrypt data using customer-specific KMS keys before writing the data to S3, fulfilling the encryption and key management requirements with minimal operational burden.

A: Server-side encryption with S3-managed keys (SSE-S3) does not use customer-specific keys, failing a key requirement.

B: Amazon EMR requires more operational effort than AWS Glue. Furthermore, using a custom client-side root key (CSE-Custom) adds significant key management overhead.

D: Amazon EMR has higher operational overhead than AWS Glue. Also, server-side encryption (SSE-KMS) encrypts data upon arrival at S3, not necessarily during processing on the cluster itself.

1. AWS Glue Developer Guide - Security configurations on the AWS Glue console: "You can use security configurations to encrypt your data at rest... When you specify a security configuration for an AWS Glue job

you can specify a KMS key to encrypt at-rest data that is written to local disks by ETL jobs when spilling data." This supports encrypting data "where it is processed".

2. Amazon S3 User Guide - Protecting data using client-side encryption: "Client-side encryption is the act of encrypting your data locally... The AWS Encryption SDK supports client-side encryption with AWS KMS." This document explains that the application (in this case

the AWS Glue job script) performs encryption before upload

which aligns with the CSE-KMS strategy.

3. AWS Glue FAQs: "AWS Glue is a fully-managed ETL service that makes it simple and cost-effective to categorize your data... You don’t need to create and manage the infrastructure." This confirms that AWS Glue is the choice for the least operational effort compared to Amazon EMR.

The most effective and secure method to grant granular AWS permissions to specific pods within an Amazon EKS cluster is by using IAM Roles for Service Accounts (IRSA). This approach adheres to the principle of least privilege. The solution involves creating distinct Kubernetes service accounts for the UI and the data services. Corresponding IAM roles are then created, one with a policy granting only DynamoDB access and the other with a policy granting only S3 access. Each service account is configured to assume its respective IAM role. When a pod is deployed with a specific service account, it automatically receives temporary credentials for the associated IAM role, ensuring it can only access the intended AWS service.

A: Attaching policies to the EC2 instance profile grants permissions to all pods on that node, which violates the principle of least privilege as the UI pod could access S3 and vice-versa.

B: IAM policies cannot be attached directly to EKS pods. Policies are associated with IAM identities (like roles), which pods can then assume via a service account.

D: This option correctly identifies the IRSA mechanism but incorrectly maps the permissions. It grants S3 access to the UI and DynamoDB access to the data services, which is the reverse of the stated requirement.

1. AWS EKS User Guide

"IAM roles for service accounts": This document states

"With IAM roles for service accounts

you can associate an IAM role with a Kubernetes service account. This service account can then provide AWS permissions to the containers in any pod that uses that service account." This directly supports the mechanism of associating a role with a service account as described in the correct answer. (Source: AWS Official Documentation

Amazon EKS User Guide

Section: Identity and access management > IAM roles for service accounts).

2. AWS EKS Best Practices Guides

"IAM Roles for Service Accounts (IRSA)": This guide explicitly recommends

"We recommend using IAM Roles for Service Accounts (IRSA) to assign IAM permissions to your pods." It further warns against attaching permissions to nodes: "Avoid assigning IAM permissions directly to nodes. This would grant those permissions to any pod that is scheduled on that node." This directly refutes option A and endorses the approach in option C. (Source: AWS Official Documentation

Amazon EKS Best Practices Guide for Security

Section: Identity and Access Management > IAM Roles for Service Accounts (IRSA)).

3. AWS Whitepaper

"Amazon Elastic Kubernetes Service (EKS) running on AWS Fargate Security Overview": While focused on Fargate

the principle is identical for EC2 nodes. Page 10 discusses IRSA

explaining that it allows for "fine-grained permission management" by associating IAM roles with Kubernetes service accounts

which is the core concept of the correct solution. (Source: AWS Whitepapers & Guides

Document ID: AWS-EKS-Fargate-Security-Overview-2020

Page 10

Section: IAM Roles for Service Accounts).

The scenario requires DNS queries originating from an on-premises network to be resolved for resources within an AWS VPC. Amazon Route 53 Resolver is the service designed for this hybrid cloud DNS integration. An inbound endpoint for Route 53 Resolver provides one or more elastic network interfaces (ENIs) within the VPC. The on-premises DNS server can then be configured to conditionally forward DNS queries for the VPC's domain to the IP addresses of these ENIs. The inbound endpoint allows Route 53 Resolver to receive these queries from the on-premises network over the Direct Connect connection and resolve them using the VPC's DNS.

A. AWS Verified Access is a service for providing secure, VPN-less access to corporate applications. It is not a general-purpose DNS resolution service for hybrid networks.

B. AWS Direct Connect provides the private network connectivity between the on-premises data center and the VPC, but it does not have built-in DNS resolution capabilities.

C. A Route 53 Resolver outbound endpoint is used for the opposite direction: forwarding DNS queries from the VPC to an on-premises DNS server.

1. Amazon Route 53 Developer Guide: Under the section "Resolving DNS queries between VPCs and your network

" it states

"To forward DNS queries from your network to Route 53 Resolver

you create a Route 53 Resolver inbound endpoint in a VPC... Then you configure your on-premises DNS resolver to forward the applicable DNS queries to the IP addresses for the inbound endpoint." (See: How Route 53 Resolver works with your network).

2. Amazon Route 53 Developer Guide: The guide clarifies the function of endpoints: "Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC." (See: Managing Resolver endpoints).

3. AWS Documentation - What is AWS Verified Access?: This service is described as one that "provides secure access to your corporate applications without requiring a VPN." This confirms it is an application access service

not a DNS resolver. (See: AWS Verified Access User Guide

Introduction).

4. AWS Documentation - What is AWS Direct Connect?: This service is defined as a way "to establish a dedicated network connection from your premises to AWS." It is a networking service

not a DNS service. (See: AWS Direct Connect User Guide

Introduction).

The requirement is to encrypt personally identifiable information (PII) at rest for an application running on Amazon EC2 and its Amazon RDS database, with minimal infrastructure changes. Amazon EBS encryption is a native feature that encrypts data at rest for volumes attached to EC2 instances. Similarly, Amazon RDS encryption encrypts the underlying database storage, automated backups, read replicas, and snapshots. Both services seamlessly integrate with AWS Key Management Service (KMS) to manage the encryption keys. Enabling these features is a straightforward configuration change, directly addressing the compliance requirement for both tiers of the application with the least operational overhead.

A. AWS Certificate Manager (ACM) provides and manages SSL/TLS certificates for securing network communications (data in transit), not for encrypting data at rest on storage volumes.

B. AWS CloudHSM provides dedicated hardware security modules. While it can be used for encryption, it is a more complex and costly solution, violating the "least amount of changes" requirement.

C. This option incorrectly combines SSL encryption, which is for data in transit, with the task of encrypting database volumes at rest. SSL does not encrypt the underlying storage.

1. Amazon EBS encryption: "Amazon EBS encryption is a feature that offers a simple encryption solution for your EBS volumes without you having to build

maintain

and secure your own key management infrastructure. It uses AWS Key Management Service (AWS KMS) keys when creating encrypted volumes and snapshots."

Source: AWS Documentation

Amazon EC2 User Guide for Linux Instances

"Amazon EBS encryption"

Section: "How EBS encryption works".

2. Amazon RDS encryption: "Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server that hosts your DB instance. After your data is encrypted

Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. You don't need to modify your database client applications to use encryption... Amazon RDS uses AWS Key Management Service (AWS KMS) to manage the encryption keys for your encrypted DB instances."

Source: AWS Documentation

Amazon RDS User Guide

"Encrypting Amazon RDS resources".

3. AWS KMS Integration: "AWS KMS integrates with many AWS services to help you protect the data that you store in those services. When you use an AWS service that is integrated with AWS KMS

you can use the service to encrypt your data."

Source: AWS Documentation

AWS Key Management Service Developer Guide

"How AWS services use AWS KMS".

4. AWS Certificate Manager Purpose: "AWS Certificate Manager is a service that lets you easily provision

manage

and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for use with AWS services and your internal connected resources."

Source: AWS Documentation

AWS Certificate Manager User Guide

"What is AWS Certificate Manager?".

The solution requires an API that supports robust user authentication and authorization, geographic access restriction, and minimal latency for users in the United States.

Amazon API Gateway REST APIs are better suited for this scenario than HTTP APIs because they offer more comprehensive, built-in features for authentication and authorization, such as IAM permissions, Cognito user pools, and Lambda authorizers.

To restrict access based on geography, AWS WAF is the appropriate service. A WAF geographic match rule can be configured to allow requests only from the United States. For a regional API Gateway endpoint, the AWS WAF web ACL must be deployed in the same AWS Region as the API. Deploying this regional API in a US region ensures minimal latency for the target user base.

B. This is incorrect. For a regional resource like an API Gateway HTTP API, the AWS WAF web ACL must be configured in the same Region, not a different one.

C. This describes a configuration for an edge-optimized API deployed in a region other than us-east-1. While valid, a regional API (as implied in option A) is a more direct and standard solution that fully meets the requirements.

D. While the WAF configuration is technically correct for an HTTP API, REST APIs provide a richer feature set for the specified "user authentication and authorization" requirements, making them the superior choice.

1. AWS Documentation - Choosing between HTTP APIs and REST APIs: "REST APIs provide a wide array of features for building and managing APIs... If you need features such as API keys

per-client throttling

request validation

AWS WAF integration

or private API endpoints

use a REST API." This supports the choice of a REST API for its richer feature set related to authorization.

Source: AWS API Gateway Developer Guide

"Choosing between HTTP APIs and REST APIs."

2. AWS Documentation - Associating a web ACL with an AWS resource: "For Amazon API Gateway

you can associate a web ACL with a regional API or an edge-optimized API... For a regional API

you must create your web ACL in the same AWS Region as your API." This confirms that for a regional API

the WAF must be in the same region

validating the configuration in option A and invalidating option B.

Source: AWS WAF Developer Guide

"Associating or disassociating a web ACL with an AWS resource."

3. AWS Documentation - Geographic match rule statement: "A geographic match rule statement inspects the source IP address of a web request against a list of countries that you specify." This confirms WAF's capability to meet the geographic restriction requirement.

Source: AWS WAF Developer Guide

"Rule statement basics

" section "Geographic match rule statement."

4. AWS Documentation - Choosing an API Gateway API endpoint type to set up: "Regional API endpoints are intended for clients in the same AWS Region. When clients are in the same Region as the API

a Regional API reduces connection overhead." This supports that a regional endpoint in the US provides low latency for US-based clients.

Source: AWS API Gateway Developer Guide

"Choosing an API Gateway API endpoint type to set up."

This solution provides the highest level of security by implementing a defense-in-depth strategy. Placing the Amazon RDS cluster in private subnets ensures it is not directly accessible from the public internet, which is a fundamental security best practice for databases. An AWS Site-to-Site VPN establishes a secure, encrypted IPsec tunnel between the company's on-premises office and the AWS VPC. This allows the desktop clients to communicate with the RDS cluster over a private, encrypted connection as if it were on the local network, without exposing any resources to the public internet. This combination of network isolation (private subnets) and encrypted transit (VPN) represents the most secure architecture for the given requirements.

A. Placing the RDS cluster in public subnets exposes it to the internet, which is a significant and unnecessary security risk, even with a VPN.

C. This option is incomplete. Security groups alone cannot establish connectivity from an on-premises network to private subnets within a VPC; a VPN or AWS Direct Connect is required.

D. This is the least secure option. It places the database in public subnets and relies only on security groups for network filtering, creating a direct attack surface on the internet.

1. AWS Documentation - Amazon RDS User Guide: Under "Security in Amazon RDS

" the section "Using Amazon RDS with Amazon VPC" states

"A common strategy is to have a public subnet with a web server that has access to the internet

and a private subnet with no internet access that contains your DB instances... We recommend that you run your DB instance in a private subnet." This supports placing RDS in private subnets for security.

2. AWS Documentation - AWS Site-to-Site VPN User Guide: The "What is AWS Site-to-Site VPN?" section explains

"By default

instances that you launch into an Amazon VPC can't communicate with your own (remote) network. You can enable access to your remote network from your VPC by creating an AWS Site-to-Site VPN (Site-to-Site VPN) connection..." This confirms VPN is the correct tool for secure on-premises to VPC connectivity.

3. AWS Whitepapers - "Amazon Virtual Private Cloud Connectivity Options": This whitepaper details connectivity patterns. In the section "AWS Managed VPN

" it describes the service as a way to "establish an encrypted connection between your on-premises network and your Amazon VPCs over the internet." This validates the use of a VPN for secure

private communication.

4. AWS Documentation - Amazon VPC User Guide: The "Subnets for your VPC" section clarifies the distinction: "Resources in a private subnet can't be accessed from the internet." This reinforces why databases should be placed in private subnets to meet the "MOST securely" requirement.

The primary requirement is to migrate a Microsoft SQL Server database to AWS while optimizing costs. Babelfish for Aurora PostgreSQL is a capability of Amazon Aurora PostgreSQL-Compatible Edition that allows it to understand the SQL Server wire protocol (TDS) and T-SQL dialect. This enables migration from SQL Server to the cost-effective, open-source-compatible Aurora PostgreSQL engine with minimal to no application code changes. By moving away from the commercial SQL Server engine, the company eliminates expensive licensing fees, which is the most significant factor in cost optimization for this scenario. Aurora's managed nature also reduces operational overhead compared to self-managed solutions.

A. Migrating to SQL Server on EC2 still requires paying for Microsoft SQL Server licenses and adds the operational burden of managing the instance, making it less cost-optimized.

C. A direct migration to PostgreSQL on EC2 would require significant, costly application refactoring and schema conversion, and lacks the benefits of a managed database service.

D. Amazon RDS for Microsoft SQL Server is a managed service but still incurs licensing costs for the commercial SQL Server engine, failing to meet the primary goal of cost optimization.

1. AWS Documentation

"Working with Babelfish for Aurora PostgreSQL": In the section "What is Babelfish for Aurora PostgreSQL?"

it states

"With Babelfish

Aurora PostgreSQL now understands T-SQL

Microsoft SQL Server's proprietary SQL dialect

and supports the same communications protocol

so your apps that were originally written for SQL Server can now work with Aurora with fewer code changes." This confirms its suitability for migrating SQL Server applications.

2. AWS Documentation

"Migrating a SQL Server database to Babelfish for Aurora PostgreSQL": The overview section of this guide highlights the benefits

which include "Stop paying for expensive and restrictive database licenses." This directly addresses the cost optimization requirement of the question.

3. AWS Database Blog

"Modernize Microsoft SQL Server to Amazon Aurora with Babelfish": This article explains the value proposition: "Babelfish for Aurora PostgreSQL reduces the risk of migration projects by reducing the amount of code you have to change... It also helps you stop paying for expensive database licenses." This reinforces that Babelfish is the optimal path for cost-effective SQL Server modernization.

4. AWS Documentation

"Amazon Aurora Pricing": This page details the pricing for Aurora

which does not include commercial license fees

unlike RDS for SQL Server. It highlights cost-effectiveness through features like I/O-Optimized configurations and pay-per-use models

contrasting with the fixed licensing costs of commercial databases.