Google Cloud Products and Services practice questions

Configure Cloud Armor with IP allowlist

Why it fails: Cloud Armor is a web application firewall (WAF) that protects HTTP(S) load-balanced applications by filtering traffic based on rules like IP allowlists or OWASP signatures. However, Cloud Storage buckets are not fronted by HTTP(S) load balancers; they are accessed via the Cloud Storage API or the googleapis.com endpoint. Therefore, Cloud Armor cannot restrict access to Cloud Storage buckets, making this option ineffective for securing stored sensitive data.

Enable VPC Service Controls

Why it fails: VPC Service Controls enables you to build a security perimeter around Google Cloud services, restricting data access based on the originating VPC network, project, or client identity. It helps prevent data exfiltration but does not support IP address conditions; it evaluates context such as the requesting service or network, not the specific source IP. For restricting access to a bucket from a corporate IP range, VPC Service Controls alone is insufficient—it complements but does not replace IP-based IAM conditions.

Configure Cloud NAT

Why it fails: Cloud NAT provides source network address translation for private Compute Engine instances so they can reach the internet without external IP addresses. It is a data-plane gateway that enables outbound communication, not an access control mechanism for inbound requests to Cloud Storage. Configuring Cloud NAT does not restrict who can access your bucket, nor does it affect encryption or IAM policies, so it has no bearing on securing sensitive data at rest.

Firestore

Why it fails: Firestore is a document-oriented NoSQL database optimized for mobile and web applications with hierarchical data, not for high-throughput time-series ingestion. It enforces document size and write-rate limits per document, and its query engine is designed for flexible indexing on moderate datasets, not sustained millions of QPS. Sensor data would quickly hit contention and throttling, and the lack of native time-series row-key patterns forces inefficient composite indexes.

BigQuery

Why it fails: BigQuery is a columnar analytics data warehouse, where query latency is measured in seconds, not milliseconds, because it is optimized for scanning and aggregating massive datasets, not point lookups. Streaming ingestion is eventually consistent and not designed for per-sensor read-after-write access at IoT scale. Using BigQuery for real-time sensor retrieval would incur high cost and unacceptable latency, as its strength lies in batch analysis, not transactional or time-series point queries.

Cloud Spanner

Why it fails: Cloud Spanner is a globally distributed relational database built for strong consistency and ACID transactions, which introduces overhead like distributed Paxos consensus and transaction coordination. These mechanisms guarantee correctness for multi-row transactions but increase read latency and reduce write throughput for simple time-series appends. Its SQL and relational schema also force schema rigidity, making it a poor fit for high-velocity, schema-evolving IoT data where single-digit millisecond point reads are required.

Cloud CDN

Why it fails: Cloud CDN is incorrect because, while it caches static and dynamic content at Google's edge locations to reduce latency and offload origin traffic, it does not provide DDoS protection, rate limiting, or WAF capabilities. CDN can distribute cached content but cannot intelligently route traffic based on health checks or scale compute resources, and any security filtering it offers is typically limited to basic cache-related controls, not comprehensive attack mitigation.

Cloud NAT

Why it fails: Cloud NAT is incorrect because it is designed for outbound-only connectivity, allowing instances with internal IPs to access the internet securely without exposing them to inbound traffic. It does not perform inbound load balancing, DDoS filtering, or WAF inspection, and it cannot terminate HTTP(S) traffic or distribute user requests across a global fleet, making it irrelevant for protecting or scaling a global web application's frontend.

Cloud DNS

Why it fails: Cloud DNS is incorrect because it only translates domain names to IP addresses and manages DNS records, such as A, AAAA, or CNAME records, for routing users to the correct endpoint. It does not inspect HTTP traffic, filter malicious requests, or provide any form of load balancing or DDoS protection at the application layer; relying solely on DNS to protect or scale a global web application would leave it vulnerable to attacks and unable to handle traffic bursts.

BigQuery

