Hard Difficulty Questions

Removing the VM from the VPC will bypass the organization policy

Why wrong: Removing a VM from a VPC network has no impact on organization policy enforcement because `compute.requireOsLogin` is evaluated based on the project's resource hierarchy, not on network membership. Organization policies are applied to projects and VMs at the project level, and a VM's network is irrelevant to whether OS Login is required. The policy still applies to all VMs in the project, regardless of VPC configuration.

Grant the VM's service account the OS Login Admin role to bypass the policy

Why wrong: Granting the VM's service account the OS Login Admin role does not affect the `compute.requireOsLogin` organization policy. The OS Login Admin role (roles/oslogin.admin) is an IAM role that manages OS Login settings for users, but IAM roles do not override organization policy enforcement. The constraint applies to all VM instances in the project, so the policy remains enforced regardless of the service account's permissions.

Move the project to a folder that doesn't inherit the organization policy

Why wrong: Moving the project to another folder within the organization does not bypass an organization-level policy because organization policies are inherited by all folders and projects below the node where they are set. Unless the new folder contains an explicit policy override that sets `compute.requireOsLogin` to not enforced, the original org-level policy still applies. Since the policy is defined at the organization node, changing folders has no effect on inheritance.

Set min-instances to 0 and max-instances to 1000 with concurrency of 1

Why wrong: Concurrency 1 is inefficient for high concurrency workloads.

Set min-instances to 10 and max-instances to 100 with concurrency of 1

Why wrong: Min 10 keeps instances running even when idle, increasing cost; concurrency 1 is inefficient.

Set min-instances to 1 and max-instances to 100 with concurrency of 1

Why wrong: Concurrency 1 means each instance handles one request at a time, inefficient for high concurrency.

Cloud VPN with multiple tunnels for redundancy

Why wrong: Cloud VPN establishes encrypted IPsec tunnels that carry traffic over the public internet, regardless of how many tunnels you deploy for redundancy. Even with multiple tunnels or higher bandwidth limits, the underlying path includes public internet infrastructure, so the compliance requirement is still violated. Additionally, Cloud VPN typically caps at ~3 Gbps aggregate throughput per gateway, which is insufficient for the required 10 Gbps capacity.

Partner Interconnect via a carrier partner

Why wrong: Partner Interconnect relies on a third-party service provider to extend connectivity from your on-premises network to Google, which means traffic may traverse the provider's shared infrastructure rather than a direct Google-managed link. While it avoids the public internet, it does not meet the same level of isolation and directness as Dedicated Interconnect, and it often requires a carrier agreement and may have variable latency or performance. For a compliance mandate that emphasizes a direct, private circuit, Partner Interconnect is less suitable than Dedicated Interconnect.

Cloud Router with BGP peering over the public internet

Why wrong: Cloud Router is a BGP routing component that exchanges routes dynamically between your VPC and on-premises network, but it does not create any underlying transport. If you attempt to peer BGP over the public internet, the routing protocol itself still runs over public IP space, which violates the stated requirement that no internet-based connectivity be used. Moreover, public BGP sessions are not encrypted natively and expose routing information, making this both a compliance and security failure.

Use the default Logging retention of 30 days

Why wrong: Cloud Logging retains log entries for only 30 days by default (with custom retention options extending up to 3650 days, but still not independent of Logging). For a five-year audit requirement, relying on the default retention guarantees that data access logs older than a month will be permanently deleted. You need a log sink to export to Cloud Storage, where you can apply a bucket retention policy and lifecycle management for long-term archival.

Set up a Cloud Monitoring alert for any Data Access log entries

Why wrong: A Cloud Monitoring alert policy can be set to match Data Access log entries, but its purpose is to trigger notifications when certain events occur, not to store or preserve log data. The alert itself does not create a repository of logs, nor does it affect Logging's retention limits. It may be useful for real-time detection of unusual access, but it cannot substitute for the combination of enabling Data Access logs, exporting via a sink, and securing the destination bucket.

Vertical scaling — Dataflow automatically increases worker machine types under load

Why wrong: Dataflow scales horizontally (adds/removes workers) — it doesn't automatically change machine types (vertical scaling) during a job run.

GKE cluster autoscaler — Dataflow runs on GKE and inherits its autoscaling

Why wrong: Dataflow does not run on GKE — it manages its own worker VM fleet. The GKE autoscaler is irrelevant for Dataflow.

