Fundamental Cloud Concepts practice questions

Cloud Spanner

Why wrong: 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 wrong: 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 wrong: 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 wrong: Missing 'GB' and equals sign in flags.

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

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

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: BigQuery is an analytics data warehouse, not a transactional database.

Cloud SQL

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

Cloud Spanner

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

Use a preemptible VM and accept the risk of failure.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Memorystore is a caching layer, not a primary database with strong consistency guarantees.

Cloud Bigtable

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

Cloud SQL

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

Firestore

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: `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 wrong: `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 wrong: This is a manual workaround, not a configuration approach.

Cloud Storage

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Cloud SQL is for relational databases, not suitable for a data lake with unstructured data.

Firestore

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

Cloud Pub/Sub

Why wrong: 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 wrong: 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 wrong: Incorrect. Data Loss Prevention (DLP) API is for inspecting and redacting sensitive data, not for controlling access.

Multi-region deployment

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

Ensure that Google's data centers are guarded 24/7

Why wrong: Physical security of data centers is Google's responsibility, not the customer's.

Implement network segmentation using VPC firewalls

Why wrong: Implementing network segmentation with VPC firewalls is a customer responsibility, but the question asks for three actions; the chosen three are more directly tied to SOC 2 requirements.

Use multi-homing to route traffic to multiple regions

Why wrong: Multi-homing typically uses DNS or BGP advertisements to route user traffic toward a healthy region, but it operates only at the network layer and has no awareness of database transactions. If the primary region’s database becomes unavailable, multi-homing can steer users to another region, yet that region will not contain the replicated data unless a separate data replication mechanism exists. It therefore addresses connectivity resilience, not data durability, leaving a critical gap in the DR plan.

Take periodic snapshots and restore in another region

Why wrong: Periodic snapshots are point-in-time backups that must be transferred and restored before the application can resume service, introducing a target RPO of hours or days and an RTO largely determined by snapshot size and restore speed. Any transaction committed after the last snapshot is permanently lost, so this approach provides crash-consistent recovery rather than a low-latency failover. Snapshots are valuable for long-term retention or as a last line of defense, but they cannot meet the demanding recovery objectives of a true disaster recovery strategy.

Configure a global load balancer with failover

Why wrong: A global load balancer with failover monitors the health of regional backends and can shift user traffic to a different pool when the primary pool fails, but it operates solely at the HTTP, DNS, or even L4 layer and never inspects or coordinates database state. If the primary database goes down, the load balancer will happily route requests to a secondary region whose storage might be stale or absent, because traffic routing and data replication are orthogonal concerns. To be a real DR solution, the load balancer must be paired with a synchronous or asynchronous replication engine; by itself it only provides request routing, not continuity.

Measured service

Why wrong: Measured service is a NIST essential characteristic that focuses on metering and billing. Cloud systems automatically monitor, control, and report resource usage (compute, storage, bandwidth, and active user accounts), enabling pay-per-use and transparency for both provider and consumer. However, this characteristic has nothing to do with the consumer's ability to provision capabilities without human interaction — it addresses how usage is quantified, not how it is requested.

Resource pooling

Why wrong: Resource pooling describes the provider's ability to serve multiple consumers using a multi-tenant model, where physical and virtual resources are dynamically assigned and reassigned according to demand. This gives the appearance of location independence and enables economies of scale, but it is an architectural property of the provider's infrastructure, not a consumer action. The NIST characteristic that defines unilateral self-service provisioning is on-demand self-service, which is about consumer-initiated actions rather than provider-side pooling.

Rapid elasticity

Why wrong: Rapid elasticity is the capability to scale resources outward and inward automatically or manually, quickly, and in some cases elastically to meet variable demand, often appearing unlimited to the consumer. While it enables dynamic workload management, it describes the behavior of the resource allocation after provisioning, not the initial self-service act. On-demand self-service specifically requires that the consumer can provision these resources themselves without any human interaction, which is the defining characteristic in question.