Google Professional Cloud Developer

Docker Compose and dockerd can provide a fast local rebuild/restart loop, but it does not closely emulate Kubernetes manifests or the Kubernetes deployment flow used with GKE and Cloud Deploy. Compose uses a different configuration model (docker-compose.yml) and lacks native concepts like Deployments, Services, ConfigMaps, and RBAC. This fails the requirement to closely emulate production Kubernetes manifests and deployment behavior.

Terraform and kubeadm are oriented toward provisioning infrastructure and bootstrapping Kubernetes clusters, not rapid inner-loop development. kubeadm is heavyweight and operationally complex for a laptop workflow, and Terraform adds infrastructure management overhead rather than enabling hot-reload. Neither provides an automatic file-watching rebuild/redeploy loop comparable to Skaffold, so the ≤10-second iteration requirement is not met.

kaniko and Tekton are primarily designed for building images and running pipelines in Kubernetes (CI/CD), not for a fast local developer inner loop on resource-constrained laptops. kaniko commonly pushes to a registry, and Tekton requires a Kubernetes cluster and pipeline setup overhead. This combination is better suited to remote build systems (e.g., in-cluster CI) than local hot-reload development without a registry.

Incorrect. Project-level pubsub.publisher and pubsub.subscriber allow the device identity to publish to any topic and subscribe to any subscription in the project (subject to role permissions), which violates the requirement to restrict each device to its own resources. This is a common anti-pattern for multi-tenant or per-device isolation scenarios.

Incorrect. Granting pubsub.topics.create and pubsub.subscriptions.create focuses on provisioning, not on restricting publish/subscribe to existing resources. It also increases risk by allowing devices to create arbitrary topics/subscriptions (potential quota exhaustion and cost growth). Even with a custom role, you still need resource-level publish/subscribe permissions for isolation.

Incorrect. A shared service account means all devices effectively have the same permissions, so any device can publish/subscribe to any resource that service account can access. This breaks isolation and makes it hard to attribute actions to a specific device. It also complicates incident response because rotating/revoking credentials impacts all devices.

Cloud SQL supports relational modeling for hierarchies, but it does not provide Google client SDKs with built-in offline persistence and automatic sync for mobile/tablet apps. You would need to implement local storage, change tracking, conflict resolution, and sync logic yourself. roles/cloudsql.editor also doesn’t directly grant database-level DML permissions; it manages instances and is broader than needed for app-level writes.

Bigtable can handle high write throughput and large scale, but it is a wide-column store optimized for time-series/analytics-style access patterns, not hierarchical document navigation with offline-first mobile sync. There are no Firestore-like client SDKs for offline caching/synchronization. Additionally, roles/bigtable.viewer is read-only, so it cannot support the backend requirement to enrich records with writes.

Firestore in Datastore mode is primarily for Datastore API compatibility and does not align as directly with Firebase-style offline synchronization expectations for client apps. Even if the database choice were acceptable, roles/datastore.viewer is read-only and cannot support the Cloud Run backend’s requirement to perform up to 5,000 writes per minute to enrich records.

Cloud SQL (PostgreSQL) is a managed relational database but still requires schema management and careful capacity planning. Weekly schema migrations and downtime risk are exactly the pain points described. At 45,000 writes/second, a single instance will not suffice; scaling typically requires read replicas (not for writes) or application-level sharding, increasing operational overhead. It also doesn’t naturally support highly variable per-user records without frequent migrations.

Cloud Storage is an object store for blobs (files) with very high durability and throughput, but it is not a database optimized for low-latency key-based reads/writes with per-user transactional consistency. You could store per-user JSON objects, but you’d lose efficient querying, atomic updates across multiple related items, and database-like concurrency controls. It’s better for raw telemetry archives, exports, or batch analytics inputs.

Cloud Spanner provides horizontally scalable relational SQL with strong consistency and high availability, and it can handle very high write throughput. However, it is schema-based and best when you need relational modeling, SQL joins, and cross-row/table transactions at scale. The scenario explicitly wants to avoid rigid schemas and frequent migrations, and only needs per-user transactional consistency with simple key-based reads—making Spanner unnecessarily complex and costly.

Distributing uploads across many buckets can help in some systems that have per-bucket hot-spotting constraints, but Cloud Storage generally supports very high request rates per bucket. The scenario emphasizes a newly created idle bucket and a sudden step increase, which points to ramp/throttling behavior and retry storms. Sharding adds operational complexity (naming, lifecycle, IAM, analytics) without directly addressing the spike-induced 429/5xx.