Cloud Monitoring alerting policy that triggers worker additions via gcloud

Why wrong: Manual alerting-based scaling adds latency and is error-prone — Dataflow's built-in autoscaler handles this automatically.

Write transactions to Cloud Spanner; run analytics queries directly against Spanner.

Why wrong: Cloud Spanner is a horizontally scalable NewSQL database optimized for strongly consistent transactional (OLTP) workloads, but its storage and query engine are not designed for complex, petabyte-scale analytical scans. Running large analytical queries directly against Spanner would contend with live transaction traffic, degrading OLTP performance and driving up cost, since Spanner bills per node capacity rather than by query volume. Furthermore, Spanner's row-oriented storage is less efficient for columnar aggregation than BigQuery's columnar design, so achieving 2-second responses on ad-hoc analytics would be unreliable.

Store transactions in Cloud Bigtable and use Dataproc/Spark for analytics queries.

Why wrong: Bigtable is a wide-column NoSQL database designed for high-throughput, low-latency point lookups and scans, not for SQL-based analytical queries. Running Spark on Dataproc to scan Bigtable would require a full table scan and would incur cluster spin-up and job-scheduling overhead, making reliable 2-second ad-hoc query results highly unlikely. Moreover, this pattern requires you to manage and pay for a separate Dataproc cluster, adding operational complexity without providing a serverless query engine comparable to BigQuery.

Use Cloud SQL for storage and Cloud Dataprep for analytics transformations.

Why wrong: Cloud SQL is a managed relational database with fixed CPU/memory/storage limits that cannot sustain a 100 GB/day streaming ingestion rate without manual sharding or frequent maintenance, and its query performance degrades sharply with large analytical scans. Cloud Dataprep is a data preparation UI for cleaning and transforming data, not an analytics/BI query engine, so it cannot execute the low-latency SQL-like queries the requirement demands. This option conflates data wrangling with interactive analytics and fundamentally lacks a scalable analytical storage tier.

The data in Cloud Storage is automatically deleted along with the key.

Why wrong: Destroying a KMS key does not issue any delete command to Cloud Storage. The object's ciphertext stays in the bucket, continues to occupy storage space, and may still incur storage charges. No lifecycle rule or background process removes objects whose wrapping key has been destroyed, so the data is still present — it is simply inaccessible.

Cloud Storage automatically re-encrypts the data using Google-managed keys as a fallback.

Why wrong: Cloud Storage cannot automatically re-encrypt the objects with Google-managed keys because re-encryption requires reading the plaintext, which is impossible once the KMS key is gone. The DEK is wrapped and unreadable without the destroyed key, and Google does not retain a copy of the plaintext or a fallback key that could unwrap an already-wrapped DEK. The entire purpose of customer-managed key destruction is to make any such recovery impossible.

The key enters a 'disabled' state where data can still be decrypted by Google support.

Why wrong: Key destruction is permanent and irreversible, whereas disabling a key is a temporary, reversible administrative action. When a key is destroyed, Cloud KMS deletes the key material immediately, so even Google Support has no access to it and cannot decrypt the data. A disabled key still exists and could be re-enabled, but a destroyed key does not — so this answer mischaracterizes the event as disabling.

Use the Cloud SQL public IP with SSL required — Cloud Run can reach public IPs

Why wrong: Using a Cloud SQL public IP with SSL required is technically reachable from Cloud Run, but it exposes the database to the public internet, creating unnecessary attack surface. Cloud SQL instances configured with only a private IP would have public access disabled altogether, forcing you to rely on firewall or IP allowlists. The built-in Auth Proxy via `--add-cloudsql-instances` provides secure, private connectivity without exposing the database, making it a better practice. Additionally, managing SSL certificates manually for instance connections adds complexity.

Deploy a separate Cloud SQL Auth Proxy container in the same Cloud Run service as a sidecar

Why wrong: Cloud Run (fully managed) runs a single container per instance and does not support sidecar containers natively; only Cloud Run for Anthos permits multiple containers per pod. Deploying a separate Cloud SQL Auth Proxy container in the same service is therefore impossible in standard Cloud Run. Instead, the `--add-cloudsql-instances` flag causes the Cloud Run runtime to embed the Auth Proxy as a process within your container's sandbox, providing the same benefit without an extra container.

Enable Serverless VPC Access connector to route Cloud Run traffic to the private Cloud SQL IP

