Free Practice Questions for Amazon Web Services SAA-C03 Exam

Amazon Macieis purpose-built for detecting PII in S3.

Option Auses EventBridge to filter SensitiveData findings and notify via SNS, meeting the requirements.

Options B and Dinvolve GuardDuty, which is not designed for PII detection.

Option Cuses SQS, which is less suitable for immediate notifications.

AWS Auto Scaling is the right answer because the requirement is to adjust capacity automatically based on a predictable time-based usage pattern. AWS documentation states that you can use scheduled scaling actions with Amazon EC2 Auto Scaling to change desired capacity at specific times or on recurring schedules. That makes it well suited for workloads that need more capacity during the day and less at night. Spot Instances and Reserved Instances are pricing models, not automation mechanisms for scheduled capacity changes. CloudFormation provisions infrastructure but does not itself optimize day-night scaling behavior. Therefore, AWS Auto Scaling is the correct service for this requirement.

Amazon RDS for MySQL Reserved Instances provide significant savings over on-demand pricing when you plan to run the database for long periods. This is the most cost-effective option for non-production, long-running managed MySQL workloads.

Reference Extract:

" Reserved Instances provide a significant discount compared to On-Demand pricing and are recommended for steady-state workloads that run for an extended period. "

Source: AWS Certified Solutions Architect – Official Study Guide, RDS Cost Optimization section.

AWS recommends using cost allocation tags to associate costs with owners (e.g., department, project) and AWS Budgets to create cost or usage budgets with alerts at defined thresholds (e.g., 60%). Budgets can send notifications via email or Amazon SNS when “Actual or forecasted” spend exceeds the threshold. Cost Explorer forecasts help visualize trends but do not provide budget alerting or ownership attribution by themselves. Trusted Advisor does not generate budget threshold alerts. Therefore, tagging resources for accountability and setting a budget with a 60% alert provides governance and proactive notifications aligned with cost control best practices for experimentation.

For steady, predictable EC2 usage with potential changes in instance families over time, AWS recommends Savings Plans. Compute Savings Plans “apply to any EC2 instance regardless of region, instance family, operating system, or tenancy,” and also apply to AWS Fargate and AWS Lambda, delivering the most flexibility over a multi-year horizon. A 3-year term provides the highest discount among Savings Plans for long-lived workloads. EC2 Instance Savings Plans are limited to a chosen instance family in a region; as needs evolve (e.g., size or family changes), discounts may not fully apply. Spot Instances are not appropriate for long, interruption-sensitive jobs because Spot capacity can be reclaimed with short notice. Therefore, a Compute Savings Plan (3-year) best matches cost optimization with flexibility for growth and changes.

EBS gp3 volumes allow you to independently configure IOPS and throughput, up to 16,000 IOPS, regardless of the volume size, and at a lower cost compared to io1/io2 provisioned IOPS volumes. This meets the requirement for cost-effective, predictable IOPS performance for Amazon RDS for PostgreSQL.

AWS Documentation Extract:

" With gp3 volumes, you can provision performance independent of storage capacity, up to 16,000 IOPS. This allows for cost-effective scaling for applications that require high performance at a lower price point compared to io1. "

(Source: Amazon EBS documentation, gp3 Volumes)

A: gp2 ties IOPS to volume size; 5 TiB is wasteful if only 15,000 IOPS are needed.

B: io1 works but is significantly more expensive than gp3 for most workloads.

D: Magnetic volumes do not support high IOPS.

Amazon FSx for NetApp ONTAP fully supports native NetApp SnapMirror replication, making it the most efficient and reliable option for migrating NetApp data from on-premises to AWS.

From AWS Documentation:

“You can use SnapMirror to replicate data from your on-premises NetApp systems to FSx for ONTAP for seamless, block-level, incremental transfers. This provides a highly efficient and performant method for migration, especially for large datasets.”

(Source: Amazon FSx for NetApp ONTAP – Migration Guide)

Why Option C is correct:

SnapMirror offers block-level replication, making it highly efficient for millions of small files.

It supports NFS and SMB file shares, preserving directory structures and permissions.

