Check for blocking SCPs and IAM permission boundaries, fix them in CodeCommit, and deploy through CloudFormation

Why the Answer Is Correct

The symptom is that some developers in some accounts cannot access the S3 bucket, and there are two independent mechanisms in this organization that can produce exactly that denial. The first is an SCP attached to a specific OU or account, which caps permissions for every principal beneath it regardless of what identity-based policies allow; if such an SCP were attached broadly it would affect everyone under it, but one attached to a narrower OU can affect only a subset of accounts, matching the reported pattern. The second is an IAM permissions boundary attached to the developers, which also caps what they can do. The correct response therefore is to ensure neither an SCP nor a permissions boundary is blocking access, make the necessary changes in the CodeCommit repository, and invoke deployment through CloudFormation so that the fix is applied through the same infrastructure-as-code path as every other change in the organization (D). Only this option covers both denial layers while honoring the stated IaC requirement. D is the correct answer.

Why the Other Options Are Wrong

A modifies the S3 bucket policy, turns off S3 Block Public Access, adds an aws:SourceAccount condition, and adds the account IDs of the affected developers. Turning off Block Public Access weakens the bucket's public-access protection rather than fixing an authorization denial, and listing account IDs in a bucket policy condition does not restore permissions that an SCP or a permissions boundary has removed, since those caps apply regardless of any allow. B verifies that no IAM permissions boundaries are denying access, makes changes to boundaries, and then uses an AWS Config recorder in the affected developer accounts to revert blocking changes before committing the fix and deploying through CloudFormation. teo2157 pointed out two defects: if an SCP were responsible it would affect all developers under it rather than only some, and this option does not check SCPs at all; additionally teo2157 noted that a Config recorder would let the team trace what changed. Introducing a recorder-driven revert also creates a second, out-of-band change mechanism in a company that requires all changes through CloudFormation. C configures an SCP preventing anyone from modifying IAM resources in the developer OUs and adds an aws:SourceAccount condition with the affected account IDs. An SCP applies to every principal in the accounts it is attached to, so it cannot selectively target only the affected accounts, and preventing modification of IAM resources does not address an S3 access denial. D is correct.

Community Comment Notes

Community voted D (93). trungtd described D as the most comprehensive option, noting that it ensures both SCPs and IAM policies are correctly configured and that it adheres to the requirement to use CloudFormation for all changes. jamesf highlighted that D reviews both SCPs and IAM permission boundaries and keeps changes committed to CodeCommit and deployed through CloudFormation, preserving the required model. teo2157 was the sole dissenter, preferring B on the reasoning that an SCP would affect all developers rather than some and that a Config recorder would allow tracing of IAM policy changes; the first point is a valid argument about the symptom pattern but does not excuse B's omission of SCPs or its out-of-band revert mechanism.