A reports an inadequate or failed acceptance condition: The EBS volume reports higher provisioned throughput, but instance EBS attachment metrics remain capped. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that i/O telemetry reaches the desired range after eliminating the measured attachment bottleneck. The underlying design requirement is buying faster storage alone cannot exceed the instance's EBS throughput ceiling.

C reports an inadequate or failed acceptance condition: The instance has faster networking but its EBS volume provision is still the bottleneck. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that i/O telemetry reaches the desired range after eliminating the measured attachment bottleneck. The underlying design requirement is buying faster storage alone cannot exceed the instance's EBS throughput ceiling.

D reports an inadequate or failed acceptance condition: Application threads are tuned while observed storage read bandwidth stays flat. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that i/O telemetry reaches the desired range after eliminating the measured attachment bottleneck. The underlying design requirement is buying faster storage alone cannot exceed the instance's EBS throughput ceiling.

A would set an Athena workgroup cost limit only, leaving bytes scanned per query unchanged. This is not a defensible answer to the stated constraint (A distributed reporting pipeline sends large parquet-like datasets into S3 but Athena scans unnecessary columns): columnar storage plus partition pruning reduces scanned data and pay-per-scan costs. The required design is store data in efficient columnar format, partition by selective query dimensions, and prune partitions; acceptance depends on evidence that athena bytes scanned and query duration decline for the same correct result set.

B would partition by an unrelated low-selectivity field so all partitions must be scanned anyway. This is not a defensible answer to the stated constraint (A distributed reporting pipeline sends large parquet-like datasets into S3 but Athena scans unnecessary columns): columnar storage plus partition pruning reduces scanned data and pay-per-scan costs. The required design is store data in efficient columnar format, partition by selective query dimensions, and prune partitions; acceptance depends on evidence that athena bytes scanned and query duration decline for the same correct result set.

D would store all new analytical events as unpartitioned row-based files and scan every column. This is not a defensible answer to the stated constraint (A distributed reporting pipeline sends large parquet-like datasets into S3 but Athena scans unnecessary columns): columnar storage plus partition pruning reduces scanned data and pay-per-scan costs. The required design is store data in efficient columnar format, partition by selective query dimensions, and prune partitions; acceptance depends on evidence that athena bytes scanned and query duration decline for the same correct result set.

A reports an inadequate or failed acceptance condition: A workgroup cap rejects expensive queries but does not lower bytes scanned for accepted ones. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that athena bytes scanned and query duration decline for the same correct result set. The underlying design requirement is columnar storage plus partition pruning reduces scanned data and pay-per-scan costs.

B reports an inadequate or failed acceptance condition: Partition pruning is ineffective because queries filter on a different dimension. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that athena bytes scanned and query duration decline for the same correct result set. The underlying design requirement is columnar storage plus partition pruning reduces scanned data and pay-per-scan costs.

C reports an inadequate or failed acceptance condition: Athena query metrics show every column read from unpartitioned row files. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that athena bytes scanned and query duration decline for the same correct result set. The underlying design requirement is columnar storage plus partition pruning reduces scanned data and pay-per-scan costs.

