A reports an inadequate or failed acceptance condition: The internal load balancer has a healthy target group but is not reachable by internet clients. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that aAAA/DNS resolution and IPv6 client requests succeed without direct public exposure of the backends. The underlying design requirement is dual-stack client entry does not imply every backend instance must have public IPv6 addressing.

B reports an inadequate or failed acceptance condition: Backend private IPs become publicly reachable, contrary to the exposure constraint. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that aAAA/DNS resolution and IPv6 client requests succeed without direct public exposure of the backends. The underlying design requirement is dual-stack client entry does not imply every backend instance must have public IPv6 addressing.

C reports an inadequate or failed acceptance condition: Public DNS publishes an IPv4-only backend address for an IPv6-only client. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that aAAA/DNS resolution and IPv6 client requests succeed without direct public exposure of the backends. The underlying design requirement is dual-stack client entry does not imply every backend instance must have public IPv6 addressing.

B would configure VPC peering but expect it to filter BGP announcements already propagated by the Transit Gateway. This is not a defensible answer to the stated constraint (A BGP-connected network must restrict route propagation between audit and production VPC groups on one Transit Gateway): tGW route-table association and propagation provide segment-specific routing boundaries. The required design is associate attachments with segregated TGW route tables and enable only deliberate propagation or static routes; acceptance depends on evidence that audit attachments cannot learn production-only prefixes while shared services remain reachable.

C would allow all Transit Gateway attachments to propagate routes into the same default table. This is not a defensible answer to the stated constraint (A BGP-connected network must restrict route propagation between audit and production VPC groups on one Transit Gateway): tGW route-table association and propagation provide segment-specific routing boundaries. The required design is associate attachments with segregated TGW route tables and enable only deliberate propagation or static routes; acceptance depends on evidence that audit attachments cannot learn production-only prefixes while shared services remain reachable.

D would use only security group names as route-propagation controls between isolated TGW attachments. This is not a defensible answer to the stated constraint (A BGP-connected network must restrict route propagation between audit and production VPC groups on one Transit Gateway): tGW route-table association and propagation provide segment-specific routing boundaries. The required design is associate attachments with segregated TGW route tables and enable only deliberate propagation or static routes; acceptance depends on evidence that audit attachments cannot learn production-only prefixes while shared services remain reachable.

A reports an inadequate or failed acceptance condition: A VPC peering connection is Active, but restricted TGW BGP routes remain visible. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that audit attachments cannot learn production-only prefixes while shared services remain reachable. The underlying design requirement is tGW route-table association and propagation provide segment-specific routing boundaries.

C reports an inadequate or failed acceptance condition: Audit and production prefixes are both propagated into the same default TGW route table. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that audit attachments cannot learn production-only prefixes while shared services remain reachable. The underlying design requirement is tGW route-table association and propagation provide segment-specific routing boundaries.

D reports an inadequate or failed acceptance condition: Security groups deny selected traffic, although audit VPCs still learn production-only prefixes. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that audit attachments cannot learn production-only prefixes while shared services remain reachable. The underlying design requirement is tGW route-table association and propagation provide segment-specific routing boundaries.

A would create a single shared IAM user in every AWS account and distribute long-term access keys. This is not a defensible answer to the stated constraint (Developers across 40 AWS accounts sign in through a corporate SAML identity provider): iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users. The required design is integrate the IdP with IAM Identity Center and assign permission sets to account groups; acceptance depends on evidence that idP users assume provisioned roles in only their assigned AWS accounts.

B would configure SAML only for the management account without account-assignment permission sets. This is not a defensible answer to the stated constraint (Developers across 40 AWS accounts sign in through a corporate SAML identity provider): iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users. The required design is integrate the IdP with IAM Identity Center and assign permission sets to account groups; acceptance depends on evidence that idP users assume provisioned roles in only their assigned AWS accounts.

D would assign every federated user the same AdministratorAccess permission set in all 40 accounts. This is not a defensible answer to the stated constraint (Developers across 40 AWS accounts sign in through a corporate SAML identity provider): iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users. The required design is integrate the IdP with IAM Identity Center and assign permission sets to account groups; acceptance depends on evidence that idP users assume provisioned roles in only their assigned AWS accounts.

A reports an inadequate or failed acceptance condition: IAM users successfully sign in with long-term keys in each account. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that idP users assume provisioned roles in only their assigned AWS accounts. The underlying design requirement is iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users.

B reports an inadequate or failed acceptance condition: Corporate SAML login succeeds only for the management account. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that idP users assume provisioned roles in only their assigned AWS accounts. The underlying design requirement is iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users.

C reports an inadequate or failed acceptance condition: Federated users see AdministratorAccess in accounts outside their assigned groups. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that idP users assume provisioned roles in only their assigned AWS accounts. The underlying design requirement is iAM Identity Center manages workforce federation and multi-account access without permanent per-account IAM users.

B would trust the whole external account and grant unrestricted S3 access to every bucket. This is not a defensible answer to the stated constraint (A workload in account A needs read-only access to selected objects in account B without static access keys): temporary STS credentials plus trust and permission policies bound cross-account access. The required design is configure a scoped cross-account IAM role trust policy and assume it using STS; acceptance depends on evidence that cloudTrail shows role assumption and access only to allowed bucket actions and resources.

C would grant an identity policy in account A only, without a destination account role trust policy. This is not a defensible answer to the stated constraint (A workload in account A needs read-only access to selected objects in account B without static access keys): temporary STS credentials plus trust and permission policies bound cross-account access. The required design is configure a scoped cross-account IAM role trust policy and assume it using STS; acceptance depends on evidence that cloudTrail shows role assumption and access only to allowed bucket actions and resources.

