SAP-C02 Practice Exam — SAP-C02：Solutions Architect - Professional

The correct answer is A. Here's the detailed explanation:

Why Option A is the Best Solution?

The requirements are:

1.On-premises systems must resolve `cloud.example.com`.

2.All VPCs must resolve `cloud.example.com`.

3.High performance is required (minimal latency and complexity).

Option A meets these requirements by:

1.Associating the private hosted zone with all VPCs → Ensures VPC resources can resolve `cloud.example.com` natively via Route 53.

2.Creating a Route 53 inbound resolver in the shared services VPC → Provides a centralized DNS resolution endpoint for on-premises queries.

3.Using AWS Transit Gateway for connectivity → Ensures low-latency communication between VPCs and on-premises.

4.Forwarding on-premises DNS queries to the inbound resolver → Allows on-premises systems to resolve `cloud.example.com` efficiently.

Why Other Options Are Incorrect?

-Option B: Uses anEC2-based conditional forwarder, which introduces unnecessary management overhead (scaling, patching) compared to Route 53 Resolver (fully managed).

-Option C: Associates the private hosted zoneonly with the shared services VPC, meaning other VPCs cannot resolve `cloud.example.com` natively (requires outbound resolver, which adds complexity).

-Option D: Similar to Option C, but uses aninbound resolver while still restricting the hosted zone to one VPC, breaking resolution for other VPCs.

Key Considerations for Performance

-Route 53 private hosted zones provide the fastest DNS resolution within VPCs when associated directly.

-Route 53 Resolver (inbound) is fully managed and optimized for hybrid DNS, unlike manual EC2 solutions.

-Transit Gateway ensures high-speed connectivity between VPCs and on-premises.

Conclusion

Option A is the most efficient, scalable, and performant solution, leveraging native AWS services (Route 53 private hosted zones + inbound resolver) without introducing unnecessary complexity.

ref:: https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-dns-management-of-hybrid-cloud-withamazon-route-53-and-aws-transit-gateway/

Based on the information provided, the best solution for implementing a multi-region failover capability for the company's REST API would be:

C. Deploy a new API Gateway API and Lambda functions in another Region. Change the Route 53 DNS record to a failover record. Enable target health monitoring. Convert the DynamoDB tables to global tables.

This approach provides a complete disaster recovery solution by:

Deploying the entire API infrastructure (API Gateway and Lambda functions) in a second region

Using Route 53 failover records with health monitoring to automatically redirect traffic when needed

Converting DynamoDB tables to global tables to ensure data consistency across regions

Option A is incomplete because it only deploys new Lambda functions in the new region and updates the existing API Gateway to use an edge-optimized endpoint. This doesn't provide true regional failover since the API Gateway itself would still be a single point of failure in one region.

The correct solution (C) creates a fully redundant setup across regions with automatic failover capabilities through Route 53 health checks and global tables for data replication.

Sources

Implementing multi-Region failover for Amazon API Gateway | AWS Compute Blog (https://aws.amazon.com/cn/blogs/compute/implementing-multi-region-failover-for-amazon-api-gateway/）

Deploy a reference architecture that models a serverless active/passive workload with asynchronous replication of application data and failover from a primary to a secondary AWS Region - Multi-Region Application Architecture Solution （ https://docs.aws.amazon.com/solutions/latest/multi-region-application-architecture/welcome.html）

AWS Backup vs global table/database for cost-effective RTO,RPO requirements | AWS re:Post （https://repost.aws/questions/QUWf0GuonKSvW8U2N4o8huHw/aws-backup-vs-global-table-database-for-cost-effective-rto-rpo-requirements）

Configure custom health checks for DNS failover for an API Gateway API - Amazon API Gateway （https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html）

Community | Scale across borders: build a multi-region architecture while maintaining data residency （https://community.aws/content/2dhVhtsciD5gVBlCKUlHoszrDzU/scale-beyond-borders）

ref:https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/transitional-ou.html

Based on the information provided, the best solution for migrating the stateful application to AWS while ensuring scalability and a consistent user experience would be:

C. Enable Aurora Auto Scaling for Aurora Replicas. Use an Application Load Balancer with the round robin routing and sticky sessions enabled.

This solution is optimal because:

Aurora Auto Scaling for Aurora Replicas will allow the database tier to automatically scale read capacity based on demand, which is essential as the user base grows significantly.

The Application Load Balancer (ALB) is the appropriate choice for HTTP/HTTPS traffic of a web-based application, offering more advanced routing capabilities than a Network Load Balancer.

Sticky sessions are crucial for maintaining a consistent user experience with a stateful application, as they ensure that a user's session remains connected to the same EC2 instance throughout their session.

Round robin routing with the ALB will distribute incoming traffic evenly across the healthy EC2 instances in the Auto Scaling group, providing efficient load distribution.

Option A is less suitable because Network Load Balancers operate at the transport layer (TCP/UDP) and are typically used for extreme performance requirements rather than standard web applications. Additionally, NLBs don't natively support sticky sessions in the same way ALBs do, which is critical for this stateful application.

Sources

REL07-BP01 Use automation when obtaining or scaling resources - AWS Well-Architected Framework（https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_adapt_to_changes_autoscale_adapt.html）

HA and automatic scaling for ASP.NET Web Forms applications on AWS - AWS Prescriptive Guidance （https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-asp-net-web-forms/ha-scaling.html）

Hyperscaling Aurora MySQL-Compatible to handle sudden traffic growth - AWS Prescriptive Guidance （https://docs.aws.amazon.com/prescriptive-guidance/latest/hyperscale-aurora-mysql/introduction.html）

Replatforming backend databases - AWS Prescriptive Guidance （https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-replatforming-cots-applications/replatforming-backend-databases.html）

Navigating the Cloud: Joby Aviation’s PLM migration to AWS | AWS for Industries （https://aws.amazon.com/cn/blogs/industries/navigating-the-cloud-joby-aviations-plm-migration-to-aws/）

1. Serverless Architecture: The company wants to adopt serverless technologies.
2. Backward Compatibility: Older consumer devices, which do not support certain HTTP headers, must still be supported.
3. Header Removal Logic: Specific HTTP headers, identified by the User-Agent, must be removed for compatibility with older devices.

Options Analysis:

• A: Creating an Amazon CloudFront distribution and an Application Load Balancer (ALB) allows requests to be routed efficiently. CloudFront can remove the problematic HTTP headers using a CloudFront function based on the User-Agent value. The ALB can invoke the appropriate Lambda function for request processing. This solution aligns well with the requirements and involves minimal effort.

• B: Using an API Gateway REST API and configuring the gateway to handle header removal introduces unnecessary complexity. While functional, it requires creating additional mapping templates or modifying responses, which adds operational overhead compared to the simplicity of CloudFront and ALB.

• C: Using an API Gateway HTTP API to remove headers requires managing response mapping templates and associating them with the HTTP API. Similar to option B, this adds complexity and operational effort.

• D: Using a Lambda@Edge function with a CloudFront distribution is a viable alternative but adds latency since Lambda@Edge executes at the edge locations. This may impact performance compared to CloudFront functions, which are natively integrated and faster for lightweight tasks like header removal.

Key Benefits of Option A:

• Seamless Header Removal: CloudFront functions provide a lightweight mechanism to remove headers based on the User-Agent value.
• Efficient Routing: The ALB efficiently routes requests to the correct Lambda function for processing.
• Serverless Design: Fully aligns with the serverless architecture requirement while ensuring backward compatibility.

Thus, Option A is the correct answer.