Select Two (Multi-Select) Questions

Use Storage Transfer Service to replicate data to a secured bucket.

Why wrong: Storage Transfer Service is designed to move or replicate objects between buckets, from on-premises, or from other clouds. Replicating customer data to a 'secured' bucket does not impose any new restrictions on who may access the original bucket, nor does it generate audit records for those access attempts. It changes the data's location, not the identity- or attribute-based authorization policy that determines access. Therefore, while it may support resilience, it is not a security control for restricting access.

Set up Private Google Access to restrict access to the bucket.

Why wrong: Private Google Access is a network configuration that allows VM instances without an external IP address, or on-premises hosts using Cloud Interconnect, to reach Google APIs and Cloud Storage through internal or private IPs. It changes the network path used to access a bucket, but it does not authenticate individual users or enforce bucket-level permissions. Any IAM permission granted to a user is still honored over this private connection, so it cannot 'restrict access' in the sense of blocking specific people or conditions. It also produces no access logs for user actions.

Enable default encryption on all buckets using CMEK.

Why wrong: Default encryption with Cloud KMS CMEK encrypts all data at rest in the bucket using a customer-managed key, protecting against physical exfiltration and meeting key-management compliance requirements. However, encryption is a confidentiality control independent of authorization: a user with Storage Object Viewer or Admin permission can still list and read cleartext data regardless of which key was used for encryption. It does not restrict who attempts access, does not create audit logs of access events, and does not enforce time/IP conditions. Encryption and access control are complementary layers, not substitutes.

Physical security of data centers

Why wrong: Physical security of data centers is a baseline requirement for any reputable cloud provider, but it is not a transformative business benefit. Under the shared responsibility model, the provider is responsible for protecting the physical infrastructure—such as servers, storage, and networking hardware—but this is table stakes, not a capability that enables agility or innovation. Customers gaining access to a secure facility is expected and does not change how they build or scale applications, making it a prerequisite rather than a key benefit.

Data locality to keep data within national borders

Why wrong: Data locality, the ability to keep data within specific national borders to meet regulatory requirements, is a compliance consideration rather than a transformation benefit. While cloud providers offer regional data centers and data residency options to help organizations satisfy legal obligations like GDPR or data sovereignty laws, this is a constraint-driven feature, not one that provides competitive advantage or operational efficiency. In fact, data locality restrictions can limit performance and redundancy options, so unlike elasticity or managed services, it is not a universally desirable trait.

Ability to purchase reserved instances for predictable workloads

Why wrong: Purchasing reserved instances is a pricing model that offers discounted rates in exchange for a commitment to use a certain amount of capacity over one or three years, but it does not alter the fundamental capabilities of cloud technology. Reserved instances are a financial instrument for predictable workloads, enabling cost savings, but they do not provide scalability, management assistance, or any architectural advantage. Since this is purely a billing optimization, it does not represent a key benefit of cloud computing in the same way elasticity or managed services do.

Cloud Profiler

Why wrong: Cloud Profiler is a continuous profiling service that captures CPU and memory usage data for running applications, identifying which functions consume the most resources and are the main performance bottlenecks. It is designed for deep code-level performance tuning and optimization, not for general health monitoring. It does not provide uptime checks, alerting, or overall system health dashboards, so it cannot serve as a standalone monitoring solution for health and performance.

Cloud Debugger

Why wrong: Cloud Debugger allows you to inspect the exact state of a running application at a specific point in the code without pausing or stopping it, which is invaluable for diagnosing production bugs and understanding runtime variables. However, it is an interactive troubleshooting tool, not a monitoring service: it does not continuously collect metrics, track uptime, or generate alerts. Its transient, on-demand nature makes it inappropriate for ongoing health and performance monitoring.

Cloud Trace

Why wrong: Cloud Trace is a distributed tracing service that captures latency data for individual requests as they travel through microservices, helping you visualize where time is spent and identify performance bottlenecks in end-to-end request paths. It is extremely useful for analyzing request latency and optimizing service interactions, but it is not a general health monitoring tool: it lacks infrastructure metrics, uptime checks, and broad alerting capabilities. Cloud Trace is most appropriately used as a specialized tool for latency investigations, not as the primary mechanism for monitoring overall health and performance.

