Cloud Digital Leader Trust and security with Google Cloud Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use Cloud Pub/Sub alone to listen for SCC findings and then manually remediate

  Why it's wrong here

  Pub/Sub alone is a messaging/transport layer, not an executor: it can receive SCC findings delivered via a notification config, but it has no built-in compute to process them. Someone would have to run a subscriber and manually interpret each finding to revoke public access, which creates a human-in-the-loop delay and scalability problem. In the proper automated pattern, Pub/Sub delivers the finding payload to a Cloud Function, which then performs the remediation—so using Pub/Sub without an automated subscriber is only half of the needed pipeline.

• ✗

  Use IAM to deny all users except project owners from making buckets public

  Why it's wrong here

  IAM restrictions are a preventive control that blocks future changes to bucket policies, but SCC findings detect existing buckets that are already public—those must be actively remediated. This approach does nothing for buckets that were made public before the policy was applied, nor does it respond to the findings themselves. Additionally, overly restrictive IAM could break legitimate uses of public access and does not provide the real-time, automated resolution the scenario demands.

• ✓

  Set up a Cloud Function triggered by SCC findings to remove public access

  Why this is correct

  This is the correct event-driven pattern: SCC publishes findings to Cloud Pub/Sub via a notification config, and a Cloud Function can be subscribed to that Pub/Sub topic using the background-trigger mechanism. The function receives the finding JSON, parses the bucket name, and uses the Cloud Resource Manager or Cloud Asset API to remove the public IAM binding or the public ACL. This happens within milliseconds of detection, is fully automated, and scales naturally with findings, making it the right fit for real-time security remediation.

• ✗

  Configure a Cloud Scheduler job to run a script that checks and removes public access

  Why it's wrong here

  Cloud Scheduler executes jobs on a fixed time schedule (e.g., cron), so it cannot react immediately to an SCC finding—it will only run at the next scheduled interval, leaving a window of exposure. Repeatedly scanning all buckets on a schedule is also wasteful and may miss short-lived public access changes that occur between runs. This is a polling-based approach rather than an event-driven one, which conflicts with the need to remediate findings as soon as they are generated.

Go deeper

Related to this question