Fundamental Cloud Concepts practice questions

Cloud Spanner

Why it fails: Cloud Spanner is a globally distributed, horizontally scalable relational database that provides external consistency and ACID transactions across regions. That transactional guarantee is expensive and unnecessary for append-only IoT sensor data, and Spanner's synchronous replication protocol adds latency that makes it unsuited to single-digit millisecond reads at millions of QPS. It also lacks Bigtable's native time-series-specific features such as row-key-driven range scans and automatic data compaction for event streams.

BigQuery

Why it fails: BigQuery is a serverless, columnar analytics data warehouse optimized for scanning petabytes of data in one SQL pass, with queries measured in seconds or minutes depending on data volume and slot availability. It is not built for point lookups of individual sensor readings or for the sub-10 millisecond read latency required by real-time IoT dashboards and edge applications. The overhead of executing even a tiny analytical query is far too high for millions of QPS, and its pricing model assumes large analytic scans, not high-frequency key-value access.

Firestore

Why it fails: Firestore is a document-oriented NoSQL database designed primarily for mobile and web applications, with data modeled as collections of documents and real-time synchronization features. Its document model and automatic multi-field indexing create write and read amplification that becomes prohibitive when continuously appending millions of time-series records per second. While Firestore scales for many concurrent users, it does not match Bigtable's ability to perform high-throughput, ordered scans over timestamp-based row keys with single-digit millisecond latency.

gcloud compute instances create my-instance --custom-cpu 6 --custom-memory 20

Why it fails: Missing 'GB' and equals sign in flags.

gcloud compute instances create my-instance --cpu=6 --memory=20GB

Why it fails: The correct flags are --custom-cpu and --custom-memory, not --cpu and --memory.

gcloud compute instances create my-instance --machine-type custom-6-20480

Why it fails: This command uses --machine-type with a custom machine type name (custom-6-20480), which is syntactically correct. However, the question specifically asks for the command that uses the --custom-cpu and --custom-memory flags to define a new custom machine type, making option B the correct choice.

Create a new zonal instance group in europe-west1-a and use a round-robin DNS

Why it fails: A zonal managed instance group in europe-west1-a still represents a single failure domain: if that zone experiences an outage or is unavailable, the application goes down. Round-robin DNS only rotates requests across the instance group's IP addresses—it performs no health checking or latency-aware routing, and it cannot steer users to the least-loaded or nearest healthy instance. To get both regional redundancy and intelligent traffic distribution, the correct architecture is a regional MIG fronted by an external HTTP(S) load balancer.

Keep the instance group in us-central1 but enable Cloud CDN

Why it fails: Cloud CDN primarily caches static objects such as images, CSS, and JavaScript; dynamic application responses are passed through to the origin in us-central1. A web application with session-based or personally identifiable dynamic content will see little cache hit rate improvement, so users in Europe will still experience transatlantic round-trip latency. Moving the compute backend to a European region, not caching at the edge, is what actually reduces network RTT for the dynamic parts of the application.

Move the application to Cloud Run and deploy in europe-west1

Why it fails: Cloud Run is a serverless compute platform that would require the web application to be containerized and modified to handle per-request scaling and statelessness; it is not a drop-in change from a Compute Engine-managed instance group. Even if Cloud Run is deployed in europe-west1, the application must support requests with possible cold starts and environment constraints, and the team would still need a load balancer or HTTPS ingress to route traffic. The stated goal is to improve latency for the existing Compute Engine-based application, so changing the instance group to regional and putting it behind an HTTP(S) load balancer is the lower-risk, directly relevant fix.

Enable object versioning and set a lifecycle rule to delete objects without CMEK

Why it fails: Object versioning and lifecycle rules operate on object generations and age-based or other lifecycle conditions, but they have no reliable way to inspect an object's encryption metadata or key name. Lifecycle management can delete or transition objects based on age, storage class, or labels, but it cannot filter on whether an object uses a specific CMEK, so this approach cannot enforce the policy. Moreover, versioning retains previous versions, which may also lack CMEK, and the rule would be an after-the-fact deletion, allowing a window where non-compliant objects exist.

