Google Professional Cloud Developer (PCD) — Questions 601–675

Option B is correct because Cloud Build requires an explicit step to run the `gcloud run deploy` command in order to trigger a deployment to Cloud Run. While Cloud Build can build and push images, it does not automatically deploy to Cloud Run unless a deploy step is included in the build configuration. This step uses the built image (from Artifact Registry) and deploys it as a new revision to the specified Cloud Run service.

Cloud Build with a build trigger on tag push is the correct choice because it natively supports event-driven pipelines triggered by Git tags, enabling automatic build and deployment of each microservice. Combined with Cloud Build's ability to run integration tests in a staging environment and then promote to production, it provides a complete CI/CD solution for GKE without additional orchestration services.

BigQuery Omni enables querying data in S3 and Azure Blob Storage using a multi-cloud analytics approach.

Option C is correct because a managed instance group (MIG) with an instance template based on instance-3's boot disk provides automated health checking, auto-healing, and managed instance replacement. If instance-3 fails, the MIG automatically recreates it from the template, ensuring rapid restoration without manual intervention. This aligns with the goal of designing highly available and reliable applications on Google Cloud.

Shadow writes allow testing by writing to both old and new DBs. Comparison queries validate data integrity. Load testing and rollback plan are also important but not testing approaches per se.

Regional HA configures a primary and a standby in different zones within the same region, using synchronous replication to ensure no data loss and failover in under 60 seconds.

Option A is correct because the `run.googleapis.com/request_count` metric tracks the number of concurrent requests per instance, which directly matches the requirement. A Metric Threshold condition with a threshold of >8 triggers an alert when the average exceeds 8 for at least 1 minute, aligning with the specified criteria.

A is correct because leader-optimized routing directs read requests to the nearest region that contains the leader replica for the requested data, reducing inter-continental latency while still reading from the leader to ensure strong consistency. C is correct because placing a multi-region Spanner instance in geographic locations close to users minimizes network round-trip time, and Spanner's synchronous replication across regions maintains strong consistency even with high read/write throughput.

Option A is correct because when restoring a Cloud Bigtable backup, the target cluster must already exist in the specified region. The restore operation does not create a new cluster; it populates an existing cluster with the backed-up data. This ensures the cluster's configuration (e.g., node count, storage type) is predefined and meets the recovery requirements.

Option C is correct because Cloud SQL provides a fully managed relational database that requires minimal code changes when migrating from an existing relational database, while Cloud Storage with Cloud CDN handles user-uploaded images with scalable object storage and low-latency content delivery. This combination minimizes operational overhead by eliminating the need to manage database servers or file servers, and improves scalability through automatic replication and global edge caching.

Pub/Sub is correct because it provides a serverless, highly scalable ingestion service that can receive change data capture (CDC) events from an on-premises Oracle database via a connector like Debezium or Oracle GoldenGate, and stream them into BigQuery for near-real-time analytics without managing servers. Datastream is correct because it is a serverless CDC service specifically designed to replicate data from sources like Oracle directly to BigQuery, handling schema mapping and minimal operational overhead.

MySQL 8.0 has changed default character set to utf8mb4 and default collation to utf8mb4_0900_ai_ci. They should check: 1) Usage of utf8 vs utf8mb4 (utf8 is now an alias for utf8mb3). 2) The default collation change. 3) Any collation that is deprecated or removed in 8.0.

Using Cloud SQL export to Cloud Storage (SQL dump) and then loading into BigQuery is simple and cost-effective for daily snapshots. Using Datastream would be overkill and more expensive for a daily batch. Federated queries would incur repeated query costs and may not be as fresh.

Using mysqldump to export the database and then importing it via mysql client is the simplest approach for a one-time migration where downtime is acceptable. DMS is more suitable for continuous migrations with minimal downtime.

