Free Practice Questions for Amazon Web Services SAA-C03 Exam

AWS Application Migration Service (AWS MGN) is the recommended tool for a lift-and-shift strategy, especially for time-sensitive migrations. It automates the replication of on-premises VMs to AWS, minimizing the effort required for migration and testing.

Key steps:

Replication with AWS MGN: The AWS Replication Agent is installed on the VMs to continuously replicate data to AWS, allowing you to manage migration easily.

Testing and Cutover: Initial replication allows for testing in AWS before performing the final cutover, ensuring that the migration process is smooth and data integrity is maintained.

AWS Documentation: AWS MGN is recommended for migrating virtual machines to the cloud with minimal downtime and disruption​​.

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.

The best answer is to enableS3 Block Public Access at the account leveland back it with theAWS Config s3-account-level-public-access-blocks ruleplus automated remediation. AWS states that S3 Block Public Access can be applied at the account level and overrides public bucket policies and ACLs so you can centrally prevent public access across the account. AWS Config provides a managed rule specifically for checking those account-level settings, and AWS Systems Manager includes an automation runbook to remediate drift. This is stronger and more scalable than relying on detection tools alone, because it both prevents exposure and automatically restores compliance if settings change. (AWS Documentation)

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

This solution provides encryption at rest and in transit with the least operational overhead while adhering to the company’s security policies.

Encryption at Rest: Amazon RDS for MySQL can be configured to encrypt data at rest by using AWS Key Management Service (KMS) managed keys. This encryption is applied automatically to all data stored on disk, including backups, read replicas, and snapshots. This solution requires minimal operational overhead because AWS manages the encryption and key management process.

Encryption in Transit: AWS Certificate Manager (ACM) allows you to provision, manage, and deploy SSL/TLS certificates seamlessly. These certificates can be used to encrypt data in transit by configuring the MySQL instance to use SSL/TLS for connections. This setup ensures thatdata is encrypted between the application and the database, protecting it from interception during transmission.

Why Not Other Options?:

Option B (IPsec tunnels): While IPsec tunnels encrypt data in transit, they are more complex to manage and require additional configuration and maintenance, leading to higher operational overhead.

Option C (Third-party application-level encryption): Implementing application-level encryption adds complexity, requires code changes, and increases operational overhead.

Option D (VPN for encryption): A VPN solution for encrypting data in transit is unnecessary and adds additional complexity without providing any benefit over SSL/TLS, which is simpler to implement and manage.

AWS References:

Amazon RDS Encryption- Information on how to configure and use encryption for Amazon RDS.

AWS Certificate Manager (ACM)- Details on using ACM to manage SSL/TLS certificates for securing data in transit.

Amazon RDS read replicas provide a way to offload read traffic from the primary database, allowing read-intensive applications to query the replica without impacting the performance of the production (write) database. This is especially effective for workloads that involve frequently changing data but do not benefit from caching, since queries are rarely repeated.

Reference Extract from AWS Documentation / Study Guide:

" Read replicas allow you to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. "

Source: AWS Certified Solutions Architect – Official Study Guide, RDS Read Replica section.

Option B is the best answer because AWS Budgets can take automated actions, and forecast-based thresholds let the company intervenebeforeactual spending fully lands. AWS documentation explains that AWS Budgets actions can target EC2 instances, and forecast-based budget alerts are specifically intended to warn when projected spend is expected to exceed the threshold during the period. That makes forecasted costs more proactive than waiting until actual spend reaches the full budgeted amount. Option A works, but it adds extra operational overhead by introducing SNS and Lambda when AWS Budgets actions can already automate the response directly. Option C is unrelated because a scheduled rule does not respond to budget state. Therefore, forecast-based AWS Budgets actions that automatically stop the EC2 instances is the most cost-effective and direct design. (AWS Documentation)

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

Amazon FSx for Lustre: Lustre is a high-performance file system designed for workloads that require fast storage with sustained high throughput and low latency. It integrates with Amazon S3, making it suitable for HPC environments.

Persistent File Systems:

Persistent Storage: Suitable for long-term storage and recurrent use, providing durability and availability.

High Throughput and Low Latency: Persistent Lustre file systems can handle large amounts of data with sub-millisecond latency, meeting the needs of high-performance computing workloads.

Simultaneous Access: FSx for Lustre allows thousands of compute instances to access and process large datasets concurrently, ensuring that the high volume of data is handled efficiently.

Highly Available: FSx for Lustre is designed to provide high availability and is managed by AWS, reducing the operational burden.

The IAM policy includes two statements:

1️⃣ Allow ec2:TerminateInstances on all resources

2️⃣ Deny ec2:TerminateInstances if the request does NOT come from:

192.0.2.0/24

203.0.113.0/24

AWS IAM policy evaluation rules state:

Explicit Deny always overrides Allow.

A request must meet all applicable conditions in the policy to be granted.

aws:SourceIp condition applies when IAM actions are invoked via the public AWS APIs.

In this scenario, the administrator is not originating the request from one of the allowed CIDR blocks, so the Deny condition is triggered, overriding the Allow statement.

Therefore, the operation is blocked with:

