Why Cloud Technology Can Transform Business practice questions

Cloud Spanner

Why wrong: Cloud Spanner is a horizontally scalable, globally distributed relational database that provides strong consistency and high availability at scale. However, its unique architecture requires schema design using interleaved tables, commit timestamps, and different query optimization patterns, which are not directly compatible with an Oracle schema. For a single-region Oracle migration with ordinary transaction volumes, Spanner's per-node costs and operational complexity are far higher than necessary; it is intended for globally distributed or extremely high-throughput workloads, not for a straightforward lift-and-shift.

Bare Metal Solution for Oracle

Why wrong: Bare Metal Solution for Oracle provides dedicated physical servers on Google Cloud to run Oracle workloads, but it does not eliminate or reduce Oracle licensing costs. You are still responsible for obtaining and managing Oracle Database licenses, and you must also handle OS and database administration, patching, and tuning yourself. It is designed for workloads that require full Oracle compatibility or specific performance/security compliance, but it does not achieve the cost savings that an open-source migration would, making it unsuitable for a cost-driven migration away from Oracle.

Compute Engine with a load balancer and instance group update

Why wrong: Google Compute Engine managed instance groups can apply rolling updates by replacing instances via a new instance template, but they are not container orchestrators. Running a containerized app here means you must individually manage the container runtime, image pulls, health checks, and container restarts on each VM. A load balancer only distributes traffic; it cannot coordinate the rollout or rollback of container versions, making updates error-prone and less automated than Kubernetes.

App Engine with automatic scaling

Why wrong: App Engine's automatic scaling adjusts the number of running instances based on incoming traffic, but it does not implement a container-native rolling update strategy. You can switch traffic between service versions, but there is little control over batch size, surge percentages, or health-based promotion, so a problematic code change may get full traffic before you can intervene. Rollback is version traffic re-routing, but it is less granular and not tied to container health signals like GKE's readiness and liveness probes.

Cloud Storage Object holds

Why wrong: Object holds are a data retention feature applied to individual objects in Cloud Storage that temporarily block deletion or replacement of those objects. During bucket replication, especially for dual- or multi-region buckets, an object might be subject to a lifecycle management rule that could delete it before the replica is fully updated. By placing a hold, you guarantee the source object remains intact until replication completes, thus preserving cross-region consistency and preventing permanent data loss.

Cloud CDN

Why wrong: Cloud CDN is a content delivery network that caches static web content at Google's global edge points of presence to reduce latency and improve throughput for end users. However, it does not manage where the origin data is stored, replicate data across storage regions, or enforce data residency constraints. The underlying bucket and its replication configuration remain untouched by CDN, so it cannot satisfy a multi-region storage residency requirement.

Cloud Interconnect

Why wrong: Cloud Interconnect is a service that provides dedicated, high-bandwidth network connections from your on-premises network to Google Cloud privately. It is a network transport mechanism and does not offer any storage, replication, or data-residency capabilities. Configuring Interconnect has no effect on where Cloud Storage objects are physically stored, so it is irrelevant to the need for multi-region data persistence within the EU.

Cloud Interconnect for dedicated connectivity

Why wrong: Cloud Interconnect establishes dedicated, high-bandwidth networking between an on-premises data center and Google Cloud, but it is only a transport mechanism. It offers no data replication, failover, or recovery capabilities on its own, meaning it cannot reduce the on-premises footprint for disaster recovery without additional services; it simply improves connectivity and does not protect against regional or zonal failures.

Preemptible VMs for cost savings

Why wrong: Preemptible VMs are cost-optimized instances that can be terminated by Compute Engine at any time within 24 hours, making them unsuitable for disaster recovery or any stateful workload that requires reliability and availability. Their transient nature means a DR failover could be interrupted mid-recovery, so while they reduce cost, they cannot be the foundation for reducing the on-premises data center footprint without risking recovery SLAs.

Rewrite all applications as cloud-native microservices before migration.

Why wrong: Rewriting all apps is time-consuming and risky; not aligned with minimizing risk.

Migrate everything to Google Kubernetes Engine (GKE) immediately.

Why wrong: Requires containerization of all apps, which may be complex and risky for legacy systems.

Lift and shift all applications to Compute Engine as-is.