Use a Cloud Function to scan each object after upload and delete those not encrypted with CMEK

Why it fails: Post-upload scanning with a Cloud Function triggered by object finalize events is a detective and corrective control, not a preventive one. There is a latency window between the upload and the function's deletion action during which a non-compliant object is accessible, and any failure in the function or its permissions could leave sensitive data stored indefinitely. It also adds operational complexity and cost, and is not a substitute for enshrining encryption requirements in the storage policy at the time of the write.

Set the bucket's default encryption to use a CMEK key, and enable the 'Requester Pays' setting

Why it fails: Setting default encryption to a CMEK only applies when the client does not specify an encryption header; a client can still explicitly use a different CMEK key or even a customer-supplied encryption key, bypassing the default. Requester Pays is purely a billing feature that shifts costs from the bucket owner to the requester and has no interaction with encryption enforcement. Together, these settings do not guarantee that every stored object is encrypted with the intended CMEK, so the requirement remains unmet.

Cloud Memorystore

Why it fails: Cloud Memorystore is a fully managed in-memory Redis service that excels at real-time pub/sub messaging and sub-millisecond latency caching. In a chat application, it can maintain ephemeral presence indicators, message queues, and fan-out channels where clients subscribe via Redis pub/sub. However, it is not a durable database; messages still need a persistent store like Firestore, and Memorystore should be considered a complementary accelerator rather than the primary record of conversation.

Cloud SQL

Why it fails: Cloud SQL is a managed relational database that offers single-region deployments and read replicas, but it lacks built-in real-time pub/sub and does not provide low-latency multi-region replication. Chat requests that require real-time updates would instead need to rely on polling or external message brokers, adding complexity and latency. Its synchronous transactional model and connection limits make it poorly suited to the high-frequency, concurrent write patterns of a chat system.

Cloud Datastore

Why it fails: Cloud Datastore is the predecessor to Firestore and inherits a similar NoSQL document model, but it does not support real-time listeners, offline persistence, or automatic multi-region replication. To show new messages in a chat, you would have to implement client-side polling against the datastore, which is inefficient and slow compared to Firestore's push-based updates. Since Firestore is the recommended successor with full real-time capabilities, Datastore is not a viable choice for this build.

Cloud Bigtable

Why it fails: Cloud Bigtable is a wide-column NoSQL database optimized for large-scale analytical and time-series workloads, not for transactional chat messaging with real-time fan-out. It supports extremely high throughput for batch and streaming writes, but it does not offer pub/sub, triggers, or client-side real-time synchronization, and its access patterns are designed for key-based lookups rather than evolving conversations. Pairing Bigtable with a chat app would require building extensive backend infrastructure that Firestore already provides natively.

BigQuery

Why it fails: BigQuery is an analytics data warehouse, not a transactional database.

Cloud SQL

Why it fails: Cloud SQL supports MySQL, PostgreSQL, and SQL Server, not Oracle.

Cloud Spanner

Why it fails: Spanner is globally distributed and not compatible with Oracle SQL syntax.

Use a preemptible VM and accept the risk of failure.

Why it fails: Preemptible VMs are short-lived and can be terminated by Compute Engine at any time (after a 30-second warning) when capacity is needed elsewhere, with a typical maximum lifetime of 24 hours. A once-daily batch job without checkpointing or restart logic has no way to resume from where it left off, so a mid-run termination wastes all compute time and incurs repeat costs for reruns. Accepting this risk for a job that must finish daily is a false economy.

Use a preemptible VM and set a maximum runtime of 2 hours.

Why it fails: Setting a maximum runtime on a preemptible VM only stops the instance after the specified duration; it does not cap, delay, or prevent preemption by Compute Engine, which can kill the VM at any time with a 30-second warning. Preemptible VMs have no guarantee of running even for the configured maximum, so a batch job relying on a 2-hour runtime could be terminated after minutes, losing all progress if no checkpointing is used. The option assumes a maximum runtime provides protection, but it does not address the fundamental ephemerality of preemptible capacity.

