Regional Secret Manager IAM condition fails on resource.name — Policy Troubleshooter

Hello Google Cloud Community,

We are implementing a least-privilege disaster recovery workflow in Google Cloud, using regional Secret Manager in europe-west1, IAM Conditions, Cloud SQL and Cloud Storage.

We have two issues that we cannot resolve using the official documentation.

Issue 1 — Regional Secret Manager IAM Condition

We have a regional secret version with the following structure:

projects/PROJECT_NUMBER/locations/europe-west1/secrets/SECRET_ID/versions/1

A dedicated service account has a custom role containing only secretmanager.versions.access, restricted by this IAM Condition:

request.time < timestamp("2026-11-14T13:44:46Z") &&
resource.type == "secretmanager.googleapis.com/SecretVersion" &&
resource.name == "projects/PROJECT_NUMBER/locations/europe-west1/secrets/SECRET_ID/versions/1"

Policy Troubleshooter returns:

• Principal membership: MATCHED

• Required permission: INCLUDED

• Time condition: TRUE

• Resource type: TRUE

• Resource name equality: FALSE

• Overall access: CANNOT_ACCESS

• Deny policy: NOT_DENIED

We have tested six different resource-name representations using the v3 and v3beta Troubleshooter APIs, without success.

Our questions:

1. What exact resource.name does IAM Conditions evaluate for secretmanager.versions.access on a regional secret version?

2. How can we grant access exclusively to version 1 of a specific regional secret, without granting access to other versions or regions?

3. Is there a documented limitation in Policy Troubleshooter when evaluating regional Secret Manager versions?

Issue 2 — Cloud Storage object permissions

Policy Troubleshooter returns HTTP 400 INVALID_RESOURCE_NAME when evaluating storage.objects.get for an existing GCS object using:

//storage.googleapis.com/projects/_/buckets/BUCKET/objects/PREFIX/OBJECT

We also tested URL-encoded object paths.

Is direct object-level evaluation supported by Policy Troubleshooter?

If not, is a metadata-only objects.get request executed under a Workflows service account, with a positive object inside the authorized prefix and a negative object outside it, a supported way to verify the effective IAM restriction?

We want to preserve strict least-privilege access. We do not want to grant broad Secret Manager permissions, access all secret versions, or use Owner/Editor roles as a workaround.

Thank you for your help. Official documentation or examples of the correct IAM Condition would be greatly appreciated.