Why it fails: BigQuery is an analytical warehouse for large scans and aggregations, returning results in seconds, not single-digit milliseconds per key lookup. It is the right choice for batch analytics and SQL reporting over the sensor history, but it cannot serve millions of point reads per second at that latency.

Cloud Spanner

Why it fails: Cloud Spanner is a horizontally scalable relational database with strong consistency, but its globally synchronised transactional writes and SQL layer cannot deliver single-digit millisecond reads at millions per second for petabyte-scale time-series ingestion. It suits globally distributed OLTP workloads needing ACID transactions across regions — not high-throughput key-value sensor reads, where Bigtable's design applies.

Firestore

Why it fails: Firestore's document model and per-document read scaling cannot sustain millions of reads per second over petabytes of time-series key-value data at single-digit millisecond latency. It is tempting because Firestore excels at mobile and web app synchronisation with real-time listeners and offline support, where flexible document schemas and moderate throughput matter more than raw ingest volume.

Cloud CDN

Why it fails: Cloud CDN is a content delivery network that improves content distribution, not network connectivity, so it does not meet the hybrid cloud networking requirement.

Cloud VPC

Why it fails: Cloud VPC is a logical network within Google Cloud, not a connectivity service between on-premises and cloud, so it is not directly applicable.

Dataflow

Why it fails: Dataflow is for data processing, not for creating dashboards or reports. It is not a BI tool.

Looker

Why it fails: Looker is a paid BI platform that requires a license, so it does not meet the free requirement.

BigQuery

Why it fails: BigQuery is a data warehouse, not a dashboard/reporting tool.

BigQuery

Why it fails: BigQuery is an analytics warehouse optimised for large scans and aggregations, not single-digit millisecond point lookups at millions of reads per second. It tempts because it ingests petabytes of time-series data cheaply, which suits batch analytics rather than high-throughput key-value serving.

Cloud Spanner

Why it fails: Cloud Spanner is a strongly consistent relational database; its globally synchronised transactions add commit and read latency, missing single-digit millisecond key-value throughput. It tempts because it scales horizontally to petabytes and offers high availability, suiting transactional workloads rather than IoT time-series ingestion.

Firestore

Why it fails: Firestore is a document database with per-document read scaling limits and higher-latency queries, so it cannot sustain millions of key-value reads per second at single-digit milliseconds. It tempts because it stores simple schemaless data and scales automatically for mobile and web applications.

Create a Cloud SQL read replica and run analytical queries on the replica

Why it fails: A Cloud SQL read replica maintains a near-real-time, read-only copy of the primary database using asynchronous replication, so analytical reporting queries can be executed against the replica without consuming CPU, memory, or I/O from the transactional primary. This isolates the query load, preserving write and transactional performance, and because replication is continuous, the replica is typically seconds behind, making it suitable for operational dashboards and near-real-time analytics. BigQuery and caching do not provide the same combination of low latency and load isolation for this use case.

Upgrade the primary Cloud SQL instance to a higher machine type

Why it fails: Upgrading the primary instance to a larger machine type increases its available CPU and memory, but it does not separate analytical workloads from the transactional path; the same instance still executes all queries, and a large aggregation or big table scan can saturate resources and contend with writes for locks, buffer pool, and I/O. This approach only delays the problem, scales linearly with cost, and is not a durable solution for predictable performance isolation.

Enable Cloud SQL query caching on the primary instance

Why it fails: Enabling query caching on the primary instance only returns cached results when the exact same SQL query is re-executed, so it does nothing to offload the processing of complex, ad-hoc analytical queries that touch large datasets or use non-deterministic functions. MySQL's query cache was also removed as of MySQL 8.0, so it is not a viable long-term solution on Cloud SQL; even when available, it adds overhead on writes and does not protect the primary from heavy scan workloads.

App Engine Standard environment

Why it fails: App Engine Standard environment is a sandboxed, language-restricted PaaS that only supports a fixed set of languages and specific runtime versions (e.g., Java 11, Python 3.9). It does not permit custom runtimes, Docker containers, or system-level dependencies, making it unsuitable for a web application that requires a custom runtime or native libraries. Its tight integration with Google services and automatic scaling are valuable, but the lack of runtime flexibility makes it the wrong choice here.