Use a standard VM with a sustained use discount.

Why it fails: Sustained use discounts apply automatically to instances that run more than 25% of a billing month, but the discount caps at about 20% for most machine types and requires no upfront commitment. For a daily batch job that runs only a few hours each day, the instance may not accumulate enough monthly usage to qualify for the maximum discount, and even if it does, the savings are significantly smaller than a 1-year committed use discount. Selecting this option leaves cost savings on the table while still using a reliable standard VM.

asia-northeast1 and asia-northeast2

Why it fails: asia-east1 (Taiwan) and asia-northeast1 (Tokyo) are separated by roughly 1,200 miles, which nominally exceeds the 500-mile minimum, but the requirement is specifically about U.S. multi-region deployments, where regional isolation is intended to protect against correlated failures like seismic activity, power-grid outages, or network backbone disruptions that rarely span the Pacific Ocean. These two regions are on different tectonic plates and have independent power grids, so distance alone is not disqualifying, but the question's context assumes a U.S.-based deployment and the expected region pair is within the United States, making this option incorrect for the stated multi-region strategy.

europe-west1 and europe-west4

Why it fails: europe-west1 (Belgium) and europe-west4 (Netherlands) are only about 300 miles apart, which falls below the 500-mile distance threshold generally used to ensure that a single regional disaster, such as a flooding event or a large-scale power failure, does not simultaneously affect both sites. Their geographical proximity means they may share cross-border electricity interconnects and regional network transit paths, so a correlated failure could take down both regions, violating the high-availability requirement for a multi-region deployment. Thus, this pair lacks the independent failure-domain separation needed for a robust disaster-recovery architecture.

us-east1 and us-east4

Why it fails: us-east1 (South Carolina) and us-east4 (Virginia) are both on the U.S. East Coast and are separated by less than 500 miles, specifically about 450 miles. This is below the minimum distance required to achieve meaningful geographic redundancy, because a hurricane, regional grid disturbance, or network outage along the densely interconnected Eastern Seaboard could plausibly impact both regions simultaneously. The proximity also suggests shared backhaul infrastructure and similar regional weather patterns, so this pair does not provide sufficient isolation to meet the organization's recovery-point and recovery-time objectives.

Memorystore

Why it fails: Memorystore is a caching layer, not a primary database with strong consistency guarantees.

Cloud Bigtable

Why it fails: Bigtable is eventually consistent and not designed for multi-region strong consistency.

Cloud SQL

Why it fails: Cloud SQL is not globally distributed; it is regional.

Firestore

Why it fails: Firestore in Native mode provides strong consistency within a region but does not support global distribution across continents with strong consistency; it is not suitable for the stated requirements.

Use preemptible VMs with checkpointing and automatic restarts

Why it fails: Preemptible VMs are up to 60-80% cheaper than standard on-demand instances, making them ideal for a fault-tolerant batch job like nightly transcoding. Because preemptible instances can be terminated at any time within a 24-hour window, implementing checkpointing that writes partial transcoding progress to durable storage, paired with managed instance group automatic restarts, ensures the pipeline resumes without losing completed work. This combination minimizes compute cost while maintaining job completion reliability.

Purchase committed use discounts for 1 year

Why it fails: Committed use discounts require a 1-year or 3-year commitment to pay for a fixed amount of vCPU and memory, which only saves money if the workload runs continuously. A nightly batch that runs only 6 hours per day would leave the committed resources idle for 18 hours, eliminating any potential savings and resulting in a higher effective cost than paying per-second for preemptible usage. This option also lacks the flexibility to adapt to changing pipeline demands.

Use sole-tenant nodes

Why it fails: Sole-tenant nodes dedicate an entire physical server to a single customer, which is designed for workloads that require hardware isolation, compliance, or bring-your-own-license (BYOL) agreements. They do not inherently lower compute costs; instead, they incur per-node billing at a premium over shared infrastructure, so using them for a nightly transcoding batch would increase expenses. The licensing benefits are irrelevant here because the pipeline does not have such isolation or license constraints.