403 AccessDenied: explicit deny

This matches the behavior described in the AWS IAM Policy Evaluation Logic used in the Security Pillar of the Well-Architected Framework:

Explicit Deny > Allow > Default Deny

IP-based Conditions restrict API calls originating outside approved network ranges

Options A/B/C do not accurately reflect this explicit Deny condition behavior.

Spot Instances are the best pricing model because the jobscan tolerate interruptions, and the company wants the most cost-effective option. AWS recommends theprice-capacity-optimizedstrategy for Spot because it selects pools that balancelow pricewithlower interruption risk. Using multiple instance types in the Auto Scaling group also helps the company stay flexible enough to adopt newer generations over time. Reserved Instances do not fit as well because they reduce flexibility and do not align with the requirement to keep shifting toward the latest instance generations each year. Capacity-optimized alone minimizes interruption risk, but AWS recommends price-capacity-optimized when you want both lower interruption rates and better prices. Therefore, Spot with price-capacity-optimized allocation is the strongest answer.

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

The most secure way to grant an external vendor’s AWS-hosted automation tool access into a company AWS account is to use cross-account IAM role assumption. Option A follows the standard AWS pattern: the company creates an IAM role in its own account that has only the permissions the vendor needs, and the role’s trust policy allows the vendor’s IAM role (in the vendor’s AWS account) to assume it. This approach avoids creating long-lived credentials in the company account and supports least privilege, auditing, and easy revocation.

With role assumption, the vendor continues to authenticate in its own AWS account and uses AWS STS to obtain temporary credentials when accessing the company account. Temporary credentials reduce exposure compared to access keys because they expire automatically and can be constrained with session duration, external IDs (where appropriate), and conditions. The company retains full control over permissions through the role policy, and CloudTrail can record AssumeRole events and subsequent API activity for auditing.

Option B is less secure because it creates an IAM user in the company account and would typically require managing long-lived credentials for the vendor tool, increasing the risk of leakage and ongoing operational overhead. Option C is not valid because IAM users are not shared across accounts; you cannot “add” a user from another account into an IAM group in your account. Option D is incorrect because “AWS account” is not a typical IAM identity provider type for this purpose; cross-account access is done through role trust policies, not by creating an IdP with an AWS account ID and username.

Therefore, A is the most secure solution because it uses short-lived credentials, enforces least privilege, centralizes control in the company account, and provides strong auditability without issuing permanent access keys.

To securely integrate Amazon S3 with an application that uses Amazon Cognito for user authentication, the following two steps are essential:

Step 1: Create an Amazon Cognito Identity Pool (Option A)

Amazon Cognito Identity Poolsallow users to obtain temporary AWS credentials to access AWS resources, such as Amazon S3, after successfully authenticating with the Cognito user pool. The identity pool bridges the gap between user authentication and AWS service access by generating temporary credentials using AWS Identity and Access Management (IAM).

Once a user logs in using theCognito User Pool, the identity pool providesIAM roles with specific permissionsthat the application can use to access S3 securely. This ensures that each user has appropriate access controls while accessing the S3 bucket.

This is a secure way to ensure that users only have temporary and least-privilege access to the S3 bucket for their documents.

Step 2: Create an Amazon S3 VPC Endpoint (Option C)

By creating anAmazon S3 VPC endpoint, the company ensures that communication between the application (which is hosted in a private subnet) and the S3 bucket occurs over theAWS private network, without the need to traverse the internet. This enhances security and prevents exposure of data to public networks.

TheVPC endpointallows the application to access the S3 bucket privately and securely within the VPC. It also ensures that traffic stays within the AWS network, reducing attack surface and improving overall security.

Why the Other Options Are Incorrect:

Option B: This is incorrect becauseAmazon Cognito User Poolsare used for user authentication, not for generating S3 access tokens. To provide S3 access, you need to useAmazon Cognito Identity Pools, which offer AWS credentials.

Option D: ANAT gatewayis unnecessary in this scenario. Using aVPC endpointfor S3 access provides a more secure and cost-effective solution by keeping traffic within AWS.

Option E: Attaching a policy to restrict access based on IP addresses is not scalable or efficient. It would require managing users’ dynamic IP addresses, which is not an effective security measure for this use case.

AWS References:

Amazon Cognito Identity Pools

Amazon VPC Endpoints for S3

The Kubernetes Horizontal Pod Autoscaler (HPA) scales pods, not nodes. When the cluster runs out of node capacity, the HPA cannot schedule more pods.

On Amazon EKS, AWS recommends using the Kubernetes Cluster Autoscaler to automatically adjust the number of nodes in the cluster’s underlying Auto Scaling group based on pending pods.

Cluster Autoscaler watches for pods that cannot be scheduled because of insufficient resources and then scales out nodes automatically with minimal administrative overhead. It also scales in nodes when they are underutilized.

Why others are not correct:

A: Just tracking memory usage does not automatically scale nodes or integrate with Kubernetes scheduling.

C: A custom Lambda-based resizer is unnecessary undifferentiated heavy lifting compared to the native Cluster Autoscaler.

D: An Auto Scaling group is already typically used under EKS, but by itself it does not respond to pod scheduling pressure without Cluster Autoscaler.

