Google ACE Practice Question: Grant a third-party monitoring vendor's service…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Set a session duration limit in the vendor's service account settings.

  Why it's wrong here

  Session duration limits in a service account's settings control how long a delegated OAuth token remains valid, forcing re-authentication after the configured period, but they do not expire the IAM role binding itself. After the session limit elapses, the service account can generate a new token and continue to exercise the role, so the binding retains access indefinitely. Only an IAM Condition on the binding can enforce a hard expiration at the authorization layer.

• ✓

  Add an IAM Condition with a date/time expression that expires the binding after 90 days.

  Why this is correct

  Attaching an IAM Condition with a date/time expression such as `request.time < timestamp('2025-08-01T00:00:00Z')` to the role binding makes the permission valid only until that timestamp. When a service account attempts to access a resource after the expiry, Cloud IAM evaluates the condition and returns `PERMISSION_DENIED` because the condition is false. This enforces the 90-day limit automatically at authorization time, without manual steps or separate cleanup jobs.

• ✗

  Grant the role and set a reminder to manually revoke it in 90 days.

  Why it's wrong here

  Granting the role and relying on a calendar reminder to revoke it after 90 days depends on a human executing the cleanup promptly; a missed or delayed action leaves the binding active and grants unintended access. Cloud IAM provides no built-in reminder system, so this approach is not enforceable. A policy-enforced IAM Condition evaluates request.time at every access attempt and denies access automatically once the expiration timestamp passes, eliminating the need for manual revocation.

• ✗

  Use a temporary service account that is automatically deleted after 90 days via a Cloud Scheduler job.

  Why it's wrong here

  Creating a temporary service account with a Cloud Scheduler deletion job does not enforce a 90-day expiry on the IAM role binding itself; the account could be deleted prematurely or persist if the job fails, and the role remains on the project until the account is removed. This option is tempting because Cloud Scheduler can automate resource lifecycle tasks, and in a scenario where the entire service account must be ephemeral (e.g., for a short-lived batch workload), deleting the account after 90 days would be a valid approach.

Go deeper

Related to this question