Planning and Configuring a Cloud Solution practice questions

Balanced persistent disk (pd-balanced)

Why it fails: Balanced persistent disk (pd-balanced) offers a compromise between cost and performance, with IOPS and throughput that scale with the provisioned disk size. However, its per-disk performance ceiling is significantly lower than pd-extreme, and it does not allow independent provisioning of IOPS separate from capacity. For a stateful app that experiences unpredictable spikes in I/O or requires consistently high random write throughput, pd-balanced will likely become a bottleneck, leading to increased latency and potential application timeouts.

SSD persistent disk (pd-ssd)

Why it fails: SSD persistent disk (pd-ssd) provides solid-state performance and is a common default for many applications, but it is not designed for the absolute highest IOPS. Performance is directly tied to the disk's provisioned size, so reaching IOPS comparable to pd-extreme would require an excessively large, costly disk. Additionally, resizing pd-ssd while attached to a running VM may require more complex, snapshot-based procedures or an extended maintenance window, which disrupts the availability of a stateful application and makes it a poor fit for this scenario.

Standard persistent disk (pd-standard)

Why it fails: Standard persistent disk (pd-standard) is backed by rotational hard drives and delivers only a few hundred IOPS, with high latency and low throughput. It is unsuited for the random read/write patterns that stateful applications typically generate, such as database transaction logs or real-time updates. While it is the cheapest option, its severe performance limitations will cause significant application slowdowns and are only acceptable for cold storage, backups, or bulk data that is accessed infrequently.

Export the Cloud SQL instance as a dump and recreate it in VPC-A

Why it fails: Exporting the database and recreating the instance inside VPC-A is a data migration, not a connectivity fix. It forces downtime, application connection string changes, and manual re-import, while losing the original instance’s automatic backups and scaling configuration. This approach also does not solve how the existing Cloud SQL service should be reached from VPC-A; it merely moves the problem to a different location.

Configure the Cloud SQL instance with a public IP and allow the VM's IP in authorized networks

Why it fails: Assigning a public IP and adding the VM’s IP to Cloud SQL authorized networks permits access by source-IP allowlist, but it contradicts the stated requirement to avoid public IP use. Authorized networks only accept external IP addresses, so a VM with only an internal address cannot be allowlisted from within the peer; traffic would also traverse the public internet. This approach increases the attack surface and fails the company’s private-connectivity constraint.

Use Cloud VPN to connect VPC-A to the VPC where Cloud SQL is deployed

Why it fails: Using Cloud VPN to connect VPC-A to the Cloud SQL VPC could work technically, but the company explicitly said they do not want a VPN. VPN adds operational overhead for tunnel health, routing, and gateway endpoints, and it introduces extra latency compared with VPC peering. Since Cloud SQL’s private IP is already reachable through Google’s peering infrastructure, a VPN is an unnecessary and rejected alternative.

Committed use discounts

Why it fails: Committed use discounts (CUDs) require purchasing a 1-year or 3-year commitment for consistent vCPU/memory usage. A nightly 3-hour batch job uses the VM for roughly 90 hours per month, well below the 730-hour monthly baseline that makes a CUD worthwhile. You would pay for idle committed resources the rest of the day, negating any discount, so CUDs are not cost-effective for this short, intermittent workload.

On-demand VMs

Why it fails: On-demand VMs use standard pay-as-you-go pricing and do not provide the significant discount of Spot VMs, so they are not the most cost-effective choice for fault-tolerant batch workloads.

Sustained use discounts

Why it fails: Sustained use discounts (SUDs) automatically apply to VMs that run for more than 25% of a month (approximately 730 hours). This workload runs only 3 hours per night, totaling about 90 hours per month, which is far below the threshold, so no SUD would apply. Additionally, SUDs are not a purchasing decision; they just adjust billing after the fact, so they cannot be intentionally chosen to reduce cost for short nightly jobs.

Standard persistent disks with snapshots

Why it fails: Standard persistent disks are backed by hard disk drives and offer significantly lower IOPS and throughput compared to SSD persistent disks. MongoDB, especially under write-heavy or high-concurrency workloads, requires fast random I/O; standard pd would become a severe bottleneck. While snapshots are still supported for backup, the disk's poor random-access performance makes it unsuitable for a database of any real size.

Extreme persistent disks with snapshots

