Question 490
A Kafka-compatible analytics team polls one MSK topic from a single consumer instance despite having eight independent partitions. Topic lag grows under load and consumer CPU is saturated, but brokers are healthy. Which consumer-side change is most direct?
- Add brokers to the healthy MSK cluster but keep exactly one CPU-saturated application consumer process for all eight available partitions.
- Run additional consumers in the same consumer group up to useful partition parallelism, and test ordering requirements.
- Increase producer batch size alone while maintaining the single consumer handling all partitions and its saturated processing CPU.
- Create twelve consumers in one group for the eight-partition topic and assume all twelve will process an assigned partition simultaneously.
Explanation
Correct Answer
B:Kafka consumer groups can distribute partitions among consumers, increasing processing parallelism without changing topic semantics.
Incorrect Answers
A:More broker-side capacity does not address the measured processing bottleneck in a single consumer instance.
C:Producer batching can change write efficiency but does not add consumer group workers to process existing lagged partitions.
D:Kafka generally assigns each partition to only one active group consumer; extra consumers beyond the partition count are not a useful parallelism increase.
Question 491
A GPU inference endpoint receives predictable bursts every hour, but CPU-based scaling metrics remain near zero as GPU utilization and waiting requests climb. The team runs containers on a compatible managed platform. What metric strategy improves scaling decisions?
- Increase tasks only when average CPU utilization crosses 90 percent even though GPU-bound inference has already queued requests at low CPU.
- Scale workers using a supported custom CloudWatch GPU utilization or in-flight request metric validated against tail latency.
- Keep scaling solely on average CPU because GPU-bound inference always saturates general-purpose CPU cores first.
- Replace GPU utilization with the container image pull duration as the target-tracking metric, even after the service is running.
Explanation
Correct Answer
B:GPU and queue metrics reflect the saturated resource and user waiting time, unlike unrelated CPU readings.
Incorrect Answers
A:CPU-only metrics do not detect the saturated GPU or outstanding request queue identified by tracing.
C:GPU-dependent request backlogs can occur while CPU appears idle, making CPU a poor signal for this workload.
D:Image pull time measures startup deployment and does not track actual live GPU inference workload or queue latency.
Question 492
A payments API stores JWT verification public keys in a remote identity service. Each request synchronously downloads the same key set, creating a measured latency spike when the identity service slows. Keys rotate with a published cache lifetime. What is the best targeted performance adjustment?
- Cache the verified JWKS according to its supported rotation and expiry rules, refreshing safely when an unknown key ID appears.
- Disable JWT signature validation entirely so no identity key lookup can occur.
- Embed one expired public key forever and ignore changes to the provider key set.
- Increase the JWT verification service connection pool but still download the identical JWKS over HTTPS for every customer request.
Explanation
Correct Answer
A:Safe key-set caching avoids repeated network retrieval while respecting key rotation and validation requirements.
Incorrect Answers
B:Skipping token signature verification would create an authentication vulnerability rather than safe latency optimization.
C:A permanent stale key cannot support normal key rotation and may reject valid tokens or trust revoked key material.
D:A larger HTTP pool may reduce handshake overhead but not the repeated upstream key-set requests that the supported JWKS cache lifetime is intended to avoid.
Question 493
A customer API already uses an ALB and an Auto Scaling group across three Availability Zones. A single RDS for PostgreSQL DB instance, however, is still deployed in one AZ and caused the last application-wide outage when that AZ failed. Which change removes the documented database single point of failure?
- Add RDS read replicas in the same Availability Zone as the existing primary and keep the primary as the single writable failure point.
- Convert the RDS DB instance to a Multi-AZ deployment and test automatic failover behavior and connection recovery.
- Deploy more application targets across existing AZs and assume the database becomes available when app nodes are redundant.
- Enable a larger RDS instance class and high storage IOPS while leaving the writer in one AZ with no failover standby.
Explanation
Correct Answer
B:A supported RDS Multi-AZ deployment maintains a standby in another AZ and supports managed failover; client retry/reconnection behavior still needs testing.
Incorrect Answers
A:Read replicas may offload queries but do not provide synchronous standby failover of the writer if the primary AZ disappears.
C:The web tier is already multi-AZ; the single-AZ DB remains the documented root cause and must gain database-level failover.
D:Capacity upgrades do not remove Availability Zone failure exposure; Multi-AZ deployment addresses availability.
Question 494
An Aurora cluster contains one writer and three read replicas in a single Region. During a writer incident, automatic promotion selects a reader that was intentionally provisioned for reporting and is too small for production writes. Which Aurora-specific configuration should the architect review?
- Increase Aurora reader endpoint weight for the reporting replica, assuming that controls which replica is promoted during writer failure.
- Lower the reporting replica instance class further while keeping all Aurora promotion tiers at their defaults.
- Reconfigure only the Route 53 application alias to point at the existing writer endpoint instead of reviewing Aurora failover candidates.
- Review the Aurora Replica promotion priority tiers and instance sizing so suitable failover candidates are preferred for writer promotion.
Explanation
Correct Answer
D:Aurora failover selection considers promotion tiers, with ties and availability affecting selection; production-ready replicas need deliberate tier and capacity planning.
Incorrect Answers
A:Reader endpoint distribution and failover promotion priority are different. Configure Aurora promotion tiers and adequate candidates.
B:A smaller reporting reader can still be promoted unless tiers explicitly prefer production-capable candidates. Sizing and priority both matter.
C:An application DNS alias does not control which Aurora replica is elected to become the new writer.
Question 495
An asynchronous Lambda worker consumes SQS messages. A poison message fails the handler every time and repeatedly blocks useful work; the business needs evidence for investigation without endless retries. What queue-level control is most appropriate?
- Increase the SQS visibility timeout to its maximum and allow the same poison message to retry indefinitely without a DLQ.
- Configure Lambda partial batch responses only but leave the poison message on an unbounded redelivery cycle.
- Configure a dead-letter queue and a realistic maxReceiveCount, alert on DLQ depth, and investigate or redrive after repair.
- Delete every message after its first failed processing attempt so other messages can proceed without preserving evidence.
Explanation
Correct Answer
C:A DLQ isolates repeatedly failing messages while preserving evidence for controlled recovery and allowing healthy messages to proceed.
Incorrect Answers
A:Longer invisibility delays retries but does not bound repeated failures or preserve a separate investigation queue.
B:Partial responses reduce duplicate successes, but the persistently malformed item still needs bounded receive count and a DLQ.
D:Dropping failed work violates investigation and durability requirements; route it to a DLQ after controlled retries.
Question 496
A regional API with steady load begins returning 5xx when one AZ becomes impaired because its target group continues sending traffic to unhealthy instances. What operational control should be validated before adding more capacity?
- Raise ALB idle timeout and assume it will stop routing new connections to application targets returning HTTP 500.
- Enable more instances only in the impaired AZ, without changing the target-group health check or exclusion behavior.
- Review ALB health-check path and thresholds and ensure unhealthy targets are removed while healthy AZ targets remain available.
- Set the health-check matcher to accept every HTTP 5xx result as healthy and retain the failing targets.
Explanation
Correct Answer
C:Target health decisions determine whether the ALB continues to send requests to failed instances; correct checks and spare healthy capacity address the failure.
Incorrect Answers
A:Idle timeout controls connection lifetime; it does not validate health-check status or remove unhealthy targets.
B:Extra impaired targets do not fix incorrect health evaluation and may increase errors; confirm healthy routing across remaining AZs.
D:Treating failed responses as success hides the outage; appropriate endpoint status checks should exclude unhealthy nodes.
Question 497
A service occasionally loses its only downstream database connection because retries from hundreds of API tasks begin at the same instant after a brief outage. The database recovers, but the synchronized retry surge immediately overwhelms it again. Which resilience change breaks this feedback loop?
- Increase the database connection limit but leave all clients retrying simultaneously without randomized delays.
- Use fixed-delay retries at exactly the same interval in every API task, without jitter or admission control.
- Put RDS Proxy in front of the database but retain unlimited concurrent application retries and assume pooling always eliminates all overload.
- Use bounded exponential backoff with full jitter, circuit-breaking or admission controls, and idempotent recovery where required.
Explanation
Correct Answer
D:Jitter spreads retries over time and bounded policies prevent a synchronized retry storm from repeatedly saturating the recovered database.
Incorrect Answers
A:Higher limits may postpone exhaustion but do not break the synchronized surge feedback loop that overwhelms the recovering DB.
B:A synchronized retry cadence repeatedly recreates the load spike. Randomized bounded backoff desynchronizes demand.
C:RDS Proxy can pool connections but does not replace bounded backoff, circuit breaking or idempotent request-level resilience under massive retry storms.
Question 498
A batch processing cluster periodically fails to launch replacement instances during traffic spikes. Application logs are healthy until scale-out, but EC2 API responses report a service quota limit for instances in the chosen family. What should reliability engineering do?
- Increase the Auto Scaling group maximum desired size while keeping the account EC2 vCPU quota unchanged.
- Replace the launch template user-data script, despite the EC2 API explicitly reporting a service quota denial rather than launch-script failure.
- Plan required quotas and capacity ahead of demand, request relevant quota increases, and diversify allowed capacity where appropriate.
- Add larger instances of the same constrained family without checking the family vCPU quota or capacity availability.
Explanation
Correct Answer
C:An account or family service quota can block scale-out even when Auto Scaling policy is correct; headroom and alternate capacity paths are needed.
Incorrect Answers
A:The group cannot scale past enforced EC2 capacity quotas regardless of its own maximum setting.
B:A post-launch bootstrap change does not correct an API-level quota preventing instances from launching.
D:Larger instances can consume more family quota and may worsen launch failures; plan quotas and diversify eligible pools.
Question 499
A regulated checkout application already uses an RDS MySQL Multi-AZ DB instance and tested backup restoration. Its disaster runbook, however, has never shown how Java connection pools behave when RDS switches the writer to the standby. The compliance officer requests controlled evidence of failover and endpoint recovery during a maintenance window. Which test is most appropriate?
- Trigger an unscheduled cross-Region Aurora switchover even though this is an existing single-Region RDS MySQL Multi-AZ DB instance.
- Temporarily delete the only source database so that an unrehearsed restore can be called a managed Multi-AZ failover test.
- Run an approved RDS reboot with failover on the existing Multi-AZ instance under controlled traffic, measure recovery and verify client reconnection to the updated DB endpoint.
- Measure snapshot restore recovery time only, but leave the actual managed writer-to-standby failover and Java connection-pool behavior untested.
Explanation
Correct Answer
C:An RDS reboot with failover can switch to the standby and update the DB DNS endpoint, allowing validation of measured recovery and application pool reconnect behavior with appropriately controlled transaction safety.
Incorrect Answers
A:Aurora Global Database switchover is a different database product and fault domain; it cannot validate the specific Multi-AZ RDS endpoint transition already deployed.
B:Deleting the instance is destructive and is not the supported controlled failover mechanism for an existing Multi-AZ DB instance.
D:Backup restoration measures a different recovery mechanism and does not prove client reconnection after an RDS Multi-AZ failover.
Question 500
An ECS worker processes SQS standard-queue videos; each task takes anywhere from 40 seconds to 25 minutes. The configured short visibility timeout lets a second worker pick up long-running tasks, but setting it permanently to 30 minutes makes genuine worker crashes slow to retry. The worker can report healthy progress and retain each message receipt handle. What is the most targeted control?
- Increase the queue-level visibility timeout permanently to its longest supported interval, even for tasks that usually finish in forty seconds.
- Implement a worker heartbeat that calls ChangeMessageVisibility to extend only the in-progress message invisibility as needed, and delete after success.
- Add SQS long polling and assume waiting longer for ReceiveMessage extends the visibility of a message that has already been received by an active worker.
- Increase the DLQ maxReceiveCount for every task and assume this postpones premature concurrent delivery of an in-progress long job.
Explanation
Correct Answer
B:ChangeMessageVisibility can extend an individual message’s visibility while processing continues, balancing long successful jobs with timely failed-worker retries.
Incorrect Answers
A:A permanently long timeout delays delivery after a real worker crash; using individual ChangeMessageVisibility progress updates better balances the short and long jobs.
C:Long polling affects message acquisition and empty receives, not the invisibility timeout for a message already delivered.
D:DLQ redrive thresholds govern repeated failures, not when a currently running message becomes visible again.
AWS Certified Solutions Architect - Professional SAP-C02 Practice Tests