Question 460
A production RDS PostgreSQL database has high CPU during business hours and engineers debate whether slow queries or disk throughput are responsible. They need query-level evidence before resizing the DB instance. Which diagnostic tool should be used?
- Enable Enhanced Monitoring to inspect host processes only, without collecting top SQL, database waits or active-session load.
- Use Amazon CloudWatch Database Insights to examine RDS database load, top SQL statements, and wait events before deciding whether to tune queries or resize.
- Resize the RDS instance based solely on CPU percentage without checking SQL load, top queries or wait classes.
- Review PostgreSQL connection count and CloudWatch CPU only and infer the exact slow query from their correlation.
Explanation
Correct Answer
B:Database Insights exposes RDS DB load and permits filtering by SQL statements and waits, distinguishing query/lock or storage pressure before a size change. The legacy RDS Performance Insights console was discontinued in November 2025; use the supported CloudWatch Database Insights experience.
Incorrect Answers
A:Operating-system telemetry helps spot non-SQL processes but cannot by itself identify the expensive query statements and wait events required here.
C:A size increase before diagnosis can be costly and misses the query-level causes; Database Insights supplies the needed DB load dimensions.
D:Aggregate metrics cannot identify which SQL statements or wait events dominate database load; a per-query insights tool is needed.
Question 461
A stateless ECS service has a p95 latency spike only under load. CPU utilization increases sharply and tasks are evenly distributed across AZs. The service owner wants a scaling signal tied to observed demand instead of manual instance changes. What should the architect implement?
- Increase desired task count to a fixed high value and keep it there independent of changing incoming load.
- Scale only the EC2 capacity of unrelated ECS clusters while leaving the stateless Fargate/service task desired count fixed.
- Tune ECS Service Auto Scaling using a suitable target-tracking metric and validate scaling against load-test p95 latency.
- Enable ECS deployment circuit breaker without setting service capacity scaling policies or testing throughput.
Explanation
Correct Answer
C:Target tracking can scale tasks with demand, and realistic tests verify whether metric-driven capacity actually improves tail latency.
Incorrect Answers
A:Permanent overprovisioning does not automatically respond to observed demand or validate peak p95 performance against targets.
B:Service request latency requires sufficient tasks for the affected service; changing unrelated capacity does not implement service auto scaling.
D:Deployment rollback protects release stability but is not a load-linked task scaling mechanism for recurring peaks.
Question 462
A Lambda API shows high cold-start latency after long idle periods, but the handler executes quickly once initialized. The business needs consistently low startup latency for predictable scheduled peaks. Which Lambda feature should be evaluated?
- Increase configured memory and CPU allocation, expecting it to guarantee zero initialization delay on every scheduled peak.
- Configure provisioned concurrency for the required version or alias and measure warm-invocation latency and extra cost.
- Enable Lambda SnapStart on a supported runtime and assume it guarantees the strictest double-digit-millisecond cold-start SLA for every request.
- Reserve concurrency without provisioning initialized environments, assuming reserved slots are pre-warmed before arrival.
Explanation
Correct Answer
B:Provisioned concurrency pre-initializes supported execution environments, reducing cold-start impact during expected demand periods.
Incorrect Answers
A:More memory can sometimes shorten initialization but does not keep environments preinitialized; predictability of cold-start latency favors provisioned concurrency.
C:SnapStart can markedly reduce initialization, but it is best-effort and can still experience cold-start variability; strict predictable peaks may favor provisioned concurrency.
D:Reserved concurrency caps/allocates capacity but does not preinitialize environments. Provisioned concurrency explicitly pre-warms execution capacity.
Question 463
An internet-facing API is deployed in two AWS Regions. Client telemetry shows long path latency to the nearer Region because DNS resolver caching and network routes do not consistently choose a healthy regional endpoint. Responses are dynamic and not cacheable. What should the architect assess?
- Use Route 53 latency-based records with long caching intervals, expecting all existing clients to instantly switch to the nearest healthy endpoint.
- Deploy CloudFront with a long default TTL for every state-changing API response even though replies are dynamic and must not be cached.
- Assess AWS Global Accelerator with regional endpoint health monitoring and routing for dynamic traffic over the AWS global network.
- Use regional NLBs with unrelated public IP addresses and ask every client to implement its own regional route selection.
Explanation
Correct Answer
C:Global Accelerator provides static global anycast entry points and endpoint-based routing without requiring response caching.
Incorrect Answers
A:DNS-based decisions can be cached and depend on resolver behavior; this does not provide the stable globally routed anycast path the scenario seeks.
B:CDN caching changes response semantics; Global Accelerator transports dynamic TCP/HTTP requests without relying on stale object caching.
D:Independent regional endpoints do not provide managed global routing to healthy regional targets over AWS network paths.
Question 464
A nightly batch loads 400,000 tiny objects into an S3-based data lake. Athena queries spend disproportionate time and cost scanning and opening many files. The schema allows columnar storage and partition pruning. Which data-layout change should be evaluated?
- Partition the original JSON files by date but retain hundreds of thousands of tiny objects per partition.
- Compact small files into appropriately sized columnar Parquet objects and partition data on useful query predicates.
- Convert JSON to Parquet but write each original tiny record as a separate Parquet file, preserving the object count.
- Compact files into large unsorted JSON objects but use no partitioning despite clear date-based query predicates.
Explanation
Correct Answer
B:Columnar compressed layouts and fewer appropriately sized objects reduce scan overhead; partition pruning limits data touched by relevant queries.
Incorrect Answers
A:Partition pruning may reduce scope but does not address file-open overhead and JSON scan inefficiency from the extreme small-file layout.
C:Columnar encoding can reduce scanned bytes but leaves the pathological small-file overhead without compaction into efficient objects.
D:Compaction helps file-open costs but misses columnar scan efficiency and predicate-based partition pruning, both of which matter in the scenario.
Question 465
A retailer already runs checkout on a compatible Aurora MySQL cluster. Finance needs near-real-time BI SQL joins over sales, returns and inventory in an existing Amazon Redshift warehouse, without competing with transactional queries on the writer. Reporting needs warehouse analytical features, not simply more read capacity for live Aurora SELECT statements. Aurora MySQL engine, InnoDB tables with primary keys, Region and warehouse prerequisites are verified for a supported zero-ETL integration. What architecture best meets the requirement?
- Increase the Aurora writer instance class and continue to execute all complex analytical joins directly on the production checkout connection pool.
- Add Aurora reader replicas and execute all warehouse-style cross-dataset joins on the Aurora reader endpoint without using the established Redshift analytics environment.
- Create the supported Aurora MySQL zero-ETL integration to Amazon Redshift, verify the target receives and keeps eligible transactional tables in sync, and run BI joins there.
- Schedule nightly full Aurora MySQL CSV exports to S3 and load them into Redshift the following morning without monitoring intra-day changes.
Explanation
Correct Answer
C:Supported Aurora zero-ETL integrations replicate compatible transactional data into Redshift in near real time for warehousing, joins and analytical processing while leaving checkout on Aurora; engine, InnoDB/PK, version, Region and target restrictions must be verified.
Incorrect Answers
A:A larger writer may improve raw query capacity but keeps reporting coupled to the production write path and does not use the requested analytical warehouse.
B:Readers are useful for lag-tolerant operational SELECT load and are a valid distinct design, but do not directly satisfy this explicit Redshift warehouse integration and cross-dataset BI requirement.
D:Nightly batch exports are much staler than the near-real-time business requirement even if they provide a destination Redshift table.
Question 466
A PostgreSQL RDS instance reports high host CPU utilization, yet query-level wait analysis shows only modest active SQL demand during the spike. The operations team suspects an operating-system process, thread scheduling or memory pressure rather than the top SQL statement. Which additional RDS telemetry should be enabled before buying a larger instance?
- Increase the DB instance class without obtaining a per-process breakdown because instance-level CPU utilization alone identifies the expensive operating-system task.
- Inspect only Performance Insights top SQL and database waits, even though these already show modest active SQL demand and cannot identify individual OS processes.
- Review only standard CloudWatch CPUUtilization and FreeableMemory metrics, assuming those aggregate counters list the CPU of each OS task.
- Enable Amazon RDS Enhanced Monitoring and inspect its OS-level process and thread CPU and memory metrics at an appropriate granularity.
Explanation
Correct Answer
D:RDS Enhanced Monitoring provides operating-system process and thread data distinct from SQL statement and database wait analysis.
Incorrect Answers
A:Instance-level CPU is an aggregate signal; changing class first provides no evidence about whether a database child process, helper or OS task drives the observed spikes.
B:Top SQL and database wait insights are complementary but are not the OS-level process and thread telemetry explicitly missing from the current incident analysis.
C:Standard CloudWatch metrics show host-level utilization but do not supply the per-process/thread measurements exposed by Enhanced Monitoring.
Question 467
A Java 17 AWS Lambda payment-quote endpoint is invoked only a few times per day but must respond quickly when an infrequent request arrives. Initialization dominates its measured cold-start latency. The function does not mount EFS, does not require ephemeral storage above 512 MiB, and can refresh network connections and unique IDs after restoration. Management prefers to avoid paying continuously for idle provisioned concurrency. Which approach should be benchmarked?
- Keep high provisioned concurrency active around the clock even when there are no requests, without comparing its standby expense.
- Enable Lambda SnapStart on the unpublished $LATEST version and invoke $LATEST directly, avoiding any published-version deployment.
- Enable Lambda SnapStart on a supported published Java 17 function version and validate restored-state uniqueness, connection refresh, startup latency and costs.
- Enable both Lambda SnapStart and provisioned concurrency on the same published function version to combine the two modes.
Explanation
Correct Answer
C:SnapStart restores execution environments from a published initialized snapshot for supported runtimes and can reduce cold initialization without provisioning an always-warm concurrency pool.
Incorrect Answers
A:Provisioned concurrency can lower startup delay but reserves initialized capacity while idle; it does not meet the stated preference to avoid continuous standby allocation.
B:SnapStart is supported on published function versions and aliases that reference them, not directly on unpublished $LATEST.
D:SnapStart and provisioned concurrency cannot be configured on the same function version, so this combination is not a supported way to meet the requirement.
Question 468
Analysts refresh the same Athena SQL dashboard query every three minutes. Its source partitions are written only once overnight, output bytes are identical within a one-hour window, and repeated scans consume a substantial fraction of the team workgroup budget. Without changing the existing Parquet layout, what should the data platform configure?
- Raise the Athena workgroup bytes-scanned limit so each unchanged dashboard query can re-run more expensive scans without reusing its earlier result.
- Configure Athena result reuse for eligible matching queries in the same workgroup with a maximum age consistent with overnight data freshness and monitor reuse behavior.
- Add a CURRENT_TIMESTAMP value to the projected SQL on every refresh even though it is not needed in the report.
- Increase the workgroup bytes-scanned limit while continuing to rerun identical full scans even though the source data is unchanged.
Explanation
Correct Answer
B:Athena result reuse may bypass re-execution for an eligible matching query within its configured age, reducing scan cost and refresh latency while retaining freshness constraints.
Incorrect Answers
A:A higher scan limit is a budget guardrail change, not a mechanism for reusing an eligible cached result of the same query.
C:Nondeterministic query changes and extra time-dependent expressions can prevent query-result reuse and are contrary to the stable-result assumption.
D:A larger limit permits more cost but does not leverage the unchanging data and repeat-identical-query behavior described.
Question 469
A mature ECS Fargate service is stable under load but its task definitions reserve 4 vCPU and 16 GiB memory while measured CPU and memory usage remain low. The team wants an evidence-based downsizing recommendation without jeopardizing p95 latency. Which service gives a workload-specific task-sizing recommendation?
- Review AWS Compute Optimizer recommendations for eligible ECS services on Fargate, compare suggested task CPU/memory settings, and test under production-like demand before adjusting the task definition.
- Apply ECS Service Auto Scaling only to increase task count, assuming scaling task count automatically reduces each task's vCPU and memory reservation.
- Enable ECS Service Auto Scaling target tracking for task CPU utilization, assuming the target tracking policy automatically changes the vCPU and memory values in each Fargate task definition.
- Reduce reserved task memory below the measured peak solely from a one-minute utilization sample and skip load testing the p95 latency SLO.
Explanation
Correct Answer
A:Compute Optimizer can analyze ECS/Fargate utilization metrics and produce CPU and memory sizing recommendations, with eligibility and metric-history caveats; a load test protects the service objective.
Incorrect Answers
B:Service Auto Scaling adjusts how many tasks run, not the task definition's provisioned per-task size.
C:Task-count target tracking responds to demand by changing desired replicas; it does not directly recommend or set the task definition CPU/memory values.
D:Unvalidated aggressive memory reductions can cause task failures under real demand and do not provide the supported historical resource-sizing evidence requested.
Question 470
A DynamoDB table with large overall read capacity receives most queries for one frequently viewed product ID. Throttling persists while many other partition keys are cold. Which tuning approach directly targets this specific bottleneck?
- Double provisioned write units although reads against one key are the only throttled operation.
- Create a second index with the same hot partition key and assume all load redistributes automatically.
- Increase table-wide provisioned read capacity alone without changing requests to the hot partition key or using a cache, even though other partitions are idle.
- Reduce the hot-key access rate with caching or restructure the access pattern to distribute reads where semantics allow.
Explanation
Correct Answer
D:Hot partition keys can hit local throughput limits even with spare table-wide capacity; distributing or caching requests addresses concentration.
Incorrect Answers
A:Write throughput adjustments do not correct a concentrated read hot key.
B:An index that mirrors the concentrated key can reproduce the same hotspot.
C:Extra table-wide capacity can leave the same hot partition key with localized throughput pressure; changing access concentration is the direct fix.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests