Google Professional Cloud Developer (PCD) — Questions 1–75

Cloud Data Fusion is a data integration service that provides a visual interface to design and execute data transformations. While it does not automatically convert BTEQ scripts, it can be used to manually rebuild the transformation logic into BigQuery SQL, making it the most suitable option for handling SQL dialect differences. BigQuery Data Transfer Service for Teradata only transfers data and schema, not SQL scripts.

The Cloud Trace exhibit shows that the auth service accounts for the largest segment of the overall request latency, as indicated by the longest span duration in the trace waterfall. In Google Cloud Trace, each span represents a service's contribution to the total latency, and the service with the highest cumulative span time is the primary contributor. Since the auth service span is the longest, it is the correct answer.

Cloud Deploy is the recommended service for managing progressive deliveries and rollbacks on GKE, as it provides built-in rollback capabilities, audit logging, and delivery pipeline management. Unlike raw Kubernetes Deployment history, Cloud Deploy integrates with Cloud Build and offers a controlled, auditable deployment process with the ability to roll back to any previous release revision.

Cloud Storage automatically encrypts all data at rest using server-side encryption with Google-managed encryption keys by default, without any additional configuration. This ensures that data is protected before it is written to disk and remains encrypted throughout its lifecycle.

Cloud Spanner provides strongly consistent writes globally through synchronous replication using the TrueTime API and Paxos-based consensus. This ensures that all write operations are immediately consistent across regions, meeting the requirement for strong consistency on writes.

An Ingress with a Google-managed SSL certificate is the correct choice because it provides a single stable IP address via a global forwarding rule, terminates SSL at the Google Cloud HTTP(S) load balancer, and routes traffic to the GKE Deployment. This approach offloads SSL decryption from the application pods and uses a managed certificate that auto-renews, meeting both the stable IP and SSL termination requirements.

The most likely reason is that the document ID in the query parameter is URL-encoded, and the function does not decode it before using it as a Firestore document reference. Firestore document IDs are case-sensitive and must match exactly; a URL-encoded string like 'doc%20name' will not match the actual document 'doc name', causing the update to fail and return 'Error'. Using `decodeURIComponent` on the parameter before passing it to Firestore resolves this.

Horizontal Pod Autoscaling (HPA) based on custom metrics allows the application to automatically scale the number of pod replicas in response to application-specific signals (e.g., requests per second, queue depth) rather than just CPU/memory. This ensures that each microservice can handle varying load efficiently, maintaining high availability and scalability without over-provisioning.

The Cloud SQL Auth Proxy, when deployed as a sidecar container in the same pod, provides encrypted connections and IAM-based authentication to Cloud SQL without requiring a public IP or complex network configuration. It automatically handles TLS 1.3 encryption and uses the service account's IAM permissions to authorize connections, ensuring secure access from Cloud Run.

DMS CDC requires that binary logs on the source are retained from the point of the full dump until cutover. If the binary logs are purged (e.g., by expiring logs or manual cleanup), the CDC phase cannot continue.

BigQuery Omni uses external tables stored in S3 (or Azure Blob). You create an external table that points to the S3 location, then query it with standard SQL.

The high latency is caused by many small read requests, each incurring API overhead. By increasing the read size (e.g., reading larger chunks or using range requests), the application reduces the number of API calls, which lowers cumulative latency and improves throughput. This directly addresses the root cause of excessive small reads.

Cloud Run's gen2 execution environment, by default, allocates CPU only during request processing. When concurrency is high, multiple requests compete for the same CPU quota, causing contention and increased latency for CPU-intensive tasks. The service's CPU-intensive nature exacerbates this issue, as the CPU is not continuously available between requests.

Datastream is a serverless, fully managed change data capture (CDC) and replication service that streams data from Oracle (and other sources) into BigQuery with near-real-time latency. It uses log-based CDC (Oracle Redo Logs) to capture changes without impacting source performance, and it handles schema mapping and data transformation automatically, minimizing operational overhead.