Reduces cutover time and allows for incremental syncs.

Uses the existing 10 Gbps network for fast transfers.

Why the other options are incorrect:

Option A (DataSync): Suitable for many file-based migrations but less efficient for very large datasets with millions of small files compared to SnapMirror.

Option B (Storage Gateway): Volume Gateway is not used for full-scale file migrations; it ' s for hybrid cloud access.

Option D (Snowball Edge): Useful for offline migrations, but online SnapMirror is more efficient and avoids shipping delays.

Amazon CloudFront caches eligible GET responses at globally distributed edge locations. After the first request is served from the API Gateway origin, subsequent requests can be returned from a nearby edge cache without invoking API Gateway’s Lambda integration. A one-hour TTL aligns with the catalog’s update frequency and substantially reduces both global network latency and Lambda invocation volume. API Gateway caching also reduces backend calls, but its cache is associated with the API stage in the deployment Region and does not provide the same globally distributed edge-cache benefit. Increasing Lambda memory might improve individual execution performance but would not eliminate repeated executions for identical catalog requests. Replacing the serverless API with an Application Load Balancer and EC2-based cache would increase operational overhead. CloudFront therefore satisfies both the global-latency and backend-load requirements.

================

AWS Global Accelerator is a service that improves global application availability and performance using the AWS global network. It supports both TCP and UDP protocols and provides optimized routing and lower latency for real-time applications such as VoIP, regardless of where the user is located globally.

AWS Documentation Extract:

" AWS Global Accelerator uses the AWS global network to optimize the path to your application endpoints, improving performance for TCP and UDP traffic, such as VoIP. "

(Source: AWS Global Accelerator documentation)

B: CloudFront accelerates HTTP/S content, not TCP/UDP.

C: Route 53 geoproximity routing is for DNS-based routing, not for traffic acceleration.

D: Network Load Balancers support TCP/UDP, but do not address global latency or provide acceleration.

Express Workflows in AWS Step Functions are optimized for high-throughput, short-duration, and low-cost workflows. They are suitable for applications with large volumes of parallel and interdependent tasks. When paired with HTTP APIs from API Gateway, which are more cost-efficient than REST APIs, this setup offers scalability and cost-effectiveness.

S3 Glacier Flexible Retrieval is designed for long-lived archive data that is accessed infrequently and can be retrieved in minutes to hours, making it a strong cost-effective choice for medical records that are rarely accessed. AWS documentation states that standard retrievals from this storage class typically finish in 3 to 5 hours, which fits the requirement to retrieve records within a few hours. For immutability, AWS S3 Object Lock provides a WORM model and can prevent deletion or overwriting for a fixed retention period. Together, Glacier Flexible Retrieval and Object Lock satisfy the needs for low-cost archival storage, long retention, immutability, and acceptable restore times. S3 Standard and Intelligent-Tiering cost more than necessary for rarely accessed 10-year data, and One Zone-IA does not provide the same resilience posture.

============

For an application requiring TCP communication and high availability:

Network Load Balancer (NLB)is the best choice for load balancing TCP traffic because it is designed for handling high-throughput, low-latency connections.

Auto Scaling groupensures that the application can automatically scale based on demand, adding or removing EC2 instances as needed, which is crucial for handling user growth.

Option C (Application Load Balancer): ALB is primarily for HTTP/HTTPS traffic, not ideal for TCP.

Option D (Manual scaling): Manually adding instances does not provide the automation or scalability required.

Option E (Gateway Load Balancer): GLB is used for third-party virtual appliances, not for direct application load balancing.

AWS References:

Network Load Balancer

Auto Scaling Group

Amazon Aurora global database is the best answer because AWS documents state that Aurora global database replicates data to secondary Regions using dedicated infrastructure, with latency typically under one second. That directly matches the requirement for near-real-time access in eu-west-2. AWS also notes that Aurora global database is intended for cross-Region reads with minimal lag and fast disaster recovery. Standard RDS cross-Region read replicas can help, but they are not positioned as the lowest-lag cross-Region option in the way Aurora global database is. DynamoDB global tables are excellent for globally distributed NoSQL workloads, but the question centers on database-backed dashboards with complex analytical queries, which aligns better with Aurora. For the most up-to-date cross-Region dashboard reads, Aurora global database is the strongest fit.