Why it fails: Extreme persistent disks provide the highest provisioned IOPS and throughput in Compute Engine, but they are overkill and considerably more expensive than SSD persistent disks for typical MongoDB workloads. Their performance is useful for massive, latency-sensitive databases, yet most MongoDB deployments on Compute Engine run effectively on pd-ssd without needing extreme-tier performance. Choosing Extreme pd here would incur unnecessary cost without a corresponding benefit.

Local SSDs

Why it fails: Local SSDs are physically attached to the host machine and deliver extremely high throughput and low latency, but the data is ephemeral and is lost if the VM is stopped, deleted, or fails. Snapshots are not supported for local SSDs, so they cannot provide the backup and recovery that MongoDB requires for durable data. Thus, local SSDs are acceptable only for temporary caches or scratch space, not for a production database.

Cloud Functions (1st gen) with VPC connector

Why it fails: Cloud Functions (1st gen) supports Serverless VPC Access connectors only for outbound (egress) traffic, allowing the function to make requests to resources in a VPC but not to receive inbound traffic from that VPC. The function remains an externally reachable resource with a public URL, and it cannot be attached to a VPC as a network resource or triggered privately via internal IPs. Because the event source is in a VPC and likely needs to invoke or deliver events to the function internally, 1st gen's one-way outbound-only model is insufficient.

Cloud Functions (2nd gen) with Cloud VPN

Why it fails: Cloud VPN creates an IPsec tunnel between an on-premises network and a Google Cloud VPC, which is a hybrid connectivity solution, not a mechanism for attaching a serverless function to a VPC. Even if Cloud Functions (2nd gen) is paired with Cloud VPN, the function itself still requires a VPC connector to route traffic into the VPC; the VPN tunnel only connects external networks to the VPC gateway. Without a VPC connector, the function's outbound requests would go over the public internet, and the VPN cannot provide the function with a private VPC identity or internal routing.

Cloud Functions (1st gen) with Cloud NAT

Why it fails: Cloud NAT is designed to allow VMs and other resources that have no external IP addresses to make outbound connections to the internet by translating their private IPs to a public IP. It does not provide connectivity from a serverless function to a VPC, nor does it enable private resource discovery or internal IP communication within the VPC. For Cloud Functions (1st gen), adding Cloud NAT would not address the core limitation that 1st gen cannot be triggered privately from a VPC; it only solves the opposite problem of outbound internet access, so it is irrelevant for this requirement.

Assign each VM a static external IP address

Why it fails: Assigning static IPs to individual VMs does not provide a single endpoint and is not recommended for HA.

Use Cloud DNS with geo-routing

Why it fails: Geo-routing is for global load balancing, not necessary for zonal HA.

Use a single-zone managed instance group with a snapshot schedule

Why it fails: Single-zone does not provide cross-zone HA.

roles/cloudfunctions.invoker

Why it fails: roles/cloudfunctions.invoker is the correct permission because Cloud Functions 2nd gen uses an HTTP trigger, and Pub/Sub's push subscription must be authorized to call that HTTP endpoint. Granting this role to the Pub/Sub service account (service-{project-number}@gcp-sa-pubsub.iam.gserviceaccount.com) allows its push requests to reach the function. Without this role, the function's URL returns 403 and messages never trigger execution.

roles/iam.serviceAccountUser

Why it fails: roles/iam.serviceAccountUser is not required here. It authorizes a principal to impersonate a service account and obtain temporary OAuth2 credentials, which is relevant only when you need to act as that account in code, such as with `--impersonate-service-account`. The Cloud Function's runtime already runs as its assigned service account directly, so no impersonation step is needed and this role would be a redundant, unnecessary privilege.

roles/pubsub.publisher

Why it fails: roles/pubsub.publisher is the wrong permission for this function because the function is consuming messages, not producing them. The publisher role grants the ability to publish new messages to a Pub/Sub topic, which would be needed only if the function performed a write-back like sending results to another topic. For a pure subscriber workload, granting this role violates least privilege and adds no functional value.

Cloud SQL

Why it fails: Cloud SQL is a relational database service (MySQL, PostgreSQL, or SQL Server) that stores data in internal volumes and requires importing data via dump files or client tools; it cannot directly reference CSV files stored in Cloud Storage. Its capacity and performance are designed for OLTP workloads, not for analyzing terabytes of data with large scans. For this reason, Cloud SQL is not a viable option for direct analysis of external structured files.

Dataproc

