Free Practice Questions for Amazon Web Services SAA-C03 Exam

Amazon Timestreamis purpose-built for storing and analyzing time-series data like telemetry.

Option Aleverages Timestream, SageMaker for ML, and QuickSight for visualization, meeting all requirements with minimal complexity.

Option Binvolves more complex DynamoDB-EMR integration.

Option Cuses Neptune, which is designed for graph databases, not telemetry data.

Option Dincorrectly uses Athena for visualization instead of QuickSight.

To securely migrate an on-premises Oracle database to Amazon Aurora, the following steps are recommended:

Use AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS): AWS SCT helps convert the source database schema to a format compatible with the target database (Aurora). AWS DMS facilitates the actual data migration, ensuring minimal downtime and data integrity.

Use AWS Site-to-Site VPN: Establishing a Site-to-Site VPN connection provides a secure and encrypted tunnel between the on-premises environment and AWS. This ensures that data transferred during the migration is protected against interception and unauthorized access.

For improving availability and performance of the hybrid application, the following solutions are optimal:

AWS Global Accelerator (Option A): Global Accelerator provides high availability and improves performance by using the AWS global network to route user traffic to the nearest healthy endpoint (across AWS Regions). By adding the Network Load Balancers as endpoints, Global Accelerator ensures that traffic is routed efficiently to the closest endpoint, improving both availability and performance.

Network Load Balancer (Option D): Thestateful TCP-based workloadhosted on Amazon EC2 instances and thestateless UDP-based workloadhosted on-premises are best served by Network Load Balancers (NLBs). NLBs are designed to handle TCP and UDP traffic with ultra-low latency and can route traffic to both EC2 and on-premises endpoints.

Option B (CloudFront and Route 53): CloudFront is better suited for HTTP/HTTPS workloads, not for TCP/UDP-based applications.

Option C (ALB): Application Load Balancers do not support the stateless UDP-based workload, making NLBs the better choice for both TCP and UDP.

AWS References:

AWS Global Accelerator

Network Load Balancer

VPC Endpoint for S3: A gateway endpoint for Amazon S3 enables you to privately connect your VPC to S3 without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.

Configuration Steps:

In the VPC console, navigate to "Endpoints" and create a new endpoint.

Select the service name for S3 (com.amazonaws.region.s3).

Choose the VPC and the subnets where your EC2 instances are running.

Update the route tables for the selected subnets to include a route pointing to the endpoint.

Security Compliance: By configuring an S3 gateway endpoint, all traffic between the VPC and S3 stays within the AWS network, complying with the company's security regulations to avoid internet traversal.

AWS guidance for global, highly available, low-latency applications using a relational database recommends:

Amazon CloudFront with Amazon S3 for static content to cache data at edge locations globally and minimize latency for static assets.

A regional application tier deployed close to users using managed container services such as Amazon ECS on AWS Fargate, which removes the need to manage servers and scales automatically, reducing operational overhead.

A relational database tier using Amazon Aurora global database, which is purpose-built for globally distributed applications. Aurora global database provides a primary cluster in one Region with low-latency read replicas in secondary Regions and fast cross-Region replication, enabling low-latency reads and high availability for global users.

Option A uses only a single Region, which does not meet the “global users with low latency” requirement.

Option C uses RDS and DMS-based replication, which requires more management and does not provide Aurora’s integrated global database features.

Option D replaces the relational database with DynamoDB, which violates the requirement that the application interacts with a relational database.

AmazonEventBridgeAPI destinations allow you to send data from AWS to external systems, like Salesforce, using HTTP APIs, including those secured with OAuth. This provides a secure and scalable solution for sending messages from the order processing application to Salesforce.

Option A and B (SNS): SNS is not ideal for OAuth-secured external APIs and lacks the necessary OAuth integration.

Option D (MSK): Amazon MSK is a Kafka-based streaming solution, which is overkill for simple message forwarding to Salesforce.

AWS References:

Amazon EventBridge API Destinations

UsingAD ConnectorwithAWS IAM Identity Center(formerly AWS Single Sign-On) allows the company to leverage its existingon-premises Active Directoryfor centralized identity management and access control. AD Connector acts as a proxy to the on-premises AD withoutrequiring additional infrastructure or complex setup. This solution integrates seamlessly with AWS, allowing the development team to use their existing AD credentials to access AWS resources across multiple accounts managed by AWS Organizations. The permissions for AWS resources can be managed centrally through IAM Identity Center by configuring permission sets.

This solution provides:

Least operational overhead: AD Connector is fully managed, and IAM Identity Center allows centralized management of permissions across accounts.

Secure access: The solution complies with security policies by using existing AD authentication mechanisms.

Option A (AWS Managed AD): Setting up a fully managed AWS AD and establishing a trust is more complex and involves additional operational overhead.

Option B (IAM Users): Manually managing IAM users and permissions is less scalable and increases operational complexity.