============

An Application Load Balancer supports path- and host-based routing, which makes it ideal for routing requests based on subdomains. EC2 Auto Scaling ensures that the number of instances adjusts dynamically based on traffic, which helps manage cost and performance during predictable peak hours.

Amazon S3 supports one Lifecycle configuration per bucket that can contain multiple rules. Lifecycle rules can include filters, including object size filters: ObjectSizeGreaterThan and ObjectSizeLessThan. You can combine rules so that one targets large objects and another provides a default expiration. Here, configure Rule 1 with a size filter ObjectSizeGreaterThan = 1 TB and Expiration = 2 days (48 hours) to purge very large videos early. Configure Rule 2 with Expiration = 7 days without a size filter to serve as a catch-all maximum retention for all objects. Options B and D are invalid because S3 does not allow multiple Lifecycle configurations per bucket. Option C cannot distinguish large files; it would delete all files at the same schedule without honoring the 48-hour policy for > 1 TB objects. This single configuration with two rules meets both retention targets with minimal overhead and full S3-native capability.

For processing thousands of images and generating large files while minimizing manual tasks and operational overhead, usingAWS Batchis the best solution. AWS Batch allows you to run large-scale, parallel, and managed batch computing jobs without needing to manage the underlying infrastructure.

AWS Batch: Automates the image processing jobs, dynamically allocating the necessary resources based on the job requirements, which reduces operational overhead.

AWS Step Functions: Orchestrates the entire image processing workflow, ensuring that tasks are executed in the correct sequence, improving manageability.

Amazon S3: Stores the processed files, providing scalable and cost-effective storage.

Option A (ECS with EC2 Spot Instances): While cost-effective, managing ECS and Spot Instances involves more operational effort.

Option C (Lambda with EC2 Spot): Lambda functions have size and duration limitations, making them less suited for large image processing tasks.

Option D (EC2 with Step Functions): Managing EC2 instances involves more overhead than using AWS Batch.

AWS References:

AWS Batch

AWS Step Functions

Amazon RDS for Oracle is a managed database service, which significantly reduces operational overhead compared to running Oracle on EC2 or on-premises. AWS Secrets Manager natively integrates with RDS and supports automatic, scheduled password rotation with minimal setup. You can configure the rotation schedule (including yearly), and Secrets Manager will handle the secure password storage and rotation workflow for you.

AWS Documentation Extract:

" AWS Secrets Manager helps you protect access to your applications, services, and IT resources without the upfront investment and on-going maintenance costs of operating your own infrastructure. You can configure automatic rotation for supported databases such as Amazon RDS for Oracle. "

(Source: AWS Secrets Manager documentation)

A, C, D: These solutions require custom scripting, Lambda, and alarms, leading to more operational overhead.

Amazon EFS is a regional, elastic file system that “scales to petabytes” and can be accessed from “thousands of compute instances” concurrently. You can mount EFS across VPCs and across AWS accounts by providing network connectivity (e.g., VPC peering) to the EFS mount targets and allowing NFS (TCP 2049) in the mount target security group, optionally using EFS access points and a file system policy for cross-account access control. VPC peering has no hourly charge and minimal operational overhead, and EFS automatically scales as files are added—meeting the scalability and cost goals.

Option A duplicates data, incurs DataSync and extra storage costs, and adds sync lag.

Option C adds an extra Lambda hop and complexity without exposing a shared filesystem to the primary function.

Option D is impractical: Lambda layers are immutable artifacts with tight size limits (up to 50 MB compressed/250 MB uncompressed) and are not suited for dynamic, growing file sets.

Option B: Pre-signed URLs provide temporary, authenticated access to S3, limiting uploads to the time frame specified. This solution is lightweight, efficient, and easy to implement.

Option Arequires the management of IAM temporary credentials, adding complexity.

Option Cinvolves unnecessary development effort.

Option Dintroduces more complexity with STS and roles than pre-signed URLs.