Skip to main content

Practice exam · AWS

AWS Certified Solutions Architect - Professional (SAP-C02) practice exam

50
questions
180
minutes
75%
to pass the practice exam
59
questions in the bank

Short answer

The AWS Certified Solutions Architect - Professional (SAP-C02) practice exam has 50 questions in 180 minutes, with a 75% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.

Domains covered

  • Continuous Improvement for Existing Solutions
  • Design for New Solutions
  • Accelerate Workload Migration and Modernization
  • Design Solutions for Organizational Complexity

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Design for New Solutions

A company runs hundreds of EC2 instances across many VPCs attached to a Transit Gateway. The instances make frequent API calls to Amazon S3 and DynamoDB, and currently route this traffic out through NAT gateways to the public S3/DynamoDB endpoints, incurring high NAT gateway data-processing costs and unnecessary internet exposure. They want to keep the traffic on the AWS private network and reduce cost, with minimal per-VPC configuration overhead. Which approach is most appropriate?

  1. Replace the NAT gateways with NAT instances to lower the data-processing cost while keeping the same public-endpoint routing to S3 and DynamoDB.
  2. Provision a Direct Connect public VIF and route S3 and DynamoDB traffic over it to keep the traffic off the internet.
  3. Create gateway VPC endpoints for S3 and DynamoDB in each VPC and update the relevant route tables, removing the S3/DynamoDB traffic from the NAT gateway path. ✓ (correct)
  4. Create a single interface VPC endpoint for S3 in one central VPC and route every other VPC's S3 traffic to it through the Transit Gateway.
Why this is correct

Gateway VPC endpoints for S3 and DynamoDB per VPC is correct: gateway endpoints keep S3/DynamoDB traffic on the AWS private network via route-table prefix lists, are free of charge, and eliminate NAT gateway data-processing costs and internet exposure for that traffic with minimal configuration. A single central interface endpoint routed via TGW is wrong because gateway endpoints (S3/DynamoDB) are not reachable across VPC/TGW boundaries — their prefix-list routes are local to the VPC; and interface endpoints for S3 incur per-hour and per-GB charges while still requiring careful DNS handling, so routing all VPCs to one central endpoint over TGW is not the intended low-overhead pattern. A Direct Connect public VIF is wrong because it is for hybrid connectivity from on-premises to AWS public endpoints, not for EC2-to-S3 traffic within AWS, and adds cost/complexity that gateway endpoints solve natively. Replacing NAT gateways with NAT instances is wrong because the traffic still flows to public S3/DynamoDB endpoints over a NAT path, keeping internet exposure, and NAT instances add management overhead and become a bandwidth/availability bottleneck.

Question 2 · Continuous Improvement for Existing Solutions

A financial reporting platform runs a synchronous REST API on Amazon API Gateway integrated with an AWS Lambda function that writes to an Amazon Aurora MySQL cluster. During end-of-month batch periods, clients submit thousands of 'generate statement' requests within a few minutes. The Lambda function frequently times out at the 29-second API Gateway integration limit because statement generation takes 40-120 seconds, and Aurora connections are exhausted by the Lambda concurrency spikes. Clients receive 504 errors and retry, amplifying the load. A solutions architect must improve reliability and remove the bottleneck while keeping the existing client contract that submits a request and later checks for a result. Which change BEST addresses the root causes?

  1. Enable provisioned concurrency on the Lambda function to eliminate cold starts and turn on API Gateway throttling at the account level so the burst is smoothed out before reaching the function.
  2. Move the generate endpoint behind an Application Load Balancer with the Lambda function as a target so the 29-second integration timeout no longer applies, and enable Aurora read replicas so statement generation reads scale horizontally.
  3. Increase the Lambda function timeout to 180 seconds and raise the function's reserved concurrency limit so that all incoming requests are processed in parallel, then enable API Gateway caching on the generate endpoint to absorb the retries.
  4. Convert the API to an asynchronous pattern: have API Gateway place the request on an Amazon SQS queue and immediately return a 202 with a job ID, process the queue with a Lambda function whose reserved concurrency is capped below the Aurora connection ceiling, use RDS Proxy to pool connections, and expose a separate status endpoint that reads job state from DynamoDB. ✓ (correct)