Cloud Scheduler

Why wrong: Cloud Scheduler is a fully managed cron service that invokes jobs on a defined schedule, such as HTTP endpoints or Pub/Sub topics. It does not ingest billing data, evaluate spend thresholds, or emit budget alerts, so it cannot be used to monitor cloud spending or receive cost-related notifications. It is designed for job orchestration, not cost governance.

Cloud Asset Inventory

Why wrong: Cloud Asset Inventory captures a historical record of your cloud resources, their metadata, IAM policies, and resource relationships. It provides visibility into asset configuration and changes but does not collect or analyze billing or cost data, nor does it support threshold-based notification on spending. Consequently, it cannot help monitor GCP costs.

Cloud Logging

Why wrong: Cloud Logging stores and enables searching of application, security, and audit logs, including billing logs if you export them. However, it does not natively track budget consumption or send proactive budget alerts; any budget monitoring would require custom log-based metrics and separate alerting policies, making it an indirect and complex solution for spend alerts.

Query logs using Logging Query Language

Why wrong: Logging Query Language is a filtering and querying syntax used in Cloud Logging to search and analyze log entries, not a mechanism for collecting or evaluating metric data. While logs and metrics can be correlated through logs-based metrics, the query language itself operates on log records, not on the time-series data managed by Cloud Monitoring. Therefore, using it would address log analysis, not metric collection or alerting.

Automatically remediate incidents with Cloud Functions

Why wrong: Cloud Functions can be used to automate incident response, but only as an external webhook target configured within an alerting policy's notification channel. Cloud Monitoring itself does not directly invoke or orchestrate remediation; it only sends notifications to channels such as HTTPS webhooks. Thus, automatic remediation with Cloud Functions is a downstream integration you build, not a built-in capability of the Monitoring service.

Access Transparency

Why wrong: Access Transparency logs administrative actions taken by Google personnel and provides read-only audit logs to customers, but it does not inspect data flows or implement any blocking controls. Its purpose is operational accountability, not preventing data exfiltration—it records what happened after the fact rather than stopping sensitive data from leaving your environment.

Security Command Center

Why wrong: Security Command Center (SCC) is a security and risk management platform that aggregates findings, detects vulnerabilities, and flags misconfigurations across GCP, helping you identify suspicious activity. However, it operates as a monitoring and alerting tool; it does not enforce policy or mediate data transfers, so it cannot actively prevent exfiltration, only signal potential risks for manual remediation.

Cloud Armor

Why wrong: Cloud Armor is a web application firewall and DDoS protection service that filters requests based on IP, geolocation, and custom rules at the edge of your load balancers. It is designed to block malicious HTTP/S traffic from reaching your apps, but it has no insight into data content or storage egress, and therefore cannot prevent sensitive data from being copied out of GCP services like Cloud Storage or BigQuery.

Set up VPC Service Controls to restrict access to the production VPC.

Why wrong: VPC Service Controls builds a security perimeter that restricts data movement to and from Google-managed services, preventing data exfiltration; it does not govern instance attributes such as labels or external IP ranges. Therefore, it cannot enforce either the labeling requirement or the no-public-IP rule.

Create a folder for each environment and apply the label automatically using a Cloud Function triggered by Resource Manager events.

Why wrong: This approach is reactive, not preventive: a Cloud Function triggers only after an instance is created, so an unlabeled instance exists in the interim and the label is added post-creation. It also depends on the function's reliability and cannot guarantee that every instance gets the label, especially if the event is missed or the function fails.

Enable node auto-repair to automatically fix security vulnerabilities in nodes

Why wrong: Node auto-repair is a GKE feature that monitors node health and recreates nodes that fail repeated health checks, such as those with disk problems, memory pressure, or unreachable kubelet. It does not patch OS kernels or apply security updates; instead, node auto-upgrade is the mechanism that brings nodes to the current security patched version. Relying on auto-repair for vulnerability fixes is a misconception that leaves known CVEs unpatched.