Why it fails: Dataproc is a managed service for running Apache Spark, Hadoop, or Flink clusters, and while it can process CSV files using Spark SQL or Hive, it requires provisioning and managing a compute cluster before any query can run. This adds operational overhead and startup time, and it is not an interactive query service like BigQuery. For a company wanting to analyze terabytes of structured data efficiently, Dataproc is overly complex and hence incorrect.

Dataflow

Why it fails: Dataflow is a unified stream and batch processing engine based on Apache Beam, designed for building ETL/ELT pipelines and event processing, not for interactive SQL querying. To analyze terabytes of structured data with standard SQL, a query engine is needed; Dataflow would require writing custom pipeline code to read, transform, and output results, making it unsuitable for ad-hoc analysis. Thus, it is incorrect for this use case.

Coldline

Why it fails: Coldline is a fixed storage class designed for data you expect to access at most once per quarter. It has a 90-day minimum storage duration and charges retrieval and early-deletion fees, so it is not ideal when access patterns are unknown or data may be accessed more often than that. Unlike Autoclass, Coldline does not automatically transition objects to another class based on actual usage, so it cannot optimize cost dynamically.

Standard

Why it fails: Standard is the default storage class for Cloud Storage and is optimized for frequently accessed or hot data. It has no minimum storage duration and no retrieval fees, but it is the most expensive per GB per month, so it is a poor choice for data that is rarely or never accessed. Standard also does not perform any automatic reclassification, so using it for cold data would lock in unnecessary high costs unless you manually manage lifecycle policies.

Nearline

Why it fails: Nearline is a fixed storage class intended for data accessed less than once per month, with a 30-day minimum storage duration and retrieval charges. It does not automatically adapt to changing access patterns, so if the data is accessed more frequently than expected or not at all, you still pay the Nearline rate and potential retrieval costs. Autoclass is superior here because it can automatically place objects into the most appropriate class based on observed access, avoiding the need to pre-guess frequency and tolerate Nearline's fixed constraints.

Cloud Functions

Why it fails: Cloud Functions is the correct answer because it is Google Cloud's event-driven Functions-as-a-Service product: you deploy individual functions that run only in response to triggers, and the platform fully manages servers, scaling, and patches. A monolithic application can be decomposed into smaller functions corresponding to HTTP endpoints or events, and Cloud Functions scales each one automatically and bills only while it executes. This gives the lowest operational overhead of any option, though it suits modular decomposition rather than hosting the entire monolith as a single executable.

Google Kubernetes Engine (GKE)

Why it fails: Google Kubernetes Engine is a managed Kubernetes orchestration service that still requires you to plan and maintain node pools, cluster versions, network policies, and workload autoscaling. For a single monolithic application, GKE adds substantial operational complexity around Kubernetes concepts and infrastructure tuning, so it is overkill unless the company already operates a Kubernetes platform or needs its portability and ecosystem.

Compute Engine

Why it fails: Compute Engine is an Infrastructure-as-a-Service offering that gives you raw virtual machines, with full responsibility for OS patching, security hardening, disk management, and manual autoscaling or load-balancer configuration. Choosing Compute Engine for a monolithic migration means you must manage the underlying infrastructure yourself, which is the opposite of the serverless/minimal-management model implied by the correct answer.

The bucket's IAM policy does not include the service account

Why it fails: Incorrect. If the service account already has the Storage Object Admin role, the bucket's IAM policy is not the cause unless an explicit deny is set. Option A covers the permission issue more directly.

BigQuery

Why it fails: BigQuery is a serverless, columnar analytics data warehouse optimized for running complex SQL queries over huge datasets, but it is explicitly not designed for serving real-time, high-QPS point lookups or time-series reads at the millisecond level. Query execution in BigQuery involves scanning, compiling, and scheduling—even cached results can take hundreds of milliseconds to over a second—so it cannot meet the single-digit millisecond latency required for IoT dashboarding or device fleet operations. Additionally, BigQuery charges per query/scan and has a per-project concurrency limit (e.g., default 50 concurrent interactive queries), making it a poor fit for millions of individual sensor reads, though it could serve as a downstream analytics layer after Bigtable stores raw telemetry.

Cloud Spanner

Why it fails: Cloud Spanner is a horizontally scalable relational database that offers global consistency, ACID transactions, and SQL semantics, but those strengths become liabilities for time-series IoT workloads. Because Spanner is designed for transactional consistency across geographically distributed replicas, it uses a two-phase commit and Paxos-based consensus algorithm, which introduces additional write latency and overhead compared to an eventually consistent or single-region wide-column store. While Spanner can scale to billions of rows, its per-node throughput (hundreds of thousands of QPS, not millions) and the complexity of modelling time-series tuples as relational rows with secondary indexes make it an inefficient and unnecessarily expensive fit; you rarely need cross-row, ACID transactions for independent sensor readings.

