A reports an inadequate or failed acceptance condition: The container image includes a literal password in its environment defaults. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that deployed task definitions contain no literal password and the application retrieves the current secret. The underlying design requirement is retrieving a managed secret at runtime avoids embedding sensitive credentials into images or pipelines.

B reports an inadequate or failed acceptance condition: Build logs show a successful secret retrieval, but the deployed app still uses the old baked-in value. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that deployed task definitions contain no literal password and the application retrieves the current secret. The underlying design requirement is retrieving a managed secret at runtime avoids embedding sensitive credentials into images or pipelines.

C reports an inadequate or failed acceptance condition: Secrets Manager rotates the credential and the application loses DB access because it never refreshes. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that deployed task definitions contain no literal password and the application retrieves the current secret. The underlying design requirement is retrieving a managed secret at runtime avoids embedding sensitive credentials into images or pipelines.

B would treat an EC2 inventory list as proof that every node meets the required configuration. This is not a defensible answer to the stated constraint (Hundreds of managed nodes must receive a repeatable post-deploy configuration while preserving change evidence): state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability. The required design is use Systems Manager State Manager associations with approved documents and compliance reporting; acceptance depends on evidence that association compliance and execution records show configuration on all targeted managed nodes.

C would send State Manager associations to the wrong resource tags, excluding production managed nodes. This is not a defensible answer to the stated constraint (Hundreds of managed nodes must receive a repeatable post-deploy configuration while preserving change evidence): state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability. The required design is use Systems Manager State Manager associations with approved documents and compliance reporting; acceptance depends on evidence that association compliance and execution records show configuration on all targeted managed nodes.

D would run an ad-hoc shell script on a subset of instances without managed-node tracking. This is not a defensible answer to the stated constraint (Hundreds of managed nodes must receive a repeatable post-deploy configuration while preserving change evidence): state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability. The required design is use Systems Manager State Manager associations with approved documents and compliance reporting; acceptance depends on evidence that association compliance and execution records show configuration on all targeted managed nodes.

A reports an inadequate or failed acceptance condition: A node appears in Systems Manager inventory without the required association execution. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that association compliance and execution records show configuration on all targeted managed nodes. The underlying design requirement is state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability.

C reports an inadequate or failed acceptance condition: The association exists but its last execution failed on most required production nodes. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that association compliance and execution records show configuration on all targeted managed nodes. The underlying design requirement is state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability.

D reports an inadequate or failed acceptance condition: Only a subset of tagged managed nodes reports compliant state. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that association compliance and execution records show configuration on all targeted managed nodes. The underlying design requirement is state Manager maintains desired node configuration, whereas ad hoc SSH leaves little centralized traceability.

A would assign a permanent 1% route split and claim full rollout readiness without promotion criteria. This is not a defensible answer to the stated constraint (A critical API release must be tested by a small production cohort before general rollout): a measured canary reduces blast radius compared with replacing every healthy target simultaneously. The required design is use weighted routing or a canary deployment that exposes a defined small traffic share before promotion; acceptance depends on evidence that metrics segregate canary health and full traffic is assigned only after acceptance checks.

B would direct 100% of production traffic to the untested API revision immediately. This is not a defensible answer to the stated constraint (A critical API release must be tested by a small production cohort before general rollout): a measured canary reduces blast radius compared with replacing every healthy target simultaneously. The required design is use weighted routing or a canary deployment that exposes a defined small traffic share before promotion; acceptance depends on evidence that metrics segregate canary health and full traffic is assigned only after acceptance checks.

D would use only a synthetic health check without measuring actual cohort error or latency metrics. This is not a defensible answer to the stated constraint (A critical API release must be tested by a small production cohort before general rollout): a measured canary reduces blast radius compared with replacing every healthy target simultaneously. The required design is use weighted routing or a canary deployment that exposes a defined small traffic share before promotion; acceptance depends on evidence that metrics segregate canary health and full traffic is assigned only after acceptance checks.

A reports an inadequate or failed acceptance condition: The 1% weighted target continues indefinitely despite failed readiness criteria for full promotion. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that metrics segregate canary health and full traffic is assigned only after acceptance checks. The underlying design requirement is a measured canary reduces blast radius compared with replacing every healthy target simultaneously.

B reports an inadequate or failed acceptance condition: The new API version receives all requests before the canary error threshold is measured. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that metrics segregate canary health and full traffic is assigned only after acceptance checks. The underlying design requirement is a measured canary reduces blast radius compared with replacing every healthy target simultaneously.

C reports an inadequate or failed acceptance condition: Canary health is green only in a staging environment with no production cohort data. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that metrics segregate canary health and full traffic is assigned only after acceptance checks. The underlying design requirement is a measured canary reduces blast radius compared with replacing every healthy target simultaneously.

B would keep backups in the primary Region and restore after its outage despite a sub-five-minute RPO. This is not a defensible answer to the stated constraint (A payments service requires a tested RPO under five minutes during a Region disaster and a tightly bounded RTO): backup-only recovery is unlikely to meet near-real-time regional recovery targets. The required design is use cross-Region database replication with a prepared standby application and automated, rehearsed failover; acceptance depends on evidence that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO.

C would run asynchronous cross-Region replication without lag alarms or failover drills. This is not a defensible answer to the stated constraint (A payments service requires a tested RPO under five minutes during a Region disaster and a tightly bounded RTO): backup-only recovery is unlikely to meet near-real-time regional recovery targets. The required design is use cross-Region database replication with a prepared standby application and automated, rehearsed failover; acceptance depends on evidence that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO.