Expose the cluster control plane via a public endpoint to allow monitoring

Why wrong: Making the Kubernetes control plane publicly reachable exposes several attack surfaces, including the API server kubelet authorization and the webhook admission chain, to arbitrary internet traffic. Even with RBAC enabled, anonymous port scan and potential zero-day exploitation become far more likely, and you lose the ability to strictly limit who can attempt to reach the management plane. A private control plane endpoint, coupled with VPC peering or Cloud VPN, allows the same monitoring access while staying off the public internet.

Memorystore

Why wrong: Memorystore is an in-memory data store (Redis/Memcached) that provides microsecond latency but does not persist data by default; it is used for caching session data or frequently accessed objects, not as a durable system of record. Relying on it as the primary store risks data loss on failure or restarts, so it cannot replace a persistent database for user profiles. It complements Firestore or Bigtable by caching reads, but is wrong as the sole storage layer.

Cloud Spanner

Why wrong: Cloud Spanner is a horizontally scalable relational database that offers strong consistency, ACID transactions, and SQL at global scale. For a startup storing simple user profiles, it requires predefined schemas, fixed columns, and higher cost per node, making it overkill and more expensive than necessary. While it supports high scalability, its complexity and operational overhead are not justified for lightweight, unstructured mobile app data.

Cloud SQL

Why wrong: Cloud SQL uses a relational schema requiring predefined tables and fixed columns, which prevents the storage of unstructured data without constant migrations. It is an ideal selection for applications requiring ACID compliance and complex joins on structured datasets, such as financial transaction systems or ERP software where data integrity and relational consistency are paramount.

Sole-tenant nodes

Why wrong: Sole-tenant nodes do not reduce compute costs; they are dedicated physical servers that isolate your VM instances for compliance or licensing reasons. You pay a premium for the entire node even if it's underutilized, making them more expensive than regular instances, so they are unsuitable for a cost-reduction initiative.

Committed use discounts

Why wrong: Committed use discounts (CUDs) require a contract to pay for a fixed amount of vCPUs, memory, or GPUs for 1 or 3 years in exchange for up to 70% off on-demand pricing. They are designed for predictable, steady-state workloads, not for batch jobs with varying durations, because you are committed to paying for resources you may not fully use, which does not align with intermittent cost savings.

Sustained use discounts

Why wrong: Sustained use discounts (SUDs) are automatically applied to instances that run for more than 25% of the month, increasing incrementally up to 30% off. However, batch jobs that are short-lived, sporadic, or terminated early may not accumulate enough monthly utilization to trigger the discount, so they provide unreliable savings for the described need.

Apply a deny IAM policy to each project individually

Why wrong: Applying a deny IAM policy to each project individually is not effective because deny policies are evaluated per resource and are not inherited across projects; you would need to configure and maintain each project separately, leading to inconsistent coverage if a new project is created or a policy is missed. Moreover, IAM policies, including deny policies, are designed to control who can perform actions, not to restrict resource configurations such as whether a VM is allowed to have an external IP. This approach is operationally fragile and does not provide the centralized, inherited enforcement that an organization policy constraint offers.

Set a quota for external IP addresses per project

Why wrong: Setting a quota for external IP addresses per project is an incorrect solution because quotas only limit the maximum number of a resource that can be created, not whether the resource is allowed at all. Users can still assign a single external IP to a VM, and they might request quota increases, which defeats the intended blanket restriction. A quota also does not prevent a VM from being created with an external IP; it only caps the count, so it is not a suitable substitute for an organization policy constraint that explicitly denies external IP assignment.

Use network tags to block external IPs

Why wrong: Network tags are not a mechanism for controlling whether a VM gets an external IP; they are primarily used for applying firewall rules and for logically grouping VM instances for network policy decisions. Tags cannot be used to block or restrict the assignment of an external IP address because the existence of an external IP is a property of the VM's network interface, not a traffic rule. Firewall rules associated with tags can only filter network traffic, not alter the IP configuration of the VM, so this option is fundamentally mismatched to the requirement.

Set up a Pub/Sub topic for billing alerts

Why wrong: Setting up a Pub/Sub topic for billing alerts is an optional integration for programmatic alert delivery, but it doesn't create a budget or thresholds itself; without a budget, the topic remains idle. Budget alerts natively support email and provide the option to publish to Pub/Sub, so creating a separate topic is a redundant or supplementary step, not a primary action for cost control.

Activate the Cost Management dashboard

Why wrong: Activating the Cost Management dashboard merely enables a visualization interface in the Cloud Billing console; it's a passive tool that presents cost data but does not enforce thresholds, send alerts, or allow custom SQL queries. The dashboard requires no threshold configuration and is intended for monitoring, not for automated control, making it an ineffective response to a question about implementing cost controls with alerts.

Enable billing export to Cloud Storage

Why wrong: Enabling billing export to Cloud Storage writes detailed billing files (CSV/JSON) that are useful for long-term retention and batch processing, but it does not support direct SQL querying or interactive analysis. To analyze the data, you'd need to load it into BigQuery or run separate pipelines, and it provides no alerting or threshold-based control, so it only partially serves the analysis need.

Create a separate billing account for each project

Why wrong: Creating a separate billing account for each project is not only an administrative burden but also fails to enforce any location constraint, since resources can still be provisioned in any region as long as the project's quotas and policies allow it. Billing accounts control cost and payment, not the geographic placement of resources. Therefore this approach neither satisfies the location requirement nor simplifies governance.

Use IAM deny policies at the organization node to block resource creation outside us-central1

Why wrong: IAM deny policies are used to explicitly deny principals from performing specific actions on specific resources; they cannot directly block the creation of resources in a particular cloud region. The gcp.resourceLocations organization policy is the constraint that defines allowed locations, evaluated during resource creation, not at authorization time. Consequently, deny policies are the wrong mechanism for this geographic restriction.

Create a folder and apply an organization policy constraint to restrict locations at the folder level

Why wrong: Applying a location constraint at the folder level would restrict resource creation only for projects within that specific folder, but the requirement is to enforce the restriction across *all* projects in the organisation, which demands an organisation-level policy constraint. This option is tempting because folder-level policies are the correct mechanism when the goal is to apply different location restrictions to distinct business units or departments, rather than a single, uniform rule for the entire hierarchy.

Cloud Run

Why wrong: Cloud Run is a serverless compute platform that executes stateless containers in response to HTTP requests or events; it has no capability to capture point-in-time disk images. Because it abstracts away the underlying infrastructure and ephemeral filesystem, it cannot serve as a backup or disaster recovery mechanism for an existing Compute Engine VM's persistent disks. Using it for backup would conflate application execution with data durability, which is not its intended role.

Dataflow

Why wrong: Dataflow is a fully managed service for executing Apache Beam pipelines, designed for stream and batch data processing like ETL, real-time analytics, and data transformation. It does not interact with Compute Engine's storage layer to create disk images or recover boot volumes. Using Dataflow to back up a persistent disk would be impossible because Dataflow operates on data flowing through pipelines, not on raw block-level disk state, and it lacks APIs to snapshot or restore virtual disks.

Cloud SQL

Why wrong: Cloud SQL is a managed relational database service that provides automatic backups, point-in-time recovery, and read replicas for its own database instances, such as MySQL, PostgreSQL, or SQL Server. However, it is not a backup solution for Compute Engine instance disks; a Compute Engine VM's persistent disk may contain an entire operating system, application binaries, and arbitrary files, none of which Cloud SQL can capture. Even if the application uses Cloud SQL, the VM's boot and data disks remain outside Cloud SQL's backup domain.

Cloud Storage

Why wrong: Cloud Storage is an object store for arbitrary files, not a container-native registry; it lacks the manifest, tag, and layer integrity checks that Docker registries need. While you could theoretically upload a tarball, Cloud Run and Cloud Build expect images in a registry, so using Cloud Storage would break the pipeline's native integration.