Firestore

Why it fails: Firestore is a document-oriented NoSQL database built for mobile and web application development, with a hierarchical data model and real-time sync capabilities via SDKs. Its design assumes relatively low write amplification and is not optimized for append-heavy, high-throughput time-series ingestion; Firestore has documented write limits (e.g., 10,000 writes/second per database) and its query engine is not designed to serve millions of read queries per second with single-digit millisecond latency. For IoT sensor data that arrives continuously at petabytes scale, Firestore's per-entity limits, pricing model, and lack of native time-series compaction make it unsuitable, even though it does support indexes and transactions that an IoT analytics pipeline rarely needs.

Cloud Run

Why it fails: Cloud Run is a serverless compute service, not a GKE mode. The question asks for a GKE mode, so this is incorrect.

Compute Engine with managed instance groups and autoscaling

Why it fails: Compute Engine with managed instance groups is not a GKE mode. The question specifically asks for a GKE mode.

GKE Standard with node auto-provisioning

Why it fails: GKE Standard with node auto-provisioning is a GKE mode but requires more manual management and does not scale as quickly as GKE Autopilot for burst traffic. It also does not scale to zero.

Lift and shift MySQL on Compute Engine and set up replication manually

Why it fails: Lifting and shifting MySQL to Compute Engine forces you to manually configure binary log positions, secure replication over the internet or VPN, and build your own failover/backup systems. This approach is operationally heavy, error-prone, and misses the point of the migration because you still have to patch, monitor, and scale the VM yourself instead of using Cloud SQL's managed high-availability and automated backups.

Export the database to a Cloud Storage bucket and import into Cloud SQL

Why it fails: Exporting to Cloud Storage with mysqldump and importing into Cloud SQL is a one-time bulk copy that requires stopping writes to the source or risking inconsistent data. During the export/import window your application is effectively down, and the process does not support live replication, so it cannot provide the near-continuous sync that a production migration to a transactional database typically demands.

Stream data to BigQuery using Dataflow

Why it fails: BigQuery is a serverless data warehouse designed for analytical queries, not for transactional MySQL workloads—it does not speak the MySQL wire protocol and does not support the same OLTP semantics like row-level locking or ACID transactions. Streaming data into BigQuery via Dataflow would require building custom pipeline logic and still leave you without a Cloud SQL-compatible relational database, so it fundamentally cannot replace the on-premises MySQL instance.

Use Cloud SQL external replication with a Compute Engine instance

Why it fails: External replication to a Compute Engine instance introduces latency from the PostgreSQL streaming protocol over the public internet or a VPN, making it impossible to guarantee an RPO under 5 seconds due to unpredictable network delays. This configuration is tempting because it provides a manual, cross-region replica for read scaling or backup, and would be correct if the RPO requirement were relaxed to minutes or hours.

Deploy a high-availability (HA) configuration within the same region

Why it fails: A Cloud SQL high-availability (HA) configuration uses synchronous replication to a standby in a different zone within the same region. It protects against zonal or instance-level failure, but because the standby lives in the same region, a regional event such as a multi-zone outage or regional service disruption takes down both the primary and the standby. This does not meet a cross-region disaster recovery requirement and provides no failover path to us-west1 or any other region.

Enable automatic backups and point-in-time recovery

Why it fails: Automatic backups and point-in-time recovery are internal data protection features, not a failover or replication mechanism. Cloud SQL daily backups typically have an RPO of up to 24 hours, and point-in-time recovery is bounded by the transaction log retention window, which cannot be shrunk to seconds. Even with log replay, the recovery point is tied to the last completed backup and transaction logs, so it cannot achieve an RPO under five seconds, nor does it automatically redirect traffic to a replica in another region.

Cloud Functions (1st gen) with an HTTP trigger and a Pub/Sub push subscription

Why it fails: This option uses a 1st gen HTTP trigger with a Pub/Sub push subscription, which does allow messages to reach the function as HTTP POST requests, but the fundamental problem is the 1st gen HTTP function timeout is capped at 9 minutes. Because the processing takes 10 minutes, the function execution will be forcibly terminated regardless of the push subscription's own retry mechanisms; the push subscription only redelivers the message, it cannot extend the function's execution time, so every retry will also time out and fail.

