Question 320
A Kinesis Data Streams workload reports one hot shard while other shards are idle. Producers use a constant partition key for all customers and consumer processing keeps falling behind despite additional total shard capacity. Which design change addresses the skew?
- Choose partition keys that spread independent records across hash ranges and assess resharding or enhanced fanout as appropriate.
- Keep using the same constant partition key and simply add many unused shards, assuming one key automatically spans them.
- Switch Kinesis into on-demand capacity mode but retain a single constant partition key for nearly all new records.
- Decrease stream retention so the hot shard can process its current incoming writes faster.
Explanation
Correct Answer
A:Kinesis assigns records to shards based on partition key; a constant key concentrates traffic regardless of spare capacity elsewhere.
Incorrect Answers
B:A given partition key maps to a shard hash range and will not distribute itself merely because more shards exist.
C:On-demand can respond to distributed shard demand but does not force one hot partition key to spread across unrelated shard hash ranges.
D:Shorter retention does not remove concentrated ingest throughput on the selected shard.
Question 321
An ALB-backed API uses target groups distributed across two Availability Zones. One entire AZ has failures, but health checks consider the corresponding targets available due to a shallow root path even though transaction endpoints fail. Which reliability check should be fixed?
- Use application-aware ALB health-check endpoints and thresholds that reflect real transactional readiness, then test AZ failure routing.
- Disable all health checks and assume any registered target must be able to serve business requests.
- Increase only the ALB idle timeout while leaving the health probe that reports false positives unchanged.
- Configure AWS WAF rate limits on the public ALB while retaining the target health check that falsely passes the broken application.
Explanation
Correct Answer
A:A misleading health probe can retain unusable targets in rotation despite infrastructure capacity in a healthy AZ.
Incorrect Answers
B:Unconditionally routing to all targets amplifies failures when an AZ or application becomes impaired.
C:A longer client connection timeout does not remove transaction-failing targets.
D:WAF can filter HTTP requests but cannot determine which registered target is healthy for the business transaction and remove it from rotation.
Question 322
A public catalog repeatedly reads the same product metadata from Amazon RDS, with a measured hotspot in duplicate SELECT queries. The catalog tolerates a short delay before updates become visible, and caching must remain under the application's invalidation control. Which change directly addresses this bottleneck?
- Increase RDS database instance size to handle the duplicate SELECT load but leave identical catalog queries uncached.
- Add an Aurora or RDS read replica and route all catalog SELECTs there without caching repeated product records.
- Enable RDS Proxy for the catalog queries and assume connection pooling caches full SELECT result sets.
- Implement cache-aside for hot product metadata in Amazon ElastiCache with an appropriate TTL and invalidate or refresh entries on catalog updates.
Explanation
Correct Answer
D:Cache-aside reduces repeated reads for stable data while explicitly handling permitted staleness and invalidation, addressing the observed read hotspot.
Incorrect Answers
A:Larger instances may supply headroom but do not eliminate redundant reads, the measured bottleneck which the application-controlled cache can address.
B:Read replicas can redistribute read traffic, but the requirement is specifically to avoid repeated identical queries with app-controlled invalidation; a cache is more direct.
C:RDS Proxy pools connections and manages sessions; it is not the application result cache that prevents repeated hot product reads.
Question 323
A global image catalogue serves the same immutable images to customers on five continents. Response time is dominated by repeated long-haul retrievals from one S3 Region. Which change most directly reduces request latency for cacheable content?
- Enable S3 Transfer Acceleration for uploads and expect it to cache public GET responses at edge locations worldwide.
- Place CloudFront in front of the S3 origin with suitable cache behavior and controlled TTLs for immutable image versions.
- Set S3 Cross-Region Replication to additional Regions but keep all client download URLs pointed at the original single Region.
- Place a regional ALB in front of the single S3 bucket but avoid CDN edge caches, assuming the ALB provides global image object caching.
Explanation
Correct Answer
B:CloudFront caches popular objects closer to viewers and reduces repeated long-distance origin fetches for cacheable content.
Incorrect Answers
A:Transfer Acceleration optimizes supported S3 transfer paths; it does not provide CloudFront edge caching for repeated viewer downloads.
C:Replication can place data in more Regions but does not automatically route repeated GET requests through geographically near caches.
D:ALBs route requests to backends but do not function as the worldwide HTTP content cache requested for immutable images.
Question 324
An online game API needs stable anycast IP addresses for global clients and fast rerouting toward healthy regional TCP endpoints. Responses are highly dynamic and should not be cached. What AWS service is most appropriate?
- Use Route 53 latency-based DNS failover and assume it provides the same fixed anycast IPs regardless of DNS resolver caching.
- Configure CloudFront with caching disabled and assume it is a generic persistent TCP socket accelerator for arbitrary gaming protocols.
- Deploy AWS Global Accelerator with regional endpoints and health-based traffic controls.
- Use an NLB in each Region with separate regional IPs and require clients to manage failover on their own.
Explanation
Correct Answer
C:Global Accelerator provides static anycast IPs and steers client traffic over the AWS global network toward healthy regional endpoints without HTTP caching.
Incorrect Answers
A:Latency routing is DNS-based and answers can be cached; it does not offer Global Accelerator fixed anycast addresses and its network routing model.
B:CloudFront supports HTTP(S) and supported delivery protocols, not the generalized dynamic TCP/UDP endpoint behavior of Global Accelerator.
D:Regional NLBs can provide TCP endpoints but do not give one global fixed anycast IP pair with integrated health-based regional traffic steering.
Question 325
Thousands of brief Lambda invocations connect directly to a small RDS for PostgreSQL instance. Database CPU is moderate but the number of simultaneous client connections and connection-establishment overhead overwhelms the server. Which managed component addresses the observed bottleneck?
- Place Amazon RDS Proxy between Lambda clients and the database with suitable authentication and connection pooling settings.
- Add an RDS read replica to offload some queries but keep every Lambda invocation opening a new session to the primary.
- Enable Multi-AZ failover while leaving unbounded new Lambda connections to the writer instance.
- Increase database max_connections and its instance size as the only action without bounding clients or pooling sessions.
Explanation
Correct Answer
A:RDS Proxy multiplexes and pools supported database connections, reducing connection churn and pressure from bursty clients.
Incorrect Answers
B:Extra read capacity does not fix the observed primary connection storm; the pooled proxy path is the direct connection-pressure control.
C:Multi-AZ increases resilience but does not pool database client connections or reduce the establishment overhead reported here.
D:More resources may delay exhaustion but retain the unbounded connection fan-in; RDS Proxy more directly reduces per-invocation connection churn.
Question 326
A single EBS gp3 volume supports a database whose CloudWatch metrics show sustained IOPS saturation at its currently configured provisioned performance level. The volume has abundant free storage and the instance meets needed throughput ceilings. What is the most direct tuning action?
- Increase only gp3 volume GiB expecting provisioned IOPS automatically to rise with size as with some gp2 configurations.
- Increase gp3 provisioned throughput (MiB/s) while leaving IOPS unchanged despite metrics showing an IOPS rather than bandwidth ceiling.
- Increase the gp3 provisioned IOPS within supported limits after checking host and volume performance ceilings.
- Add an EBS-optimized instance with more aggregate bandwidth but leave the volume-level gp3 IOPS configuration saturated.
Explanation
Correct Answer
C:gp3 decouples provisioned IOPS and throughput from storage size within service limits, so IOPS can be tuned without adding unused capacity.
Incorrect Answers
A:gp3 IOPS is separately provisioned within limits; increasing storage capacity does not automatically correct an IOPS ceiling.
B:The specific bottleneck is IOPS. Throughput tuning alone cannot resolve exhausted I/O operations per second.
D:The stem states the host meets the demand; volume-level IOPS remains the limiting performance setting.
Question 327
A DynamoDB table with otherwise ample read capacity develops throttling because most requests target one partition key representing a globally popular product. Adding capacity has not solved the hotspot. What data-model improvement addresses the skew?
- Redesign the access pattern to distribute hot-key load where supported, using write sharding or appropriate cached/aggregated reads while preserving query semantics.
- Increase provisioned read capacity uniformly across the table without changing the dominant partition-key distribution.
- Add a GSI using the same hot product ID as its partition key and send all queries there instead.
- Turn on DynamoDB global tables and send hot-key reads to two Regions without considering each Region replica hot-partition limits.
Explanation
Correct Answer
A:Hot partitions are caused by concentrated key access; spreading or caching targeted operations addresses per-partition limits more directly than only total capacity.
Incorrect Answers
B:A hot logical key can exhaust per-partition throughput despite ample table-level capacity; more uniform provisioned units do not fix key skew.
C:Moving the identical hot key to an index recreates the same skew; a redesigned access pattern or read caching must distribute demand.
D:Replicas can serve regional reads, but the fundamental partition-key hot spot remains within each Region unless access is redesigned.
Question 328
An Aurora PostgreSQL cluster already has reader replicas serving analytics through the reader endpoint, while the writer remains healthy. Read traffic doubles for unpredictable campaign periods, and a fixed count of eight readers wastes capacity most nights. The team wants replica capacity to track reader demand, not simply add one permanent reader. What should it configure?
- Enable Aurora Auto Scaling for supported reader instances with minimum and maximum replica counts and target tracking on reader CPU or connections, then verify client use of the reader endpoint.
- Scale up the Aurora writer instance class during reporting bursts but keep the reader fleet at a permanently fixed minimum.
- Enable Aurora Serverless v2 writer capacity scaling and assume it automatically creates and terminates provisioned Aurora reader instances.
- Increase the maximum Aurora reader-endpoint connection count without a replica-count scaling policy.
Explanation
Correct Answer
A:Aurora Auto Scaling scales the eligible number of Aurora Replicas according to reader metrics and configured bounds; it does not scale the primary writer, so reader-endpoint routing remains essential.
Incorrect Answers
B:More writer CPU does not respond to reader-endpoint traffic or automatically add eligible Aurora replicas.
C:Serverless instance capacity adjustment is not the Aurora Auto Scaling replica-count policy requested for the dedicated reader pool.
D:Connection settings alone do not adjust the number of running read replicas to match variable load.
Question 329
A product catalog receives repeated eventually consistent DynamoDB GetItem reads for hot items. The team wants a managed in-memory API-compatible cache to reduce read latency without rewriting the data model into a relational engine. Which service should it evaluate?
- Use Amazon DynamoDB Accelerator (DAX) as an API-compatible in-memory cache, provided the application tolerates eventual-consistency and TTL behavior.
- Implement Amazon ElastiCache with an application-managed cache-aside adapter and assume it is a transparent DynamoDB API-compatible drop-in without client changes.
- Switch DynamoDB to on-demand capacity mode and assume it automatically caches repeated GetItem responses in memory between requests.
- Enable DynamoDB point-in-time recovery and treat restored historical table versions as a transparent low-latency read cache for live GetItem requests.
Explanation
Correct Answer
A:DAX supplies a DynamoDB-compatible caching layer for eligible GetItem operations, but the client must tolerate eventual-consistency/TTL behavior and writes that bypass DAX can make cached values stale.
Incorrect Answers
B:ElastiCache can serve a separately implemented cache-aside design, but it does not impersonate the DynamoDB client API with no application changes or automatically invalidate all DynamoDB updates.
C:On-demand billing changes DynamoDB capacity provisioning and costs, not the use of an API-compatible in-memory response cache for repeated key reads.
D:PITR provides table recovery to a point in time; it is not a live API-compatible cache for routine GetItem requests and would require separate recovery-table handling.
Question 330
A company needs subsecond autocomplete over multilingual product descriptions and faceted filtering, while its transactional source of truth remains in Aurora. SQL LIKE searches on the writer are degrading checkout throughput. Which search architecture most directly addresses this?
- Add RDS Proxy in front of Aurora and keep full-text LIKE and faceting queries against the same transactional writer.
- Add a general-purpose Aurora read replica and continue repeated wildcard LIKE scans without an appropriate full-text search index.
- Index searchable data in Amazon OpenSearch Service using an appropriate ingestion pipeline and route search queries to the index.
- Move product descriptions into a DynamoDB table with only the order ID as a key and expect native full-text relevance scoring.
Explanation
Correct Answer
C:A purpose-built search index supports text search and aggregations without forcing the transactional database writer to scan descriptions.
Incorrect Answers
A:Proxy pooling reduces connection pressure but does not supply a scalable inverted full-text index or take text search off the writer.
B:A reader may offload some reads but does not directly implement a dedicated multilingual search and faceting workload across large descriptive text.
D:A DynamoDB item lookup table does not automatically provide ranked multilingual search, autocomplete and facets.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests