Scenario practice questions

Cloud Scheduler, which triggers a series of jobs at specified cron intervals

Why wrong: Cloud Scheduler is a fully managed cron service that fires a single target (HTTP endpoint, Pub/Sub topic, or App Engine service) on a fixed time schedule. It does not maintain state between invocations, evaluate prior job results, or implement conditional branching such as 'if the build passed, deploy; otherwise notify'. While Cloud Scheduler can trigger a Workflows execution at a set interval, relying on it alone to orchestrate a multi-step CI/CD pipeline would require stitching together many independent schedules and external logic to simulate conditions and error handling, which is exactly what Workflows is designed to do natively.

Cloud Pub/Sub, by publishing messages between pipeline stages to trigger each subsequent step

Why wrong: Cloud Pub/Sub is an asynchronous, durable messaging service that decouples event producers from consumers, enabling fan-out, event-driven architectures, and at-least-once delivery. It can be used to connect pipeline stages via topics and subscriptions, but it has no built-in concept of a 'workflow' — it does not sequence steps, preserve the overall execution state, evaluate intermediate outcomes, or decide the next step based on previous results. Moreover, message ordering is only guaranteed within a single ordered key and retries can cause duplicate messages, so building the described conditional deployment logic on Pub/Sub alone would require substantial custom code (e.g., lock states, idempotency, and a state store). Pub/Sub is a transport layer, not an orchestration engine.

Cloud Run, by writing the orchestration logic as a container application that calls other services sequentially

Why wrong: You could write orchestration logic as a Cloud Run application, but this requires custom code for retry handling, state management, and error recovery that Workflows provides out of the box. Using the purpose-built service is more maintainable.

Private cloud

Why wrong: Private cloud is defined as a cloud environment dedicated exclusively to a single organization, often using on-premises hardware or a hosted private data center with strong isolation guarantees. Google Cloud operates as a multi-tenant public cloud platform where compute and storage resources are shared across many customers, isolated logically rather than physically dedicated. Therefore, using Google Cloud, even with dedicated projects or VPCs, still constitutes public cloud deployment.

Hybrid cloud

Why wrong: A hybrid cloud architecture specifically requires a connection between on-premises or private cloud infrastructure and a public cloud environment. Since the scenario uses only Google Cloud with nothing running in on-premises data centers or a private cloud, the 'hybrid' condition is not met. Without a local workload integrated with the public cloud, the deployment remains purely public, not a blend of two distinct environments.

Community cloud

Why wrong: Community cloud is a multi-tenant infrastructure shared by several organizations that have common regulatory, compliance, or governance requirements, such as multiple government agencies on a shared platform. The ordinary commercial use of Google Cloud does not involve a community of organizations pooling shared infrastructure for a common mission; instead, each customer independently rents public cloud resources. Thus, this is public cloud consumption, not a community cloud arrangement.

Software as a Service (SaaS)

Why wrong: Software as a Service (SaaS) is incorrect because it delivers a complete, ready-to-use application—like Gmail or Salesforce—where the provider owns everything from hardware through the application layer, and the customer only manages user access and data. The scenario in question concerns the provisioning of virtual machines and the customer's ongoing administration of the OS and middleware, which are tasks that never exist in a SaaS model. Since the service being described is raw compute capacity rather than a finished business application, it cannot be classified as SaaS.

Platform as a Service (PaaS)

Why wrong: Platform as a Service (PaaS) is the wrong classification because it supplies a managed application-hosting environment—such as Google App Engine—where the provider handles the underlying OS, runtime, and middleware, while the customer remains responsible for writing and deploying application code. Compute Engine, by contrast, offers raw virtual machines with full customer control over the guest OS, libraries, and middleware, which is a level of infrastructure control that PaaS does not permit. The question describes compute resources where the buyer configures and maintains the operating system, which is the defining responsibility of IaaS, not PaaS.

Function as a Service (FaaS)

Why wrong: Function as a Service (FaaS) is not the correct model because it executes stateless, event-driven functions in a serverless environment, requiring the provider to manage all infrastructure automatically and scale functions per invocation in milliseconds. The described offering gives the customer a persistent virtual machine to install an operating system and run middleware, which is fundamentally different from FaaS's ephemeral function execution and auto-scaling model. FaaS abstracts away the server entirely, whereas the scenario explicitly involves managing the server's OS, so FaaS does not match.

Data warehousing — storing historical data for reporting purposes.

Why wrong: Data warehousing is a technical infrastructure pattern that centralizes and stores historical structured data from operational systems for reporting and analysis, typically using ETL/ELT pipelines and star-schema modeling. While it provides the raw material for analytics, it is not an organizational concept or culture. Becoming data-driven is a behavioral and leadership shift—using evidence to override intuition—and a warehouse supports that shift but does not constitute it.

Business intelligence — creating reports and dashboards.

Why wrong: Business intelligence (BI) refers to the tools and methods used to produce reports, dashboards, and data visualizations that make metrics visible and monitor business performance. While BI is a critical enabler, it remains a presentation layer—dashboards can be built, viewed, and still ignored in favor of seniority or tradition. The concept the question targets is the ongoing discipline of using data as the guiding rationale for decisions, not merely generating visual artifacts.

Data governance — policies for who owns and manages data.

Why wrong: Data governance establishes the policies, standards, and accountability structures for data ownership, quality, access controls, and compliance, often through roles like data stewards and practices like data cataloging and lineage tracking. It ensures that data is reliable, secure, and properly managed, which is a prerequisite for trustworthy analysis, but governance by itself does not embed the habit of decision-making on data. The key distinction is between managing data as an asset and actively leveraging it in every business decision.

The company wants to pay less for cloud services.

Why wrong: Managed private cloud is significantly more expensive than public cloud because you pay for dedicated physical servers, isolated storage, and separate network appliances without sharing the cost across multiple tenants. Public cloud's multi-tenant model spreads infrastructure expenses across many customers, lowering unit costs, whereas private cloud's exclusivity eliminates those economies of scale. Cost reduction is therefore a reason to choose multi-tenant public cloud, not a managed private solution.

The company wants the fastest possible internet speeds for their applications.

Why wrong: Internet speed to end users depends on network architecture, peering, bandwidth, and location—not on whether infrastructure is private or public. In fact, public clouds typically operate massive, globally redundant backbones with advanced Anycast and edge caching that can deliver faster, more consistent connectivity than a single managed private cloud deployment. Choosing a managed private cloud for speed would be a network design mistake; regulatory or security requirements are the correct drivers.

The company has fewer than 10 employees and doesn't need multi-tenant scale.

Why wrong: Company size has no bearing on cloud deployment model. A 10-person company can effectively leverage public cloud's multi-tenant infrastructure, where tenants are isolated logically but share physical resources; conversely, a large enterprise may not need a managed private cloud if compliance permits multi-tenant. The choice is driven by data sensitivity and regulatory mandates, not by employee count or perceived multi-tenant scale requirements.

Cloud Armor, by blocking requests from IP addresses associated with personal devices

Why wrong: Cloud Armor protects applications that sit behind Google Cloud external HTTP(S) load balancers by filtering traffic based on network-layer signals like IPv4/IPv6 ranges, geolocation, and HTTP headers. It cannot inspect whether the client device is enrolled in an endpoint management system or whether it has a verified device certificate because those attributes are not exposed in the network packet. Moreover, personal devices often have dynamic IP addresses or share a NAT address, making IP-based blocking either ineffective or overly broad, and Google Drive itself is not a customer-managed HTTP(S) load-balanced service that Cloud Armor can guard.

Enabling two-factor authentication for all users, which prevents unauthorized access

Why wrong: Two-factor authentication (2FA) verifies the user's identity through a second factor (e.g., TOTP or FIDO2 security key), but it does not inspect the endpoint's enrollment status or risk profile. After a successful 2FA challenge, the authenticated session on an unmanaged personal device retains the same Google Drive permissions as on a company-managed device, so the user can still download files. Google Workspace context-aware access would be needed to evaluate device attributes such as device compliance or certificate presence, which 2FA alone cannot provide.

Encrypting all Google Drive files so they cannot be read on personal devices

Why wrong: Google Drive files are encrypted at rest by Google, but this encryption is transparent to authorized users. An authenticated user can still download and read files on a personal device — encryption doesn't prevent downloads.

Outsourcing — moving work to contractors in lower-cost locations.

Why wrong: Outsourcing is a contractual arrangement where a company transfers specific business functions or tasks to external third-party providers, frequently in lower-cost geographies, to reduce expenses or access specialized expertise. Cloud-enabled remote work, by contrast, retains employees on the organization's payroll while using cloud-based infrastructure (e.g., VDI, SaaS collaboration suites) to let them work from home or other locations. The cloud does not change who performs the work—it only removes the physical constraint, meaning the described capability is about distributed internal work, not external delegation.

Digital transformation — the company is changing its business model.

Why wrong: Digital transformation is an enterprise-wide strategic initiative that uses digital technologies to fundamentally change business models, revenue streams, customer experiences, and operational processes—for example, pivoting from product sales to subscription services. While enabling remote work might be one initiative within a digital transformation program, the scenario specifically describes the operational capability of employees collaborating from disparate locations using cloud tools. The essence here is the location-independent work model itself, not a redefinition of the company's business model or value proposition, so labeling it as digital transformation overstates the scope and misses the concrete mechanism at play.

Automation — replacing human work with AI and robotics.

Why wrong: Automation entails using technologies like robotic process automation (RPA), AI/ML models, or physical robots to execute tasks with little or no human intervention, thereby replacing or augmenting human labor with machine execution. Cloud-enabled remote work, in contrast, relies on human employees who remain central to the work, using cloud platforms for communication, document sharing, and project management to overcome distance. The cloud does not substitute human cognition or effort; it simply provides the connectivity and shared environment that allows employees to perform their existing roles from any location, so describing the capability as automation is conceptually incorrect.

IT infrastructure modernization — replacing on-premises servers with cloud VMs.

Why wrong: This option frames the change as a lift-and-shift infrastructure migration, but the core business transformation is the move from manual, error-prone spreadsheet tracking to a real-time digital platform. Replacing on-premises servers with cloud VMs alone would not generate the 35% customer satisfaction gain; that requires rearchitecting the workflow and data flow, not just the hosting environment. The infrastructure is an enabler, not the transformation itself.

Cost reduction initiative — eliminating the spreadsheet software license fees.

Why wrong: This misinterprets the business case, as spreadsheet license fees are negligible compared to the operational waste from manual data entry and reconciliation. The transformation's measurable impact is a 35% increase in customer satisfaction, which drives retention and revenue, not a marginal reduction in software spend. Cost reduction is not the strategic driver; the strategic driver is differentiating service through instant, accurate tracking information.

Employee productivity transformation — helping logistics coordinators work faster using cloud apps.

Why wrong: While logistics coordinators may work faster, this misidentifies the primary beneficiary of the transformation. The real value lies in the customer-facing outcome: real-time shipment visibility and proactive automated notifications that eliminate the need for customers to call for status updates. Employee productivity is a secondary, internal benefit, not the fundamental change driving higher customer satisfaction and operational efficiency.

A small business whose customers are all located within 10 kilometers of the company's single data center

Why wrong: When all customers are within 10 km of the origin, the round-trip network latency is already sub-millisecond, making the marginal latency reduction from a CDN edge negligible. CDN performance gains come from caching content closer to users who are geographically far away; here, the origin is already 'close enough.' Page load speed in this scenario is more likely limited by server processing, database queries, or front-end rendering, not by network distance. Deploying a CDN would introduce third-party dependency and configuration overhead with virtually no measurable impact on user experience.

A real-time financial trading application that requires unique, uncacheable price data delivered to a single city's traders

Why wrong: A CDN accelerates content by serving cached copies from edge locations near users. Real-time financial price data is unique per request and prohibited from caching, so every query must still travel to the origin server; this creates a cache miss on every request. Because all traders sit in a single city, there is no geographic latency gap for a CDN to close. The extra CDN hop (e.g., TLS termination and routing) would actually add overhead while providing zero performance benefit.

An internal HR system used exclusively by employees in the company's headquarters

Why wrong: Employees at headquarters are already on the same corporate LAN or low-latency private network as the HR application's data center, so the network distance to origin is minimal. CDN edges only help when users are geographically dispersed; here they are not, so catch-serve would add unnecessary third-party hops. Additionally, routing HR data through an external CDN raises data-privacy concerns (e.g., payroll, PII) and egress costs without any latency advantage. An internal system is better served by the existing local infrastructure.

Disaster recovery planning

Why wrong: Disaster recovery planning is concerned with business continuity—defining Recovery Time Objectives (RTOs), Recovery Point Objectives (RPOs), failover procedures, and data replication strategies to restore operations after a disruption. The scenario, however, is about determining which migration strategy applies to each application, not about building resilience for existing systems. Disaster recovery is a separate workstream that may run in parallel, but it does not involve categorizing applications into the 6 Rs.

Capacity planning for on-premises servers

