A reports an inadequate or failed acceptance condition: The destination S3 copy remains in the same Region as the source. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that versioned objects replicate to the destination Region and can be read during source outage. The underlying design requirement is s3 CRR places copies in another Region; versioning supports distinct recovered object versions.

B reports an inadequate or failed acceptance condition: Current object keys exist in another Region but historical versions cannot be recovered. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that versioned objects replicate to the destination Region and can be read during source outage. The underlying design requirement is s3 CRR places copies in another Region; versioning supports distinct recovered object versions.

C reports an inadequate or failed acceptance condition: Encrypted source versions remain unreplicated due to destination key-policy errors. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that versioned objects replicate to the destination Region and can be read during source outage. The underlying design requirement is s3 CRR places copies in another Region; versioning supports distinct recovered object versions.

B would use direct synchronous invocation of workers with no persistent queue or retry path. This is not a defensible answer to the stated constraint (A stateful message-processing tier loses work when instances are replaced during a rolling update): durable queues and idempotency separate compute lifetime from business transaction persistence. The required design is move durable work items into SQS and implement idempotent consumers with retry/dead-letter handling; acceptance depends on evidence that worker termination does not erase queued messages and retries avoid double side effects.

C would retry every failed job blindly without idempotency or dead-letter handling. This is not a defensible answer to the stated constraint (A stateful message-processing tier loses work when instances are replaced during a rolling update): durable queues and idempotency separate compute lifetime from business transaction persistence. The required design is move durable work items into SQS and implement idempotent consumers with retry/dead-letter handling; acceptance depends on evidence that worker termination does not erase queued messages and retries avoid double side effects.

D would keep durable messages solely in EC2 memory during rolling instance replacement. This is not a defensible answer to the stated constraint (A stateful message-processing tier loses work when instances are replaced during a rolling update): durable queues and idempotency separate compute lifetime from business transaction persistence. The required design is move durable work items into SQS and implement idempotent consumers with retry/dead-letter handling; acceptance depends on evidence that worker termination does not erase queued messages and retries avoid double side effects.

A reports an inadequate or failed acceptance condition: The API acknowledgement succeeded, but no durable queue record remains after backend failure. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that worker termination does not erase queued messages and retries avoid double side effects. The underlying design requirement is durable queues and idempotency separate compute lifetime from business transaction persistence.

C reports an inadequate or failed acceptance condition: Retrying the same message creates two downstream payments rather than one idempotent effect. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that worker termination does not erase queued messages and retries avoid double side effects. The underlying design requirement is durable queues and idempotency separate compute lifetime from business transaction persistence.

D reports an inadequate or failed acceptance condition: A worker restart empties all pending in-memory jobs from the original node. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that worker termination does not erase queued messages and retries avoid double side effects. The underlying design requirement is durable queues and idempotency separate compute lifetime from business transaction persistence.

A would use multi-AZ Auto Scaling but allocate all remaining capacity to a constrained instance family. This is not a defensible answer to the stated constraint (A batch fleet must scale quickly during an AZ disruption without exceeding EC2 service quotas): regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG. The required design is prevalidate quotas, spread capacity across AZs, and use mixed instance families in Auto Scaling policies; acceptance depends on evidence that a failure drill launches replacement capacity within the quota and target instance diversity.

B would scale only with one specific EC2 instance type in the already impaired AZ. This is not a defensible answer to the stated constraint (A batch fleet must scale quickly during an AZ disruption without exceeding EC2 service quotas): regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG. The required design is prevalidate quotas, spread capacity across AZs, and use mixed instance families in Auto Scaling policies; acceptance depends on evidence that a failure drill launches replacement capacity within the quota and target instance diversity.

D would ignore service quotas and assume Auto Scaling can launch every requested replacement instance. This is not a defensible answer to the stated constraint (A batch fleet must scale quickly during an AZ disruption without exceeding EC2 service quotas): regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG. The required design is prevalidate quotas, spread capacity across AZs, and use mixed instance families in Auto Scaling policies; acceptance depends on evidence that a failure drill launches replacement capacity within the quota and target instance diversity.

A reports an inadequate or failed acceptance condition: Current hosts report healthy before the failing zone is isolated, with no alternative capacity. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a failure drill launches replacement capacity within the quota and target instance diversity. The underlying design requirement is regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG.

B reports an inadequate or failed acceptance condition: A desired Auto Scaling group size is set, but launch requests hit an EC2 quota limit. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a failure drill launches replacement capacity within the quota and target instance diversity. The underlying design requirement is regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG.

C reports an inadequate or failed acceptance condition: A replacement fleet comes from one instance family that has insufficient capacity in the healthy AZ. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that a failure drill launches replacement capacity within the quota and target instance diversity. The underlying design requirement is regional quotas and single-family capacity limits can defeat an otherwise well-designed ASG.

B would put all business units in one account and rely solely on tags as access isolation. This is not a defensible answer to the stated constraint (A global company needs separate finance, experimentation and security billing and access boundaries): account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot. The required design is create purpose-specific AWS accounts in Organizations OUs with policies aligned to each OU; acceptance depends on evidence that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles.