Why this is correct

The asynchronous SQS option is correct because it attacks all three root causes: it decouples the long-running work (40-120s) from the 29-second API Gateway synchronous limit (504s disappear because the API returns 202 immediately), it caps concurrency below the Aurora connection ceiling to stop connection exhaustion, and RDS Proxy pools/reuses connections so concurrency spikes no longer open one DB connection per invocation. The status endpoint preserves the submit-then-poll client contract. Increasing the Lambda timeout to 180s and raising concurrency is wrong because API Gateway's synchronous integration timeout is a hard 29-second limit regardless of the Lambda timeout, so 504s persist, and raising concurrency makes Aurora connection exhaustion worse, not better; API Gateway caching cannot cache POST/generate semantics that produce unique statements. Moving behind an ALB does remove the 29-second limit (ALB allows longer idle timeouts), but it leaves clients blocked on a synchronous connection for up to two minutes during a burst, and read replicas do not solve connection exhaustion caused by uncontrolled Lambda concurrency; this is a weaker, partial improvement. Provisioned concurrency only fixes cold starts (not the actual problem) and account-level throttling would broadly reject legitimate traffic without solving the long-running-work mismatch.

Question 3 · Continuous Improvement for Existing Solutions

A global application currently runs active in us-east-1 with all data in an Amazon Aurora cluster and serves users worldwide through a single Regional endpoint. Leadership now requires an RTO of under 5 minutes and an RPO of seconds for a full Region failure, but wants to avoid the cost and complexity of running a second full active read/write stack continuously. Read latency for international users should also improve. Which disaster-recovery strategy BEST fits these requirements?

  1. Build a pilot-light architecture where only the Aurora secondary is replicated and all application servers are kept stopped, starting and scaling them out only after the primary Region fails.
  2. Deploy a full active-active multi-Region architecture with Aurora writes accepted in both Regions simultaneously and Route 53 latency-based routing distributing all read and write traffic globally.
  3. Implement a warm standby in a second Region: deploy Aurora Global Database with a secondary Region (typical cross-Region replication lag under a second and managed failover in minutes), run a scaled-down but always-on application stack there fronted by the same infrastructure, and use Amazon Route 53 health checks with failover routing to shift traffic. ✓ (correct)
  4. Use a backup-and-restore strategy: take Aurora snapshots copied to a second Region every hour and use CloudFormation to recreate the stack on demand when the primary Region fails.
Why this is correct

Warm standby with Aurora Global Database is correct because Aurora Global Database gives sub-second cross-Region replication (RPO of seconds) and managed cross-Region failover in roughly a minute (supporting an RTO under 5 minutes), the always-on scaled-down stack means no cold start delay during failover, Route 53 failover shifts traffic quickly, and the Global Database secondary also serves low-latency local reads for international users. Backup-and-restore is wrong because hourly snapshot copies give an RPO of up to an hour and restoring/redeploying a full stack takes far longer than 5 minutes, violating both targets. Pilot light is wrong because keeping all application servers stopped means you must start and scale them after the failure, which generally pushes RTO beyond 5 minutes; it trades cost for slower recovery and does not meet the strict RTO. Full active-active is wrong because Aurora Global Database does not provide multi-Region simultaneous writes in the way described (write forwarding routes writes back to the primary, it is not multi-master active-active), so the option misrepresents the capability, and it adds exactly the continuous cost and complexity leadership wants to avoid.

Take the full practice exam

  • 50 questions drawn from the bank, with a 180-minute timer
  • Score by domain and a review of every question
  • An AI tutor to talk through each question you miss
  • What you miss feeds your study plan

Independent, unofficial practice exam. AWS and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.

Frequently asked questions

How many questions does the AWS Certified Solutions Architect - Professional (SAP-C02) practice exam have?

It has 50 questions and a 180-minute limit. The passing mark of the practice exam is 75%.

Is this the official AWS Certified Solutions Architect - Professional (SAP-C02) exam?

No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.

Do I need an account to take it?

You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.