Why wrong: Capacity planning for on-premises servers is fundamentally about forecasting future resource requirements—such as CPU, memory, storage, and network—based on historical utilization, growth trends, and anticipated workloads. While such planning may inform the size of target instances during a rehost or replatform, the scenario describes categorizing applications by migration strategy, not calculating hardware dimensions. This option is wrong because it addresses infrastructure sizing, not the strategic classification of applications for migration.

Software development lifecycle (SDLC) planning

Why wrong: The software development lifecycle (SDLC) describes the stages of creating or modifying software—requirements gathering, design, coding, testing, deployment, and maintenance—typically using models like waterfall or agile. In contrast, cloud migration portfolio assessment evaluates existing applications to decide whether to rehost, replatform, refactor, repurchase, retire, or retain them. This option is wrong because the scenario is about migrating running workloads, not about the iterative process of building new software.

Economies of scale — the cloud provider has more purchasing power than the startup.

Why wrong: Economies of scale let cloud providers purchase hardware, power, and bandwidth at discounted rates, lowering per-unit costs and passing savings to customers. But the startup's bottleneck is not price; it is capital procurement and delivery lead time. The scenario's contrast is between slow physical hardware ordering and immediate self-service provisioning, so reduced unit costs do not account for the difference in time-to-market.

Geographic reach — the cloud provider has data centers in more regions.

Why wrong: Geographic reach is a genuine cloud advantage: with regions worldwide, workloads can be deployed close to end users to reduce latency and meet data-residency requirements. However, that benefit is orthogonal to the scenario's core observation, which is the collapse of procurement from several weeks to minutes. Even a cloud provider with a single region would still let the startup spin up resources instantly, so regional footprint does not explain the two-week versus six-to-eight-week difference.

Reliability — cloud providers have better uptime SLAs than on-premises servers.

Why wrong: Reliability, backed by uptime SLAs and multi-zone redundancy, protects applications once they are running, but it does not determine how quickly resources can be initially created. The startup's timeline problem is about the wait for servers to arrive and be prepared, not about the probability they will stay online afterward. Thus, while a cloud SLA is valuable, it is not the benefit reflected in the speed improvement described.

The company is automating its accounting system using cloud software.

Why wrong: Automating accounting with cloud software (e.g., cloud ERP or SaaS finance tools) addresses the finance function—accounts payable/receivable, ledgers, and reporting—and yields no direct insight into the physical condition or future reliability of manufacturing equipment. The change involves software substitution and workflow automation, not the IoT sensor data pipeline and ML-based prognosis that characterize the predictive maintenance transformation. This is a classic back-office initiative, whereas the described shift is a front-line operational innovation tied to physical asset health.

The company is replacing human maintenance workers with robots.

Why wrong: Replacing human maintenance workers with robots refers to physical automation of inspection or repair tasks, for instance using robotic arms or autonomous mobile robots to perform hands-on work. The predictive maintenance model described does not eliminate human involvement; rather, it equips maintenance crews with data-driven recommendations on which machine to service and when, so they can intervene before a breakdown. The core intent is to augment and inform human decision-making using ML insights, not to substitute labor with robotic hardware.

The factory is migrating its ERP system to the cloud to improve supply chain visibility.

Why wrong: Migrating an ERP system to the cloud aims to integrate finance, procurement, and inventory processes to gain end-to-end supply chain visibility, but it does not involve any sensor telemetry or machine-learning-driven failure prediction. The transformation described in the scenario is specifically about equipment maintenance practices on the factory floor, not about transactional back-office systems. ERP migration is an IT modernization project that can improve planning and traceability, yet it lacks the condition-monitoring and predictive analytics core of the described change.

Company B must have spent more on cloud than Company A, proving that higher cloud investment always produces better outcomes

Why wrong: Investment level is not the differentiating factor. Company A may have spent as much or more on its migration. The type of value created — operational efficiency vs. new customer capabilities — is the differentiator.

Company A made a mistake by moving to cloud; it should have stayed on-premises to avoid disruption

Why wrong: Cloud migration itself was not the mistake; Company A's error was treating the cloud as merely a different data center, lifting-and-shifting existing workloads without rearchitecting anything. Staying on-premises would have preserved legacy constraints like fixed capacity, slow procurement, and limited access to managed services such as auto-scaling and serverless computing, leaving it even less prepared for digital transformation. The disruption came from applying an old operating model to a new platform, not from the move itself.

Company B succeeded because it used a different cloud provider with superior technology