D would prepare secondary application servers but omit database replication for the payments records. This is not a defensible answer to the stated constraint (A payments service requires a tested RPO under five minutes during a Region disaster and a tightly bounded RTO): backup-only recovery is unlikely to meet near-real-time regional recovery targets. The required design is use cross-Region database replication with a prepared standby application and automated, rehearsed failover; acceptance depends on evidence that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO.

A reports an inadequate or failed acceptance condition: Only the primary-region backup exists when the recovery drill begins. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO. The underlying design requirement is backup-only recovery is unlikely to meet near-real-time regional recovery targets.

C reports an inadequate or failed acceptance condition: Replication lag during Region isolation exceeds the five-minute RPO threshold. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO. The underlying design requirement is backup-only recovery is unlikely to meet near-real-time regional recovery targets.

D reports an inadequate or failed acceptance condition: Recovery completes after the bounded RTO despite healthy app servers in the standby Region. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a Region-isolation drill shows replication lag below the allowed RPO and service restoration within RTO. The underlying design requirement is backup-only recovery is unlikely to meet near-real-time regional recovery targets.

A would apply AWS Backup policies to current accounts but omit enrollment and coverage of newly created accounts. This is not a defensible answer to the stated constraint (Compliance needs a central backup policy covering EBS and RDS across accounts with locked recovery points): organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots. The required design is use AWS Backup organization policies, a cross-account backup vault, and Vault Lock where applicable; acceptance depends on evidence that new accounts inherit backup schedules and locked restore points remain protected against early deletion.

B would enable an unlocked vault with broad deletion permissions and call the restore points immutable. This is not a defensible answer to the stated constraint (Compliance needs a central backup policy covering EBS and RDS across accounts with locked recovery points): organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots. The required design is use AWS Backup organization policies, a cross-account backup vault, and Vault Lock where applicable; acceptance depends on evidence that new accounts inherit backup schedules and locked restore points remain protected against early deletion.

D would protect backups only within the same member account that could be compromised. This is not a defensible answer to the stated constraint (Compliance needs a central backup policy covering EBS and RDS across accounts with locked recovery points): organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots. The required design is use AWS Backup organization policies, a cross-account backup vault, and Vault Lock where applicable; acceptance depends on evidence that new accounts inherit backup schedules and locked restore points remain protected against early deletion.

A reports an inadequate or failed acceptance condition: A protected vault allows early delete despite the required Vault Lock retention. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that new accounts inherit backup schedules and locked restore points remain protected against early deletion. The underlying design requirement is organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots.

B reports an inadequate or failed acceptance condition: An ordinary same-account backup plan completes but has no independent protected recovery points. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that new accounts inherit backup schedules and locked restore points remain protected against early deletion. The underlying design requirement is organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots.

C reports an inadequate or failed acceptance condition: Current accounts have backups, but a newly created account has no inherited plan. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that new accounts inherit backup schedules and locked restore points remain protected against early deletion. The underlying design requirement is organization backup governance and Vault Lock protect recovery evidence beyond isolated snapshots.

B would rely on a very long DNS TTL and assume clients will immediately switch after a regional failure. This is not a defensible answer to the stated constraint (A user-facing multi-Region application needs controlled DNS failover when a regional endpoint fails health checks): failover routing changes DNS answers; it does not create a healthy standby application automatically. The required design is configure Route 53 failover records with meaningful health checks and pretested secondary application capacity; acceptance depends on evidence that healthy resolver lookups return the secondary record after the primary endpoint fails.

C would configure a weighted DNS record pair without health checks and expect automatic failover. This is not a defensible answer to the stated constraint (A user-facing multi-Region application needs controlled DNS failover when a regional endpoint fails health checks): failover routing changes DNS answers; it does not create a healthy standby application automatically. The required design is configure Route 53 failover records with meaningful health checks and pretested secondary application capacity; acceptance depends on evidence that healthy resolver lookups return the secondary record after the primary endpoint fails.

D would use Route 53 failover records that point at an unprovisioned secondary application. This is not a defensible answer to the stated constraint (A user-facing multi-Region application needs controlled DNS failover when a regional endpoint fails health checks): failover routing changes DNS answers; it does not create a healthy standby application automatically. The required design is configure Route 53 failover records with meaningful health checks and pretested secondary application capacity; acceptance depends on evidence that healthy resolver lookups return the secondary record after the primary endpoint fails.

A reports an inadequate or failed acceptance condition: The failover record exists, but old cached primary answers persist past the allowed recovery window. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that healthy resolver lookups return the secondary record after the primary endpoint fails. The underlying design requirement is failover routing changes DNS answers; it does not create a healthy standby application automatically.

C reports an inadequate or failed acceptance condition: Two weighted DNS records remain active even when the primary endpoint fails. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that healthy resolver lookups return the secondary record after the primary endpoint fails. The underlying design requirement is failover routing changes DNS answers; it does not create a healthy standby application automatically.

D reports an inadequate or failed acceptance condition: Route 53 returns the secondary DNS name, but its application cannot handle a request. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that healthy resolver lookups return the secondary record after the primary endpoint fails. The underlying design requirement is failover routing changes DNS answers; it does not create a healthy standby application automatically.