## TL;DR
Fix the import first and do not rewrite the audit logic, because the audit never reached the IAM API. Match the language to the current Google Cloud client library name, remove any old google-cloud or resourcemanager package mix, reinstall into a clean environment, and run a one-project policy read before the full audit. A script that can read one project policy can be trusted to scale; one that cannot import will fail identically on every project.

```text
google cloud iam import error correct package name: IAM policy audit failed
```

## Use this when
- A Python or Go IAM audit job fails at startup with an import or module error.
- The audit worked on one machine and fails in CI with a different library layout.
- Policy collection never starts, so the review has no GCP evidence.

## Not for this skill when
- The script runs but calls return permission denied. That is an IAM grant problem, not a packaging problem.
- You are designing a new audit. Start from the current client library samples instead.

## Steps
1. Capture the full startup error including the module or package name it names, the language runtime version and the exact command the job runs. Verify: the failing import string is copied verbatim into the ticket.
2. Compare that name with the current library for the language in use, for Python the google-cloud-resourcemanager and google-cloud-iam distributions and their google.cloud import paths, and note any legacy name still present. Verify: the wrong or legacy package name is identified against the current documented name.
3. Create a clean virtual environment or container for the audit job, install only the current client libraries plus the audit dependencies, and freeze the resulting versions into the requirements file. Verify: the clean environment installs with no conflicting legacy Google packages.
4. Update the import statements to the current paths, run the interpreter import check on its own, and confirm it exits cleanly before any audit code runs. Verify: the import check passes with no error output.
5. Point the script at one test project, read its IAM policy through the resource manager client, and print the binding count as a smoke test. Verify: a real policy comes back with bindings listed for the test project.
6. Run the full audit across the folder or organization, watch for per-project errors separated from startup errors, and save the output with the library versions attached. Verify: the audit completes and every project shows either bindings or a named per-project error.
7. Pin the working versions in CI and add the import smoke test as the first job step so a future library rename fails loudly at setup, not silently at audit time. Verify: the CI job shows the smoke test step passing before collection starts.

## Why it happens
Google Cloud client libraries have been renamed and split several times, and old examples still circulate with retired package names. An audit script copied from an older snippet imports a module that no longer exists in a fresh environment, while a long-lived workstation may still have the legacy package installed, which is why the same script passes locally and fails in CI. Installing the current distributions into a clean environment and testing the import in isolation separates packaging faults from IAM faults completely.

## Variants and edge cases

### google cloud iam ModuleNotFoundError in audit script
The Python phrasing of the same fault. Match the distribution name to the import path; they are related but not identical strings.

### IAM policy audit fails in CI but works locally
Environment drift phrasing. Diff the installed package lists between the two environments before touching audit logic.

### old google api client import breaks policy collection
Legacy client phrasing. Migrate the read calls to the current resource manager client rather than resurrecting the retired library.

Edge cases to check before closing the review cycle:
- Mixed legacy and current Google packages can import successfully and fail later at call time. A clean environment is the reliable test.
- Generated policy exports fail for a different reason, usually output size. Keep startup errors and export errors in separate buckets.
- Service account impersonation changes which project policies are readable. Smoke test with the same identity the job uses.

Compatibility: Google Cloud IAM and Resource Manager client libraries for Python and Go, current google-cloud distributions, organization and folder level policy audits.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dkmOnlEbbDGr4If8-gHoAg