Why wrong: Does not modernize applications and may not address scalability or cost optimization.

Preemptible VMs

Why wrong: Preemptible VMs are spot instances that Google can terminate at any moment, with a maximum lifetime of 24 hours. They are engineered for fault-tolerant batch processing, such as data analysis or rendering jobs, not for general-purpose or steady-state workloads. Relying on them to reduce overall TCO would risk unexpected interruptions, forcing re-runs and compromising service availability, so they are not a universal cost-reduction mechanism.

Committed use discounts

Why wrong: Committed use discounts entail a 1- or 3-year contractual commitment to a specific amount of vCPU, memory, and GPU in exchange for steep discounts. They are most effective for predictable, steady-state usage; if the company's variable underutilization is the target, committing could lock it into paying for resources it doesn't need. This inflexibility and the risk of over-commitment make them less suitable for reducing TCO when utilization fluctuates.

Sustained use discounts

Why wrong: Sustained use discounts are automatically applied to Compute Engine resources with no upfront commitment, rewarding monthly usage beyond 25% of the hour-based month with incremental savings up to 30%. Because the discount scales with actual utilization, it aligns perfectly with variable usage, unlike fixed contracts, and directly reduces total cost of ownership for workloads that run a substantial fraction of the month. This makes it the most appropriate option here.

Migrate to Cloud Bigtable

Why wrong: Bigtable is a NoSQL database, not suitable for SQL Server workloads.

Use Cloud Run for database hosting

Why wrong: Cloud Run is a serverless compute platform, not a database service.

Use Database Migration Service (DMS) to migrate to Cloud SQL for MySQL

Why wrong: This would migrate to MySQL, not SQL Server, introducing compatibility issues.

Vertex AI

Why wrong: Vertex AI is wrong for this scenario because it is a full-featured ML platform designed for custom model training, hyperparameter tuning, and deployment, typically requiring users to prepare datasets, choose algorithms, and manage training jobs. The startup's stated need is to use pre-built AI without deep ML knowledge, and Vertex AI's flexibility and control come with a steeper learning curve that contradicts that requirement.

BigQuery ML

Why wrong: BigQuery ML is wrong because it is intended for creating and running ML models using SQL queries over data already stored in BigQuery, not for exposing pre-trained APIs like image recognition. It requires the user to define the model type, input features, and training data, and it does not offer a one-call REST endpoint for tasks such as object detection or image classification, making it unsuitable for a startup seeking out-of-the-box AI.

Migrate to Firestore

Why wrong: Firestore is a NoSQL document database, not suitable for relational workloads.

Use Database Migration Service (DMS) for homogenous migration

Why wrong: DMS only helps with migration, not reduction of licensing costs.

Multi-cloud

Why wrong: Multi-cloud is an architectural strategy that distributes workloads across multiple public cloud providers (e.g., AWS, Azure, Google Cloud) to achieve redundancy, avoid vendor lock-in, or leverage best-of-breed services. While it does outsource infrastructure and thus avoids physical hardware purchases, its primary objective is resilience and flexibility, not CapEx reduction. In fact, managing multiple environments increases operational complexity, egress costs, and security overhead, which can offset financial benefits. Therefore it is not the direct solution to the startup's CapEx reduction goal.

Hybrid cloud

Why wrong: Hybrid cloud combines a private on-premises environment with public cloud services, enabling data and application portability between them. Although this can offload some bursty workloads to the public cloud, the persistent private portion requires the organization to purchase and maintain physical servers, storage, and networking equipment. That unavoidable capital investment means the startup would still incur the CapEx it aims to eliminate. Hence, while offering flexibility, hybrid cloud is not the optimal answer for a pure CapEx reduction strategy.

Private cloud

Why wrong: A private cloud delivers dedicated cloud-like services to a single organization, either on-premises or in a hosted environment. On-premises private cloud demands direct capital expenditure for hardware, power, cooling, and data-center space, exactly what the startup wants to avoid. Even a hosted private cloud often carries fixed, reserved pricing that behaves like a capital commitment, rather than a flexible operational expense. Thus, private cloud is fundamentally incompatible with the goal of reducing capital expenditure on hardware.

Cloud Load Balancing