The JSON and XML APIs are different interfaces to the same Cloud Storage service. Switching APIs does not meaningfully change backend throttling behavior, quotas, or the need to handle 429/5xx correctly. You would still need proper retry and backoff logic. This option is a common trap: changing protocol rarely fixes rate limiting or transient errors caused by sudden load.

Propagating HTTP errors to end users does nothing to reduce failed responses; it simply exposes internal throttling and transient failures to customers and increases perceived downtime. Best practice is to handle 429/5xx with controlled retries, backoff, and circuit-breaking where appropriate. For DR/failover, you want graceful recovery and stable throughput, not raw error passthrough.

Although a custom role containing only cloudsql.instances.connect appears to be more restrictive, it is not the best answer when the question asks for Google-recommended practices. For standard Cloud SQL Auth Proxy connectivity, Google commonly expects the predefined roles/cloudsql.client role rather than a custom role. Custom roles also add operational overhead and can be error-prone if the workload later needs additional related permissions. On certification exams, the predefined least-privilege role is usually preferred unless the prompt explicitly asks you to build a custom role.

roles/cloudsql.editor is overly permissive because it allows modifying Cloud SQL resources rather than only connecting to them. A Python microservice using the Auth Proxy does not need instance management permissions to establish a database session. Granting editor access violates the principle of least privilege and increases security risk if the workload is compromised. For exam scenarios, management roles are incorrect when the requirement is only application connectivity.

roles/cloudsql.viewer provides read-only visibility into Cloud SQL resources but does not grant the ability to connect through the Cloud SQL Auth Proxy. The proxy requires connection-related permissions, which viewer does not include. As a result, the workload would be able to inspect metadata but not establish the authenticated proxy connection needed by the application. Viewer is a common distractor because it sounds relevant to Cloud SQL without actually enabling access.

Bigtable is a wide-column NoSQL database optimized for massive throughput and low-latency key/value access patterns. It is not a relational MySQL replacement and does not provide SQL joins or the same transactional semantics expected for “critical transactions.” While it can be replicated for availability, it’s not the best fit for globally consistent relational writes. Migrating would require significant application redesign and may not meet strong consistency expectations for multi-row relational transactions.

Firestore in Datastore mode is a managed NoSQL document database. Although it can be deployed in multi-region configurations and offers strong consistency for many operations, it is not a relational database and lacks SQL querying, joins, and typical MySQL transactional patterns across complex relational schemas. Migrating a marketplace’s critical transactional workload from MySQL to Datastore mode usually requires major data model and query redesign, and it may not satisfy the relational/transaction requirements implied by “critical transactions.”

Moving services to GKE and adding a load balancer improves application scalability and availability, but it does not fix the fundamental issue: write latency is dominated by cross-region round-trip time to the single MySQL primary in us-central1. Even perfectly scaled compute cannot reduce the physics of intercontinental latency for database commits. The bottleneck is the database architecture (single-writer primary), so the solution must address global write locality and consistency at the data layer.

Cloud Storage log sinks are designed for archival and batch-style processing. Even if you trigger on object finalization, logs are written as files with variable batching/flush intervals, so end-to-end latency is not reliably within 5 seconds. It also adds operational overhead (bucket management, object lifecycle, parsing files) and is not the recommended pattern for near-real-time cache invalidation.

Cloud Asset Inventory real-time feeds are best for tracking asset inventory/metadata changes (create/delete, IAM/policy, some config changes). They are not a strong fit for rapid instance power-state transitions like RUNNING/STOPPED/SUSPENDED or preemption signals, and may not provide the consistent sub-5-second lifecycle fidelity required for dispatch correctness.

BigQuery log sinks are optimized for analytics, not low-latency eventing. Querying every minute already violates the 5-second freshness requirement, and frequent queries increase cost and complexity. This is a pull-based polling design that risks stale cache entries and misrouting, especially during bursts of lifecycle changes (preemptions, autoscaling, rolling updates).

Compute Engine requires provisioning and managing VM instances (patching, scaling groups, health checks). Even if Pub/Sub push delivers messages efficiently, the VM must remain running to receive traffic, so you pay while idle—violating “costs only when new messages arrive.” It also conflicts with the requirement of no dependency on managed infrastructure such as VMs or clusters.

Cloud Functions should not create a pull subscription and poll Pub/Sub. Polling adds unnecessary latency and cost because the function would need to run continuously or be invoked on a schedule, which breaks the event-driven model. It also complicates scaling during spikes and can lead to missed 300 ms processing targets due to polling intervals and subscription management overhead.