Internal HTTPS Load Balancer

Why it fails: The Internal HTTPS Load Balancer is the correct choice because it is a regional, internal-only load balancer that terminates TLS and routes HTTP/HTTPS traffic to backend instances using private IP addresses. It supports managed SSL certificates and does not require any public internet exposure, perfectly matching the no-public-internet requirement. This makes it ideal for internal web applications that must remain accessible only within the private network.

External SSL Proxy Load Balancer

Why it fails: The External SSL Proxy Load Balancer is incorrect because it is an internet-facing load balancer that uses a public IP address and terminates SSL/TLS for TCP traffic, not HTTP/HTTPS. Even though it handles TLS, its purpose is to expose services to external clients, which violates the no-public-internet constraint. It also does not provide internal-only access, as it is designed to accept traffic from the public internet.

External HTTPS Load Balancer

Why it fails: The External HTTPS Load Balancer is incorrect because it is explicitly internet-facing, with a public IP address and global external endpoint. While it does support HTTPS and TLS termination, its primary use case is serving public web traffic, which directly conflicts with the requirement that the application should not be accessible from the public internet. There are no options to make it operate as an internal load balancer.

Use `depends_on` in the state bucket resource to depend on all other resources

Why it fails: `depends_on` in the state bucket would make Terraform destroy other resources first, which is correct, but the bucket should depend on others, not vice versa. Actually, the bucket should be destroyed last, so it should depend on nothing, but other resources can depend on it. However, explicit dependency is needed.

Use `lifecycle` block with `create_before_destroy = true`

Why it fails: `create_before_destroy` affects create/destroy order for a single resource, not inter-resource order.

Use `terraform state rm` to remove the bucket from state before destroying

Why it fails: This is a manual workaround, not a configuration approach.

Place all resources in the same zone to simplify management

Why it fails: Placing all resources in a single zone may simplify management and reduce inter-zone communication latency, but it creates a single point of failure for the entire application stack. If that zone experiences an outage—due to power, cooling, or network issues—your frontend and database become unavailable simultaneously. Google Cloud's regional services are explicitly designed to survive zone failures, and a single-zone deployment forfeits that built-in availability benefit.

Configure the database as a single large instance with automatic backups

Why it fails: Automatic backups protect against data loss from accidental deletions or corruption, but they do not provide high availability. A single large database instance is a single point of failure; if it crashes or its zone fails, you cannot fail over automatically. Recovery requires restoring from a backup, which results in significant downtime and potential data loss up to the last backup or point-in-time recovery window, making it unsuitable for a production multi-tier application.

Deploy the web frontend in a single zone to reduce network latency

Why it fails: Deploying the web frontend in a single zone might slightly reduce network latency because requests do not traverse a zone boundary, but this gain is minimal—intra-region latency is typically single-digit milliseconds. However, doing so introduces a single point of failure: if that zone experiences an outage, the entire frontend becomes unreachable, even if the database and other tiers remain healthy. The availability risk and potential revenue loss far outweigh any negligible performance benefit.

Cloud Storage

Why it fails: Cloud Storage is an object store designed for batch and archival data. It does not support sub-second query latency or real-time streaming analytics, making it unsuitable for this use case.

Cloud Load Balancing

Why it fails: Cloud Load Balancing distributes incoming HTTP requests across multiple instances, but it does not provide the analytics capability needed. While it can enhance scalability, it is not one of the three core services required for real-time analytics.

Export the Oracle database as CSV files, upload to Cloud Storage, and import into Spanner using Dataflow

Why it fails: Exporting the Oracle database to CSV files and then loading them into Spanner via Dataflow is a batch operation that requires stopping writes to the source database to ensure a consistent snapshot. This approach incurs significant downtime, which directly conflicts with the requirement to minimize downtime. Additionally, it lacks any mechanism for capturing ongoing transactions after the initial export, so it cannot provide continuous replication.

Use gcloud commands to stream data from Oracle to Spanner

