Google ACE Practice Question: A team wants to grant a contractor the Storage…

Answer analysis

Option-by-option breakdown

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

• ✗

  IAM deny policies scoped to non-business hours

  Why it's wrong here

  IAM deny policies are evaluated before allow bindings and unconditionally block the listed permissions, but they cannot natively evaluate time-of-day or day-of-week attributes. To enforce access only during business hours you would have to manually swap deny policies in and out, which is operationally fragile and creates a race window where permissions can be wrong. IAM Conditions are the native, declarative way to make a role binding valid only during a specified time window, so deny policies are an unnecessarily complex and brittle alternative.

• ✓

  IAM Conditions on the role binding

  Why this is correct

  IAM Conditions attach to a specific role binding and can include expressions using request.time, which supports date/time, day-of-week, and time-of-day comparisons such as Monday through Friday between 09:00 and 17:00. The condition narrows the binding's effect without altering the rest of the organization, folder, or project IAM policy. This approach is the recommended pattern because it is evaluated in real time by Cloud IAM, requires no external orchestration, and applies automatically to every API request that uses that binding.

• ✗

  VPC Service Controls with a time-based access policy

  Why it's wrong here

  VPC Service Controls operate at the perimeter level by using context-aware conditions to control which services a request can reach based on attributes like the client network, identity, and resource location. While the context object includes request.time as a possible condition attribute, VPC Service Controls are designed to enforce service perimeter boundaries, not to scope an IAM role binding's permissions to business hours. They do not modify or narrow the specific permissions granted to a principal; instead they block access to entire Google Cloud services, making them the wrong granularity for this task.

• ✗

  Cloud Scheduler removing and re-adding the IAM binding on a schedule

  Why it's wrong here

  Using Cloud Scheduler to remove and re-add a role binding is a cron-driven mutation of the IAM policy that is asynchronous, and during the switch a denied user could be incorrectly allowed or blocked depending on the job's timing. It also creates a dependency on Cloud Scheduler jobs and Pub/Sub-style execution, and any failure would leave the binding in the wrong state for an indefinite period. IAM Conditions provide time-based gating without mutating policy state, so the scheduler approach is an unnecessary and error-prone workaround for a feature Cloud IAM already natively supports.

Go deeper

Related to this question