Why wrong: Enabling Serverless VPC Access connector lets Cloud Run reach resources on a VPC network via internal IPs, but it is not necessary or optimal for Cloud SQL. Cloud SQL uses the Cloud SQL Auth Proxy for authenticated connections, and the built-in `--add-cloudsql-instances` flag automatically handles the proxy and IAM-based authentication. Routing raw private IP traffic through the connector does not provide the same level of database-specific security, and it adds VPC management overhead.

Delete old records from the database to free space — no instance changes needed

Why wrong: Deleting old records merely marks the space as reusable inside PostgreSQL; the disk footprint is not returned to Cloud SQL until a VACUUM (or VACUUM FULL) reclaims it, and even then the filesystem may not shrink. Running heavy delete/VACUUM operations against a production instance consumes I/O and can hold locks, which is slow and risky when the storage is already at 90%. The fastest safe fix is a direct storage increase, not a data cleanup that could take hours and still leave the instance full.

Create a new larger Cloud SQL instance and migrate data with Cloud Database Migration Service

Why wrong: Creating a new instance and migrating with Database Migration Service introduces significant downtime for data synchronisation and cutover, whereas the scenario demands the *fastest safe action*—which is a direct storage resize on the existing instance. This option is tempting because Database Migration Service is designed for zero-downtime migrations between environments, making it correct when moving to a different region or major version upgrade, but here the bottleneck is disk capacity, not architectural change.

Enable automatic storage increase and wait — Cloud SQL will expand the disk retroactively

Why wrong: Enabling automatic storage increase configures Cloud SQL to grow the disk in the future when storage reaches the configured threshold, but it does not retroactively expand an already-full disk. If the instance is currently at 90% capacity with an alert, you still need to perform a manual storage increase to relieve the immediate pressure. This setting is a preventive measure to apply after resizing manually, not a substitute for the immediate fix.

Use a Cloud Scheduler cron job that scans Cloud Storage every minute and processes new files with Dataflow.

Why wrong: A Cloud Scheduler cron job that scans Cloud Storage every minute introduces up to 60 seconds of inherent latency, because a file arriving just after a scan waits until the next poll. It is polling-based, not event-driven, and requires separate bookkeeping to track which blobs have already been processed to avoid duplicates or missing files. Repeatedly listing the bucket also incurs unnecessary API costs and compute time during idle periods, whereas Pub/Sub notifications fire instantly and cost nothing when no files land.

Use Cloud Functions triggered by GCS events to read and transform the 5 GB file directly.

Why wrong: Processing a 5 GB file directly inside a Cloud Function triggered by a GCS event is not viable because of the execution environment's hard limits. Cloud Functions gen1 times out at 9 minutes and gen2 at 60 minutes, with a maximum of 8 GB memory—so loading the entire 5 GB file into memory for transformation is risky and often fails. More fundamentally, a single function instance processes the file serially, whereas Dataflow shards the work across many workers and can easily finish within the 10-minute window.

Use BigQuery Data Transfer Service to load files from Cloud Storage on a schedule.

Why wrong: BigQuery Data Transfer Service is built specifically for scheduled, idempotent loads into BigQuery, not for running custom transformation pipelines. Its minimum schedule interval is 15 minutes, which fails the 10-minute processing requirement, and it cannot execute the custom transformation logic (e.g., data cleanup, enrichment, or schema changes) that the CSV requires. Even though it can read from Cloud Storage, it moves data directly into BigQuery tables and does not support a parallel, pipeline-based processing model like Dataflow.

Enable Cloud SQL high availability; the standby replica will serve read traffic.

Why wrong: Enabling Cloud SQL high availability configures a synchronous standby replica in the same region, but that standby is intended exclusively for automatic failover and cannot serve read traffic. It is a mirror of the primary that stays in a warm standby state; it does not accept connections or queries unless a failover occurs. Since it provides zero additional read capacity during normal operation, it does not address the stated requirement of scaling reads—only a dedicated read replica can do that.

Scale the primary Cloud SQL instance vertically to a larger machine type.

Why wrong: Vertically scaling the primary Cloud SQL instance to a larger machine type increases its CPU, memory, and storage limits, which can temporarily help handle more load. However, this approach has a hard ceiling because all reads and writes still contend on a single instance, and the upgrade often requires a brief maintenance downtime. It also increases cost disproportionately and does not scale horizontally; read replicas, in contrast, distribute SELECT workload across multiple independent instances designed exactly for this pattern.

