## TL;DR
Compare the rule parameters with the actual account policy value by value, because the rule judges the real policy, not the intention behind it. Read the current IAM account password policy, list the Config rule required values for length, character classes, reuse and expiry, and change whichever side is wrong: tighten the account policy to the standard, or correct a rule parameter that was set stricter than the approved standard. Then trigger a re-evaluation so the review sees a fresh result instead of the stale noncompliant record.

```text
AWS Config rule noncompliant error for IAM password policy: access review failed
```

## Use this when
- The iam-password-policy Config rule reports noncompliant in one or more accounts.
- A password policy exists but one setting misses the approved standard.
- The review evidence and the Config dashboard disagree about compliance.

## Not for this skill when
- A single user is locked out or cannot set a password. That is a user level problem, not the account policy rule.
- No password policy exists at all and none is required. Record the exception through governance instead of silently editing the rule.

## Steps
1. Open the Config rule in the flagged account and copy its parameter values exactly as configured, including required length and each character requirement flag. Verify: the rule parameters are recorded without paraphrase.
2. Read the current account password policy through the IAM console or CLI and list the same fields in the same order for a direct comparison. Verify: both lists sit side by side and the differing field is obvious.
3. Check the approved password standard for the organization and decide whether the account policy or the rule parameter is the one that deviates from it. Verify: the deviating side is named with the standard as the reference.
4. Apply the correction on that side only, tightening the account policy or fixing the rule parameter through the normal change process with the ticket reference attached. Verify: the change is saved and shows in the configuration history.
5. Trigger a re-evaluation of the rule from the Config console or CLI rather than waiting for the periodic run, and note the evaluation start time. Verify: a new evaluation runs after the change time.
6. Confirm the resource compliance flips to compliant, or read the new annotation to see which field still fails if it does not, and repeat the comparison for that field only. Verify: the rule reports compliant or names one remaining field.
7. Attach the before and after policy values and the compliant evaluation to the access review evidence for the account. Verify: the evidence pack contains both states and the final compliant result.

## Why it happens
The Config rule and the account policy are maintained by different hands, often a security baseline team for the rule and account administrators for the policy. A baseline update that raises required length, or an account built before the standard changed, leaves the two quietly out of step until a review reads the rule result. Neither side is broken; they simply disagree. The disciplined fix is a field by field comparison against the approved standard, changing only the side that deviates so the rule keeps its meaning for the next account.

## Variants and edge cases

### iam-password-policy rule noncompliant but policy exists
The puzzled phrasing. Existence is not compliance; one short field, often reuse count or expiry, is enough to fail the rule.

### AWS Config password policy evaluation failed in audit
The audit phrasing. Auditors read the rule result, so a fresh compliant evaluation after the fix is the evidence that matters.

### password policy compliance differs between accounts
The fleet phrasing. Compare parameters account by account; baselines deployed by different stacks often differ in one field.

Edge cases to check before closing the review cycle:
- Password policy changes do not force existing passwords to change. Note that user passwords created under the old policy remain until reset.
- Accounts managed through a baseline stack will overwrite manual fixes. Change the baseline source, not only the account.
- Config aggregator views lag account level results. Confirm compliance in the account itself before reporting closure.

Compatibility: AWS Config managed rule for IAM password policy, IAM account password policy settings, AWS Organizations baseline deployments.

## Provenance

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