Practice Test #4

Cloud Trace is used for distributed tracing, request flow analysis, and latency breakdown across services. It helps identify where time is spent and can correlate slow or failing requests, but it does not dynamically inspect arbitrary local variables at a specific source line in a running process. To see values like customerId and tokenExpiry at line 214, Trace would require prior application instrumentation rather than an on-the-fly debugging feature. Therefore it does not meet the requirement to observe those variables without code changes.

Cloud Monitoring is for metrics, dashboards, alerting, uptime checks, and SLO-based observability. It can show error rates, request volume, and infrastructure or application metrics, but it does not capture local in-process variables from a specific line of source code. While logs-based metrics can be derived from existing logs, the prompt explicitly requires generating new observations of variable values without modifying the application. That makes Monitoring the wrong tool for this task.

Cloud Debugger Snapshots capture a point-in-time view of program state, including stack frames and local variables, when execution reaches a chosen line. That is useful for inspecting state during live debugging, but snapshots are not the best fit when the requirement is to write observations to Cloud Logging every time the branch is hit over the next 4 hours. The prompt asks for repeated logging behavior rather than occasional state capture. Logpoints are specifically intended for that repeated, log-oriented use case.

Incorrect. roles/storage.admin at the project level grants broad permissions across all Cloud Storage resources in the project (including all buckets), not just acct-prod-uploads. This violates least privilege and the requirement to avoid project-wide roles. Even if operationally simple, it increases risk if the function is compromised or misbehaves.

Incorrect. roles/editor is a highly privileged, legacy broad role that grants permissions far beyond Cloud Storage (compute, networking, IAM-related actions in some contexts, etc.). It directly conflicts with least privilege and is a common anti-pattern in production. The question explicitly requires avoiding project-wide roles, which Editor typically implies at project scope.

Incorrect. Using the default service account contradicts the requirement to avoid default service accounts. Default identities are often shared and may have broader permissions than needed, making it harder to enforce least privilege and increasing blast radius. Best practice is to use a dedicated user-managed service account per workload with narrowly scoped permissions.

Cloud Code can assist development workflows, but this option still directs the application to pubsub.googleapis.com, which is the real managed Pub/Sub service. That requires internet connectivity, valid credentials, and API enablement in the Google Cloud project. It can also incur charges and introduces external dependency latency, which conflicts with the requirement for offline, under-two-minute local validation. Therefore, it does not satisfy the core constraints of the scenario.

This option uses the production Pub/Sub endpoint rather than a local emulator, so it cannot work without internet access. Enabling the Pub/Sub API in the project is only relevant when calling the real service, not when using the emulator. It also risks billable usage and slows down local iteration compared with an in-memory local emulator. As a result, it fails the explicit requirements for offline and no-cost testing.

This option is partially correct because setting PUBSUB_EMULATOR_HOST is indeed how many client libraries discover the local emulator endpoint. However, it says any project ID string is fine, while the scenario explicitly provides a dev project ID and asks how to configure local testing, making the documented emulator startup with that project ID the better fit. It also omits the env-init step, which is the standard gcloud-supported way to configure the local environment for emulator use. Because B is more complete and better aligned with the prompt, D is not the best answer.

Adding the image to exempt image patterns creates a bypass in the policy that can persist beyond the incident. Even if it’s scoped to a specific image name, it weakens the control model and increases long-term risk (future images could match patterns, or the exemption could be reused). This is generally contrary to least privilege and good governance for supply-chain security.

Signing with a personal private key and changing the attestor’s public key undermines the trust model. Attestors should be controlled by security/CI systems with strong key management, rotation, and separation of duties. Updating the attestor to trust an individual developer key is risky, hard to audit, and can create a precedent that bypasses the intended CI/CD verification process.

Temporarily disabling the organization-level Binary Authorization policy is overly broad and high risk. It removes enforcement for all covered resources, not just the urgent service, increasing the chance of accidental or malicious unverified deployments during the window. It also conflicts with strict uptime/SLA environments where controlled, minimal-change procedures and auditability are essential.

Signed URLs are unnecessary because clients never access the bucket; the Cloud Run service can read directly using IAM. Also, granting permissions to the Compute Engine default service account violates the requirement that production workloads must not run with default service accounts. Signed URLs also introduce operational overhead (key rotation, URL generation) without improving the server-side access pattern here.

Public Access Prevention is correct for ensuring the bucket can’t become public, but this option still grants access to the Compute Engine default service account, which violates the explicit constraint that production workloads must not run with default service accounts. Cloud Run should use a dedicated user-managed service account for least privilege and better auditability.

Using a user-managed service account and granting roles/storage.objectViewer is correct, but enforcing signed URLs is not the best practice for this scenario. Signed URLs are intended for delegating temporary access to external clients; here, only the Cloud Run service needs access. The stronger control for “never publicly accessible” is Public Access Prevention, not signed URLs.