Why wrong: Company B's success cannot be attributed to choosing a 'superior' provider because all major cloud platforms offer comparable compute, storage, and networking primitives; the difference lay in what Company B built on top of its platform. The question contrasts migrating a legacy application (Company A) with creating a new customer-facing capability (Company B), so the architectural intent — not the vendor or brand — determines whether cloud adoption differentiates the business. No provider can automatically confer competitive advantage if the underlying solution is simply the same application hosted elsewhere.

Security

Why wrong: Security is a fundamental operational requirement, but it is not a pricing or payment model. While Google Cloud provides robust security features like encryption, IAM, and VPC firewalls, these are delivered as part of the service and do not define how costs are incurred. The question asks about the financial approach to replacing on-premises infrastructure, and security does not directly address the elimination of upfront hardware investments or usage-based billing.

High availability

Why wrong: High availability is an architectural property that describes a system's ability to remain operational during failures, typically implemented through redundancy across zones or regions. It is a critical service-level advantage of cloud platforms, but it does not change the fundamental cost structure or payment model. The question focuses on how migrating avoids large upfront hardware costs, which is a financial transformation, not an operational resilience characteristic.

Scalability

Why wrong: Scalability refers to the dynamic adjustment of resources to handle variable workloads, such as using managed instance groups to autoscale based on CPU utilization. While this is a valuable operational capability of the cloud, it is about resource management efficiency, not the pricing model itself. Even on-premises systems can be over-provisioned for scale, but the payment model—pay-as-you-go versus upfront capital investment—remains the distinct financial reason for migration, making scalability an incorrect answer.

App Engine Standard

Why wrong: App Engine Standard is a PaaS that only supports language-specific sandboxed runtimes, not arbitrary Docker containers, so your containerized image cannot be deployed as-is. Its scaling model is tied to preconfigured runtime instances rather than request-driven container lifecycle, and it doesn't offer the same port-agnostic, per-request auto-scaling behavior as Cloud Run. For a startup already using containers, rewriting the app to match App Engine's runtime constraints defeats the purpose.

Google Kubernetes Engine

Why wrong: Google Kubernetes Engine requires you to provision and manage a cluster, including node pools, networking, and cluster upgrades, even though the control plane is managed. While cluster autoscaler can reduce nodes during low traffic, it typically cannot scale to zero because system components and kube-system pods still need at least one node, leaving idle cost and operational overhead. For a small startup with sporadic web traffic, this complexity and baseline expense are unnecessary compared to a serverless platform.

Compute Engine

Why wrong: Compute Engine is raw IaaS where you reserve virtual machines, and you are responsible for installing the Docker runtime, patching the OS, and configuring an autoscaling group if you want scaling at all. It never automatically scales to zero—you would have to stop or delete the VM manually, and you would still pay for attached disks and static IPs. Deploying a containerized web app this way introduces substantial manual infrastructure management and idle costs.

Scalability

Why wrong: Cloud scalability technically lets you add or remove compute/storage capacity in minutes to match current load, but it has no bearing on the fact that you own physical servers in a colocation facility that must be replaced at end-of-life. The question describes avoiding a hardware refresh cycle, and elasticity only helps with variable demand, not with aging, deprecated infrastructure that needs capital spending.

Agility

Why wrong: Agility in the cloud (faster provisioning, CI/CD pipelines, and the ability to stand up environments in minutes) is a real benefit, but it does not address the specific pain point of the colocation hardware refresh. Your question is about cost avoidance for replacing physical equipment, while agility is about time-to-market and operational speed, so it is not the primary driver in this scenario.

Innovation (AI/ML access)

Why wrong: Cloud access to AI/ML services, serverless data analytics, and fully managed databases is a strategic advantage that could certainly accompany migration, but it is not why this company is moving given the stated context. The driver here is the financial burden of refreshing colocation hardware, and while innovation features are attractive, they are secondary to the CAPEX-avoidance rationale that the question points to.

Cloud HSM

Why wrong: Cloud HSM provides hardware-backed keys for enhanced cryptographic security, but it is not a prerequisite for key rotation. Cloud KMS can automatically rotate software-generated keys without an HSM, so the absence of an HSM does not hinder key lifecycle management. Moreover, an HSM alone does not address the requirement to track key usage, which is the primary goal here.

Secret Manager

Why wrong: Secret Manager is purpose-built for storing application secrets like passwords, API tokens, and database credentials, not for managing customer-managed encryption keys. While it can store arbitrary sensitive strings, it lacks the cryptographic key versioning and rotation APIs that Cloud KMS provides for integrated encryption with Cloud Storage. Therefore, it is the wrong service for the key rotation requirement.