Cloud Source Repositories

Why wrong: Cloud Source Repositories is Google's hosted Git repository, providing code storage, branch management, and integration with IAM, but the question explicitly assumes GitHub as the source control and trigger source. Since source is already in GitHub, Cloud Source Repositories would be redundant and is not a required component of this pipeline.

BigQuery ML

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

Cloud Functions

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

Cloud Run

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

Cloud Scheduler

Why wrong: Cloud Scheduler is a managed cron service that triggers jobs on a fixed schedule, such as invoking an HTTP endpoint or publishing to a Pub/Sub topic at a prescribed time. It is fundamentally batch-oriented, not event-driven: it cannot react to streaming data as it arrives, nor handle unbounded, continuous ingestion from IoT devices. Using it for streaming would require polling, introduce latency, and fail to scale with real-time event rates.

Dataproc

Why wrong: Dataproc is a service for running managed Hadoop and Spark clusters against bounded datasets, typically stored in Cloud Storage or BigQuery, as batch analytics workloads. Although Spark Streaming can technically run on a Dataproc cluster, the service itself is not a fully managed streaming pipeline and requires you to provision, monitor, and scale clusters manually. In a cloud-native architecture, it is not the appropriate tool for ingesting and transforming an unbounded, real-time IoT data stream.

Cloud Functions

Why wrong: Cloud Functions is a serverless function-as-a-service platform designed for short-lived, event-driven tasks that execute in milliseconds to at most a few minutes. While it can be triggered by Pub/Sub messages, it is not intended to run continuous, stateful streaming pipelines or process high-throughput data with complex transformations. Its timeout limits and lack of built-in streaming state management make it unsuitable for the sustained, precisely ordered processing required by real-time IoT analytics.

Cloud DNS

Why wrong: Cloud DNS is a managed authoritative DNS service that translates human-readable domain names into IP addresses. It operates at the DNS layer and is entirely unaware of HTTP request content, so it cannot inspect for SQL injection or XSS patterns. While DNS can influence traffic routing via latency-based policies, it neither caches web content nor enforces security rules, making it irrelevant to the attack described.

Cloud NAT

Why wrong: Cloud NAT provides outbound internet connectivity to private VM instances that lack external IP addresses, while blocking unsolicited inbound connections. It operates at the network layer and has no visibility into application-layer payloads, so it cannot identify malicious HTTP requests like SQLi or XSS. Additionally, Cloud NAT does not cache any content, so it serves a completely different purpose than a WAF or CDN.

Cloud Load Balancing

Why wrong: Cloud Load Balancing distributes incoming traffic across multiple backends to achieve scalability and high availability, supporting both L3/L4 and L7 (HTTP/S) modes. However, its role is traffic routing, not security enforcement; it does not inspect request payloads for malicious patterns. Load balancing also does not cache content, so it fails to address either the performance or the WAF security requirements of the scenario.

Use a single region with multiple zones

Why wrong: A single regional deployment with multiple zones only protects against zonal failures, not regional outages. For EU latency, the region may still be distant from some users, and if the entire region experiences an outage the application becomes unavailable. This option does not address cross-region latency or regional disaster recovery.

Enable Cloud CDN on the application

Why wrong: Cloud CDN caches static content at Google's edge PoPs, reducing latency for repeated static asset requests, but it does not affect dynamic application compute or provide failover. If the backend region fails, the CDN may serve stale cached content but cannot serve new dynamic requests. It is complementary to, not a substitute for, regional deployment or a global load balancer.

Increase machine size in a single zone

Why wrong: Increasing machine size in a single zone only scales vertical capacity, which does not reduce network latency for geographically distributed users or improve availability. It leaves the application vulnerable to zonal and regional failures and does not move compute closer to EU users. This is a capacity optimization, not a latency or resilience solution.

Cloud CDN

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

Cloud NAT

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

Cloud DNS

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