App Engine Flexible environment

Why it fails: App Engine Flexible environment is a fully managed PaaS that runs custom containers on Google-managed VMs, allowing you to use any language or system library by supplying your own Dockerfile. It automatically scales, provides load balancing, health checks, and, importantly, supports session affinity, making it well-suited for a traditional web application. Compared to App Engine Standard, it sacrifices some sandbox constraints for greater runtime flexibility, and compared to Cloud Run, it offers a more conventional PaaS experience with persistent instances and connection-oriented features.

Cloud Functions

Why it fails: Cloud Functions is a FaaS (Function-as-a-Service) offering designed for small, event-driven code snippets that run in response to triggers (e.g., HTTP calls, Pub/Sub messages, Cloud Storage events). It imposes strict limits on execution time, memory, and concurrency, and it is inherently stateless, with no support for persistent connections, WebSockets, or session stickiness. As such, it is not capable of hosting a complete, stateful web application, making it an incorrect choice for a continuous web service.

Standard

Why it fails: Standard storage (GCS Standard) is optimized for frequently accessed 'hot' data, with no minimum retention period and no data-retrieval fees. For backup data that is accessed approximately once per year, the higher per-GB storage price makes Standard unnecessarily expensive. Even though retrieval is instant, the ongoing storage cost would exceed that of Archive storage by a wide margin, so it is not the most economical choice.

Nearline

Why it fails: Nearline storage is intended for data accessed less than once a month, carrying a 30-day minimum storage duration and per-GB retrieval fees. For a yearly access pattern, Nearline's per-GB price is significantly higher than Archive storage, so it would overpay for storage that remains mostly idle. Since the backup is rarely touched, the lower monthly cost of Archive storage makes it the better value.

Archive

Why it fails: Archive storage is Google Cloud's lowest-cost storage class for long-term backup and archival data, designed for access less than once a year. It has a 365-day minimum storage duration and charges retrieval fees, but the substantially lower per-GB price minimizes total cost for data retained for years. Although retrieval is not instant like Standard and incurs additional charges, the infrequent yearly restore makes Archive the most cost-effective choice.

BigQuery ML

Why it fails: BigQuery ML enables SQL-based model building for linear regression, binary classification, and other simple algorithms, with training executed on BigQuery's shared infrastructure. However, it does not allow custom neural network architectures or fine-grained control over distributed training, as it abstracts away the underlying cluster. For a bespoke ML model requiring custom layers or multi-node training, BigQuery ML is too constrained.

Cloud Functions

Why it fails: Cloud Functions is an event-driven, serverless compute platform designed for short-lived, single-purpose functions, with generous limits but a maximum runtime of 9 minutes (gen1) or 60 minutes (gen2) and limited GPU support. Custom ML training, especially deep learning, often runs for hours and requires resource-intensive, stateful computation that exceeds these constraints. Thus Cloud Functions is not a practical choice for building or training a large model.

Cloud Run

Why it fails: Cloud Run is a managed serverless container platform that executes stateless HTTP requests, scaling containers from zero and billing by the number of invocation requests. While it can run any binary, it is not designed for long-running, resource-intensive training jobs because it restricts concurrency, has a maximum request timeout, and does not provide the distributed coordination required for multi-machine training. Its typical use case is serving a trained model or running lightweight preprocessing, not model training.

Cloud Functions must be associated with a VPC to access Pub/Sub.

Why it fails: Cloud Functions accesses Pub/Sub through the standard Google Cloud API endpoint, which does not require a VPC. You can add Serverless VPC Connector or Gen 2 VPC egress settings for private networking, but this is optional and only when you want to avoid the public internet. The statement is false because VPC association is not a mandatory prerequisite.

Cloud Functions can run for up to 60 minutes per invocation in all generations.