Why wrong: Cloud Load Balancing provides a single anycast IP and distributes incoming traffic across healthy backend VMs, but it is a traffic-routing layer, not a capacity controller. It does not monitor utilization signals or modify the number of running instances in response to demand. To absorb traffic spikes, it must be paired with a managed instance group autoscaler, so relying on the load balancer alone leaves fixed capacity that can still be overwhelmed.

Cloud Functions

Why wrong: Cloud Functions is a serverless compute platform that automatically scales function instances per incoming event, but it is designed for short-lived, event-driven or synchronous tasks with execution timeouts measured in minutes. A retail website experiencing sustained traffic spikes on VM-based workloads would require stateful sessions, custom binaries, or long-running processes that Cloud Functions does not support. Therefore, while Cloud Functions can offload specific API calls, it cannot replace the autoscaling VM capacity that MIGs provide.

Cloud CDN

Why wrong: Cloud CDN improves responsiveness and reduces origin load by serving cached objects from Google's global edge caches, but it only helps with static or cacheable content such as images, CSS, and JavaScript. It does not modify the underlying compute tier, so uncached or dynamic requests still reach the backend VMs, and the origin's fixed capacity remains a bottleneck if traffic spikes are not cacheable. CDN should be used to reduce the magnitude of traffic reaching the backend, not to scale the backend itself.

Cloud Armor

Why wrong: Cloud Armor is a web application firewall (WAF) and DDoS mitigation service that operates at the edge of Google's network to filter HTTP(S) traffic based on security policies. While it can block malicious requests and volumetric attacks, it does not create an isolation boundary around your data or enforce fine-grained user-level access control to GCP APIs and resources. PCI DSS requires both network segmentation between cardholder data environments and strict access controls, which Cloud Armor alone cannot provide.

Cloud NAT

Why wrong: Cloud NAT (Network Address Translation) allows private VM instances to initiate outbound connections to the internet while preventing unsolicited inbound traffic from reaching them. It is a networking feature that manages egress connectivity, not a security control for isolating sensitive data or enforcing identity-based access policies. Under PCI DSS, you need logical segregation of the cardholder data environment and authenticated, per-user access restrictions; Cloud NAT does not address either of these requirements.

Cloud VPN

Why wrong: Cloud VPN creates an encrypted IPsec tunnel between an on-premises network and a Google Cloud VPC, enabling secure hybrid connectivity. It is a data-in-transit encryption mechanism, but it does not create isolation between workloads inside GCP, nor does it enforce access control policies on GCP resources or APIs. For PCI DSS, you still need separate controls to segment the cardholder data environment and manage user permissions, which Cloud VPN leaves entirely unaddressed.

Cloud Interconnect

Why wrong: Cloud Interconnect creates a dedicated, high-speed connection between your on-premises network and Google Cloud, reducing latency for hybrid cloud traffic by avoiding the public internet. However, it does not cache media content or deliver it from edge locations; it only extends your network path to GCP. For a media streaming company serving global end users, the latency bottleneck is the last-mile delivery from the origin to the user, which Cloud Interconnect cannot address, making it an incorrect choice for this requirement.

Cloud Storage

Why wrong: Cloud Storage is a highly durable object storage service where you can store media files and serve them directly over HTTP. While it can handle large volumes of content, it does not provide any built-in caching at Google's edge locations; each request for a media segment travels over the public internet to the bucket's region, which can introduce significant latency for distant users. It is often used as an origin backend for Cloud CDN, but on its own it fails to reduce user-perceived latency for media streaming.

Cloud Load Balancing

Why wrong: Cloud Load Balancing distributes incoming traffic across multiple backend instances (e.g., VM groups or managed instance groups) based on factors like health, capacity, and proximity, improving scalability and availability. However, it operates only at the forwarding and routing level—it does not cache media content or store it at edge points-of-presence; it simply sends each request to a backend, which remains the single origin. For media streaming, the origin's geographic distance still dictates latency, so load balancing alone does not solve the problem of reducing latency for global users.

Cloud Vision API

Why wrong: Cloud Vision API is built for image comprehension rather than textual analysis; it provides features like optical character recognition (OCR), object detection, and safe-search labeling on images. It does not accept customer text inputs for sentiment or classification and cannot produce a custom model trained on business-specific language, so it is not suited to analyzing textual customer feedback.