C would share organization management-account administrator roles directly with every business unit. This is not a defensible answer to the stated constraint (A global company needs separate finance, experimentation and security billing and access boundaries): account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot. The required design is create purpose-specific AWS accounts in Organizations OUs with policies aligned to each OU; acceptance depends on evidence that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles.

D would create account names but place every team under the same unrestricted IAM and SCP permissions. This is not a defensible answer to the stated constraint (A global company needs separate finance, experimentation and security billing and access boundaries): account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot. The required design is create purpose-specific AWS accounts in Organizations OUs with policies aligned to each OU; acceptance depends on evidence that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles.

A reports an inadequate or failed acceptance condition: All departments have separate tags but the same account's broad roles permit cross-team reads. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles. The underlying design requirement is account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot.

C reports an inadequate or failed acceptance condition: An organization exists, but its management administrators own every sandbox workload directly. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles. The underlying design requirement is account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot.

D reports an inadequate or failed acceptance condition: All unit accounts inherit identical unrestricted policies despite the regulated boundary needs. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that finance and sandbox principals cannot cross account boundaries without explicitly assumed roles. The underlying design requirement is account separation supplies hard administrative/billing boundaries that VPC-only partitioning cannot.

A would use Service Catalog products without enrolling the account in its governed OU and controls. This is not a defensible answer to the stated constraint (A new regulated account must receive required detective guardrails before engineers deploy workloads): control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines. The required design is enroll it through Control Tower Account Factory with baseline controls and governed OU placement; acceptance depends on evidence that the new account has the expected mandatory baselines and controls upon provisioning.

B would rely only on a checklist email instead of provisioning detective controls with the new account. This is not a defensible answer to the stated constraint (A new regulated account must receive required detective guardrails before engineers deploy workloads): control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines. The required design is enroll it through Control Tower Account Factory with baseline controls and governed OU placement; acceptance depends on evidence that the new account has the expected mandatory baselines and controls upon provisioning.

D would create an AWS account manually and defer mandatory controls until after workloads are deployed. This is not a defensible answer to the stated constraint (A new regulated account must receive required detective guardrails before engineers deploy workloads): control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines. The required design is enroll it through Control Tower Account Factory with baseline controls and governed OU placement; acceptance depends on evidence that the new account has the expected mandatory baselines and controls upon provisioning.

A reports an inadequate or failed acceptance condition: The new account is in the right OU but missing Control Tower detective controls. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that the new account has the expected mandatory baselines and controls upon provisioning. The underlying design requirement is control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines.

B reports an inadequate or failed acceptance condition: An owner acknowledgment is filed, while the provisioned account has no guardrail configuration. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that the new account has the expected mandatory baselines and controls upon provisioning. The underlying design requirement is control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines.

C reports an inadequate or failed acceptance condition: The manually created account can deploy before the required compliance baseline runs. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that the new account has the expected mandatory baselines and controls upon provisioning. The underlying design requirement is control Tower orchestrates governed landing zones and account lifecycle; SCPs alone are not full account baselines.

B would place trail files in a shared bucket with unrestricted delete permissions for workload roles. This is not a defensible answer to the stated constraint (Audit teams need copies of all member-account CloudTrail logs independent of application administrators): a separate log-archive account reduces the ability of workload administrators to tamper with evidence. The required design is centralize organization trail delivery into a restricted log-archive account and enforce bucket policies; acceptance depends on evidence that only the logging service and approved auditors can write or read protected trail objects.

C would deliver the organization trail to an application account whose admins can alter stored logs. This is not a defensible answer to the stated constraint (Audit teams need copies of all member-account CloudTrail logs independent of application administrators): a separate log-archive account reduces the ability of workload administrators to tamper with evidence. The required design is centralize organization trail delivery into a restricted log-archive account and enforce bucket policies; acceptance depends on evidence that only the logging service and approved auditors can write or read protected trail objects.

D would enable member-account trails but give auditors no independent central log storage. This is not a defensible answer to the stated constraint (Audit teams need copies of all member-account CloudTrail logs independent of application administrators): a separate log-archive account reduces the ability of workload administrators to tamper with evidence. The required design is centralize organization trail delivery into a restricted log-archive account and enforce bucket policies; acceptance depends on evidence that only the logging service and approved auditors can write or read protected trail objects.

A reports an inadequate or failed acceptance condition: Every team role can delete log objects in the central bucket despite the independence requirement. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that only the logging service and approved auditors can write or read protected trail objects. The underlying design requirement is a separate log-archive account reduces the ability of workload administrators to tamper with evidence.

C reports an inadequate or failed acceptance condition: An application admin successfully removes a CloudTrail object from the supposed audit archive. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that only the logging service and approved auditors can write or read protected trail objects. The underlying design requirement is a separate log-archive account reduces the ability of workload administrators to tamper with evidence.

D reports an inadequate or failed acceptance condition: Member-account trails send files to a local workload bucket that the auditor cannot independently read. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that only the logging service and approved auditors can write or read protected trail objects. The underlying design requirement is a separate log-archive account reduces the ability of workload administrators to tamper with evidence.