# Diagnose a platform policy failure at its effective scope

A workload can inherit several layers of control. Identify which rule applies to the actual identity and resource before changing permissions.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Capture the failed operation

Record the action, caller identity, target resource, environment and time. Keep the original error and request identifier where the provider supplies one.

Confirm whether the failure occurs during deployment or runtime. The pipeline identity and application identity may have different permissions and policy paths.

Avoid starting with a broad permission grant. It can hide the cause while leaving unnecessary authority behind.

## Inspect inherited controls

Trace the account or subscription's placement and the policies inherited from higher scopes. Compare with a working environment only after checking that its placement and purpose are equivalent.

A recent organisational move can change effective controls without changing application code. Include platform changes in the incident timeline.

For AWS service control policies, remember that they define a permissions boundary for affected identities rather than granting permissions. Diagnose identity policies and other relevant controls as well as the organisational restriction.

## Choose the narrow correction

If the workload is attempting a prohibited action, point the team to the supported alternative. If the baseline unintentionally blocks a legitimate capability, use a reviewed change or scoped exception.

Record the reason and affected environments. A one-off console edit without reconciliation into the platform definition can disappear during the next deployment or become unexplained drift.

Test the correction in a representative non-production scope where practical, then verify the actual workload operation.

## Close the temporary path

Remove diagnostic grants and confirm that the pipeline and runtime identities retain only their intended authority. Review any partially created resources from failed deployments.

Update the error guidance or baseline test that would have made the issue easier to understand. Repeated access-denied incidents often indicate a missing supported workflow, not merely a need for more permissions.

Keep the final effective scope in the incident record. The next engineer should be able to see which inherited rule caused the failure and why the chosen correction was appropriate.

## Sources

- [AWS: service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)