Memorystore for Redis Standard tier is the correct choice because it provides replication (a replica node) and automatic failover, which enables data persistence across restarts. Unlike the Basic tier, which is a single node with no persistence guarantees, the Standard tier uses append-only file (AOF) persistence to ensure data survives node restarts. This meets the requirement for a caching layer that persists data across restarts.

Database Migration Service (DMS) supports continuous change data capture (CDC) for PostgreSQL migrations to Cloud SQL by using PostgreSQL's native logical replication. This allows DMS to replicate ongoing changes from the source to the target with minimal downtime, enabling a near-zero-downtime cutover by simply promoting the Cloud SQL instance as the new primary.

A managed instance group with a regional persistent disk configured for synchronous replication provides the necessary 99.99% availability by ensuring the database runs across two zones with synchronous writes to both replicas. This architecture allows automatic failover within seconds if one zone fails, meeting the high-availability requirement without data loss.

When a revision shows 'Ready: Yes' but receives 0% traffic despite setting 100% via the console, the most likely cause is that the revision has a tag assigned but no traffic percentage. In Cloud Run, tags are used for direct URL routing (e.g., for testing) and do not receive any traffic from the service's main URL unless a traffic percentage is explicitly assigned. The console's traffic splitting UI allows setting a tag without a percentage, which can lead to this confusion.

Dataflow provides a fully managed, serverless execution environment for Apache Beam pipelines, which can read from Cloud SQL via a JDBC source, perform complex transformations (aggregations, joins with other sources) in a distributed manner, and write the results to BigQuery as a sink. This directly addresses the requirement for complex, daily transformations that are beyond the capabilities of simpler services.

Adding a salt prefix (e.g., a hash of the deviceID) distributes write load across multiple tablet servers, preventing hotspotting on a single node when many devices write concurrently. This ensures that sequential timestamps for the same device are not all written to the same tablet, which would otherwise cause a bottleneck.

Shadow writes (dual-write) involve writing to both databases and comparing results. Comparison queries and load testing are validation techniques.

`VACUUM ANALYZE` updates table statistics that the PostgreSQL query planner relies on to choose efficient index scans. Stale statistics can cause the planner to underestimate the selectivity of index conditions, leading to sequential scans instead of index scans, which increases latency. Regular analysis ensures the planner has accurate data distribution information to optimize query execution plans.

Cloud Build is a managed CI/CD platform that can build container images from source code and execute tests as part of the build pipeline. It integrates natively with Google Cloud services like Container Registry and Artifact Registry, and supports custom build steps, making it an ideal tool for building and testing containerized applications in a consistent, automated environment.

Cloud Trace is the correct choice because it is a distributed tracing system designed to capture latency data as requests propagate through microservices. It provides end-to-end visibility by collecting trace spans from each service, allowing the operations team to identify bottlenecks and measure API latency between services in a GKE environment.

Interleaved tables in Cloud Spanner physically colocate parent and child rows on the same split, reducing cross-node reads and improving join performance. This design is critical for globally distributed applications because it minimizes latency and ensures that related data is stored together for efficient access.

MySQL 5.7 allowed GROUP BY with columns not in the SELECT list by default (ONLY_FULL_GROUP_BY was off), but MySQL 8.0 enables it by default. This change can cause queries to fail if they rely on the old behavior.

Cloud Spanner uses a distributed architecture that splits data across splits based on the primary key. A monotonically increasing or timestamp-based key causes all new writes to hit a single split, creating a hotspot. By using a hash prefix on the primary key, writes are distributed uniformly across all splits, avoiding hotspots and maximizing write throughput.

Database Migration Service (DMS) supports continuous replication from source PostgreSQL to Cloud SQL, allowing near-zero downtime. Export/import requires downtime. Replica promotion is not a migration method.

Cloud Bigtable automatically compacts data in the background, but deleted rows are not immediately removed; they remain as tombstones until a garbage collection policy is applied. By configuring a garbage collection policy based on time or number of versions, you instruct Bigtable to permanently delete expired data and reclaim storage space, reducing costs.

