Practice Test #4

Recurring Dataproc jobs are batch-oriented and typically won’t meet a strict <45-second end-to-end latency SLA unless run extremely frequently, which increases cost and complexity. Dataproc also implies cluster management (even if ephemeral), conflicting with “cannot maintain clusters.” Pulling from Pub/Sub in batch can also complicate offset management and exactly-once guarantees without additional state handling.

Pub/Sub-triggered Cloud Functions provide at-least-once delivery, so duplicates can occur during retries, timeouts, or transient errors. Writing directly to BigQuery from Functions can therefore double-count unless you implement idempotency or deduplication. The option explicitly relies on a daily dedup query, which violates the “exactly once” requirement and also fails the <45-second end-to-end correctness requirement for analytics.

This design adds unnecessary complexity and operational overhead: writing to Bigtable and then running a second streaming pipeline to remove duplicates is explicitly a custom deduplication workflow, which the prompt disallows. It also increases cost (Bigtable instance + two pipelines) and introduces more failure modes and latency. Dataflow can handle exactly-once processing without this two-step approach.

Using Account_id alone groups data by account, but it does not provide uniqueness for multiple events per account. In Bigtable, each row key identifies a single row; repeated writes to the same row key would overwrite cells (or require complex qualifiers) and make time-range queries inefficient. It also prevents straightforward scans for a specific time window because time is not part of the key.

Concatenating Event_timestamp then Account_id optimizes for global time-based scans, but it breaks efficient per-account queries because a single account’s events are distributed across many key ranges. It can also cause hotspotting if timestamps are increasing and many writes land in the same tablet range. This is usually a poor default unless the primary query is “all accounts in a time range.”

Using Event_timestamp alone is problematic because it does not uniquely identify rows when multiple accounts have events at the same time, and it makes per-account lookups inefficient. It also risks severe hotspotting due to monotonically increasing keys, concentrating writes on a small set of tablets. This design only fits niche cases where the dominant query is strictly time-ordered and uniqueness is handled elsewhere.

Two root collections (drivers and deliveryLogs) can work, but it makes per-driver access control and per-driver queries less natural. You typically need a driverId field on each log and enforce security via field checks, which is more error-prone than path-based rules. It can also lead to inefficient queries if clients frequently filter a very large global logs collection, and can increase the risk of hot spots with sequential IDs.

Storing delivery logs as a nested list/array inside the driver profile document is a Firestore anti-pattern. Documents have a 1 MiB size limit, and logs grow continuously (up to 200/day), quickly exceeding limits. Large arrays also cause high write amplification because updating one element rewrites the document, increases contention, and harms offline sync and performance. It also prevents efficient querying over logs (e.g., by date/status).

Making delivery logs the root and putting each driver profile as a subcollection is an unnatural hierarchy for the access patterns. Driver profiles are the parent entity and are accessed independently of logs, so nesting them under logs complicates reads and security rules. It also makes it harder to fetch a driver profile without knowing a log path. This design does not align with Firestore modeling best practices.

Using the latest tag is unsafe for compliance because latest is inherently mutable and commonly repointed on every build. If a new image is pushed or the tag is moved during the release week, different environments could deploy different binaries while still referencing :latest. This violates the requirement for identical artifacts across dev/staging/prod and undermines auditability and reproducibility.

Using unique image names per environment changes naming, not immutability. You could still accidentally push different images (or move tags) for api-dev vs api-stg vs api-prod, resulting in drift. This approach also increases operational overhead and does not guarantee the same binary is deployed; it actually encourages environment-specific artifacts, which conflicts with promote-the-same-release best practices.

A semantic version tag like v2.3.7 is more stable than latest, but it is still a tag and therefore mutable unless you have strict controls preventing retagging/overwriting. The question explicitly states “even if tags are moved,” which means relying on any tag (including semantic version tags) cannot guarantee the same binary. Digests provide the technical guarantee required for compliance.

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.