Option D (Cognito): Amazon Cognito is more suited for user-facing applications rather than internal identity management for AWS resources.

AWS References:

AD Connector with IAM Identity Center

AWS IAM Identity Center

Aurora global database is specifically designed for cross-Region disaster recovery and low-latency global reads.

It provides:

Physical storage-level replication between Regions, typically with lag of under 1 second, easily satisfying RPO 1 minute.

Fast cross-Region failover capabilities, often within minutes or less, which meets the RTO 5 minutes requirement.

You configure the primary Region as the writer cluster and additional Regions (such as us-west-1) as secondary clusters with reader endpoints. In a disaster, you promote the secondary to be the new writer.

Why others are not correct:

A: Standard cross-Region read replicas for Aurora PostgreSQL do not provide automatic multi-Region failover with the same guarantees as Aurora global database and may not meet strict RTO/RPO requirements.

C: Logical replication and custom EventBridge failover is complex, error-prone, and higher overhead compared to the managed global database feature.

D: Restoring from snapshots plus cross-Region replication is too slow to meet RTO 5 minutes and certainly cannot maintain RPO 1 minute.

Amazon Aurora MySQL provides:

Continuous, incremental backups to Amazon S3 with point-in-time recovery (PITR), allowing recovery to any point within the retention window (typically up to 35 days). This easily achieves an RPO of less than 5 hours, often down to seconds.

Support for database auditing parameters so audit logs can be retained and managed (for example, in database logs or external log services) to meet the 7-day audit requirement.

Auto scaling (via read replicas, Aurora Serverless v2, or capacity management) to handle variable read/write demand throughout the year with minimal operational overhead.

Why others are less suitable:

A: DynamoDB is NoSQL and does not directly satisfy typical relational database + SQL audit requirements; Streams also only retain 24 hours, not 7 days, and on-demand backups do not inherently give an RPO < 5 hours without frequent scheduling.

B: Amazon Redshift is a data warehouse, not a primary transactional application database.

C: Snapshots every 5 hours give an RPO of up to 5 hours, not less than 5 hours, and rely on discrete snapshot points rather than continuous PITR.

DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for DynamoDB that delivers up to a 10x performance improvement—even at millions of requests per second. DAX requires minimal changes to existing applications and offloads the read workload from DynamoDB during report generation.

Reference Extract:

"DAX provides in-memory acceleration for DynamoDB tables, reducing response times from milliseconds to microseconds with minimal application changes."

Source: AWS Certified Solutions Architect – Official Study Guide, DynamoDB and Performance section.

Amazon SQS FIFO queues guarantee the order of message delivery and ensure that each message is delivered exactly once. Paired with AWS Lambda, this creates a scalable, fault-tolerant architecture that processes each order in order and prevents duplicates, which is critical for ecommerce workflows.

To handle increased loads effectively, it's essential to implement Auto Scaling for both frontend and backend tiers:

Frontend Auto Scaling Group: Scaling based on incoming network traffic ensures that the application can handle increased user requests.

Backend Auto Scaling Group: Scaling based on the Amazon SQS queue backlog ensures that the backend can process messages as they arrive, preventing delays.

This approach allows each tier to scale independently based on its specific load, ensuring optimal resource utilization and performance.

The optimal solution for scalable and resilient hybrid networking is to use AWS Direct Connect with a Direct Connect gateway for secure, low-latency access to AWS, and an AWS Transit Gateway to manage connectivity among hundreds of VPCs.

By associating the Transit Gateway with the Direct Connect gateway, you enable transitive routing between on-premises and all VPCs, while minimizing network complexity and maintaining high performance.

VPC peering does not scale well, and VPNs don’t offer the same performance or consistency.

Serving static content from Amazon S3 is highly cost-effective and scalable. By fronting the S3 bucket with Amazon CloudFront, you also enable global caching, reduced latency, and even lower costs by reducing direct S3 access. There is no need for EC2 or ALB, and no need to manage servers, further lowering operational burden and expenses. This pattern is the recommended AWS architecture for serving static web content.

Reference Extract from AWS Documentation / Study Guide:

"Hosting static websites on Amazon S3 with Amazon CloudFront reduces infrastructure costs and improves performance for global users by caching content at edge locations."

Source: AWS Certified Solutions Architect – Official Study Guide, S3 and CloudFront section.

Why Option B is Correct:

AWS WAF: Provides a simple way to create geographic match rules to block or allow traffic based on country IP ranges.

Least Operational Overhead: Attaching the WAF rule to the ALB ensures centralized control without modifying ACLs or instance firewalls.

Why Other Options Are Not Ideal:

Option A: Network ACLs operate at the subnet level and can become complex to manage for dynamic or evolving IP ranges.

Option C: Managing IP-based rules in security groups and ACLs lacks scalability and does not provide country-based filtering.

Option D: Configuring host-based firewalls increases operational overhead and does not leverage AWS-managed solutions.

AWS References:

AWS WAF Geomatch:AWS Documentation - WAF Geomatch