Cloud Spanner is the only Google Cloud database that provides globally distributed ACID transactions with strong consistency, horizontal scaling, and 99.999% SLA.

Firestore is serverless, integrates with Firebase, and is ideal for storing user preferences as documents.

Cloud Deploy automatically maintains a detailed deployment history, including the state of each rollout, approvals, and metadata. This history is stored in the Cloud Deploy API and can be queried for auditing, compliance, and troubleshooting purposes, which is not natively provided by manual kubectl commands in a CI/CD pipeline.

Static code analysis (A) is correct because it helps identify code quality issues, security vulnerabilities, and adherence to coding standards early in the pipeline, which is a best practice for Cloud Functions. Running unit tests (C) is essential to validate function logic before deployment. Deploying the function (B) is the final step that pushes the validated code to Cloud Functions, making it a required step in the CI/CD pipeline.

Automatic scaling is the correct choice because App Engine standard environment natively supports automatic scaling, which dynamically adds or removes instances based on request rate, latency, and other metrics. This allows the application to handle sudden traffic spikes without manual intervention, as the platform automatically provisions resources to meet demand.

Google Cloud Deploy is a managed continuous delivery service that automates the rollout of applications to Google Kubernetes Engine (GKE) or GKE Enterprise clusters. It supports rollback to a previous deployment revision (A) by reverting the target cluster to the last known good state, and it provides automated canary analysis (C) by integrating with Cloud Monitoring to verify deployment health metrics before progressing traffic shifts.

Setting Cloud SQL to have a private IP address only (Option D) ensures the database is accessible only within the VPC network, not from the public internet. This eliminates exposure to external threats and is a fundamental security best practice for private database access.

A multi-stage Dockerfile allows you to separate the build environment from the runtime environment. By using a distroless base image (e.g., gcr.io/distroless/nodejs), you include only the application and its runtime dependencies, omitting package managers, shells, and other OS utilities. This results in a significantly smaller container image, which reduces attack surface and improves deployment speed on Cloud Run.

Memorystore (managed Redis/Memcached) is the caching layer, providing sub-millisecond access times.

MyISAM must be converted to InnoDB before migration. utf8 must be changed to utf8mb4 to support full Unicode. DMS continuous migration minimizes downtime.

Hotspotting in Cloud Spanner occurs when writes are concentrated on a single node due to a monotonically increasing primary key (like a UUID without a hash prefix). By using a composite primary key with a hash prefix of the UUID, you distribute writes evenly across all nodes because the hash prefix ensures that successive writes land on different splits. This prevents a single node from becoming a bottleneck, thereby resolving the hotspotting issue.

Cloud Trace can be integrated with Cloud Monitoring to create alerting policies based on trace data, such as latency thresholds or error rates. This integration allows you to set up notifications when specific trace conditions are met, enabling proactive performance monitoring.

The Logs Explorer in the Google Cloud Console provides a 'Stream logs' feature that allows you to view real-time log entries as they are ingested by Cloud Logging. This is ideal for monitoring a running Compute Engine instance without needing to SSH into it. Option C is correct because the `gcloud logging tail` command streams log entries from Cloud Logging in real time, using the Logging API's tail method, and can filter by resource type (e.g., `gce_instance`) or log name.

Configuring a podDisruptionBudget ensures that a minimum number of Pods remain available during voluntary disruptions, while using regional persistent disks (which replicate data across zones) allows the StatefulSet controller to quickly reschedule Pods in another zone without waiting for the failed zone's disk to become available. This combination minimizes downtime during zonal failures by maintaining quorum and ensuring data is already accessible in the surviving zone.

Cloud Logging can ingest any log entry, and log-based metrics allow you to extract numeric values from log content to create custom metrics that appear in Cloud Monitoring. Option E is correct because the Cloud Monitoring API lets you define custom metric descriptors and then write time-series data directly to those metrics, bypassing any agent or log pipeline.