Cloud Functions (2nd gen) with an HTTP trigger

Why it fails: A 2nd gen HTTP trigger is not wired to Pub/Sub in an event-driven manner; HTTP functions are invoked by direct HTTP requests, not by Pub/Sub message delivery. To automatically process Pub/Sub messages, the function needs an Eventarc trigger that listens to the Pub/Sub topic and sends the event to the function's event-driven endpoint—an HTTP trigger would require you to manually create a push subscription or write custom polling logic, which is not the native, managed integration Cloud Functions provides for Pub/Sub.

Cloud Functions (1st gen) with a background function and retry on failure

Why it fails: A 1st gen background function with retry enabled still carries the 1st gen maximum timeout of 9 minutes, which is less than the required 10-minute processing time. Retry does not reset or extend the execution deadline; it simply re-invokes the function after a failure, so each attempt will again time out at 9 minutes and continue to fail indefinitely. Background functions in 1st gen also use the same underlying infrastructure as App Engine, which enforces this strict timeout, making the option unsuitable regardless of the retry policy.

Configure Shared VPC to isolate network traffic

Why it fails: Shared VPC lets a host project share VPC networks with service projects, so it is purely a network administration and peering model, not a security control. It does not filter or isolate traffic between specific instances; any instance in the shared VPC can reach another unless separate firewall rules or other mechanisms are applied. Therefore, using Shared VPC alone would not restrict multi-region application traffic.

Delete the default allow rules that allow all traffic

Why it fails: The default VPC firewall rules include an allow rule for all internal traffic within the network, and deleting them would prevent legitimate communication between application tiers rather than restricting unwanted traffic. These default rules do not open traffic to the internet, and removing them would not add a meaningful layer of security. The correct approach is to add explicit deny or allow rules, not to delete the default internal allow rule.

Use Cloud NAT to allow inbound traffic from the internet

Why it fails: Cloud NAT is an outbound-only gateway that enables instances without external IP addresses to reach the internet, so it cannot enable inbound connections from internet clients. Inbound traffic to a multi-region application requires an external load balancer, Cloud Load Balancing, or a VPN, not NAT. Thus, Cloud NAT is not a solution for allowing inbound traffic.

Database Migration Service

Why it fails: Cloud Database Migration Service is designed for relational database engines (e.g., MySQL, PostgreSQL, Oracle, SQL Server) and does not have a connector for MongoDB. Since the source is a 5 TB on-premises MongoDB deployment, DMS cannot read the MongoDB wire protocol or BSON data format, making it inapplicable for this migration.

Cloud Bigtable

Why it fails: Cloud Bigtable is a fully managed wide-column NoSQL database that is not wire-compatible with MongoDB. Migrating would require reshaping BSON documents into column families, rewriting all queries and operational code, and dealing with different consistency and indexing models, so it is not an appropriate target for a like-for-like MongoDB migration.

Configure the HA VPN gateway with two interfaces and use BGP to load balance traffic

Why it fails: HA VPN gateways have two interfaces with separate public IP addresses, which are designed to terminate two independent tunnels to two distinct on-premises public IPs. If the peer gateway exposes only one public IP, you cannot connect both HA VPN interfaces to it in an active/active BGP load-balancing design, because that would require the on-premises device to host two BGP sessions for two different tunnel endpoints using a single IP. The single-IP peer means the second tunnel cannot be terminated, so the two-interface BGP load-balancing configuration is not viable.

Use a Cloud Router with custom route advertisements to the on-premises network

Why it fails: Cloud Router is only the BGP control-plane component for HA VPN; it exchanges routes and applies route priority, but it does not change the physical tunnel endpoint limitation. Custom route advertisements can control which VPC ranges and on-premises prefixes are propagated, yet they have no effect on the number of IP addresses the on-premises VPN peer can use. The peer's single IP prevents two tunnels regardless of what prefixes or BGP attributes Cloud Router advertises, so this option does not address the core problem.

Create a Classic VPN tunnel instead of HA VPN

Why it fails: Classic VPN tunnels are a legacy offering that support only one tunnel per gateway and do not provide the built-in redundancy of HA VPN. Although a Classic VPN could technically connect to a peer with a single IP, the question specifically concerns configuring HA VPN, and replacing it with Classic VPN changes the architecture rather than configuring HA VPN for the peer's constraint. The lack of a second interface avoids the single-IP issue, but it sacrifices the high availability, failover, and service-level objective that HA VPN is meant to provide.