Why it fails: The maximum invocation timeout for Cloud Functions is 540 seconds (9 minutes), not 60 minutes. Functions that run longer than this limit are terminated and may return an error to the caller. This timeout applies to both background functions and HTTP triggers, and it cannot be set beyond the platform's hard limit.

Cloud Functions can be used to pull messages from a Pub/Sub subscription synchronously.

Why it fails: Cloud Functions uses push subscriptions only, so it cannot synchronously pull messages from a Pub/Sub subscription. Pub/Sub pushes each message to the function's HTTP endpoint immediately after publication. Pull subscriptions require clients to send synchronous pull requests to the Pub/Sub API, which is not the model Cloud Functions implements.

Cloud Run

Why it fails: Cloud Run is a managed serverless platform that runs containers in response to HTTP requests, and its synchronous request-based execution has a 60-minute timeout limit. Large log files often require hours of continuous processing, so a single invocation would time out, forcing you to orchestrate a complex chain of shorter invocations or break the work into many small tasks. That added complexity and the inherent execution ceiling make it less suitable than a simple preemptible VM batch job.

Compute Engine with Sole-tenant nodes

Why it fails: Sole-tenant nodes allocate an entire physical server exclusively to your project, which is used for regulatory, licensing, or data-sovereignty requirements where you need guaranteed isolation from other customers' workloads. They are more expensive than standard instances because you are paying for a dedicated physical machine, regardless of actual utilization, so they provide no cost benefit for a batch job that is tolerant to interruption. The isolation is unnecessary for processing log files, making this option both costlier and operationally heavier.

Compute Engine with standard VMs

Why it fails: Standard VMs are reliable, always-available instances that run at full price and are not interrupted by Google Cloud. For a batch job that can tolerate interruption and is designed to resume, using standard VMs means paying a premium for tenacity that the workload does not require. Preemptible VMs provide the same compute capacity for a fraction of the cost, so standard VMs are an expensive alternative with no added business value in this scenario.

Looker

Why it fails: Looker is an enterprise BI platform, but it requires BigQuery underneath for data storage.

BigQuery

Why it fails: BigQuery can analyze Workspace data if exported, but not directly integrated without ETL.

Dataflow

Why it fails: Dataflow is for data processing pipelines, not ad hoc analysis.

Local SSD

Why it fails: Local SSD is ephemeral and cannot be resized.

Cloud Storage

Why it fails: Cloud Storage is object storage, not block storage.

Filestore

Why it fails: Filestore is a managed NFS file system, not block storage.

Firestore

Why it fails: Firestore is a serverless, document-oriented NoSQL database designed for mobile/web applications with hierarchical, object-like data and real-time sync, not high-ingest time-series. It lacks Bigtable's per-node linear throughput scaling for sustained writes of petabytes of sensor data, and its query model (indexed document collections) is less efficient for wide range scans over timestamp-ordered key designs. Firestore has limits on write throughput per database (though it scales, not to millions of QPS with single-digit ms for this IoT pattern).

BigQuery

Why it fails: BigQuery is a serverless columnar data warehouse optimized for analytical SQL queries over massive datasets, with query latency often in seconds, not milliseconds. It is built for batch and interactive analytics, not for serving hot paths that require single-digit millisecond point lookups or high QPS writes from IoT streams. While it can store petabytes, using it as an operational time-series backend would incur excessive cost/latency; it is better suited to analyzing the data after Bigtable or Pub/Sub ingests it.

Cloud Spanner

Why it fails: Cloud Spanner is a globally distributed relational database that provides strong consistency and ACID transactions across regions, with SQL semantics. That relational/transactional machinery incurs overhead and is misaligned for high-volume, append-heavy time-series workloads that don't need cross-row transactions; single-row key lookups are fast, but sustained millions of QPS of sensor writes with petabytes scale is better served by Bigtable's simpler key-value model. Spanner's horizontal scaling is also more complex to tune and costs more per node than Bigtable for this use case.

Firestore