Migrate from Cloud SQL to Cloud Spanner for unlimited horizontal read scalability.

Why wrong: Migrating to Cloud Spanner would indeed provide near-unlimited horizontal read scaling with global strong consistency, but it is a strategic, long-term architectural change. The migration demands significant effort: redesigning schemas (e.g., interleaved tables, primary key choices), rewriting application code to use Cloud Spanner's client libraries, and adapting to different transaction and consistency semantics. For an immediate read bottleneck, this is an expensive and risky overreaction; Cloud SQL read replicas solve the problem quickly without forcing a full database platform migration.

Admin Activity logs only

Why wrong: Admin Activity logs alone capture only control-plane configuration operations, such as creating a VM or changing a firewall rule, and they omit data-plane API calls that read or write payloads, such as Cloud Storage object downloads or BigQuery table reads. Since the requirement is to audit all API calls, the absence of Data Access logs leaves these data operations completely invisible, so relying solely on Admin Activity logs is insufficient.

VPC Flow Logs + Cloud Monitoring metrics

Why wrong: VPC Flow Logs provide network-level metadata like source and destination IP addresses, ports, and packet counts, but they do not parse or record the content of API requests. Cloud Monitoring metrics aggregate signals such as request latency or error rate, but they also fail to capture individual API call details or who made them. Consequently, this pair can indicate that API traffic occurred but cannot attribute specific API calls to employees, so it fails the audit requirement.

System event logs + Data Access logs

Why wrong: Data Access logs capture employee-initiated read/write operations and payloads, but System event logs record GCP infrastructure actions such as host maintenance or live migration, not user API calls. This pair omits Admin Activity logs, so configuration-changing API calls like IAM changes or resource deletions are never recorded, making the audit trail incomplete for the stated requirement.

IAM deny policies on the organization + VPC Service Controls

Why wrong: IAM deny policies are used to explicitly block specific actions or resources, and VPC Service Controls restrict allowed API calls and data exfiltration within service perimeters, but neither implements a positive constraint on project placement or billing account selection. An IAM deny policy could deny the `resourcemanager.projects.create` permission organization-wide, but that would prevent all project creation and still not allow exceptions for specific approved folders; it cannot express 'allow creation only under folder X'. VPC Service Controls operate at the API layer for services like GCS and BigQuery, not at the resource management API level, so they have no bearing on which billing account is attached to a newly created project.

Cloud Asset Inventory alerts + manual review of new projects

Why wrong: Cloud Asset Inventory is a visibility service that continuously snapshots your resource hierarchy, but it is entirely reactive: it can only flag a non-compliant project after the project already exists in an unapproved folder or linked to a prohibited billing account. Alerts trigger manual review, which is a post-hoc control—by the time a reviewer acts, the project is already provisioned with its own IAM policies and can be used within the organization. It also provides no mechanism to block the project creation call at runtime, so it fails as a preventive guardrail for project placement or billing account usage.

Requiring multi-factor authentication for all project creators

Why wrong: Requiring multi-factor authentication for all project creators strengthens identity verification but does not alter the authorization context under which the project creation API call is made. A user who passes MFA still holds whatever IAM role they have, such as Project Creator at the organization level, so they can still create a project in any folder and attach any billing account they can access—provided the IAM role permits those actions. MFA only proves who is making the request; it does not constrain where the new project lands in the resource hierarchy or which billing account is linked, which are the two specific conditions the security goal requires.

Restart the Cloud SQL instance to clear all connections and queries.

Why wrong: Restarting a Cloud SQL instance forcibly drops all sessions and rolls back transactions, but it only provides a temporary reset: after the instance returns, whichever client or scheduled job reissues those same full-table-scan queries will immediately consume CPU again. It also induces several minutes of complete unavailability, far more disruptive than selectively killing the few problematic backends, and it fails to alter the missing indexes that are the root cause, so the next execution plan still does a Seq Scan.

Increase Cloud SQL's CPU to a larger machine type to handle the current load.

Why wrong: Increasing to a larger machine type can mask the symptom by providing more CPU cores to absorb the poor query plans, but the full table scans still read and filter every row, so the new capacity will quickly be saturated again under the same workload. Vertical scaling also incurs additional cost and potential connection interruption during the reconfiguration, while a simple index addition would lower the per-query cost by orders of magnitude and permanently remove the inefficiency.

Reduce `max_connections` to prevent new connections from adding load.