B would set all cache TTLs to zero while assuming edge cache reuse will improve. This is not a defensible answer to the stated constraint (A web service's CloudFront hit ratio is poor because every request varies by a nonessential query parameter): excessive cache-key variation destroys hit ratio; overbroad caching can mix user data. The required design is redesign the cache policy to exclude irrelevant query keys while retaining user-varying authentication signals; acceptance depends on evidence that equivalent public requests reuse edge objects without leaking a personalized response.

C would include every volatile tracking query parameter in CloudFront cache keys for public assets. This is not a defensible answer to the stated constraint (A web service's CloudFront hit ratio is poor because every request varies by a nonessential query parameter): excessive cache-key variation destroys hit ratio; overbroad caching can mix user data. The required design is redesign the cache policy to exclude irrelevant query keys while retaining user-varying authentication signals; acceptance depends on evidence that equivalent public requests reuse edge objects without leaking a personalized response.

D would strip all authorization-sensitive cache-key variation and risk serving personalized data to others. This is not a defensible answer to the stated constraint (A web service's CloudFront hit ratio is poor because every request varies by a nonessential query parameter): excessive cache-key variation destroys hit ratio; overbroad caching can mix user data. The required design is redesign the cache policy to exclude irrelevant query keys while retaining user-varying authentication signals; acceptance depends on evidence that equivalent public requests reuse edge objects without leaking a personalized response.

A reports an inadequate or failed acceptance condition: All assets have zero TTL and origin requests occur on each public fetch. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that equivalent public requests reuse edge objects without leaking a personalized response. The underlying design requirement is excessive cache-key variation destroys hit ratio; overbroad caching can mix user data.

C reports an inadequate or failed acceptance condition: CloudFront miss ratio remains high as every transient query token yields a unique cache key. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that equivalent public requests reuse edge objects without leaking a personalized response. The underlying design requirement is excessive cache-key variation destroys hit ratio; overbroad caching can mix user data.

D reports an inadequate or failed acceptance condition: Anonymous clients receive a user-specific cached response from another principal. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that equivalent public requests reuse edge objects without leaking a personalized response. The underlying design requirement is excessive cache-key variation destroys hit ratio; overbroad caching can mix user data.

A would increase Lambda timeout to the maximum and assume cold start duration disappears. This is not a defensible answer to the stated constraint (A bursty AWS Lambda workload suffers cold start latency and crosses the customer's p99 target): provisioned concurrency keeps execution environments prepared but costs money when reserved. The required design is apply provisioned concurrency to selected critical functions after inspecting cold start contribution; acceptance depends on evidence that cold-start-related tail latency falls under load within the purchased concurrency envelope.

B would buy provisioned concurrency for unrelated infrequently called functions instead of measured critical ones. This is not a defensible answer to the stated constraint (A bursty AWS Lambda workload suffers cold start latency and crosses the customer's p99 target): provisioned concurrency keeps execution environments prepared but costs money when reserved. The required design is apply provisioned concurrency to selected critical functions after inspecting cold start contribution; acceptance depends on evidence that cold-start-related tail latency falls under load within the purchased concurrency envelope.

D would leave reserved concurrency at zero for the critical function during expected traffic spikes. This is not a defensible answer to the stated constraint (A bursty AWS Lambda workload suffers cold start latency and crosses the customer's p99 target): provisioned concurrency keeps execution environments prepared but costs money when reserved. The required design is apply provisioned concurrency to selected critical functions after inspecting cold start contribution; acceptance depends on evidence that cold-start-related tail latency falls under load within the purchased concurrency envelope.

A reports an inadequate or failed acceptance condition: A longer Lambda timeout is configured but p99 cold start contribution is unchanged. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cold-start-related tail latency falls under load within the purchased concurrency envelope. The underlying design requirement is provisioned concurrency keeps execution environments prepared but costs money when reserved.

B reports an inadequate or failed acceptance condition: Provisioned concurrency is spent on noncritical functions while the important endpoint stays cold. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cold-start-related tail latency falls under load within the purchased concurrency envelope. The underlying design requirement is provisioned concurrency keeps execution environments prepared but costs money when reserved.

C reports an inadequate or failed acceptance condition: The critical function returns throttles after reserved concurrency is set to zero. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cold-start-related tail latency falls under load within the purchased concurrency envelope. The underlying design requirement is provisioned concurrency keeps execution environments prepared but costs money when reserved.

B would reduce partition count to one while increasing traffic, preserving a serial bottleneck. This is not a defensible answer to the stated constraint (A Kafka consumer application cannot keep up because its single consumer processes all partitions serially): kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers. The required design is increase partitioning and consumer-group concurrency within ordering requirements; acceptance depends on evidence that lag decreases as partitions are processed in parallel while per-key ordering holds.

C would process messages from the same ordering key in parallel without preserving required order. This is not a defensible answer to the stated constraint (A Kafka consumer application cannot keep up because its single consumer processes all partitions serially): kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers. The required design is increase partitioning and consumer-group concurrency within ordering requirements; acceptance depends on evidence that lag decreases as partitions are processed in parallel while per-key ordering holds.

D would launch more consumer instances than active Kafka partitions and expect true per-partition parallelism. This is not a defensible answer to the stated constraint (A Kafka consumer application cannot keep up because its single consumer processes all partitions serially): kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers. The required design is increase partitioning and consumer-group concurrency within ordering requirements; acceptance depends on evidence that lag decreases as partitions are processed in parallel while per-key ordering holds.

A reports an inadequate or failed acceptance condition: Consumer lag grows as all records are serialized through one Kafka partition. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lag decreases as partitions are processed in parallel while per-key ordering holds. The underlying design requirement is kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers.

C reports an inadequate or failed acceptance condition: Messages for the same ordering key commit out of order when concurrent workers process them. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lag decreases as partitions are processed in parallel while per-key ordering holds. The underlying design requirement is kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers.

D reports an inadequate or failed acceptance condition: Additional consumer instances are idle because there are not enough partitions to assign. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lag decreases as partitions are processed in parallel while per-key ordering holds. The underlying design requirement is kinesis and MSK parallelism are limited by shards or partitions, not merely adding consumers.

A would route all users through a single distant endpoint despite multiple healthy Regions. This is not a defensible answer to the stated constraint (A multi-Region API has high response time for distant users even though regional EC2 hosts are underutilized): network path and region selection can dominate latency after compute is already sufficient. The required design is evaluate Global Accelerator or a suitable edge and regional routing architecture with measurements; acceptance depends on evidence that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency.

B would upgrade regional EC2 CPU even though end-user network distance dominates latency. This is not a defensible answer to the stated constraint (A multi-Region API has high response time for distant users even though regional EC2 hosts are underutilized): network path and region selection can dominate latency after compute is already sufficient. The required design is evaluate Global Accelerator or a suitable edge and regional routing architecture with measurements; acceptance depends on evidence that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency.

D would use Route 53 weighted DNS alone and assume it continuously optimizes network path latency. This is not a defensible answer to the stated constraint (A multi-Region API has high response time for distant users even though regional EC2 hosts are underutilized): network path and region selection can dominate latency after compute is already sufficient. The required design is evaluate Global Accelerator or a suitable edge and regional routing architecture with measurements; acceptance depends on evidence that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency.

A reports an inadequate or failed acceptance condition: One central Region answers every user despite deployment availability in nearby Regions. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency. The underlying design requirement is network path and region selection can dominate latency after compute is already sufficient.

B reports an inadequate or failed acceptance condition: Regional EC2 CPU falls while distant user RTT stays too high. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency. The underlying design requirement is network path and region selection can dominate latency after compute is already sufficient.

C reports an inadequate or failed acceptance condition: A weighted DNS record chooses a distant endpoint for users who need low latency. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that users in test geographies reach closer healthy regional endpoints with reduced round-trip latency. The underlying design requirement is network path and region selection can dominate latency after compute is already sufficient.