Understanding AWS pre-deployment check results

Result Statuses

Each result line starts with a category tag and ends with a status:

PASS: no action required.
WARN: the check could not fully verify a condition, or found something worth reviewing. Read the message and proceed with caution.
FAIL: a problem that would likely cause the deployment to fail. Fix the issue, then re-run the check.

Result Categories

Use the following table to identify what each category checks and what to do if it reports WARN or FAIL.

Category	What it checks	If `WARN` or `FAIL` — what to do
`ENV`	Required tools, valid AWS credentials, and matching AWS partition.	Install or upgrade the missing tool (such as AWS CLI v2 or `jq`), or sign in again. A partition mismatch means you are signed in to the wrong AWS environment, so you must sign in to the correct account. AWS CloudShell avoids most `ENV` issues. A credential failure stops all later checks.
`PERM`	Whether your credentials have the permissions required by the deployment. The check does not perform any actions: this is a simulation only.	Grant the missing permission to the deploying user or role, or deploy with a role that already has it, then re-run. If you are signed in as a federated user, AWS cannot simulate permissions: this check is skipped with a `WARN`. Verify your permissions manually.
`SCP`	Whether your AWS Organization Service Control Policy blocks a required action above your account.	You typically cannot fix this yourself. Ask your AWS Organization administrator to allow the action, then re-run.
`FEASIBILITY`	Whether the account is ready for deployment. For example, a conflicting OIDC provider or an existing CloudFormation stack.	See the OIDC provider and CloudFormation stack guidance below.

OIDC provider conflict

An OIDC identity provider with the same URL already exists in the account. This usually means a Cloud Account Management stack exists from a previous deployment in this account.

Updating an account that is already connected: This is expected. Proceed.
Expected a brand-new setup: The account was previously onboarded. Check whether a stack still exists.
- If a Cloud Account Management stack exists, it owns the provider. Update it, or delete it for a clean start.
- If no stack exists but the provider does, the provider may be a leftover from a previously deleted stack. Delete the provider before deploying.

Existing CloudFormation stack

A stack with the deployment's name already exists in the account. What to do depends on its status.

Stack status	What to do
`CREATE_COMPLETE` or `UPDATE_COMPLETE`	Re-deploying updates the stack in place. To start fresh, delete the stack first.
Any `..._IN_PROGRESS` status	An operation is still running. Wait for it to complete, then re-run the pre-deployment check.
`ROLLBACK_COMPLETE` or any `*_FAILED` status	The stack cannot be updated. Delete it before deploying.

Tips and Troubleshooting

Run the check using the same credentials you will use for the deployment. The check inspects the permissions of the currently signed-in credentials.
A FAIL result means the check caught a problem before it affected the deployment. Fix the reported issue and re-run: the check does not change your AWS environment.
If you change your feature selection, re-download the deployment package and re-run the check so it reflects your new configuration.
If the deployment fails after the pre-deployment check passes, the issue is a runtime error the check cannot detect. Review the deployment events or logs in the AWS Management Console for details.
Running the pre-deployment check is not required, but it reduces the chance of a failed deployment.