Why wrong: Lowering max_connections merely caps the number of concurrent sessions, so new legitimate client requests are rejected even though the existing runaway queries continue to consume CPU using the old connections; it does not stop or slow down any query already executing. It also makes the instance less available during high use, and in Cloud SQL a max_connections change may require an instance restart, making the situation worse. The real solution is to terminate the offending queries and add indexes, not to refuse admission to healthy traffic.

Rotate the service account key to generate a new one, keeping the old key active briefly for transition

Why wrong: Rotating the key while keeping the old key active for transition leaves the leaked credential valid during that entire period, which defeats the purpose of containment. In GCP, a proper rotation means creating a new key and immediately deleting the compromised one, not overlapping their validity. Because the leaked key has already been exposed, an attacker can use it to mint access tokens until it is deleted, so the only safe action is to delete the old key right now, then create a replacement key to restore service.

Change the service account's display name and email to invalidate the leaked key

Why wrong: Changing the service account's display name or email is purely a metadata operation that does not affect the underlying cryptographic key material or the key's validity. The leaked key is an RSA private key that remains bound to the service account's ID; it will continue to authenticate as the service account until it is explicitly deleted or rotated. Moreover, the service account's email is immutable and cannot be changed, and an attacker who still holds the key can simply ignore the new display name and keep calling the IAM generateAccessToken API to obtain fresh tokens.

Remove all IAM roles from the service account to deny all actions until the investigation completes

Why wrong: Removing IAM roles from the service account temporarily prevents the key from authorizing actions, but the leaked key still exists and can be used to request OAuth2 tokens whenever roles are re-added. The secret is compromised, not just the permissions; as long as the key remains, it is a credential that an attacker can present to obtain any future access granted to that service account. A proper first response must delete or invalidate the key itself, with IAM role removal as an additional containment measure, not a substitute.

The disk is being used by a snapshot.

Why wrong: A snapshot is an independent backup of a persistent disk's data at a point in time. The existence of a snapshot does not prevent deletion of the underlying disk; you can delete the disk and still keep the snapshot for later restore. In this scenario, no snapshot reference is shown in the exhibit, and even if one existed, it would not be the reason for the deletion failure.

The disk size must be 0 to delete.

Why wrong: The size of a persistent disk is irrelevant to whether it can be deleted. Whether the disk is 10 GB or 10 TB, the delete operation only requires that the disk is not attached to an instance and that you have the appropriate IAM permissions. A disk with data can be deleted just as easily as an empty one, so a zero-size requirement is not a real constraint in Google Cloud.

The disk is not in the correct project.

Why wrong: The project context shown in the exhibit is my-project, and the deletion is attempted from that same project, so the disk is in the correct project. If the disk belonged to a different project, you would not see it here unless you had cross-project permissions, and even then the error would be a permissions issue rather than a wrong-project message. Since the project matches, this is not the cause.

Create three separate VPCs (one per region) and connect them with VPC Network Peering.

Why wrong: VPC Network Peering connects two distinct VPC networks so that their internal IP addresses can communicate, but peering is not transitive and routes are not automatically propagated beyond the peer. To connect three regional VPCs you would need to create three peerings (full mesh) and administer the corresponding route advertisements and firewall rules. In contrast, a single global VPC already gives you regional subnets with automatic routing between them, so peering merely adds operational overhead without any technical advantage.

Set up Cloud VPN tunnels between each pair of regions.

Why wrong: Cloud VPN creates encrypted tunnels between a Google Cloud VPC and an external network such as an on-premises datacenter or another cloud provider. Using it to connect regions inside the same VPC is unnecessary because the VPC already provides connectivity between regional subnets. Moreover, a mesh of VPN tunnels between every region pair adds complexity, latency from encryption, and duplicate management, while providing no benefit over native VPC routing.

Use Cloud Interconnect dedicated connections in each region and configure BGP routing between them.

Why wrong: Cloud Interconnect provides dedicated, high-bandwidth connections between your on-premises network and Google's edge, usually with BGP sessions to exchange routes. It is designed for hybrid cloud scenarios, not for connecting GCP regions to each other. Configuring Interconnect in each region and running BGP between them would bypass the VPC's internal routing and add physical infrastructure costs, while the VPC already handles inter-region traffic over Google's backbone with no extra hardware.

Create a firewall rule in every project blocking outbound traffic on port 80 and 443