The requirements emphasize high availability across multiple Availability Zones, automatic recovery, and least operational overhead. The simplest way to achieve this for containerized microservices is to use a fully managed container orchestration service with serverless compute. Amazon ECS with the Fargate launch type provides exactly that.

With ECS Fargate, AWS manages the underlying compute infrastructure (no EC2 instances to provision, patch, scale, or secure at the OS level). You define task definitions and services, and ECS schedules tasks across Availability Zones based on your networking configuration (multiple subnets in different AZs). If a container fails, ECS service scheduling automatically replaces it, fulfilling the “recover from failures” requirement. Fargate also integrates with load balancing, CloudWatch logging, and scaling policies, reducing the operational burden of keeping the platform healthy.

Option A (ECS on EC2) is still managed orchestration, but it requires managing the EC2 capacity layer: AMI updates, instance patching, cluster capacity planning, and instance scaling. Option B (EKS with self-managed nodes) typically carries even more operational responsibility because you manage node groups, upgrades, and Kubernetes operational complexity in addition to the underlying instances. Option D is the highest operational overhead because it lacks managed scheduling and self-healing; you would need to build and maintain your own process manager and failover mechanisms.

Therefore, C is the best answer because it provides a managed, multi-AZ capable, self-healing container platform with minimal infrastructure management—matching the operational efficiency goal while maintaining high availability.

The right solution isAPI Gateway + Lambda + Amazon Comprehend + DynamoDB. AWS documents that Amazon Comprehend is the NLP service for detecting entities, sentiment, and key phrases, which matches the workload exactly. DynamoDB is a fully managed, distributed database designed for high-throughput workloads and single-digit millisecond performance at scale, making it a strong fit for a highly available application handling many concurrent requests. The other answers misuse services: Amazon Translate is for translation, Amazon Textract is for extracting text from documents, and ElastiCache is a cache rather than the durable primary database described in the question. This makes option A the only architecture that aligns with both the NLP functions and the scalable database requirement. (AWS Documentation)

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

Amazon Kinesis Data Streams is designed for low-latency ingestion of streaming data. Combined with Amazon Managed Service for Apache Flink, telemetry can be processed and aggregated in near real time. Processed metrics can be sent to Amazon CloudWatch, which natively supports creating dashboards, metrics visualization, and alarms. Firehose (B) is primarily for batch ingestion and delivery, not real-time analytics. EMR with Athena (C) introduces more complexity and is better for large-scale offline analytics. DynamoDB Streams (D) is not a fit because telemetry data is not stored in DynamoDB. Therefore, option A provides the most suitable and real-time analytics pipeline for telemetry data.

Cluster Placement Group: This type of placement group is designed to provide low-latency network performance and high throughput by grouping instances within a single Availability Zone. It is ideal for applications that require tightly coupled node-to-node communication.

Configuration:

When launching EC2 instances, specify the option to launch them in a cluster placement group.

This ensures that the instances are physically located close to each other, reducing latency and increasing network throughput.

Benefits:

Low-Latency Communication: Instances in a cluster placement group benefit from enhanced networking capabilities, enabling low-latency communication.

High Network Throughput: The network performance within a cluster placement group is optimized for high throughput, which is essential for HPC workloads.

AWS Glue jobs are designed for extract, transform, and load (ETL) operations, which are perfect for transforming clinical trial data. AWS Glue integrates with AWS Key Management Service (KMS), allowing for customer-specific encryption keys, fulfilling the encryption requirement with minimal operational effort. Client-side encryption with AWS KMS ensures that the data is encrypted before it is sent to S3, aligning with the security needs specified in the scenario.

Key aspects:

AWS Glue: This managed ETL service simplifies data transformation, reduces operational overhead, and integrates seamlessly with KMS.

CSE-KMS: Client-side encryption with KMS ensures that the data is encrypted with customer-specific keys before it is processed or stored in S3, offering robust security​​.

Minimal Operational Overhead: Compared to managing an EMR cluster, AWS Glue automates much of the process, making it a lower-effort solution.

AWS Documentation: According to the AWS Well-Architected Framework, encryption with AWS KMS offers strong security controls that meet the needs of industries requiring high levels of confidentiality​​.

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.

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

Amazon ElastiCache (Redis OSS) provides an in-memory cache that drastically improves read performance with minimal operational overhead.

It integrates easily with RDS and does not require schema or database changes.

EC2-based caching (Option C) increases management overhead.

DAX (Option D) accelerates DynamoDB only, not RDS.

Moving to DynamoDB (Option A) requires complete application and schema redesign.

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

The first step is to configure a delegated administrator account for IAM Access Analyzer at the organization level. Only after delegating the administrator account can you aggregate Access Analyzer findings from all member accounts into a designated audit account. This must be set up in the AWS Organizations management account.

AWS Documentation Extract:

“You must designate a delegated administrator for IAM Access Analyzer at the organization level. The delegated administrator account aggregates findings from all member accounts.”

(Source: IAM Access Analyzer documentation)

A, C, D: These steps do not establish the organization-wide aggregation required for Access Analyzer.