Memorystore for Redis is the best choice because it provides an in-memory data store with sub-millisecond latency, ideal for session state caching, and natively supports pub/sub messaging via Redis Pub/Sub. As a managed service, it automatically handles scaling and failover, meeting the team's requirements without operational overhead.

Cloud SQL for PostgreSQL supports PostGIS and custom functions. The machine type depends on performance needs, but any tier works as long as PostgreSQL is chosen.

Cloud Error Reporting automatically groups similar errors (e.g., same stack trace or error message) and shows a count for each group, making it the fastest way to identify the most common 5xx error type without manual log inspection. It is purpose-built for this exact use case, aggregating errors from Cloud Logging and presenting them in a dashboard sorted by frequency.

Cloud SQL with regional HA configuration provisions a primary and a standby instance in different zones within the same region, using synchronous replication to enable automatic failover in under 60 seconds. This meets the requirement for high availability within a single region.

Interleaved tables store child rows with the parent row in the same split, enabling efficient joins and low-latency reads.

Helm is a package manager for Kubernetes that simplifies deploying containerized applications by using pre-configured charts. A Helm chart packages all the necessary Kubernetes resource definitions (e.g., Deployments, Services) into a single deployable unit, and running `helm install` on a GKE cluster will deploy the application correctly.

Memorystore for Redis is the correct choice because Redis natively supports pub/sub messaging, which enables cache invalidation notifications across multiple application servers. This allows each server to subscribe to channels and receive real-time invalidation messages, ensuring cache consistency in a distributed environment. Memcached, in contrast, lacks pub/sub capabilities, making it unsuitable for this requirement.

A multi-region configuration with primary regions in North America and Europe provides leader placement for writes and read replicas for low-latency reads. Adding read-only replicas in each region reduces read latency. Placing read-write replicas in both regions ensures strong consistency locally.

The error occurs because the cloudbuild.yaml references an Artifact Registry repository 'my-repo' that does not exist in the project. Cloud Build attempts to push the Docker image to the specified repository, and if the repository has not been created, the push fails with a permission or not-found error. The repository must be created before the build runs, as Cloud Build does not automatically create repositories.

The Cloud Build service account (typically the default compute engine service account or a user-specified service account) needs the `roles/iam.serviceAccountUser` role on the Cloud Run service account to impersonate it during deployment. Without this permission, Cloud Build cannot act as the Cloud Run service account to deploy the revision, even though the build itself succeeds. This is a common misconfiguration when deploying to Cloud Run from Cloud Build.

The `gcloud beta run deploy --source` flag allows Cloud Run to automatically build a container image from your source code using Cloud Build, then deploy it. This is a fully managed workflow that eliminates the need to manually build and push a container. Option E is correct because you can build a container locally, push it to Artifact Registry, and then deploy it to Cloud Run using `gcloud run deploy` with the `--image` flag, which is the standard deployment path for pre-built images.

Key Visualizer is a Cloud Bigtable-specific tool that provides a heatmap of tablet server load, row key access patterns, and traffic distribution. It directly identifies hot spots by showing which row ranges are receiving disproportionate read/write activity, enabling targeted schema optimization.

The Cloud SQL proxy sidecar container is missing from the new Deployment revision. Since the application relies on the sidecar to establish a secure connection to Cloud SQL, its absence causes the connection refused error. The old pods continue to run because they still have the sidecar from the previous Deployment revision, while the new pods crash due to the missing proxy.

Istio or Anthos Service Mesh provides fine-grained traffic splitting capabilities for canary deployments in a GKE environment. It uses Envoy sidecar proxies to route a percentage of traffic to different service versions based on HTTP headers or weight, enabling controlled rollouts without modifying application code.

MySQL 8.0 changes default authentication to caching_sha2_password, which may break application connections if the client driver does not support it. MyISAM tables should be converted to InnoDB for reliability and features like foreign keys. utf8 charset should be changed to utf8mb4 to avoid truncation of 4-byte characters. The caching_sha2_password plugin is default; if the app uses older connectors, they may need to set the default to mysql_native_password or update the connector.