Vertex AI

Why wrong: Vertex AI is a comprehensive ML platform that encompasses many tools and services, including custom training and AutoML, and requires the user to construct pipelines, endpoints, and experiment tracking. For a team wanting to simply train a text classification model without heavy ML operations, AutoML Natural Language is the direct, lower-effort path, so Vertex AI as a whole is not the most precise answer.

Cloud Natural Language API

Why wrong: Cloud Natural Language API offers a pre-trained model that readily extracts sentiment, entities, and syntax from text, but it cannot be fine-tuned or re-trained on an organization's own labeled data. If the customers' language or domain is specific, its generic predictions will not match the accuracy of a custom model, and there is no way to adapt its underlying weights.

Cloud IAM

Why wrong: Cloud IAM provides fine-grained access control for Google Cloud resources, allowing you to define who (identity) has access (role) to what (resource) — but it does not generate, rotate, or destroy any encryption key material. To meet HIPAA requirements around key governance, you need a dedicated key management service that can create and manage the lifecycle of the keys used to encrypt stored PHI. While Cloud IAM roles are used to authorize key administrators, the key management itself is outside its scope.

Cloud Data Loss Prevention (DLP)

Why wrong: Cloud Data Loss Prevention (DLP) is a data classification and de-identification service that scans for sensitive patterns such as health data and applies redaction, masking, or tokenization to protect that data at the field level. DLP does not manage encryption keys; when it needs to encrypt data, you must supply a key from an external system like Cloud KMS, but DLP itself cannot create or control the lifecycle of those keys. Thus, while DLP helps discover and protect PHI, it is not the service designed for managing the cryptographic keys that underpin encryption.

Cloud HSM

Why wrong: Cloud HSM provides hardware-backed key storage but does not allow the customer to manage their own encryption keys in the sense of controlling key material lifecycle outside Google’s infrastructure; the correct service for customer-managed keys is Cloud KMS with a customer-managed encryption key (CMEK), which lets the customer create, rotate, and delete keys via Cloud KMS APIs. Cloud HSM is tempting because it offers FIPS 140-2 Level 3 validated hardware security modules for high-security workloads, and would be the correct choice if the requirement were to perform cryptographic operations within a tamper-resistant HSM boundary rather than to manage key material directly.

Use a single non-preemptible VM to ensure completion.

Why wrong: A single non-preemptible n1-standard-8 VM guarantees uninterrupted execution because Google Cloud will not reclaim it, but you pay the full on-demand price for the entire duration, often 60-80% more than preemptible pricing. Since this nightly batch job is inherently fault-tolerant and has a tight completion window, choosing an expensive, always-on VM directly contradicts the requirement for cost optimization, even though it technically ensures the job finishes.

Use the same VM but as preemptible; if preempted, restart the job from scratch.

Why wrong: Preemptible VMs can be terminated by Compute Engine at any time with only a 30-second shutdown notice, regardless of how much progress has been made. Without checkpointing, any preemption forces the job to restart all computation from scratch; if preemption occurs after 40 minutes of the 90-minute window, the total time becomes 40 + 90 = 130 minutes, exceeding the deadline. This option lacks the resumability needed to make preemptible instances viable for a time-bound batch workload.

Use a single preemptible VM with persistent disk snapshots every 10 minutes.

Why wrong: Persistent disk snapshots capture the entire disk state, but taking one every 10 minutes injects heavy I/O overhead and snapshot creation can take time for large disks, eating into the 90-minute window. Worse, recovery requires creating a new disk from the snapshot and booting a new VM, which is not near-instantaneous; you'd also lose up to 10 minutes of work, and any in-memory state would be lost entirely. Application-level checkpointing (e.g., streaming intermediate results to durable object storage) is far more granular and faster to resume than disk snapshots, making this option both slower and less reliable.

Dataproc with Spark SQL

Why wrong: Dataproc with Spark SQL is a managed Apache Spark service that can certainly read from Cloud Storage, but it requires standing up a cluster, configuring autoscaling and cluster policies, and initializing the Spark session before any query can run. This operational overhead makes it a heavier solution than a native SQL interface, and the user would not be working within BigQuery's serverless SQL environment. The question calls for querying data 'across' cloud storage with minimal friction, which Dataproc does not provide as a single SQL interface.

