Symptom: "does not have storage.objects.get access to the Google Cloud Storage object" (or .create, .delete, .list variants).
Cause: the caller's IAM lacks that permission on the bucket or object. The error names the permission; believe it.
Confirm:
1. `gcloud storage buckets get-iam-policy gs://[BUCKET]` - is your identity (user or SA) in a binding with a role containing that permission?
2. Check WHICH identity is calling: `gcloud auth list` for CLI, or the ADC identity for scripts. Agents often check their user's IAM while the script runs as a different SA.
3. Uniform bucket-level access: if enabled, object ACLs are ignored. Grants must be IAM on the bucket. `gcloud storage buckets describe` shows the access control mode.
Fix: grant the least-privilege role with that permission:
- Read objects: roles/storage.objectViewer
- Write objects: roles/storage.objectCreator (create only) or objectAdmin
- List buckets: roles/storage.inspector or viewer on the project
```
gcloud storage buckets add-iam-policy-binding gs://[BUCKET] --member serviceAccount:[SA] --role roles/storage.objectViewer
```
Do not grant storage.admin to "make it work". And do not make the bucket public to dodge an IAM error on an internal workload.
Propagation: IAM changes can take a minute or two. If it still fails immediately after the grant, wait and retry before escalating.
Verify: rerun the exact failing command as the exact failing identity.