D would store account B IAM user access keys in the application configuration in account A. This is not a defensible answer to the stated constraint (A workload in account A needs read-only access to selected objects in account B without static access keys): temporary STS credentials plus trust and permission policies bound cross-account access. The required design is configure a scoped cross-account IAM role trust policy and assume it using STS; acceptance depends on evidence that cloudTrail shows role assumption and access only to allowed bucket actions and resources.

A reports an inadequate or failed acceptance condition: An external principal can list and read S3 buckets beyond the selected object scope. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cloudTrail shows role assumption and access only to allowed bucket actions and resources. The underlying design requirement is temporary STS credentials plus trust and permission policies bound cross-account access.

C reports an inadequate or failed acceptance condition: The account A identity policy exists, but the role in B cannot be assumed. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cloudTrail shows role assumption and access only to allowed bucket actions and resources. The underlying design requirement is temporary STS credentials plus trust and permission policies bound cross-account access.

D reports an inadequate or failed acceptance condition: An embedded access key reads the cross-account bucket without role assumption. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that cloudTrail shows role assumption and access only to allowed bucket actions and resources. The underlying design requirement is temporary STS credentials plus trust and permission policies bound cross-account access.

A would create an SCP Allow statement alone and assume it overrides explicit IAM permission grants elsewhere. This is not a defensible answer to the stated constraint (Security wants a maximum privilege boundary across member accounts even when local administrators have broad IAM policies): sCPs limit account principals' effective permission ceiling but do not grant permissions themselves. The required design is attach explicit AWS Organizations SCP guardrails to the appropriate OU; acceptance depends on evidence that an administrator role cannot perform an SCP-denied action while other authorized actions succeed.

B would attach an IAM permissions boundary only to selected developer roles, leaving other administrators unrestricted. This is not a defensible answer to the stated constraint (Security wants a maximum privilege boundary across member accounts even when local administrators have broad IAM policies): sCPs limit account principals' effective permission ceiling but do not grant permissions themselves. The required design is attach explicit AWS Organizations SCP guardrails to the appropriate OU; acceptance depends on evidence that an administrator role cannot perform an SCP-denied action while other authorized actions succeed.

D would use a resource tag that asks administrators not to perform prohibited operations. This is not a defensible answer to the stated constraint (Security wants a maximum privilege boundary across member accounts even when local administrators have broad IAM policies): sCPs limit account principals' effective permission ceiling but do not grant permissions themselves. The required design is attach explicit AWS Organizations SCP guardrails to the appropriate OU; acceptance depends on evidence that an administrator role cannot perform an SCP-denied action while other authorized actions succeed.

A reports an inadequate or failed acceptance condition: An SCP Allow is present, yet an unapproved action remains authorized through IAM. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that an administrator role cannot perform an SCP-denied action while other authorized actions succeed. The underlying design requirement is sCPs limit account principals' effective permission ceiling but do not grant permissions themselves.

B reports an inadequate or failed acceptance condition: One developer permissions boundary denies an operation while a different admin can still perform it. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that an administrator role cannot perform an SCP-denied action while other authorized actions succeed. The underlying design requirement is sCPs limit account principals' effective permission ceiling but do not grant permissions themselves.

C reports an inadequate or failed acceptance condition: An informational tag flags a forbidden action but the API still succeeds. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that an administrator role cannot perform an SCP-denied action while other authorized actions succeed. The underlying design requirement is sCPs limit account principals' effective permission ceiling but do not grant permissions themselves.

B would enable one CloudTrail trail in the management account without organization-trail coverage. This is not a defensible answer to the stated constraint (Compliance requires recording API activity throughout all current and future AWS accounts): an organization trail extends coverage across member accounts; individual standalone trails risk gaps. The required design is enable an organization CloudTrail trail that records the required management and selected data events centrally; acceptance depends on evidence that events from a newly added member account appear in the secured central log destination.

C would record management events only when the audit also explicitly requires selected object-level data events. This is not a defensible answer to the stated constraint (Compliance requires recording API activity throughout all current and future AWS accounts): an organization trail extends coverage across member accounts; individual standalone trails risk gaps. The required design is enable an organization CloudTrail trail that records the required management and selected data events centrally; acceptance depends on evidence that events from a newly added member account appear in the secured central log destination.

D would deliver log files into a member workload account whose administrators can delete them. This is not a defensible answer to the stated constraint (Compliance requires recording API activity throughout all current and future AWS accounts): an organization trail extends coverage across member accounts; individual standalone trails risk gaps. The required design is enable an organization CloudTrail trail that records the required management and selected data events centrally; acceptance depends on evidence that events from a newly added member account appear in the secured central log destination.

A reports an inadequate or failed acceptance condition: A management-account trail records events but a new member account produces no central records. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that events from a newly added member account appear in the secured central log destination. The underlying design requirement is an organization trail extends coverage across member accounts; individual standalone trails risk gaps.

C reports an inadequate or failed acceptance condition: Management events arrive, but a required S3 object-level event is absent. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that events from a newly added member account appear in the secured central log destination. The underlying design requirement is an organization trail extends coverage across member accounts; individual standalone trails risk gaps.

D reports an inadequate or failed acceptance condition: Logs land in a workload bucket and that account's administrator deletes a test object. This result does not establish the specified outcome for the current architecture. The decisive test must demonstrate that events from a newly added member account appear in the secured central log destination. The underlying design requirement is an organization trail extends coverage across member accounts; individual standalone trails risk gaps.