GKE is explicitly a managed cluster (nodes, autoscaling, upgrades), which violates the “no VMs or clusters” constraint. While pull subscriptions with worker pods can handle high throughput, you pay for cluster resources even when no messages arrive unless you implement complex scale-to-zero patterns (not typical for GKE). Operational overhead is also much higher than serverless options.

Downloading the binary during the build is fragile and typically fails the stated constraints. Outbound internet access is restricted, so the download may be blocked entirely. Even if allowed, network variability and upstream availability can easily exceed the 5-second startup requirement and threaten the 10-minute SLA. It also reduces reproducibility unless you pin checksums and handle mirrors, which adds complexity and risk.

Committing a 120 MB binary into the source repository can make builds work without internet, but it is a poor practice for CI/CD. It bloats the repo, slows cloning and mirroring, complicates code review, and can create supply-chain governance issues (binary provenance, scanning, licensing). It also couples tool distribution to source changes and can be error-prone when multiple services or pipelines need the same tool.

Filing a feature request does not solve the immediate requirement and is not a reliable strategy for meeting SLAs. Default Cloud Build environments change on Google’s schedule and may not include niche tools or specific versions. Even if added, you still need version pinning for reproducibility. On exams, “wait for the platform to add it” is almost never the correct operational answer when you have clear constraints.

Incorrect. A scheduled Function is a custom batch/ETL approach, violating the requirement to avoid custom batch jobs and likely missing the <60-second near-real-time SLA (daily schedule is explicitly too slow). It also adds operational risk (retries, duplicates, pagination, quota limits) and cost. Additionally, reading from _Required is not the right source for application container logs.

Incorrect. You don’t “modify the _Default bucket’s routing rules” to redirect logs; routing is done via Log Router sinks, and redirecting would change existing log flows, which is prohibited. The requirement is to mirror/duplicate logs while keeping current behavior intact. Also, system buckets (_Default/_Required) have constraints; best practice is to create additional sinks rather than altering baseline ingestion patterns.

Incorrect. Admin Activity and System Event logs are audit logs, not application logs from GKE containers. The requirement is specifically for resource.type="k8s_container" with labels.app="payments" and severity>=ERROR, which are application logs. Copying only _Required audit log categories would not satisfy PCI DSS 10.3 for application error logging and would miss the specified filter criteria.

Incorrect. App Engine would require building and deploying an application endpoint to receive uploads and then publish to Pub/Sub. This adds development time, operational considerations (versions, scaling behavior, monitoring), and changes the ingestion path (gateway uploads to the app rather than directly to Cloud Storage). It violates the requirement for least development and no additional compute to manage.

Incorrect for this question’s constraints. A Cloud Function triggered by Cloud Storage finalize events can publish to Pub/Sub, but it still requires writing, deploying, and operating code (runtime configuration, retries, logging/alerting, IAM for the function). Since Cloud Storage can publish directly to Pub/Sub, the function is unnecessary extra moving parts for a simple notification.

Incorrect. Running a service on GKE introduces the highest operational overhead: cluster provisioning, node management (or even with Autopilot, still more setup), deployments, scaling, security patching, and monitoring. It also requires changing the upload flow to hit the service. This is far from the “within 1 hour” and “no additional compute to manage” requirement.

Pub/Sub is not the most efficient or standard approach for CSR-to-Cloud Build automation. While you can build event-driven pipelines with Pub/Sub, CSR already has first-class integration with Cloud Build triggers for push events. Adding Pub/Sub increases complexity (topic, permissions, message format, trigger wiring) without providing additional value for a simple “push-to-deploy” workflow.

A generic webhook trigger can work, but it’s not the most efficient here because CSR is already a Google-native source with direct Cloud Build trigger support. Webhooks are typically used for external Git providers or custom systems that can POST to Cloud Build. Using a webhook adds operational overhead (managing the URL/secret and ensuring delivery) compared to a native CSR trigger.

Cloud Scheduler running gcloud builds submit every 24 hours is a polling-based approach and does not meet the requirement that each commit to release/v2 triggers a deployment. It also introduces unnecessary latency and can deploy stale code if multiple commits occur between runs. This is less reliable and less aligned with CI/CD best practices than event-driven triggers.

Incorrect. If the VM is stuck in “Starting” and repeatedly rebooting, the OS likely never reaches a stable multi-user state where sshd is running and accepting logins. Changing the Linux username does not address bootloader/kernel/filesystem failures. SSH troubleshooting is appropriate when the instance is RUNNING and serial console indicates the OS booted successfully.