Why it fails: Firestore is a NoSQL document database, not a relational one, so it lacks the global ACID transactions and SQL querying needed for this platform. While Firestore can be multi-region, its default multi-region mode uses eventual consistency, and even its strong consistency mode is limited to single-region or potentially a specific region for documents, not globally. Furthermore, Firestore's availability SLA (99.99%) falls short of the required 99.999%, so it cannot meet the platform's global consistency and uptime requirements.

Cloud SQL

Why it fails: Cloud SQL is a regional, managed relational database service (MySQL, PostgreSQL, SQL Server) that does not support global replication or multi-writer configurations across continents. Its maximum availability SLA is 99.99% for high-availability configurations, not the 99.999% required, and it cannot maintain strong consistency across geographic regions because it is designed for a single region. This makes it unsuitable for a globally distributed platform.

Bigtable

Why it fails: Bigtable is a NoSQL wide-column key/value store, not a relational database, so it cannot support SQL queries, joins, or multi-row ACID transactions needed for a transactional e-commerce backend. While it offers high scalability, it provides eventual consistency across its replicated clusters unless you choose single-cluster routing, and its availability SLA is 99.99%, below the required 99.999%. It is better suited for time-series or analytical workloads than for global transactional consistency.

Push subscription with retry policy

Why it fails: Push subscriptions can have retry policies but do not natively provide exactly-once delivery; they are at-least-once by default.

Push subscription with acknowledgment deadline extended

Why it fails: Extending acknowledgment deadline prevents premature redelivery but does not guarantee exactly-once.

Pull subscription with a dead letter topic

Why it fails: Dead letter topics handle undeliverable messages, not duplicate prevention.

Google Kubernetes Engine (GKE)

Why it fails: Google Kubernetes Engine (GKE) is a container orchestration platform that requires you to manage the control plane, node pools, and cluster upgrades, which introduces significant operational overhead and contradicts the requirement for no server management. While GKE can certainly run a legacy monolith in containers, the need to handle cluster autoscaling, monitoring, and maintenance makes it heavier than a fully managed platform. For a team migrating away from a monolith and seeking to reduce ops burden, GKE is not the optimal choice.

Cloud Run

Why it fails: Cloud Run is a serverless container platform that executes stateless, request-driven containers and scales aggressively, even to zero, which makes it ideal for individual microservices or event-driven workloads. However, a legacy monolith often holds state in memory, has long-running background processes, or expects persistent connections—patterns that conflict with Cloud Run's per-instance concurrency model and request timeout limits. App Engine Flexible Environment offers a more traditional runtime environment with sustained instance availability, making it a better fit for the monolith than Cloud Run.

Cloud Functions

Why it fails: Cloud Functions is designed for small, single-purpose, event-driven functions that scale instantly and execute in response to triggers, with no server management. A legacy monolithic application by definition consists of many tightly coupled business logic components, database interactions, and UI rendering, which cannot be decomposed into independent functions without significant refactoring. Deploying a monolith to Cloud Functions would require rewriting it as a serverless function, which is neither practical nor aligned with the migration goal of minimal changes.

Use Cloud SQL's Database Migration Service for one-time migration

Why it fails: Cloud SQL's Database Migration Service is designed to move external databases into Cloud SQL, not to alter schema on an already-existing Cloud SQL instance. It performs a one-time data copy with minimal downtime, but it cannot be used to apply DDL changes to an instance that is already the source of truth. For a schema migration on an existing primary, the DMS would not even accept the target as an internal source; it lacks the ability to synchronize ongoing changes from a Cloud SQL primary. Thus, while DMS is a useful migration tool, it is the wrong mechanism for this use case.

Schedule a maintenance window during the migration

Why it fails: Scheduling a maintenance window is a standard operational practice to control when Cloud SQL applies patches or upgrades, but it does not reduce the downtime required for a schema change. During a schema migration, a maintenance window merely ensures that the change happens at a designated time; it does not prevent the primary from being locked or from experiencing availability impact while the schema is altered. A read replica approach is what actually achieves near-zero downtime by offloading the schema change to a separate instance that can failover independently. Therefore, a maintenance window alone is insufficient for minimizing downtime during the migration.