Why Cloud Technology Can Transform Business practice questions

Cloud Spanner

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

TensorFlow on Compute Engine

Why it fails: TensorFlow on Compute Engine is wrong because it requires your team to manage the entire infrastructure lifecycle. You must provision and maintain VMs, install TensorFlow and CUDA drivers, configure GPU accelerators, implement distributed training logic, and manually monitor job restarts and scaling. While this gives maximum low-level control and flexibility, it contradicts the stated goal of minimizing infrastructure management and demands significant ML engineering expertise.

Cloud Vision API

Why it fails: The Cloud Vision API is wrong because it offers only pre-trained models that perform generic tasks such as label detection, OCR, and safe-search filtering; it cannot be trained or fine-tuned on your own labeled images. The model weights are fixed and shared across all customers, so the API cannot learn your domain-specific categories or custom labels. It is a useful prediction-time tool or a starting point for transfer learning, but it does not provide any capability for custom model training.

Vertex AI Workbench

Why it fails: Vertex AI Workbench is wrong because it is an interactive, notebook-based development environment intended for data scientists who write and run custom training code. Each Workbench instance runs on a Compute Engine VM that you must select, size, and manage, meaning you are still responsible for infrastructure operations. Unlike AutoML's automated training pipeline, Workbench does not offer a low-code or no-code model training workflow; it is a tool for building custom code, not a managed alternative for hands-off training.

Internal Load Balancer

Why it fails: An internal load balancer is a regional, private Layer 4 load balancer that operates only within a Virtual Private Cloud (VPC) network. It does not have a public IP or accept internet-facing traffic, as it is designed to load balance traffic between internal services such as database instances or microservices. Because the company's web application needs to be publicly accessible, this option is not viable.

External HTTPS Load Balancer with backend buckets

Why it fails: The external HTTPS Load Balancer with backend buckets serves content directly from Cloud Storage buckets for static resources such as images, videos, or static HTML. Backend buckets cannot route dynamic requests to Compute Engine instances, and a load balancer configured with a backend bucket would not support the compute engine backend required by the company's web application. Hence, it is inappropriate for this use case even though it is globally accessible.

Network Load Balancer

Why it fails: The Network Load Balancer is a regional Layer 4 load balancer that handles TCP/UDP traffic using a dedicated regional external IP. It does not support cross-region backends or global failover; its backend instance groups must reside in a single region. Since the company requires global failover across regions, this regional-only option does not meet the requirement.

Network egress charges

Why it fails: These are costs incurred when data leaves a cloud provider's network, e.g., per-GB transfer fees. For an on-premises data center, traffic moves over privately owned or leased lines, and there is no per-byte egress metering from a hyperscaler. Therefore, it is not a core component of on-prem TCO, though it is a significant variable in cloud total cost.

Software licensing fees

Why it fails: While software licenses are a real cost, they often follow similar pricing across on-prem and cloud, with cloud-specific options like bring-your-own-license (BYOL). They are not a differentiating cost driver in the TCO comparison; the major differentiators are infrastructure capital and operational expenses like hardware, staff, and facilities. Licensing costs would be included but are roughly equivalent, so they don't change the decision.

Preemptible VMs

Why it fails: 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 it fails: 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 it fails: 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 it fails: Bigtable is a NoSQL database, not suitable for SQL Server workloads.

Use Cloud Run for database hosting

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

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

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

Vertex AI

Why it fails: 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 it fails: 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 it fails: Firestore is a NoSQL document database, not suitable for relational workloads.

Use Database Migration Service (DMS) for homogenous migration

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

Multi-cloud

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.