Option A is correct because promoting a cross-region read replica to primary is the standard method for manual or automated failover in Cloud SQL for PostgreSQL when the primary region fails. Cloud SQL does not support automatic cross-region failover; you must use a read replica and promote it to take over as the new primary instance.

Cloud Profiler is the correct service because it provides continuous, low-overhead CPU and heap profiling for Java applications running on Compute Engine. It uses statistical sampling to identify which methods consume the most CPU time, enabling developers to pinpoint hotspots without requiring code changes or redeployment.

Option D is correct because log-based metrics are computed from logs that have passed through all exclusion filters. If an exclusion filter is configured to discard logs matching certain criteria (e.g., all HTTP 4xx responses), those logs are never evaluated by the metric filter, causing the metric to show zero data even though 404 errors are occurring. Exclusion filters are applied before log-based metric evaluation in Cloud Logging.

Memorystore for Redis is ideal for caching, session storage, and pub/sub messaging with sub-millisecond latency. Memorystore for Memcached is also for caching but does not support pub/sub. Firestore and Bigtable are not caching solutions.

Datastream is a serverless change data capture (CDC) and replication service that can continuously stream changes from Cloud SQL (including transactional data) to Bigtable. It captures inserts, updates, and deletes in near real-time, enabling the dashboard to reflect current inventory levels within seconds of a transaction.

Option A is correct because nodes provide dedicated compute and storage resources in Cloud Spanner, which are necessary to achieve low write latency and high throughput for a global application. Nodes scale linearly with performance, ensuring that write operations are processed quickly across multiple regions. For a multi-region instance, nodes are the only supported compute capacity option, as processing units are limited to regional instances.

BigQuery Omni allows querying data across clouds (including AWS S3) using BigQuery SQL. It supports federated queries of data in S3 without movement. BigQuery federated queries (standard) only work with GCP sources.

Using UUIDs as primary keys can cause hotspotting on the leading key. A better approach is to use a composite key with a sharding prefix (e.g., hash prefix) to distribute writes, and local indexes for single-region queries are not applicable. Global indexes with STORING clause avoid index joins and reduce read latency.

Increasing the concurrency setting to 200 allows each Cloud Run instance to handle more requests simultaneously, which reduces the queuing delay caused by the 2-3 second database call. Since CPU usage is only 40%, the instances have headroom to process additional concurrent requests without being CPU-bound, directly addressing the latency issue within the 10-minute SLA.

In Cloud Trace, the root cause of intermittent high latency is identified by examining spans—the fundamental units representing work in a distributed system. Spans with high latency directly indicate where time is being spent, and an error status (e.g., HTTP 5xx or gRPC error codes) pinpoints a failure that could be causing retries or blocking, leading to the observed latency. This combination is the most direct signal for root cause analysis in trace data.

Memorystore for Redis provides a managed Redis service for caching, session stores, and pub/sub messaging.

Option B is correct because in Cloud Build, user-defined substitution variables must be prefixed with an underscore. The variable `$MY_PROJECT` lacks the required underscore prefix, making it invalid. This causes the image name to be malformed, leading to the 'invalid image name' error.

BigQuery SQL dialect is similar to standard SQL, but Snowflake-specific functions need to be converted. Using a converter tool or manual rewrite with testing is typical. There is no automated full conversion tool that guarantees correctness without review.

Firestore provides offline sync and real-time updates. Cloud Storage can store images and other large files with security rules. Cloud SQL and Bigtable are not suited for mobile offline sync.

In Cloud Bigtable, adding a second cluster in a different zone enables replication across clusters. Writes must be replicated to all clusters to maintain consistency, which introduces additional network round-trips and acknowledgment overhead. This increases write latency because each write must be committed to both clusters before the client receives a success response.

Cloud Spanner change streams capture all data changes in a database or table and can be read via Pub/Sub or Dataflow. This is the native way to stream changes from Spanner.

Cloud Spanner provides global distribution, strong consistency, and ACID transactions. With fine-grained scaling using processing units and auto-scaling, it can automatically adjust capacity based on demand, optimizing cost.