Incorrect. VPC firewall rules and routes affect network connectivity to/from an instance, but they do not prevent the guest OS from booting. A VM can fully boot even with no network access. The symptom described (serial console shows repeated boot attempts and the instance remains in Starting) points to disk/OS boot issues rather than routing or firewall configuration.

Incorrect. Dropped network traffic (firewall/policy) can explain inability to SSH or reach the application, but it does not explain repeated boot attempts shown in the serial console or a VM stuck in “Starting.” Network policies operate after the OS boots and the NIC is configured; they do not typically cause kernel/init failures or reboot loops.

Cloud Storage is not the primary integration path for Error Reporting. Streaming logs to a bucket adds operational complexity (log routing, lifecycle, parsing) and does not automatically create Error Reporting events. You would still need Cloud Logging-based error entries or additional processing to surface exceptions. Cloud Run is still a good compute choice, but the logging approach is not aligned with Error Reporting best practices.

GKE Autopilot reduces cluster management but still requires Kubernetes operations (deployments, services, policies) and typically incurs baseline costs; it does not naturally scale the entire platform to zero for an HTTP API. While stderr logs from containers can reach Cloud Logging and Error Reporting, the solution violates the “lowest operational effort” and “avoid paying for idle compute” requirements compared to Cloud Run.

This is the highest operational effort option: you manage Kubernetes resources and also add a nonstandard logging pipeline to Cloud Storage. Error Reporting expects errors in Cloud Logging (or supported error event formats), not raw bucket logs. You would pay for Autopilot cluster overhead and likely for always-on components, making it poorly aligned with the diurnal traffic and cost goals.

Incorrect. Data Editor and Data Viewer on the dataset control access to dataset objects (read/write) but do not grant permission to create BigQuery jobs. The bq CLI still must submit a query job, and without roles/bigquery.jobUser (or equivalent) on the project, the service account can continue to fail with bigquery.jobs.create permission errors.

Incorrect. Creating a view does not eliminate job creation; running SELECT * FROM view still executes as a BigQuery query job and still requires bigquery.jobs.create. It also changes the operational model (introduces a managed object and deployment lifecycle) and may require additional permissions to create/manage the view, which doesn’t solve the root cause.

Incorrect. Copying data to a temporary dataset is an architectural workaround that increases cost, complexity, and operational risk (data freshness, duplication, quotas). It also does not inherently fix job creation permissions; queries against the temporary dataset would still require bigquery.jobs.create on the project where the job runs, so the same permission error could persist.

Incorrect. Granting Service Account Token Creator enables impersonation, which is powerful and risky for external users. It effectively gives reviewers a pathway to obtain credentials and potentially access beyond assigned objects, depending on permissions. It also assumes reviewers can use Google IAM-based flows and identities, conflicting with “some do not have Google accounts,” and is not least privilege.

Incorrect. Distributing a service account key to external reviewers is a major security anti-pattern: keys can be copied, reused, and exfiltrated. Also, service account keys do not support a native “expire after 24 hours” setting in the way implied; you would need to rotate/delete keys manually. This approach grants broad access and violates best practices for credential management.

Incorrect. IAM roles (even with IAM Conditions that expire) require binding to a principal identity. Reviewers without Google accounts cannot be directly granted Storage Object User on the bucket. Additionally, bucket-level role assignment is broader than per-object access unless combined with complex conditional logic; signed URLs are simpler and more precise for object-level, time-bound external access.

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.

A custom mocking framework is risky because it is very hard to accurately reproduce Pub/Sub semantics (ordering keys, redelivery, ack deadlines, flow control, and concurrency effects). Such mocks often diverge from real behavior, creating tests that pass but fail in production. It also increases maintenance burden and does not align with best practices for testing managed services when an official emulator exists.

Creating a dedicated topic and subscription per tester can reduce interference, but it adds operational overhead (resource creation/cleanup, IAM, quotas) and can still be flaky due to real service dependencies. It also violates the “zero additional GCP cost” requirement because Pub/Sub usage (publish/deliver operations, storage) is billable, and scaling this across many CI runs can become expensive.

Subscription filters can isolate messages by tester_id, but they do not eliminate cost or external dependency. You still pay for publishing and delivery attempts, and filters add complexity (ensuring every message has correct attributes, managing filter expressions). Filters also don’t fully prevent flakiness from shared infrastructure, parallel test contention, or transient Pub/Sub service behavior in CI.