Why it fails: There is no gcloud command that can stream data directly from Oracle to Spanner. The gcloud CLI is for managing Google Cloud resources, not for performing database replication or streaming data connectors. This approach is simply not feasible because no such command exists, and it would require a custom-built solution to capture and stream change data.

Use Database Migration Service (DMS) with continuous replication

Why it fails: Database Migration Service (DMS) with continuous replication is the correct choice because DMS offers a fully managed migration path from Oracle to Spanner. It uses change data capture (CDC) to continuously replicate ongoing transactions, ensuring minimal downtime during the cutover. This approach avoids the operational overhead of self-managed tools like GoldenGate and is the native Google Cloud solution for this migration scenario.

Cloud Audit Logs

Why it fails: Cloud Audit Logs record each API request, response, and identity of the caller for Compute Engine operations. They provide a detective, after-the-fact trail that lets you review which VMs were created and by whom, but they do not inspect or reject a VM creation request that violates your label or service-account policies. Audit logs have no decision-making capability and therefore cannot enforce anything; they can only record what happened after the VM exists.

Cloud Asset Inventory

Why it fails: Cloud Asset Inventory continuously snapshots GCP resources, including VM metadata, labels, and service account assignments, and exposes them through the Asset Search API or exports to BigQuery. It is useful for discovering non-compliant VMs that are already deployed, but it does not run in the request path of the Compute Engine API. There is no enforcement mechanism in Cloud Asset Inventory that can prevent a new VM from being created with an unwelcome service account or missing label.

Cloud IAM conditions

Why it fails: Cloud IAM conditions are attribute-based expressions attached to role bindings that limit when a principal is authorized to call a GCP API, such as allowing Read access only to VMs in a specific region or with a particular resource tag. When a caller submits a VM create request, IAM conditions evaluate whether the caller is permitted to invoke the method, but they cannot validate or force the label and service-account values in the request body. IAM conditions govern authorization, not the configuration of the resource being created, so they cannot enforce required labels or service accounts on a new VM.

Cloud SQL

Why it fails: Cloud SQL is for relational databases, not suitable for a data lake with unstructured data.

Firestore

Why it fails: Firestore is a document database for mobile/web apps, not a data lake component.

Cloud Pub/Sub

Why it fails: Pub/Sub is a messaging service for event ingestion, but not for storage or batch processing.

Use gsutil iam to set bucket-level IAM conditions

Why it fails: Incorrect. Setting IAM conditions at the bucket level is done via IAM policies, not directly with the gsutil iam command.

Enable Data Loss Prevention (DLP) API

Why it fails: Incorrect. Data Loss Prevention (DLP) API is for inspecting and redacting sensitive data, not for controlling access.

Multi-region deployment

Why it fails: Multi-region deployment replicates the application to more than one Google Cloud region, providing protection against a complete regional outage. However, the scenario explicitly targets resilience within a single region, so this approach is overkill and introduces significant cross-region data replication latency and cost. It also does nothing to address the specific failure mode of a single zone failing inside the region where the application is primarily hosted.

Cloud CDN

Why it fails: Cloud CDN is a caching layer that stores content at Google's edge points of presence to accelerate delivery to users. It masks some aspects of a backend outage by serving cached static assets, but it cannot execute application logic or fail over to a healthy compute backend. For an application that must remain available, you need redundant compute infrastructure in multiple zones, not edge caching, which does not provide compute-level resilience.

Global load balancing

Why it fails: Global load balancing is a routing layer that uses anycast addresses to send user traffic to the closest healthy backend across multiple regions. While it can reroute to a different region when an entire region goes down, it cannot protect against a zone data-center failure on its own; the backends in that region still need to be multi-zone. If the goal is availability inside one region, enabling global load balancing without zone-redundant backends leaves a single point of failure at the zone level.

Cloud SQL

Why it fails: Cloud SQL is a relational database.

BigQuery

Why it fails: BigQuery is for SQL, not Spark.

Dataflow

Why it fails: Dataflow is for Apache Beam, not Spark.