Cloud SQL federated queries

Why wrong: Cloud SQL federated queries allow a Cloud SQL instance to run SELECT statements against data hosted in BigQuery or other MySQL-compatible sources, but they do not turn Cloud SQL into a serverless query engine for raw files in Cloud Storage. You would still need to load the files into Cloud SQL or BigQuery, which defeats the purpose of directly querying cloud storage without loading. The service is also a traditional RDBMS with connection and instance management overhead.

BigQuery Omni

Why wrong: BigQuery Omni is specifically designed for multi-cloud analytics, allowing BigQuery queries to run against data stored in AWS S3 and Azure Blob Storage using the same SQL dialect. It does not apply to Google Cloud Storage, because GCS is already a first-class native storage location for BigQuery and is handled by standard BigQuery tables or external tables. Choosing Omni here would be both unnecessary and incorrect, as it adds cross-cloud connection complexity rather than simplifying direct queries to GCS.

Net zero emissions by 2025

Why wrong: Google's operational net-zero target applies to all its facilities and is explicitly set for 2030, not 2025. Achieving net-zero by 2025 would misrepresent Google's actual decarbonization roadmap, which involves an accelerated reduction of energy-related emissions across data centers and offices within this decade. This claim is therefore incorrect.

Carbon offset program

Why wrong: Carbon offsets are financial instruments that pay for emission reductions elsewhere, rather than physically supplying clean power to Google's own data centers. Google does not buy offsets to claim renewable energy matching; instead, it directly purchases wind and solar energy via long-term PPAs and retires the associated renewable energy certificates. Relying on offsets would not accurately reflect Google's direct investment in renewable generation capacity, making this option incorrect.

Carbon-free energy by 2025

Why wrong: Google's publicly stated ambition is to attain 24/7 carbon-free energy, meaning every hour of every day its grids are powered by carbon-free sources, but this target is set for 2030—not 2025. An intermediate goal or claim of carbon-free energy by 2025 is not substantiated by Google's official sustainability goals. This option conflates the far more ambitious 24/7 objective with a shorter timeline, and is therefore incorrect.

Software licensing for operating systems

Why wrong: Software licensing for operating systems — In GCP, OS licensing is typically bundled into the hourly cost of VM images, so Windows Server or Linux (open-source) usage is already priced into the compute fee. Premium Linux distributions like RHEL or SUSE appear as higher per-hour rates rather than a separate metered charge. As a result, it is a transparent, predictable component of the TCO, not an underappreciated cost.

Cost of physical security for data centers

Why wrong: Cost of physical security for data centers — GCP's data centers employ biometrics, man traps, armed personnel, and continuous monitoring, but these costs are folded into Google's overall infrastructure spend, not billed as a line item. When comparing TCO, customers using public cloud do not pay physical security directly; it is shared across all tenants as part of the pay-as-you-go price. It would appear in an on-premises data center TCO, not a GCP migration TCO.

Cost of electricity for servers

Why wrong: Cost of electricity for servers — In an on-premises environment, power and cooling are major operational expenses, but cloud providers like GCP include them in the fixed infrastructure costs that underpin virtual machine and storage pricing. Customers are billed only for metered usage (vCPU-hours, GB-months, network traffic), so electricity does not appear as a separate charge or utility bill. It is an embedded cost, making it an irrelevant line in a GCP TCO analysis.

Cloud VPN

Why wrong: Cloud VPN establishes encrypted IPsec tunnels between a customer's on-premises network and a Google Cloud VPC, enabling hybrid connectivity. However, it functions purely at the network layer and does not enforce any geographic restrictions on data storage or processing, nor does it provide compliance controls. While it secures data in transit, it cannot constrain where sensitive workloads reside or how their data is accessed, making it unsuitable for meeting regulatory residency requirements.

Cloud NAT

Why wrong: Cloud NAT allows private instances without external IP addresses to make outbound connections to the internet, while still receiving inbound responses, but it does not permit inbound connections. It is a translation service that provides IP source NAT, not a data governance or compliance mechanism. Cloud NAT has no awareness of data sensitivity, geographic jurisdiction, or regulatory requirements, and it cannot enforce data residency or prevent exfiltration.