Option A is correct because the Cloud Monitoring API allows you to write custom metric points directly using the `projects.timeSeries.create` method. This enables you to define your own metric descriptors and send time-series data to Cloud Monitoring, which is a fundamental way to create custom metrics.

Cloud Monitoring SLO monitoring is the correct choice because it provides a unified dashboard (single pane of glass) to define, track, and visualize service-level indicators (SLIs) such as availability and latency across multiple GKE regions. It allows you to set SLO targets, monitor compliance over time, and receive alerts when the error budget is depleted, all within a single monitoring view.

Creating a secondary index on the 'Status' column (Option B) allows Cloud Spanner to directly locate rows matching the filter without scanning the entire table. This reduces read latency because Spanner can use the index to perform a point lookup or small range scan instead of a full table scan. Indexes in Spanner are stored as separate tables, but they add minimal storage overhead compared to the latency improvement they provide.

Regional managed instance groups (MIGs) distribute instances across multiple zones within a region, providing automatic healing and high availability by recovering from zone failures. Combined with a global load balancer, they ensure traffic is routed only to healthy instances, making them ideal for stateless web applications that require resilience against zonal outages.

Option C is correct because interleaved tables in Cloud Spanner physically co-locate parent and child rows on the same split, reducing cross-node coordination for strongly consistent reads and writes. This minimizes write latency by ensuring that related data is stored together, avoiding distributed transaction overhead for operations that span parent-child relationships.

MySQL 8.0 defaults to strict SQL mode, which disables the MySQL 5.7 non-standard GROUP BY behavior (GROUP BY can select nonaggregated columns not in GROUP BY). In 8.0, this causes errors or different results unless the sql_mode includes ONLY_FULL_GROUP_BY.

Option D is correct because the log sink uses a service account to write logs to BigQuery. Even if the sink is configured correctly, the service account must have the 'bigquery.dataEditor' role on the destination dataset to insert log entries. Without this role, the sink will fail silently, and logs will not appear in BigQuery.

Cloud Tasks is the best choice because it allows you to offload synchronous external API calls to be executed asynchronously, decoupling the Cloud Function from the slow external services. This prevents the function from timing out while waiting for responses, and Cloud Tasks handles retries and scheduling automatically, improving overall reliability and performance.

Datastream is correct because it provides serverless change data capture (CDC) from Oracle databases, enabling near real-time synchronization to BigQuery. Dataflow is correct because it can consume the Datastream output and perform complex transformations (e.g., joins, aggregations, schema mapping) using Apache Beam before writing to BigQuery.

Cloud Spanner is the correct choice because it provides a globally distributed, strongly consistent relational database with horizontal scaling and a 99.999% SLA. It combines the benefits of relational database structure (ACID transactions and SQL queries) with horizontal scalability across regions, making it ideal for financial applications that require strict consistency and high availability.

Option C is correct because a Threshold alerting policy in Cloud Monitoring triggers when a metric's value crosses a defined static boundary. For this use case, setting a threshold of 80% with a duration of 5 minutes directly matches the requirement to alert when average CPU usage exceeds 80% for that period.

Option A is correct because increasing the max instances from 10 to 100 amplifies the number of concurrent function invocations. If the function depends on an external service (e.g., a third-party API or database) that enforces rate limits, the higher concurrency causes more requests to be throttled or rejected, leading to increased timeouts. This is a classic scaling anti-pattern where horizontal scaling exacerbates a bottleneck instead of relieving it.

Uptime check success rate directly measures whether the service is reachable and responding, typically via periodic HTTP probes (e.g., GET /health). A successful response (e.g., HTTP 200) indicates availability, while failures (timeouts, connection errors) indicate unavailability. This is a standard SLI for availability in HTTP-based services.

