## TL;DR
Validate the policy document and the target separately, because attachment denied has three common homes: invalid policy content, a target that cannot take the policy, or a caller without organizations permissions. Run the document through a policy validator, confirm the target is an account or organization unit under the management account control, and confirm the identity doing the review work can read and attach policies. Fix the layer that fails a direct test, then attach and verify the effective state in the target account.

```text
AWS Organizations SCP review failed: policy attachment error access denied
```

## Use this when
- Attaching or updating an SCP returns access denied or a policy error.
- A review needs to test an SCP change and cannot apply it in a test organization unit.
- The same policy attaches in one part of the organization and fails in another.

## Not for this skill when
- The SCP attaches and then denies application actions. That is effective policy analysis, a different task.
- The failure is in a member account with no organizations role. Set up the management level access first.

## Steps
1. Copy the exact attachment error and note the policy identifier, the target identifier and the identity attempting the attach, since each maps to a different fix. Verify: error, policy, target and caller are all recorded.
2. Validate the policy document with the organizations policy validator or a dry parse, fixing any syntax, version or statement problems it reports. Verify: the document validates cleanly on its own.
3. Open the target in the Organizations console and confirm it is an active account or organization unit in this organization and not a closed account or the organization root where rules differ. Verify: the target type and state are confirmed as attachable.
4. Check the caller permissions for organizations policy actions, ideally testing a read of the policy and target with the same identity before attempting the attach again. Verify: the caller can read both the policy and the target.
5. Attach the policy to a test organization unit containing one non critical account first, and confirm the attachment appears in both the console and an API describe call. Verify: the test attachment succeeds and is visible in two views.
6. Attach to the real target, then verify from inside one affected account that the effective policies list shows the new policy in the expected position. Verify: the account view lists the policy as attached.
7. Record the test and production attachments with timestamps in the review evidence, and note any target that remains unattached with its reason. Verify: the evidence shows the final attachment state per target.
8. Keep one permanent test organization unit with a sacrificial test account for policy experiments, and require every SCP change in the review to prove itself there before it touches a production target. Verify: the test unit exists, contains only the test account, and the latest change record references it.

## Why it happens
Service control policies sit at the management account level, so the work mixes document correctness, organization structure and a separate permission set from everyday account administration. An attachment error message rarely says which layer objected. Testing each layer on its own, document validation, target state and caller read access, isolates the fault in minutes, and proving the attach in a test unit first protects the organization from a policy surprise while the review experiment runs.

## Variants and edge cases

### SCP attach access denied in Organizations
The denial phrasing. Management account context is the first check; member account credentials cannot attach SCPs.

### policy validation error on service control policy
The document phrasing. The validator names the statement problem; fix content before touching targets.

### SCP not applying to account after attach
The effect phrasing. Confirm the attach on the account effective policy list; console lag and wrong target selection both mimic non application.

Edge cases to check before closing the review cycle:
- The organization root and the management account have special rules. Test attachment behaviour in a unit, not at the root.
- Full AWS access style SCP interactions with the default policy can confuse reviews. Record the baseline policy state.
- Detaching is as sensitive as attaching. Review evidence should show the intended final state, not every experiment.

Compatibility: AWS Organizations service control policies, organizations policy validation and attachment APIs, management account access.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aEqIGA4i_swUAukEzZOVbg