A reports an inadequate or failed acceptance condition: The user logs out on every instance replacement because session data lived only in RAM. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that clients remain authenticated during instance replacement without a sticky host assignment. The underlying design requirement is sticky routing cannot guarantee session continuity when the selected host or memory state disappears.

B reports an inadequate or failed acceptance condition: ALB stickiness remains configured but does not recover state after a failed host. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that clients remain authenticated during instance replacement without a sticky host assignment. The underlying design requirement is sticky routing cannot guarantee session continuity when the selected host or memory state disappears.

C reports an inadequate or failed acceptance condition: Clients retain cookies but servers no longer possess the corresponding authenticated sessions. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that clients remain authenticated during instance replacement without a sticky host assignment. The underlying design requirement is sticky routing cannot guarantee session continuity when the selected host or memory state disappears.

B would purchase additional high-capacity EC2 instances for a fleet running at 4% CPU. This is not a defensible answer to the stated constraint (A project uses several large EC2 instances at 4% CPU with no evidence of memory pressure): low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity. The required design is evaluate AWS Compute Optimizer recommendations with workload-specific memory and latency constraints; acceptance depends on evidence that a smaller supported instance family meets SLO and reduces hourly resource cost.

C would assume every Compute Optimizer recommendation is safe without verifying application runtime compatibility. This is not a defensible answer to the stated constraint (A project uses several large EC2 instances at 4% CPU with no evidence of memory pressure): low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity. The required design is evaluate AWS Compute Optimizer recommendations with workload-specific memory and latency constraints; acceptance depends on evidence that a smaller supported instance family meets SLO and reduces hourly resource cost.

D would choose smaller EC2 instances solely from average CPU, ignoring peak memory and latency constraints. This is not a defensible answer to the stated constraint (A project uses several large EC2 instances at 4% CPU with no evidence of memory pressure): low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity. The required design is evaluate AWS Compute Optimizer recommendations with workload-specific memory and latency constraints; acceptance depends on evidence that a smaller supported instance family meets SLO and reduces hourly resource cost.

A reports an inadequate or failed acceptance condition: The fleet's hourly bill increases after adding larger instances. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a smaller supported instance family meets SLO and reduces hourly resource cost. The underlying design requirement is low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity.

C reports an inadequate or failed acceptance condition: A Compute Optimizer recommendation is applied but the application cannot start on the selected architecture. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a smaller supported instance family meets SLO and reduces hourly resource cost. The underlying design requirement is low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity.

D reports an inadequate or failed acceptance condition: The cheapest suggested EC2 size fails peak memory or latency SLOs despite low average CPU. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a smaller supported instance family meets SLO and reduces hourly resource cost. The underlying design requirement is low CPU suggests rightsizing only after validating memory, platform architecture, and peak capacity.

A would use EC2 Spot as the sole capacity for always-on services without interruption analysis. This is not a defensible answer to the stated constraint (An application fleet uses on-demand capacity around the clock with predictable annual usage): commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment. The required design is purchase a suitable Savings Plan commitment after analyzing eligible steady-state baseline usage; acceptance depends on evidence that savings Plan coverage and utilization improve while instance flexibility remains appropriate.

B would pay On-Demand for the complete predictable 24/7 baseline without analyzing commitments. This is not a defensible answer to the stated constraint (An application fleet uses on-demand capacity around the clock with predictable annual usage): commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment. The required design is purchase a suitable Savings Plan commitment after analyzing eligible steady-state baseline usage; acceptance depends on evidence that savings Plan coverage and utilization improve while instance flexibility remains appropriate.

D would buy a savings commitment sized far beyond known eligible usage, increasing unused commitment cost. This is not a defensible answer to the stated constraint (An application fleet uses on-demand capacity around the clock with predictable annual usage): commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment. The required design is purchase a suitable Savings Plan commitment after analyzing eligible steady-state baseline usage; acceptance depends on evidence that savings Plan coverage and utilization improve while instance flexibility remains appropriate.

A reports an inadequate or failed acceptance condition: Spot interruption terminates a continuously required worker and breaks service availability. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that savings Plan coverage and utilization improve while instance flexibility remains appropriate. The underlying design requirement is commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment.

B reports an inadequate or failed acceptance condition: On-Demand compute spend remains unchanged across months of predictable baseline operation. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that savings Plan coverage and utilization improve while instance flexibility remains appropriate. The underlying design requirement is commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment.

C reports an inadequate or failed acceptance condition: A purchased commitment is 40% utilized because its hourly size exceeds steady demand. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that savings Plan coverage and utilization improve while instance flexibility remains appropriate. The underlying design requirement is commitment purchases reduce predictable compute spend; reserving peak bursts risks unused commitment.

B would leave all archival log objects in S3 Standard indefinitely regardless of their rare-read pattern. This is not a defensible answer to the stated constraint (An S3 bucket holds billions of historical log objects with rare reads but no lifecycle rules): object lifecycle management lowers cost when retrieval, retention, and request charges are modeled. The required design is adopt a compliant S3 storage-class transition and expiration schedule based on access analysis; acceptance depends on evidence that lifecycle inventory shows objects transition at expected ages and storage bills decline.

