Planning and Configuring a Cloud Solution practice questions

Committed use discounts

Why wrong: 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 wrong: 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 wrong: 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.

Assign each VM a static external IP address

Why wrong: 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 wrong: Geo-routing is for global load balancing, not necessary for zonal HA.

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

Why wrong: Single-zone does not provide cross-zone HA.

roles/cloudfunctions.invoker

Why wrong: 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 wrong: 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 wrong: 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.

Coldline

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Configure Shared VPC to isolate network traffic

Why wrong: 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 wrong: 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 wrong: 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.

Cloud Run

Why wrong: Cloud Run does not support GPUs.

Cloud Functions with GPU

Why wrong: Cloud Functions does not support GPUs.

Compute Engine with GPUs in a managed instance group

Why wrong: Managed instance groups cannot scale to zero; they have a minimum size of 1.

Cloud Spanner

Why wrong: Spanner is a globally distributed relational database optimised for ACID transactions, not single-digit ms time-series reads at millions of QPS.

BigQuery

Why wrong: BigQuery is an analytics data warehouse with query latency measured in seconds. It is not designed for millisecond lookups at IoT scale.

Firestore

Why wrong: Firestore is a document database suited for mobile/web apps with hierarchical data. It does not scale to millions of QPS for time-series workloads.

Create two classic VPN tunnels from the same gateway to each on-premises gateway

Why wrong: Classic VPN tunnels from the same gateway do not provide high availability because a single gateway is a single point of failure.

Use Cloud VPN with dynamic routing and a single tunnel to each site

Why wrong: Using Cloud VPN with dynamic routing but a single tunnel to each site does not provide redundancy; each tunnel is a single point of failure.

Create one HA VPN gateway with two interfaces in two different regions, each connected to a separate on-premises VPN device

Why wrong: Incorrect. An HA VPN gateway has both interfaces in the same region; it cannot have interfaces in two different regions. For region-level redundancy, two separate HA VPN gateways would be needed.

gcloud storage buckets create gs://my-bucket --location=us-central1 --encryption-key=projects/my-project/locations/us-central1/keyRings/my-ring/cryptoKeys/my-key --versioning

Why wrong: Incorrect. The `--versioning` flag is not a valid flag for `gcloud storage buckets create`; the correct flag is `--enable-versioning`.

gsutil mb -c regional -l us-central1 gs://my-bucket

Why wrong: Incorrect. `gsutil mb` does not support CMEK or versioning flags.

gsutil mb -c regional -l us-central1 --cmek=projects/my-project/locations/us-central1/keyRings/my-ring/cryptoKeys/my-key gs://my-bucket

Why wrong: Incorrect. `gsutil mb` does not support `--cmek` or versioning flags.

The number of Cloud Storage buckets used for data staging

Why wrong: Cloud Storage bucket count does not impact BigQuery slot pricing.

The cost of reserving dedicated hardware for Compute Engine

Why wrong: BigQuery flat-rate slots are unrelated to Compute Engine hardware.

Cloud SQL import

Why wrong: Cloud SQL import requires loading data into a database instance, which incurs costs and management.

Dataproc cluster

Why wrong: Dataproc requires provisioning a cluster; even with preemptible VMs, it adds complexity and cost for a one-time query.

Compute Engine with Apache Spark installed

Why wrong: Requires manual setup and server management; not cost-effective for a one-time query.

StatefulSet

Why wrong: Incorrect. StatefulSet is for stateful applications requiring stable identities, not needed here.

ConfigMap

Why wrong: Incorrect. ConfigMap stores configuration data but is not required for high availability or load balancing.

VPC firewall rules

Why wrong: Firewall rules control traffic but do not provide outbound connectivity without an external IP.

Cloud Load Balancing

Why wrong: Load balancing distributes incoming traffic, not for outbound internet.

Cloud VPN

Why wrong: Cloud VPN is for hybrid connectivity to on-premises networks, not outbound internet.

Google Kubernetes Engine (GKE) Autopilot cluster

Why wrong: GKE Autopilot removes node management but still runs a Kubernetes control plane and bills per vCPU/GiB per pod, not per HTTP request. It can scale down to zero pods only if there is no traffic, but you remain responsible for configuring HPA and maintaining container images, and a single kept-alive pod incurs continuous charges. For a legacy application going serverless, Cloud Run's request-based billing and automatic scale-to-zero make it the superior cost choice for sporadic traffic.

Compute Engine with managed instance groups and autoscaling

Why wrong: Compute Engine with managed instance groups autoscales on utilization metrics but requires you to specify a minimum instance count, operate a health-checked fleet of VMs, and handle OS patching, startup scripts, and instance templates. Even a single idle VM keeps billing per second, so the unpredictable traffic pattern with long idle periods leaves you paying for unused capacity. Unlike Cloud Run, there is no per-request pricing model and no built-in scale-to-zero from HTTP traffic alone.

Google Kubernetes Engine (GKE) Standard cluster with node autoscaling

Why wrong: GKE Standard gives you full control of the cluster but requires you to manage the control plane, nodes, and autoscaling policies, and you pay for the entire node pool even when pods are idle. Node autoscaling cannot shrink below one node, and each node is billed regardless of utilization, so a single request or a long idle period still incurs node-level costs. This operational overhead and idle-node billing make it harder to match the cost profile of a serverless platform for an unpredictable monolithic workload.

Coldline

Why wrong: Coldline is incorrect because it is optimized for data accessed at most once every 90 days (once a quarter), not once a year. While its storage cost is lower than Standard and Nearline, it remains more expensive than Archive and incurs retrieval fees, making it a poor fit for long-term, rarely accessed archives.

Standard

Why wrong: Standard is incorrect because it is designed for frequently accessed, hot data, offering no retrieval fees but the highest storage cost among all classes. Using it for data that is accessed only once a year would be unnecessarily expensive and wasteful, as you would be paying premium rates for storage you rarely touch.

Nearline

Why wrong: Nearline is incorrect because it targets data accessed at most once every 30 days (once a month), not once a year. Its storage cost is lower than Standard but higher than Coldline and Archive, and it also charges retrieval fees, so it does not provide the lowest cost for truly archival, annual-access data.

Balanced persistent disk (pd-balanced)

Why wrong: 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 wrong: 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 wrong: 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.