Cloud SQL with HA configuration provides synchronous replication to a standby instance in the same zone (or different zone) and automatic failover with 0 RPO. Spanner replicates across regions, Firestore multi-region replication is not synchronous, Bigtable cluster replication is asynchronous.

Memorystore provides managed Redis and Memcached for caching, session storage, and pub/sub. It is the correct service for these use cases.

The correct rule uses request.auth.uid to get the authenticated user's ID and resource.data.owner to compare against the document's owner field. The 'owner' field must exist and match the user ID.

Interleaved tables in Cloud Spanner physically co-locate parent and child rows on the same split, so a query joining orders and line items by the parent key (order_id) can be served from a single split without distributed reads. This eliminates cross-node network hops, dramatically reducing latency for the inventory system's order+line-item queries.

Intermediate staging in S3, encrypting data in transit, and enabling automatic refresh are typical considerations for Redshift to BigQuery transfers using Data Transfer Service.

Using timestamp as the leading part of the row key causes all recent writes to go to a single tablet server, creating a hotspot.

The cache-aside pattern involves the application checking the cache first, and if not found, loading from the database and updating the cache. Eventual consistency is acceptable for cache. The saga pattern is for distributed transactions, not caching.

MyISAM tables are not supported on Cloud SQL for MySQL 8.0; they must be converted to InnoDB. InnoDB is the default engine and provides better performance, crash recovery, and concurrency.

Option D is correct because if pods have tolerations that do not match the taints on the nodes, the scheduler will not place them on those nodes, even if the cluster autoscaler has added new nodes. This mismatch prevents scheduling, leading to unschedulable pods despite sufficient node capacity.

BigQuery federated queries allow you to query data in Cloud SQL and Cloud Bigtable directly using external tables, without moving the data. This approach meets the real-time analytics requirement by joining order data (Cloud SQL) with session logs (Cloud Bigtable) in a single SQL query, avoiding the need for a separate data warehouse or data movement.

Enabling automated backups and cross-region copies ensures data is available in another region. Configuring a cross-region read replica with failover capability provides a DR instance that can be promoted in a disaster. Point-in-time recovery is for granular restore, not failover.

Memorystore (Redis) is the managed caching service on GCP, ideal for session stores and reducing database load. Cloud SQL, Bigtable, and Firestore are not suitable as low-latency caches.

Memorystore for Redis provides in-memory caching, pub/sub, and rate limiting capabilities. Memcached does not support pub/sub.

Firestore is a serverless NoSQL document database designed for mobile and web apps. It provides offline persistence, real-time listeners, and Security Rules for access control. Cloud SQL and Spanner are not serverless; Bigtable requires cluster management.

Option A is correct because Cloud Build's encrypted variables and Secret Manager are designed to securely inject sensitive data like API keys at build time without exposing them in logs. Encrypted variables are stored in Cloud KMS and decrypted only during the build, while Secret Manager provides versioned secrets with fine-grained access control. This ensures secrets never appear in plaintext in the build configuration or output logs.

Cloud Run requires containers to listen on the port specified by the PORT environment variable, which defaults to 8080. The error indicates the container is trying to bind to port 80, a privileged port, which is not allowed by the Cloud Run runtime sandbox. This mismatch causes the container to fail health checks and deployment.

Cloud Trace is the correct tool because it provides end-to-end distributed tracing, which can capture the exact latency contribution of each gRPC call across microservices and regional clusters. By analyzing trace spans, the team can determine whether the increased latency is due to network round-trip time (RTT) between clusters or due to application-level processing delays within a service.

Option C is correct because Kubernetes Services of type ClusterIP provide a stable virtual IP and DNS name (via Cloud DNS) that resolves to the service's ClusterIP, enabling pods to discover each other without hardcoding IP addresses. GKE integrates with Cloud DNS to automatically register service DNS names in the format <service>.<namespace>.svc.cluster.local, allowing microservices to communicate reliably even if pods are rescheduled or IPs change.