C would expire historical log objects immediately without verifying required retention and audit periods. This is not a defensible answer to the stated constraint (An S3 bucket holds billions of historical log objects with rare reads but no lifecycle rules): object lifecycle management lowers cost when retrieval, retention, and request charges are modeled. The required design is adopt a compliant S3 storage-class transition and expiration schedule based on access analysis; acceptance depends on evidence that lifecycle inventory shows objects transition at expected ages and storage bills decline.

D would transition everything to deep archive without considering minimum storage duration or retrieval costs. This is not a defensible answer to the stated constraint (An S3 bucket holds billions of historical log objects with rare reads but no lifecycle rules): object lifecycle management lowers cost when retrieval, retention, and request charges are modeled. The required design is adopt a compliant S3 storage-class transition and expiration schedule based on access analysis; acceptance depends on evidence that lifecycle inventory shows objects transition at expected ages and storage bills decline.

A reports an inadequate or failed acceptance condition: All historical logs remain in S3 Standard and billed storage continues growing. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lifecycle inventory shows objects transition at expected ages and storage bills decline. The underlying design requirement is object lifecycle management lowers cost when retrieval, retention, and request charges are modeled.

C reports an inadequate or failed acceptance condition: Lifecycle expiration deletes logs before an auditor's retention requirement ends. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lifecycle inventory shows objects transition at expected ages and storage bills decline. The underlying design requirement is object lifecycle management lowers cost when retrieval, retention, and request charges are modeled.

D reports an inadequate or failed acceptance condition: Deep Archive minimum-duration and retrieval costs exceed the expected cold-storage savings. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that lifecycle inventory shows objects transition at expected ages and storage bills decline. The underlying design requirement is object lifecycle management lowers cost when retrieval, retention, and request charges are modeled.

A would route all analytical reads to the writer even when read replicas could absorb them. This is not a defensible answer to the stated constraint (An Aurora database has oversized write instance capacity but most demand is read-only query traffic): read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom. The required design is use read scaling or a smaller writer after workload and failover benchmarking; acceptance depends on evidence that writer load decreases while p95 read/write latency and failover targets stay within bounds.

B would downsize the database writer without benchmarking write peaks or failover performance first. This is not a defensible answer to the stated constraint (An Aurora database has oversized write instance capacity but most demand is read-only query traffic): read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom. The required design is use read scaling or a smaller writer after workload and failover benchmarking; acceptance depends on evidence that writer load decreases while p95 read/write latency and failover targets stay within bounds.

D would raise the Aurora writer instance size further for a primarily read-only workload. This is not a defensible answer to the stated constraint (An Aurora database has oversized write instance capacity but most demand is read-only query traffic): read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom. The required design is use read scaling or a smaller writer after workload and failover benchmarking; acceptance depends on evidence that writer load decreases while p95 read/write latency and failover targets stay within bounds.

A reports an inadequate or failed acceptance condition: Reader requests finish faster but a downsized writer fails peak transaction SLAs. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that writer load decreases while p95 read/write latency and failover targets stay within bounds. The underlying design requirement is read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom.

B reports an inadequate or failed acceptance condition: A database class change lowers cost but restoration after simulated failover exceeds its limit. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that writer load decreases while p95 read/write latency and failover targets stay within bounds. The underlying design requirement is read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom.

C reports an inadequate or failed acceptance condition: Aurora writer CPU remains high because read-only queries are still sent to it. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that writer load decreases while p95 read/write latency and failover targets stay within bounds. The underlying design requirement is read replicas offload eligible queries; writer capacity should follow actual writes and necessary headroom.

B would count only public internet transfer and ignore inter-Region and cross-AZ charges. This is not a defensible answer to the stated constraint (A team cannot explain why data-transfer charges suddenly increased after a new analytics architecture): granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing. The required design is query CUR line items and correlate cross-AZ, inter-Region, and internet traffic to workload IDs; acceptance depends on evidence that transfer bytes and corresponding charges map to the responsible request path.

C would use CPU dashboards to estimate cross-AZ bytes without examining billing transfer line items. This is not a defensible answer to the stated constraint (A team cannot explain why data-transfer charges suddenly increased after a new analytics architecture): granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing. The required design is query CUR line items and correlate cross-AZ, inter-Region, and internet traffic to workload IDs; acceptance depends on evidence that transfer bytes and corresponding charges map to the responsible request path.

D would attribute the entire increase to S3 storage regardless of traffic routes and CUR categories. This is not a defensible answer to the stated constraint (A team cannot explain why data-transfer charges suddenly increased after a new analytics architecture): granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing. The required design is query CUR line items and correlate cross-AZ, inter-Region, and internet traffic to workload IDs; acceptance depends on evidence that transfer bytes and corresponding charges map to the responsible request path.

A reports an inadequate or failed acceptance condition: The reconciliation omits inter-Region traffic even though its billed usage increased after the redesign. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that transfer bytes and corresponding charges map to the responsible request path. The underlying design requirement is granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing.

C reports an inadequate or failed acceptance condition: EC2 CPU charts show no change while data-transfer billing line items continue rising. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that transfer bytes and corresponding charges map to the responsible request path. The underlying design requirement is granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing.

D reports an inadequate or failed acceptance condition: The CUR report incorrectly labels all transfer as S3 storage. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that transfer bytes and corresponding charges map to the responsible request path. The underlying design requirement is granular cost allocation identifies expensive paths; CPU utilization alone says nothing about transfer pricing.