Why wrong: Firewall rules govern the flow of traffic over the network—they do not control whether a VM is created with an external IP address. Blocking outbound traffic on ports 80 and 443 might limit some egress internet activity, but the VM could still have a public IP and accept inbound traffic on other ports, or simply be assigned the IP without any traffic flowing. Additionally, managing per-project firewall rules does not scale and leaves gaps if a new project is created without the rule, so it is neither a technical nor an operational fix for preventing external IP assignment.

Remove the Compute Engine Admin role from all project owners

Why wrong: Removing the Compute Engine Admin role from project owners is an over-broad IAM change that cripples legitimate management tasks, such as creating and deleting instances, managing disks, and updating instance metadata. It does not guarantee prevention of external IP assignment, because owners may still have other roles, or they could grant the role back if they have project owner permissions. Furthermore, this does not block existing VMs that already have external IPs, and it breaks normal project administration, making it an incorrect and counterproductive approach.

Use Cloud Armor to block all traffic destined for public IPs in the organization

Why wrong: Cloud Armor is a Web Application Firewall (WAF) that inspects HTTP/HTTPS traffic at Layer 7 and applies security policies to mitigate attacks like OWASP Top 10 and volumetric DDoS. It operates on traffic destined to external IPs and does not prevent the actual assignment of an external IP to a VM—those VMs would still be publicly reachable, just with filtered traffic. The requirement is to keep VMs from having public IPs at all, which is a resource configuration issue that Cloud Armor cannot enforce.

Create a second Cloud VPN tunnel on the existing Cloud VPN gateway to Europe with a new BGP session, and update the on-premises router to accept the new route advertisement.

Why wrong: The existing Cloud VPN gateway is a regional resource in us-central1, so adding a second tunnel through that same gateway to Europe still forces traffic to land in us-central1 before traversing Google's backbone to europe-west1. The new BGP session would also originate from the us-central1 Cloud Router, meaning the on-premises router would keep sending packets to the same US entry point and latency would remain high. This approach fails to establish a local entry point in Europe; you need a gateway physically located in europe-west1 to give on-premises traffic a low-latency path.

Set up VPC Network Peering between the us-central1 and europe-west1 VPCs to allow cross-region communication.

Why wrong: VPC Network Peering creates private connectivity between two VPC networks, not between a VPC and an on-premises network; it cannot replace the IPsec VPN tunnel that the company still needs. Even if the two VPCs were peered, the on-premises router would never learn routes for europe-west1 subnets through peering, because peering is not a BGP-based external connection. This option would only help internal VPC-to-VPC communication and does nothing to move the company's on-premises traffic to europe-west1.

Provision a Dedicated Interconnect connection to europe-west1 and attach a new Cloud Router. Remove the existing Cloud VPN gateway.

Why wrong: Dedicated Interconnect requires physical cross-connects at a GCP co-location facility and typically takes weeks or months to provision, so it is not a quick migration step for 50 stateful instances. More importantly, the proposed action removes the existing Cloud VPN gateway before the new Interconnect is verified, which would immediately cut off connectivity to us-central1 and cause downtime. Even if Interconnect were desirable long-term, it should be provisioned in parallel and the VPN should only be decommissioned after the new path is stable and tested.

Cloud SQL with synchronous read replicas

Why wrong: Cloud SQL supports synchronous read replicas to offload read traffic, but write throughput remains limited to a single primary instance and can only scale vertically by increasing the machine size. For a financial trading platform, write-heavy workloads like incoming orders, trade executions, and balance updates would bottleneck on the primary's CPU, memory, and disk I/O; synchronous replicas also introduce network round-trip latency per write, and the architecture does not provide the horizontal write partitioning or global transaction ordering that Spanner offers.

Cloud Bigtable

Why wrong: Cloud Bigtable is a wide-column NoSQL database designed for high-throughput analytical and time-series workloads, but it does not support SQL queries or full ACID transactions. A financial trading platform requires relational integrity, multi-row atomicity, and consistency guarantees, none of which Bigtable provides; its write path is optimized for append-heavy analytics, not transactional order matching or trade settlement.

Cloud Firestore

Why wrong: Cloud Firestore is a document-oriented NoSQL database that offers strongly consistent reads and writes at the document level, but it lacks SQL query capability and does not provide across-document transaction semantics needed for integrated trading workflows. Its write throughput scales only with the number of documents and is constrained by the per-instance limits; moreover, it is built for mobile and web app data sync, not for the low-latency, high-consistency demands of a financial exchange.