Courseiva

CCNA Scaling with Google Cloud operations Questions

75 of 83 questions · Page 1/2 · Scaling with Google Cloud operations · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A company runs a web application on Google Kubernetes Engine (GKE) that experiences sudden traffic spikes. The operations team notices that the application's response time increases significantly during these spikes despite having Horizontal Pod Autoscaler (HPA) configured. They want to ensure consistent performance. What should they do?

A.Increase the CPU request limit for all pods.
B.Configure the HPA to use custom metrics based on request latency.
C.Create multiple node pools with different machine types.
D.Manually scale the deployment during expected spikes.
AnswerB

Configuring the HPA to consume custom metrics from the Kubernetes Custom Metrics API (e.g., using the Stackdriver adapter or Prometheus adapter) allows it to scale based on request latency metrics such as p95 or p99 duration. This directly measures user-facing performance so the HPA adds pods when latency rises, not just when CPU is saturated. This approach responds to application-level bottlenecks, which is the correct fix for latency-driven scaling on Google Kubernetes Engine.

Why this answer

Configuring the HPA to use custom metrics based on request latency allows the autoscaler to react directly to the application's performance degradation. Unlike CPU-based metrics, which may not reflect actual user-facing latency during traffic spikes, custom metrics like request latency provide a more accurate signal for scaling decisions, ensuring consistent response times.

Exam trap

Google Cloud often tests the misconception that CPU-based HPA is sufficient for all scaling scenarios, but the trap here is that CPU metrics do not capture application-level performance degradation caused by request latency or queue buildup during traffic spikes.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request limit does not improve scaling responsiveness; it only changes the threshold at which the HPA triggers, potentially delaying scaling and not addressing the root cause of latency spikes. Option C is wrong because creating multiple node pools with different machine types addresses node-level resource diversity but does not solve the pod-level scaling issue; the HPA still needs appropriate metrics to scale pods effectively. Option D is wrong because manually scaling the deployment during expected spikes is not a scalable or automated solution; it contradicts the purpose of using HPA and increases operational overhead, especially for unpredictable traffic patterns.

Practice this question →
2
MCQmedium

A company runs a customer-facing web application with a published SLA of 99.95% monthly availability. In the past month, the application experienced two outages: a 12-minute outage and a 7-minute outage. Did the company meet its SLA?

A.No — the company missed the SLA because any outage automatically constitutes an SLA breach
B.Yes — 99.95% availability in a 30-day month allows approximately 21.6 minutes of downtime; total outage of 19 minutes is within the budget, meaning the SLA was met
C.The answer cannot be determined without knowing the cause of the outages
D.No — two separate outages in one month always constitute an SLA breach regardless of duration
AnswerB

The math confirms the SLA was met. 30 days × 1,440 minutes = 43,200 minutes. 0.05% × 43,200 = 21.6 minutes allowed. 12 + 7 = 19 minutes actual downtime. 19 < 21.6, so the SLA is met. However, the remaining buffer is only 2.6 minutes — the team should treat this as a reliability concern.

Why this answer

The SLA of 99.95% monthly availability permits a maximum downtime of approximately 21.6 minutes in a 30-day month (total minutes in month × (1 - 0.9995) = 43,200 × 0.0005 = 21.6 minutes). The combined outage of 19 minutes (12 + 7) is within this budget, so the SLA was met. This calculation assumes a 30-day month; if the month had 31 days, the allowable downtime would be about 22.3 minutes, still exceeding 19 minutes.

Exam trap

The trap here is that candidates mistakenly think any downtime or multiple outages automatically violate an SLA, ignoring the mathematical allowance built into the 99.95% target.

How to eliminate wrong answers

Option A is wrong because not every outage automatically breaches an SLA; SLAs define a specific availability percentage that allows a calculated amount of downtime. Option C is wrong because SLA compliance is determined solely by the total duration of downtime relative to the allowed budget, not by the root cause of the outages. Option D is wrong because multiple outages do not inherently breach an SLA; only the cumulative downtime relative to the allowed threshold matters.

Practice this question →
3
MCQeasy

A company's cloud team is asked to demonstrate that their infrastructure changes are repeatable and auditable. They use Terraform configuration files committed to a Git repository to define all cloud resources. Which operational practice does this exemplify?

A.Infrastructure as Code (IaC) managed through version control, providing repeatable and auditable infrastructure changes
B.Manual change management, where each infrastructure change is recorded in a spreadsheet for audit purposes
C.Disaster recovery planning, using configuration files to document what needs to be rebuilt after a failure
D.Cost optimization, by defining infrastructure in code to enable automatic right-sizing of resources
AnswerA

This exactly describes IaC + GitOps. Terraform configurations in Git provide repeatability (same config → same infrastructure) and auditability (Git history shows every change, who made it, and when). This is a foundational cloud operations best practice.

Why this answer

By storing Terraform configuration files in a Git repository, the team treats infrastructure definitions as code, enabling version control, peer review, and a complete audit trail of changes. This is the core principle of Infrastructure as Code (IaC), which ensures that every infrastructure change is repeatable because the exact same configuration can be applied multiple times, and auditable because Git history records who changed what and when.

Exam trap

The trap here is that candidates may confuse the operational practice of IaC with its secondary benefits (like disaster recovery or cost optimization), but the question explicitly asks about repeatability and auditability, which are direct outcomes of version-controlled IaC.

How to eliminate wrong answers

Option B is wrong because manual change management via spreadsheets is error-prone, lacks automation, and does not provide the repeatability or audit trail that version-controlled code offers. Option C is wrong because disaster recovery planning is a broader strategy that may use IaC as a tool, but the question specifically asks about the operational practice of using version-controlled Terraform files for repeatable and auditable changes, not just documenting rebuild steps. Option D is wrong because cost optimization is a potential benefit of IaC but not the primary practice being demonstrated; the question focuses on repeatability and auditability, not automatic right-sizing.

Practice this question →
4
MCQmedium

A company's engineering organization wants to share operational knowledge across teams using a 'golden path' — a recommended, pre-configured set of tools, services, and templates that makes the easy path also the correct path. Which Google Cloud concept supports this practice?

A.Create a shared Google Slides presentation documenting best practices for teams to reference.
B.Use Terraform blueprints, organization policies, and Cloud Foundation Toolkit to create pre-configured landing zones that enforce standards automatically.
C.Grant all teams Organization Admin access so they can configure resources however they prefer.
D.Hire a dedicated cloud architect to review every new project's design before it starts.
AnswerB

Terraform blueprints from the Cloud Foundation Toolkit are production-ready, opinionated Infrastructure-as-Code modules that bake in Google Cloud best practices for networking, IAM, logging, and monitoring. When combined with organization policies (constraints that enforce guardrails at the organization level) and custom Terraform that provisions landing zones, every new project starts in a fully pre-configured, compliant state. This approach enforces the golden path automatically: teams inherit secure defaults without needing to manually configure resources, and any departure from standards requires an intentional exemption. This is the only option that operationalizes standards at scale, making the path the path of least resistance.

Why this answer

The Cloud Foundation Toolkit (CFT) provides Terraform blueprints and pre-configured landing zones that enforce organizational policies and standards automatically. This aligns directly with the 'golden path' concept by making the easy path (using the blueprints) also the correct path (enforcing compliance and best practices through organization policies and automated deployments).

Exam trap

The GCDL exam often tests the misconception that documentation or manual review processes are sufficient for enforcing standards at scale, when in fact automated policy enforcement and pre-configured templates are required for a true 'golden path' implementation.

How to eliminate wrong answers

Option A is wrong because a shared Google Slides presentation is a static, manual documentation approach that does not enforce standards or automate configuration, failing to create a 'golden path' that makes the easy path the correct path. Option C is wrong because granting all teams Organization Admin access removes all guardrails and security boundaries, directly contradicting the goal of enforcing standards and preventing misconfigurations. Option D is wrong because relying on a single architect to review every project creates a bottleneck and does not scale, whereas a 'golden path' should be self-service and automated.

Practice this question →
5
MCQhard

An organization has multiple projects and wants to aggregate logs from all projects into a single bucket for long-term retention and compliance. What should they do?

A.Use log sinks to route logs to a BigQuery dataset
B.Enable VPC Flow Logs
C.Use Cloud Logging's aggregation view
D.Use log sinks to route logs to a Cloud Storage bucket in a central project
AnswerD

Configuring a log sink with a Cloud Storage bucket in a central project is the recommended pattern for long-term, cross-project log aggregation. Log sinks can be defined at the organization, folder, or project level with `includeChildren` set, automatically routing all matching log entries from every child project into a single Cloud Storage bucket, which provides durable, low-cost, and immutable object storage. Combined with lifecycle policies to transition logs to colder storage classes, this minimizes cost while satisfying audit and retention requirements.

Why this answer

Log sinks in Cloud Logging can route logs from multiple source projects to a centralized Cloud Storage bucket in a separate project. This meets the requirement for long-term retention and compliance, as Cloud Storage provides durable, cost-effective archival storage with lifecycle management policies.

Exam trap

Google Cloud often tests the distinction between log aggregation for querying (aggregation views) versus log routing for centralized storage (log sinks), leading candidates to choose the aggregation view when the requirement is for long-term retention and compliance.

How to eliminate wrong answers

Option A is wrong because routing logs to a BigQuery dataset is optimized for real-time analytics and querying, not for long-term retention and compliance where cost-effective archival storage is needed. Option B is wrong because VPC Flow Logs only capture network traffic metadata within a VPC, not application or system logs from multiple projects, and they do not aggregate logs across projects. Option C is wrong because Cloud Logging's aggregation view is a feature for querying logs across multiple projects in the Logs Explorer, but it does not export or store logs in a centralized bucket for retention and compliance.

Practice this question →
6
MCQeasy

A startup is building a read-heavy mobile backend. They want a database that can scale out reads without downtime. Which database service should they choose?

A.Cloud Firestore.
B.Cloud Spanner.
C.Cloud Bigtable.
D.Cloud SQL with read replicas.
AnswerD

Cloud SQL with read replicas is the correct choice because Cloud SQL is a fully managed relational database (MySQL, PostgreSQL, or SQL Server) that provides strong consistency for reads and writes. Read replicas are asynchronous replicas of the primary instance that can serve read traffic, and this allows you to scale read capacity without downtime or architectural changes. Replicas can be promoted to primary if the original fails, and the SQL interface aligns naturally with most mobile backend APIs, making it a simple, cost-effective solution for a read-heavy workload.

Why this answer

Cloud SQL with read replicas is the correct choice because it allows you to offload read traffic to one or more read replicas, scaling out reads without downtime. Read replicas are asynchronous replicas of the primary instance, and you can promote them to standalone instances if needed, making this ideal for a read-heavy mobile backend that requires high availability.

Exam trap

Google Cloud often tests the misconception that any NoSQL or globally distributed database is automatically better for scaling reads, when in fact Cloud SQL with read replicas is the simplest, most cost-effective, and downtime-free solution for a read-heavy relational workload.

How to eliminate wrong answers

Option A is wrong because Cloud Firestore is a NoSQL document database designed for real-time sync and mobile/web apps, but it does not support traditional SQL read replicas and its scaling model is not optimized for the same kind of read-heavy relational workload. Option B is wrong because Cloud Spanner is a globally distributed, strongly consistent relational database that scales horizontally, but it is overkill and significantly more expensive for a simple read-heavy mobile backend, and it does not use the same read replica model as Cloud SQL. Option C is wrong because Cloud Bigtable is a wide-column NoSQL database optimized for large analytical and operational workloads (e.g., time-series, IoT), not for transactional read-heavy mobile backends with SQL queries, and it lacks built-in read replica support for scaling reads without downtime.

Practice this question →
7
MCQhard

A company's SRE team is debating whether to automate a frequently performed manual operational task. The automation would take 4 weeks of engineering time to build. The manual task takes 30 minutes per occurrence and happens approximately 20 times per month. Using the SRE concept of 'toil,' how should the team approach this decision?

A.Do not automate — the manual task is only 10 hours per month and the 4-week build cost is too high to justify
B.Build the automation: eliminating toil permanently is a core SRE principle, and the 4-week investment pays back within approximately 16 months while freeing engineers for higher-value reliability work indefinitely
C.Hire an additional junior engineer to perform the manual task more efficiently instead of automating
D.The team cannot make this decision without knowing the exact annual salary cost of the engineers who perform the manual task
AnswerB

This is the SRE-aligned answer. Toil elimination is a core SRE value. The math: 10 hours/month saved, 160 hours invested → 16 month payback. But the more important point is that automation eliminates the toil permanently and scales with service growth, while manual toil grows proportionally. SREs should invest in eliminating toil even with moderate payback periods.

Why this answer

Automating toil aligns with the core SRE principle of eliminating repetitive, manual work to free engineers for higher-value reliability tasks. The 4-week build cost is justified: 20 occurrences/month × 0.5 hours = 10 hours/month, so the payback period is 4 weeks × 40 hours/week ÷ 10 hours/month = 16 months, after which the team gains indefinite time savings. This decision does not require exact salary data, as the primary goal is reducing toil, not purely cost optimization.

Exam trap

The GCDL exam often tests the misconception that automation decisions require detailed financial cost analysis (like salary data) rather than the SRE principle of prioritizing toil elimination for long-term reliability gains, leading candidates to pick Option D or A.

How to eliminate wrong answers

Option A is wrong because it incorrectly treats the 4-week build cost as too high without considering the long-term cumulative savings and the SRE principle that eliminating toil permanently is a core goal, not just a cost-benefit analysis. Option C is wrong because hiring an additional junior engineer does not eliminate toil; it merely shifts the manual work to another person, violating the SRE principle of reducing operational overhead and increasing system reliability through automation. Option D is wrong because the decision to automate toil is based on the SRE concept of reducing manual effort and improving reliability, not solely on salary costs; the team can justify automation without exact salary figures by focusing on the toil reduction and long-term engineering productivity gains.

Practice this question →
8
Drag & Dropmedium

Drag and drop the steps to set up a Cloud SQL for MySQL instance with a private IP address into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The process requires setting up the VPC first, then creating the Cloud SQL instance with a private IP, and finally connecting from a VM.

Practice this question →
9
MCQhard

An operations team has been asked to estimate the annual cost impact of a proposed new cloud architecture. The architecture would replace 50 on-demand n2-standard-4 VMs (running 24/7) with an autoscaling group that averages 10 VMs under normal load but scales to 50 during peak hours (approximately 8 hours per day). Which analytical approach best estimates the cost impact?

A.Assume the autoscaling group always runs at average load (10 VMs) and multiply by the annual hours to get the new cost
B.Model the actual usage pattern: calculate cost for (16 normal hours × 10 VMs) + (8 peak hours × 50 VMs) per day, compare to fixed cost of 50 VMs × 24 hours, and use Google Cloud Pricing Calculator to price the VM type
C.Request a custom quote from Google Cloud sales since pricing for autoscaling groups is negotiated individually
D.The cost will be identical since autoscaling groups use the same VM type as the fixed fleet
AnswerB

This is the correct approach. Per day: 16 × 10 = 160 VM-hours (normal) + 8 × 50 = 400 VM-hours (peak) = 560 VM-hours. Fixed: 50 × 24 = 1,200 VM-hours. Autoscaling uses 53% fewer VM-hours. Pricing Calculator gives the $/VM-hour to calculate actual dollar savings.

Why this answer

It accurately models the variable usage pattern of the autoscaling group: 16 hours at 10 VMs plus 8 peak hours at 50 VMs per day. This approach then compares the daily cost to the fixed 50 VMs × 24 hours baseline, using the Google Cloud Pricing Calculator to price the n2-standard-4 instance type. This reflects the pay-per-use billing model of Google Compute Engine, where autoscaling does not change per-VM pricing but reduces total cost by running fewer instances during off-peak hours.

Exam trap

The trap here is that candidates assume autoscaling changes the per-VM pricing or requires special negotiation, when in fact it simply adjusts the number of running instances, and the cost impact is purely a function of total VM-hours at the standard on-demand rate.

How to eliminate wrong answers

Option A is wrong because assuming the autoscaling group always runs at the average of 10 VMs ignores the 8 peak hours where it scales to 50 VMs, significantly underestimating the actual cost. Option C is wrong because autoscaling groups use standard on-demand VM pricing; no custom quote is needed, and Google Cloud does not negotiate individual pricing for standard autoscaling configurations. Option D is wrong because the cost is not identical; the autoscaling group runs fewer total VM-hours per day (16×10 + 8×50 = 560 VM-hours) compared to the fixed fleet (24×50 = 1200 VM-hours), resulting in a lower cost despite using the same VM type.

Practice this question →
10
MCQmedium

A team deploys microservices on GKE with Horizontal Pod Autoscaler (HPA). They want to scale based on custom metrics from third-party monitoring. What must they do first?

A.Use Cluster Autoscaler.
B.Install the custom metrics API adapter.
C.Enable Cloud Monitoring and configure custom metrics.
D.Use Vertical Pod Autoscaler.
AnswerB

The HPA reads custom application metrics through the custom.metrics.k8s.io API, which is an API extension that must be implemented by an adapter installed in the cluster. For GKE, you typically deploy the Google Cloud Monitoring adapter (or a third-party like the Prometheus adapter), which registers an APIService and translates HPA metric queries into backend monitoring queries. Once installed, you can reference these custom metrics in the HPA spec, allowing scaling decisions based on values like Pub/Sub backlog or custom business counters. Without this adapter, the HPA has no endpoint to retrieve custom metric values, even if the metrics are already being collected elsewhere.

Why this answer

B is correct because Horizontal Pod Autoscaler (HPA) in GKE relies on the custom.metrics.k8s.io API to retrieve custom metrics from external monitoring systems. To expose these metrics to the HPA, you must install a custom metrics API adapter (e.g., the Prometheus Adapter or Google Cloud's custom-metrics-stackdriver-adapter) that translates the third-party monitoring data into the format the Kubernetes API server expects. Without this adapter, the HPA cannot query the custom metrics and will fail to scale.

Exam trap

Google Cloud often tests the misconception that enabling a monitoring service (like Cloud Monitoring) alone is sufficient for HPA to use custom metrics, when in fact a dedicated API adapter is required to expose those metrics to the Kubernetes control plane.

How to eliminate wrong answers

Option A is wrong because Cluster Autoscaler manages node-level scaling (adding/removing nodes), not pod-level scaling based on custom metrics; it operates independently of HPA and does not expose custom metrics to the Kubernetes API. Option C is wrong because while Cloud Monitoring can ingest custom metrics, simply enabling it and configuring custom metrics does not make them available to the HPA; you still need the custom metrics API adapter to bridge Cloud Monitoring's data into the custom.metrics.k8s.io API. Option D is wrong because Vertical Pod Autoscaler adjusts CPU/memory requests of pods, not replica count, and it does not use custom metrics from third-party monitoring; it relies on resource usage metrics from the metrics-server.

Practice this question →
11
MCQmedium

Refer to the exhibit. The autoscaler is configured to maintain a target CPU utilization of 0.6. Currently the group has 10 instances, but the autoscaler is not scaling up even though CPU utilization is above 0.8. What is the most likely reason?

A.The maximum number of instances is set to 10
B.The autoscaler is disabled
C.The instance template is misconfigured
D.The autoscaler cooldown period is preventing new instances
AnswerA

The autoscaler cannot scale beyond the configured maximum of 10 instances, regardless of how high the load or target utilization goes. Even though the autoscaler is enabled and actively making scaling decisions, the maximum instance count acts as an absolute cap on the managed instance group's size. Since the group is already at this ceiling, the autoscaler stops adding instances, which is why the target is not being met.

Why this answer

The autoscaler is configured to maintain a target CPU utilization of 0.6, but the current CPU utilization is above 0.8. Despite this, the autoscaler is not scaling up. The most likely reason is that the maximum number of instances is set to 10, and the group has already reached that limit.

In Google Cloud, the autoscaler will not create new instances beyond the configured maximum, even if the target utilization is exceeded.

Exam trap

Google Cloud often tests the misconception that the autoscaler will always scale up when utilization exceeds the target, ignoring the hard limit of the maximum instance count, which is a common configuration oversight.

How to eliminate wrong answers

Option B is wrong because if the autoscaler were disabled, it would not be monitoring CPU utilization at all, and the question states the autoscaler is configured and active (it is not scaling up, not failing to monitor). Option C is wrong because a misconfigured instance template would affect the creation of new instances or their behavior, but it would not prevent the autoscaler from attempting to scale up; the autoscaler would still try to add instances and fail with an error, not remain idle. Option D is wrong because the cooldown period prevents new instances from being added immediately after a scaling event to allow metrics to stabilize, but it does not permanently block scaling; once the cooldown expires, the autoscaler would act if the CPU is still above the target.

Practice this question →
12
MCQmedium

A cloud operations team wants to ensure that all cloud resources created in their Google Cloud organization comply with company naming standards and required cost allocation labels. Which Google Cloud capability can automatically enforce these standards on resource creation?

A.Cloud Billing reports, which flag resources missing required labels after they are created
B.Organization Policy Service with custom constraints or required label policies that prevent resource creation if naming and label standards are not met
C.Cloud Monitoring alerts that notify the team when non-compliant resources are detected
D.Cloud IAM roles that only grant resource creation permissions to employees who have passed a naming standards training
AnswerB

Organization Policy Service allows defining preventive guardrails at the organization level. Custom organization policy constraints can enforce required labels and naming patterns before resource creation is permitted — blocking non-compliant resources at creation time across all projects and services in the org.

Why this answer

Organization Policy Service with custom constraints or required label policies is correct because it provides a preventive control that blocks resource creation if the resource does not meet defined naming and label standards. This is enforced at the Google Cloud resource hierarchy level before any resource is provisioned, ensuring compliance automatically without relying on post-creation detection or manual processes.

Exam trap

The trap here is that candidates often confuse reactive monitoring or billing tools (like Cloud Monitoring or Cloud Billing reports) with preventive enforcement, not realizing that Organization Policy Service is the only option that blocks non-compliant resource creation at the API level.

How to eliminate wrong answers

Option A is wrong because Cloud Billing reports are a reactive tool that only flag resources missing required labels after they are created, not a preventive enforcement mechanism. Option C is wrong because Cloud Monitoring alerts are also reactive, notifying the team after non-compliant resources already exist, and cannot block creation. Option D is wrong because Cloud IAM roles control who can create resources but cannot enforce naming or label standards on the resources themselves; training is a procedural measure, not a technical enforcement capability.

Practice this question →
13
MCQhard

An SRE team analyzes that their service had 47 minutes of downtime in the past 30 days. Their SLO is 99.9% monthly availability. How should the team characterize their performance relative to the SLO?

A.The SLO was met because 47 minutes is less than 1 hour of downtime per month
B.The SLO was missed: 99.9% availability allows approximately 43.2 minutes of downtime in a 30-day month, so 47 minutes exceeded the error budget by about 3.8 minutes
C.The SLO cannot be evaluated because downtime minutes are not the correct unit for measuring availability
D.The SLO was met with margin because 47 minutes represents less than 0.5% downtime
AnswerB

The math: 30 days × 24 hours × 60 minutes = 43,200 minutes. 0.1% × 43,200 = 43.2 minutes allowed downtime. 47 minutes actual > 43.2 minutes allowed → SLO missed by ~3.8 minutes. The error budget is exhausted and the team should prioritize reliability work.

Why this answer

The SLO of 99.9% monthly availability allows a maximum downtime of 43.2 minutes in a 30-day month (30 days × 24 hours × 60 minutes × 0.001 = 43.2 minutes). Since the actual downtime was 47 minutes, the error budget was exceeded by 3.8 minutes, meaning the SLO was missed. This calculation is standard for Google Cloud SRE practices, where error budgets are derived directly from the SLO percentage.

Exam trap

Google Cloud often tests the precise calculation of error budgets from SLO percentages, trapping candidates who round or assume common approximations (like 1 hour per month) instead of computing the exact allowed downtime.

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes a fixed 1-hour threshold; the correct error budget for 99.9% availability over 30 days is 43.2 minutes, not 60 minutes. Option C is wrong because downtime minutes are the correct unit for measuring availability when the SLO is expressed as a percentage of uptime over a defined period. Option D is wrong because 47 minutes represents approximately 0.11% downtime (47 / 43,200), not less than 0.5%, and the SLO was missed, not met with margin.

Practice this question →
14
MCQmedium

A cloud team performs a quarterly review of its Compute Engine instances and discovers 15 VMs that have had zero CPU utilization for over 90 days. What is the recommended operational response to these idle resources?

A.Leave the VMs running in case they are needed for future workloads — storage costs are minimal for idle VMs
B.Investigate whether each VM is still needed; delete confirmed unused VMs to eliminate wasted spend, potentially saving thousands per month
C.Upgrade the idle VMs to larger machine types so they can handle future workloads if needed
D.Apply committed use discounts to the idle VMs to reduce their cost while keeping them available
AnswerB

This is the correct operational response. Investigate first (some may have legitimate low-utilization purposes like DR standby), then delete confirmed waste. 15 idle VMs can represent significant ongoing cost that stops immediately upon deletion. Cloud's on-demand model means these can be re-created if needed.

Why this answer

The recommended operational response to idle Compute Engine instances is to investigate their necessity and delete them if unused. Idle VMs with zero CPU utilization for over 90 days incur ongoing costs for persistent disks, static IPs, and other attached resources, even if the CPU is idle. Deleting confirmed unused VMs eliminates this wasted spend, potentially saving thousands per month, aligning with Google Cloud's cost optimization best practices.

Exam trap

The trap here is that candidates may assume idle VMs have negligible cost, overlooking the ongoing charges for persistent disks and static IPs, or mistakenly think committed use discounts are a catch-all cost-saving measure for any VM.

How to eliminate wrong answers

Option A is wrong because leaving idle VMs running incurs costs for attached persistent disks, static IPs, and other resources, which are not minimal; storage costs for boot disks and additional disks can accumulate significantly over time. Option C is wrong because upgrading idle VMs to larger machine types would increase costs without addressing the underlying waste, as the VMs are not being utilized. Option D is wrong because applying committed use discounts (CUDs) to idle VMs locks in a 1- or 3-year commitment for resources that are not needed, increasing financial risk and negating the cost-saving purpose of CUDs, which are intended for steady-state workloads.

Practice this question →
15
MCQhard

A company uses Cloud Functions (2nd gen) to process events from Pub/Sub. During traffic spikes, function instances scale but latency increases. They want to maximize throughput per instance. What should they configure?

A.Increase the concurrency setting.
B.Allocate more memory.
C.Increase the max instances limit.
D.Increase the function timeout.
AnswerA

In Cloud Functions 2nd gen, the concurrency setting controls how many events a single instance can process simultaneously. By default it is 1, so each instance handles one request at a time. Increasing concurrency lets one instance multiplex many events, directly raising per-instance throughput and reducing the need to spin up additional instances.

Why this answer

Increasing the concurrency setting allows each Cloud Functions (2nd gen) instance to handle multiple requests simultaneously, maximizing throughput per instance during traffic spikes. By default, concurrency is 1, meaning each instance processes one event at a time; raising this value enables parallel processing within a single instance, reducing the need to scale out and lowering latency.

Exam trap

Google Cloud often tests the misconception that scaling out (max instances) or increasing resources (memory) is the primary way to handle throughput, when the key to per-instance efficiency is concurrency tuning.

How to eliminate wrong answers

Option B is wrong because allocating more memory increases CPU power and instance performance, but it does not directly increase the number of events processed concurrently per instance; throughput gains are limited by the single-threaded default. Option C is wrong because increasing the max instances limit allows more instances to be created, which helps with scaling out but does not improve throughput per individual instance—it may even increase latency due to cold starts. Option D is wrong because increasing the function timeout extends the maximum execution duration for a single event, but does not enable parallel processing or improve per-instance throughput; it only prevents premature termination of long-running functions.

Practice this question →
16
MCQeasy

Google Cloud runs its own infrastructure operations using the Site Reliability Engineering (SRE) model, which Google invented. What is the core principle that distinguishes SRE from traditional IT operations?

A.SRE teams never allow production deployments to ensure maximum stability.
B.SRE applies software engineering principles to operations — automating toil, using quantitative SLOs, and treating reliability as an engineered system property.
C.SRE relies entirely on external monitoring vendors to detect and respond to all incidents.
D.SRE means development and operations teams are separate departments that communicate only via ticketing systems.
AnswerB

Site Reliability Engineering deliberately applies software engineering practices to operations itself: repetitive toil is automated with code, reliability is measured through quantitative service level objectives (SLOs) and error budgets, and systems are engineered with failure modes in mind rather than managed reactively. SREs write code for automation, use peer review and version control for operational artifacts, and treat reliability as a design property you can measure and tune. This is fundamentally different from traditional IT operations.

Why this answer

The core principle of SRE is applying software engineering practices to operations work. This means automating manual toil, defining quantitative Service Level Objectives (SLOs) to measure reliability, and treating reliability as an engineered property of the system — not as an afterthought. This contrasts with traditional IT operations, which often rely on manual processes and reactive troubleshooting.

Exam trap

The GCDL exam often tests the misconception that SRE is just a rebranding of traditional IT operations or that it prohibits deployments entirely; the trap here is assuming SRE is purely about stability at the expense of innovation, when in fact it uses error budgets to balance both.

How to eliminate wrong answers

Option A is wrong because SRE teams do allow production deployments; they use error budgets to balance reliability with feature velocity, not to block all changes. Option C is wrong because SRE relies on internal monitoring and alerting (e.g., using Stackdriver or Prometheus) and on-call rotations, not on external vendors for incident detection and response. Option D is wrong because SRE breaks down silos between development and operations; SRE teams work closely with development teams, often using shared ownership and common tooling, not ticketing systems as the primary communication channel.

Practice this question →
17
MCQhard

A large enterprise runs a critical application on Google Cloud consisting of Compute Engine instances behind a TCP load balancer. The application experiences intermittent slow response times that last for about 10 minutes before returning to normal. This pattern has been occurring every few days at random times. The operations team has configured Cloud Monitoring alerts for CPU and memory, but no alerts have fired. They have also reviewed the load balancer logs and see no errors, but the latency spikes. The application logs show no errors during these periods. The team suspects a resource bottleneck but cannot find it. Further investigation reveals that the application makes synchronous calls to an external authentication service for each request. What is the most likely cause and corrective action?

A.The TCP load balancer is experiencing connection draining issues; switch to a proxy-based load balancer.
B.The instance group's autoscaler is configured with a cooldown period that is too long; reduce the cooldown period.
C.The application is making synchronous calls to an external authentication service that occasionally has latency spikes; implement caching and asynchronous processing.
D.The virtual machine instances are suffering from CPU throttling due to sustained use of burstable CPU; move to a machine type with more CPUs.
AnswerC

Synchronous calls to an external authentication service introduce a hard dependency where any latency spike in that service directly blocks the application's request threads, causing intermittent slowdowns that correlate with the external service's variability. Implementing caching for authentication results and switching to asynchronous processing decouples the critical path, absorbs latency spikes, and improves overall response time consistency—especially since the rest of the infrastructure is healthy.

Why this answer

The intermittent latency spikes lasting ~10 minutes, with no errors in application or load balancer logs and no CPU/memory alerts, point to an external dependency issue. The synchronous calls to the external authentication service are the likely bottleneck: if that service experiences transient latency, every request is blocked, causing the application's response time to spike. Caching authentication tokens and using asynchronous processing (e.g., a queue or background refresh) decouples the application from the external service's variability, eliminating the cascading latency.

Exam trap

Google Cloud often tests the misconception that all latency originates from internal infrastructure (load balancers, autoscalers, or CPU), when the real cause is an external dependency's synchronous call pattern that creates a hidden bottleneck without triggering resource alerts.

How to eliminate wrong answers

Option A is wrong because TCP load balancers do not have connection draining issues that cause intermittent latency spikes; connection draining is a feature for graceful shutdown, not a source of random latency, and switching to a proxy-based load balancer would not fix an external dependency problem. Option B is wrong because the autoscaler's cooldown period affects scaling decisions, not the latency of individual requests; if CPU/memory are not spiking, autoscaling is irrelevant, and a long cooldown would cause slow scaling, not 10-minute latency bursts. Option D is wrong because CPU throttling from burstable machine types would trigger CPU utilization alerts and would not produce latency spikes without CPU or memory alerts; the pattern of random 10-minute spikes with no resource alerts contradicts sustained CPU throttling.

Practice this question →
18
MCQeasy

A company uses Cloud Functions and notices that some functions are taking longer than expected. They want to identify which functions have the highest latency. What should they use?

A.Cloud Audit Logs
B.Error Reporting
C.Cloud Monitoring metrics
D.Cloud Logging queries
AnswerC

Cloud Monitoring collects and stores time-series metrics from Cloud Functions, including execution time, invocation count, error count, and memory usage, with built-in dashboards and alerting capabilities. The execution time metric specifically supports calculating service-level objectives and detecting latency anomalies across all invocations. This makes Cloud Monitoring the correct choice for latency analysis and performance monitoring.

Why this answer

Cloud Monitoring metrics, specifically the 'execution_time' metric for Cloud Functions, provide the precise latency data needed to identify functions with the highest execution duration. Unlike logs or error reports, metrics are designed for numerical aggregation and can be used to create dashboards or alerts that rank functions by their p50, p95, or p99 latency values.

Exam trap

Google Cloud often tests the distinction between logs (Cloud Logging) and metrics (Cloud Monitoring), trapping candidates who think that because latency data appears in logs, querying logs is the correct method, when in fact metrics are the proper tool for numerical aggregation and ranking.

How to eliminate wrong answers

Option A is wrong because Cloud Audit Logs record administrative actions and access to resources, not the execution duration of individual function invocations. Option B is wrong because Error Reporting is designed to capture and analyze exceptions and errors, not to measure performance metrics like latency. Option D is wrong because Cloud Logging queries can retrieve individual log entries that may contain execution times, but they are not optimized for aggregating and ranking latency across many functions; Cloud Monitoring metrics are purpose-built for this numerical analysis.

Practice this question →
19
MCQeasy

Which Google Cloud service provides a centralized view of an application's performance metrics, logs, and traces — enabling teams to monitor system health, set up alerts, and diagnose issues from a single platform?

A.Cloud Security Command Center
B.Cloud Monitoring (part of Google Cloud's operations suite)
C.BigQuery
D.Cloud Asset Inventory
AnswerB

Cloud Monitoring is the central operational observability component of Google Cloud's operations suite, ingesting metric time series from GCP services, Prometheus, and custom app instrumentation. It offers flexible dashboards, alerting policies based on thresholds or MQL, uptime checks, and native integration with Cloud Logging and Cloud Trace for a unified troubleshooting workflow. For example, you can correlate a spike in HTTP 500 responses with error log entries and trace samples to diagnose root cause — capabilities no other listed service provides.

Why this answer

Cloud Monitoring (part of Google Cloud's operations suite) is the correct answer because it provides a unified platform for collecting and visualizing metrics, logs, and traces from applications and infrastructure. It enables teams to set up alerting policies, create dashboards, and diagnose performance issues using a single interface, integrating with services like Cloud Logging and Cloud Trace for end-to-end observability.

Exam trap

Google Cloud often tests the distinction between security-focused services and operations-focused services, so the trap here is that candidates might confuse Cloud Security Command Center (a security tool) with a monitoring solution because both provide 'visibility' into cloud resources.

How to eliminate wrong answers

Option A is wrong because Cloud Security Command Center is a security and risk management service that provides visibility into threats and vulnerabilities, not application performance metrics, logs, or traces. Option C is wrong because BigQuery is a serverless data warehouse for analytics over large datasets, not a monitoring or observability tool for real-time application performance. Option D is wrong because Cloud Asset Inventory is used to track and manage cloud resources and their metadata, not to monitor application performance or collect logs and traces.

Practice this question →
20
MCQmedium

A SRE team wants to alert when their service is consuming error budget faster than expected, rather than alerting only when the SLO threshold is crossed. Which Cloud Monitoring alerting strategy supports this approach?

A.Threshold alerting — alert when error rate exceeds 0.1%.
B.SLO burn rate alerting — alert when error budget is being consumed faster than the measurement window allows.
C.Uptime check alerting — alert when health checks fail.
D.Log-based alerting — alert when specific error messages appear in logs.
AnswerB

SLO burn rate alerting continuously calculates the rate at which errors occur relative to the SLO's error budget and the remaining time in the measurement window. When the current burn rate projects that the budget will be exhausted before the window ends, an alert triggers promptly, enabling teams to respond before the SLO is actually violated. This approach is predictive rather than reactive, and can be tuned with fast and slow burn rates to detect both acute and chronic budget consumption, making it the correct mechanism for SLO compliance monitoring.

Why this answer

B is correct because SLO burn rate alerting is specifically designed to detect when error budget is being consumed faster than the measurement window allows, enabling proactive alerts before the SLO threshold is breached. This approach uses a burn rate (e.g., 2x, 10x) to trigger alerts when the error budget depletion rate exceeds a predefined multiple of the expected rate, allowing the team to respond early. It directly addresses the requirement of alerting on error budget consumption speed rather than waiting for a hard SLO violation.

Exam trap

The trap here is that candidates confuse threshold alerting on a static error rate with SLO burn rate alerting, mistakenly thinking a fixed percentage threshold (like 0.1%) is sufficient to catch fast error budget consumption, when in fact burn rate alerting is the only method that measures consumption velocity relative to the SLO window.

How to eliminate wrong answers

Option A is wrong because threshold alerting on a static error rate (e.g., 0.1%) does not account for the error budget consumption rate over time; it only triggers when a fixed percentage is exceeded, which may be too late or too early depending on traffic volume. Option C is wrong because uptime check alerting only monitors synthetic health checks (e.g., HTTP 200 responses) and does not measure error budget consumption or SLO compliance, making it irrelevant to the scenario. Option D is wrong because log-based alerting reacts to specific error messages in logs, which is a reactive, pattern-matching approach that does not track error budget burn rate or SLO adherence.

Practice this question →
21
Multi-Selecteasy

Which THREE of the following are best practices for managing operations in Google Cloud? (Choose THREE.)

Select 3 answers
A.Set up budget alerts to monitor costs
B.Implement infrastructure as code using Deployment Manager or Terraform
C.Enable Cloud Audit Logs for security and compliance
D.Use Cloud Logging to store all logs indefinitely to ensure compliance
E.Use a single project for all workloads to simplify management
AnswersA, B, C

Budget alerts in Google Cloud are configured at the billing account or project level to send notifications when actual or forecasted spend exceeds defined thresholds. This proactive monitoring prevents unexpected charges and enables timely cost governance, ensuring that teams can adjust resource usage before overspending occurs. Alerts are not resource limits but essential visibility tools for financial accountability.

Why this answer

Setting up budget alerts in Google Cloud allows you to monitor costs proactively by triggering notifications when spending exceeds defined thresholds. This is a fundamental operational best practice to avoid unexpected bills and maintain financial control over your cloud resources.

Exam trap

The trap here is that candidates often confuse 'storing logs indefinitely' with a compliance requirement, but Google Cloud best practices emphasize cost-effective log retention policies and using log exports for long-term storage rather than keeping logs in Cloud Logging forever.

Practice this question →
22
MCQmedium

A company runs a mission-critical application that must be available 24/7. They want to ensure that if a Google Cloud region becomes unavailable (e.g., due to a natural disaster), the application automatically continues to serve users from another region. Which architecture pattern achieves this?

A.Deploy in a single region with a Managed Instance Group using 3 availability zones.
B.Deploy the application in multiple regions with a Global Load Balancer for automated failover.
C.Enable Cloud Armor on the load balancer to protect against regional failures.
D.Use Cloud Storage multi-region buckets for application data.
AnswerB

Deploying the application in multiple regions and placing the backends behind a global load balancer (e.g., Global HTTP(S) LB) provides active-active geographic redundancy. The GLB uses a single anycast IP and routes each request to the closest healthy backend based on latency and health check status; when the health checks for an entire region fail, the load balancer automatically shifts traffic to the remaining healthy regions. This protects against regional outages and is a core pattern for mission-critical applications requiring high availability. For full recovery, the application must also replicate state (e.g., Cloud Spanner or Firestore) across regions.

Why this answer

Deploying the application in multiple regions behind a Global Load Balancer (GLB) enables automated failover. The GLB uses health checks to detect regional failures and routes traffic only to healthy backends, ensuring continuous availability even if an entire region goes down. This aligns with the requirement for a multi-region active-passive or active-active architecture for disaster recovery.

Exam trap

The trap here is that candidates confuse zonal redundancy (Option A) with regional redundancy, mistakenly believing that three zones in one region provide the same disaster recovery protection as multiple regions, but a regional failure (e.g., earthquake, power grid collapse) can take down all zones simultaneously.

How to eliminate wrong answers

Option A is wrong because deploying in a single region with three availability zones protects against zonal failures (e.g., a single datacenter outage) but does not protect against a full regional failure, such as a natural disaster affecting the entire region. Option C is wrong because Cloud Armor is a web application firewall (WAF) and DDoS protection service; it does not provide failover or regional redundancy. Option D is wrong because Cloud Storage multi-region buckets provide geo-redundant object storage but do not automatically failover compute or application logic; the application itself must be deployed in multiple regions with a load balancer to serve traffic.

Practice this question →
23
MCQeasy

A cloud team wants to understand their current Google Cloud resource inventory — specifically, which VMs are running in each region, their machine types, and whether they have public IP addresses. Which approach most efficiently provides this across all projects?

A.Log into each Google Cloud project individually through the Console and manually record VM details in a spreadsheet
B.Use Cloud Asset Inventory to run a single org-wide query that returns all VM instances, their regions, machine types, and network configurations across all projects
C.Check the Cloud Billing reports, which list all resources that have incurred charges by resource type
D.Enable VPC flow logs in each project to capture VM network activity
AnswerB

Cloud Asset Inventory provides a single, org-wide searchable view of all compute.googleapis.com/Instance assets via the Cloud Asset API or Console asset search. It returns complete VM metadata—zone/region, machine type, network interfaces, external IP, labels, and status—without per-project login, and can be exported or queried programmatically, making it the only option that directly and comprehensively answers the request.

Why this answer

Cloud Asset Inventory provides a single, unified API to query resources across all projects in an organization. By using the `gcloud asset search-all-resources` command with the `--asset-types=compute.googleapis.com/Instance` filter, you can retrieve all VM instances along with their regions, machine types, and network configurations (including public IP addresses) in one operation, without needing to access each project individually.

Exam trap

The trap here is that candidates may confuse Cloud Billing reports (cost-focused) or VPC flow logs (traffic-focused) with inventory tools, or assume manual per-project inspection is acceptable, when Cloud Asset Inventory is the only option designed for cross-project resource discovery at scale.

How to eliminate wrong answers

Option A is wrong because manually logging into each project and recording details in a spreadsheet is inefficient, error-prone, and does not scale across many projects, defeating the purpose of automation in cloud operations. Option C is wrong because Cloud Billing reports show cost data aggregated by resource type, not the granular per-VM details like machine type, region, or public IP address; they are designed for cost analysis, not inventory management. Option D is wrong because VPC flow logs capture network traffic metadata (e.g., source/destination IPs, ports) but do not provide a static inventory of VM instances, their machine types, or whether they have public IP addresses; they are used for network monitoring and security analysis, not resource discovery.

Practice this question →
24
MCQeasy

A company runs a web application on Compute Engine. During seasonal sales, traffic spikes unpredictably. The operations team wants to ensure the application scales automatically without manual intervention while minimizing cost. Which solution should they implement?

A.Create a managed instance group with a fixed number of instances.
B.Use an unmanaged instance group and manually add instances.
C.Use a managed instance group with autoscaling based on CPU utilization.
D.Use a single large VM with vertical scaling.
AnswerC

A managed instance group with autoscaling based on CPU utilization automatically adjusts the number of VM instances to match current demand. The autoscaler adds instances when average CPU utilization exceeds a target threshold, and removes instances when utilization drops, providing elastic horizontal scaling. This yields both high availability under spikes and cost efficiency during low usage, all without manual intervention.

Why this answer

A managed instance group (MIG) with autoscaling based on CPU utilization is the correct solution because it automatically adjusts the number of VM instances in response to real-time traffic spikes, ensuring the application scales out during high demand and scales in during low demand. This eliminates manual intervention and optimizes cost by only running the necessary number of instances based on a target CPU utilization threshold (e.g., 60-80%).

Exam trap

Google Cloud often tests the distinction between horizontal and vertical scaling, where candidates mistakenly choose vertical scaling (Option D) because they think a larger VM is simpler, but they overlook the downtime, hard limits, and lack of elasticity required for unpredictable traffic spikes.

How to eliminate wrong answers

Option A is wrong because a managed instance group with a fixed number of instances cannot handle unpredictable traffic spikes; it would either be over-provisioned (wasting cost) or under-provisioned (causing performance degradation). Option B is wrong because an unmanaged instance group requires manual addition and removal of instances, which contradicts the requirement for automatic scaling without manual intervention. Option D is wrong because vertical scaling (resizing a single VM) has a hard limit on machine size, causes downtime during resizing, and does not provide the elasticity needed for unpredictable spikes, leading to either overpaying for idle capacity or failing to handle load.

Practice this question →
25
MCQhard

A company's application traffic is served by a Google Cloud global HTTP load balancer. They want to understand how request traffic distributes across backend instances in different regions. Which metric best represents this distribution?

A.`compute/instance/cpu/utilization` per instance group.
B.`loadbalancing/https/request_count` filtered by backend service and region.
C.`networking/vm_flow/egress_bytes_count` per VM.
D.`logging/log_entry_count` filtered by region.
AnswerB

loadbalancing/https/request_count is a native proxy-layer metric emitted by the HTTPS load balancer that increments for every client request matched to a particular backend service and region. Filtering by backend service and region lets you directly compare request volumes across global backends and quickly spot imbalances, regional affinity misconfigurations, or unhealthy pools that are not receiving traffic. It is the correct metric for verifying global load balancing behavior and for building request-rate-based alerts, though note that it counts all requests, including 4xx/5xx responses, at the load balancer itself.

Why this answer

The `loadbalancing/https/request_count` metric, when filtered by backend service and region, directly shows the number of requests handled by each regional backend. This allows you to see how traffic is distributed across regions, which is exactly what the question asks for.

Exam trap

The trap here is that candidates confuse metrics that measure backend health or resource usage (like CPU utilization) with metrics that directly measure traffic distribution, leading them to pick a metric that only indirectly relates to request counts.

How to eliminate wrong answers

Option A is wrong because `compute/instance/cpu/utilization` measures CPU usage, not request distribution, and is not specific to load balancer traffic. Option C is wrong because `networking/vm_flow/egress_bytes_count` tracks outbound bytes from VMs, not inbound request counts from the load balancer. Option D is wrong because `logging/log_entry_count` counts log entries, not HTTP requests, and filtering by region would show log volume, not traffic distribution.

Practice this question →
26
MCQeasy

A company exports all their Google Cloud logs to Cloud Storage for long-term retention required by their compliance policy (7-year log retention). Which Cloud Logging feature enables routing logs to Cloud Storage?

A.Cloud Logging automatically archives all logs to Cloud Storage with no configuration needed.
B.Configure a Cloud Logging sink (log router) that routes logs to a Cloud Storage bucket.
C.Enable log streaming in Cloud Storage settings to receive logs from Cloud Logging.
D.Use the Cloud Logging API to periodically download logs and upload them to Cloud Storage.
AnswerB

A Cloud Logging sink (also called a log router) is the correct and only managed mechanism for exporting log entries to a destination such as a Cloud Storage bucket. You can define an inclusion filter (e.g., specific resource types or severities) and choose Cloud Storage as the destination, and the Log Router will continuously deliver new log entries into the bucket. To meet a 7-year archival requirement, you must also configure a bucket retention policy or lifecycle rule so that objects are retained for the mandatory period and not deleted by default lifecycle actions. This approach is automated, auditable, and requires no custom code or manual downloads.

Why this answer

Cloud Logging uses sinks (log routers) to export logs to supported destinations, including Cloud Storage. A sink defines a filter and a destination; when configured, it routes matching log entries to the specified Cloud Storage bucket for long-term retention. This is the only native mechanism for continuous, automated log export without custom scripting.

Exam trap

The trap here is that candidates assume Cloud Logging automatically archives logs to Cloud Storage (Option A) because of the 'retention' wording, but in reality, sinks are required for any export, and the default retention is only 30 days.

How to eliminate wrong answers

Option A is wrong because Cloud Logging does not automatically archive logs to Cloud Storage; logs are retained for a default period (30 days for logs in the default bucket) and must be explicitly routed via a sink for long-term storage. Option C is wrong because Cloud Storage does not have a 'log streaming' setting; logs are written as objects, not streamed, and the feature described does not exist. Option D is wrong because using the Cloud Logging API to periodically download and upload logs is not a built-in feature; it would require custom code, introduces latency and potential data loss, and violates the principle of using native routing via sinks.

Practice this question →
27
MCQeasy

What is the difference between a Service Level Indicator (SLI), a Service Level Objective (SLO), and a Service Level Agreement (SLA)?

A.SLI is the contract with customers; SLO is the internal target; SLA is the measurement.
B.SLI is the measured metric; SLO is the internal target for that metric; SLA is the contractual customer commitment.
C.SLI, SLO, and SLA are all the same thing — different names for uptime guarantees.
D.SLA is measured in milliseconds; SLO is measured in percentage; SLI has no unit.
AnswerB

This option correctly identifies the hierarchy among the three concepts. An SLI is the actual measured metric that quantifies service performance, such as 'the proportion of requests completed successfully' or 'latency at the 95th percentile.' An SLO is an internal target value for that SLI, e.g., 'maintain 99.9% availability over a 30-day window,' which guides engineering priorities. An SLA is a contractual commitment to a customer that often sets a stricter threshold and defines compensations, such as 'if availability falls below 99.5%, issue a service credit—the SLA is a business agreement, not just an engineering metric.'

Why this answer

It accurately defines the relationship: an SLI is a specific metric (e.g., request latency at the 99th percentile), an SLO is the internal target for that metric (e.g., 99.9% of requests under 200ms), and an SLA is the contractual commitment to a customer (e.g., 99.9% uptime with financial penalties). This aligns with Google Cloud's Site Reliability Engineering (SRE) practices, where SLIs are measured, SLOs are internal goals, and SLAs are legal agreements.

Exam trap

The GCDL exam often tests the confusion between SLI, SLO, and SLA by swapping their definitions, so the trap here is assuming SLI is the contract or that all three terms are synonymous, when in reality they form a hierarchy of measurement, target, and agreement.

How to eliminate wrong answers

Option A is wrong because it reverses the definitions: an SLI is not a contract (that's an SLA), an SLO is not an internal target (it is), and an SLA is not a measurement (that's an SLI). Option C is wrong because SLI, SLO, and SLA are distinct concepts with different purposes—SLIs are metrics, SLOs are targets, and SLAs are contracts—they are not interchangeable terms for uptime guarantees. Option D is wrong because it incorrectly assigns units: SLIs can have various units (e.g., milliseconds, percentage, count), SLOs are typically expressed as percentages or thresholds, and SLAs are not measured in milliseconds but define contractual commitments.

Practice this question →
28
MCQmedium

A company has multiple teams deploying to Google Cloud and wants to allocate cloud costs by team. Each team should see only their own costs and be accountable for their spending. Which Google Cloud feature enables this cost allocation and visibility?

A.Create one large project for all teams and split the bill manually at month-end.
B.Use separate projects per team within a folder structure, with resource labels for sub-team cost attribution.
C.Purchase dedicated hardware for each team so costs are inherently separate.
D.Use Cloud Identity to create separate accounts for each team and bill separately.
AnswerB

Separate projects per team, placed under a folder structure, enforce a clean resource hierarchy: each project is the primary billing boundary, so Cloud Billing reports and budget alert thresholds map directly to a team. Resource labels add a second dimension, enabling sub-team or product-level cost breakdowns through BigQuery billing export, which is the precise mechanism for granular chargeback. This approach preserves GCP-native elastic capacity and self-service while giving finance a structured, queryable view of spend.

Why this answer

Google Cloud's resource hierarchy allows you to create separate projects per team within a folder structure, and resource labels provide granular cost attribution for sub-teams or environments. This enables each team to see only their own costs via billing export and cost breakdowns in the Cloud Billing console, ensuring accountability without manual splitting.

Exam trap

Google Cloud often tests the misconception that Cloud Identity can be used for billing separation, but Cloud Identity is for user authentication and directory services, not for cost allocation or billing account management.

How to eliminate wrong answers

Option A is wrong because creating one large project for all teams and splitting the bill manually at month-end is error-prone, lacks real-time visibility, and violates the principle of least privilege for cost data. Option C is wrong because purchasing dedicated hardware for each team is not a Google Cloud feature; it contradicts the cloud's shared infrastructure model and would eliminate the benefits of elasticity and pay-as-you-go pricing. Option D is wrong because Cloud Identity is used for identity and access management, not for billing separation; separate accounts would require separate billing accounts, which is not a scalable or recommended approach for team-level cost allocation.

Practice this question →
29
MCQmedium

A company has deployed a critical application on Google Cloud and wants to understand what happens to their workloads during a Google Cloud data center maintenance event (e.g., host system upgrades). What Google Compute Engine feature handles this automatically for most VMs?

A.VMs are terminated and restarted automatically on new hardware, causing a few minutes of downtime.
B.Live migration transparently moves VMs to healthy hosts during maintenance with no VM downtime.
C.VMs are snapshotted, the snapshot is restored on new hardware, and the VM is restarted.
D.Customers must subscribe to Google Cloud support to receive advance notice and schedule their own maintenance windows.
AnswerB

During a live migration, the VM's memory pages are continuously copied from the source host to a destination host in a series of iterative passes, while the instance continues running its normal operations. At the final pass, the VM is briefly quiesced for just a few hundred milliseconds to transfer the remaining state, then the instance resumes on the new host with the same MAC address, IP address, and open network connections. This gives the appearance of zero downtime, though technically it's an extremely short pause rather than a full shutdown and boot.

Why this answer

Google Compute Engine uses Live Migration to automatically move running VMs from a host undergoing maintenance (e.g., host system upgrades) to a healthy host without interrupting the VM. This process preserves the VM's memory, network connections, and disk state, resulting in zero VM downtime. It is enabled by default for most VM instances, except those with GPUs or certain machine types that explicitly opt out.

Exam trap

The trap here is that candidates confuse Live Migration with a restart or snapshot-based recovery, assuming maintenance always causes downtime, when in fact Google's Live Migration provides seamless, zero-downtime maintenance for the vast majority of VM instances.

How to eliminate wrong answers

Option A is wrong because VMs are not terminated and restarted; Live Migration moves them transparently with no downtime, not a few minutes of downtime. Option C is wrong because snapshots are not used for maintenance events; Live Migration transfers the VM's live memory and disk state directly, not via snapshot-and-restore. Option D is wrong because Google Cloud does not require customers to subscribe to support for maintenance handling; Live Migration is automatic and free for eligible VMs, and advance notice is provided only for VMs that cannot be live-migrated (e.g., those with GPUs).

Practice this question →
30
MCQmedium

A DevOps team wants to implement a release process where a new application version is first deployed to 5% of production traffic, monitored for errors, then gradually increased to 100% if metrics remain healthy. Which deployment strategy does this describe?

A.Blue/green deployment, where two identical environments run simultaneously and traffic is switched atomically
B.Canary deployment, where a new version receives a small percentage of traffic first and is progressively rolled out as metrics confirm it is healthy
C.Rolling deployment, where instances are updated sequentially one at a time until all run the new version
D.Recreate deployment, where the old version is terminated before the new version is deployed
AnswerB

Canary deployment precisely matches the description: 5% traffic initially, monitoring, then gradual increase to 100%. The term comes from the mining practice of using canaries to detect dangerous gas — the canary deployment detects problems before full rollout.

Why this answer

This describes a canary deployment, where the new version is initially exposed to a small subset of users (e.g., 5% of traffic) and then gradually rolled out to 100% only if key metrics (latency, error rate, CPU usage) remain within acceptable thresholds. Google Cloud's Deployment Manager and GKE support canary deployments via traffic splitting with services like Istio or native GKE ingress, allowing fine-grained control over the rollout percentage.

Exam trap

The GCDL exam often tests the distinction between canary and blue/green deployments by emphasizing the 'gradual percentage increase' versus 'atomic switch' — the trap here is that candidates confuse the 5% initial traffic with blue/green's 'staging' environment, but blue/green does not use progressive traffic shifting.

How to eliminate wrong answers

Option A is wrong because blue/green deployment involves two identical environments (blue and green) with an instantaneous traffic switch, not a gradual percentage-based rollout. Option C is wrong because rolling deployment updates instances one at a time (or in small batches) without the explicit 5% initial traffic split and metric-based gating described in the question. Option D is wrong because recreate deployment terminates all old instances before deploying the new version, causing downtime and no gradual traffic shifting.

Practice this question →
31
MCQmedium

A company's cloud costs have increased by 40% over the past quarter. The operations team wants to identify and address the root causes. Which cost optimization strategies should they investigate first?

A.Immediately upgrade all infrastructure to the latest generation hardware for better efficiency.
B.Identify idle and underutilized resources (oversized VMs, unused disks, unattached IPs), apply lifecycle policies to storage, and commit to CUDs for stable workloads.
C.Migrate all workloads to Spot VMs immediately to reduce costs by 90%.
D.Switch cloud providers to whoever has the lowest advertised list price.
AnswerB

This is the correct first step because it directly targets the largest, most actionable cost leaks in any GCP environment. Active Assist tools like Recommender identify idle VMs and oversized instances for right-sizing, while unused disks and unattached IP addresses can be immediately deleted to stop recurring charges. Storage lifecycle policies (e.g., moving from Standard to Nearline or Coldline) automatically downgrade data access tiers for rarely used data, and Committed Use Discounts (CUDs) lock in lower prices for stable, predictable baseline compute — all without sacrificing performance or availability.

Why this answer

The first step in cloud cost optimization is to identify and eliminate waste from idle or oversized resources, which is the most common source of cost inefficiency. Applying lifecycle policies to storage and committing to Committed Use Discounts (CUDs) for stable workloads are proven strategies to reduce costs without compromising performance. This approach aligns with Google Cloud's recommended FinOps practices, focusing on immediate, high-impact savings before considering architectural changes.

Exam trap

The trap here is that candidates often jump to aggressive cost-cutting measures like migrating to Spot VMs or switching providers, without first addressing the low-hanging fruit of resource waste, which is the most impactful and least risky initial step in cost optimization.

How to eliminate wrong answers

Option A is wrong because immediately upgrading to the latest generation hardware is a capital-intensive strategy that may not address the root cause of cost increases (e.g., idle resources) and could even increase costs if the new hardware is not right-sized. Option C is wrong because migrating all workloads to Spot VMs is risky for production or stateful workloads, as Spot VMs can be terminated at any time with only 30 seconds notice, leading to potential data loss or service disruption. Option D is wrong because switching cloud providers based solely on lowest advertised list price ignores hidden costs like data egress fees, network latency, and the operational overhead of migration, and does not address existing resource inefficiencies.

Practice this question →
32
MCQhard

A reliability engineering team wants to proactively identify weaknesses in their distributed system by deliberately injecting failures — killing random instances, introducing network latency, and cutting off database connections — to observe how the system responds. What is this practice called?

A.Destructive testing — deliberately breaking the system to determine the breaking point.
B.Chaos engineering — deliberately injecting controlled failures to discover system weaknesses and build resilience confidence.
C.Penetration testing — simulating attacks to find security vulnerabilities.
D.Load testing — verifying the system handles expected traffic volumes.
AnswerB

Chaos engineering is the disciplined practice of introducing controlled failures (e.g., terminating a service instance, injecting latency, or simulating a network partition) into a distributed system to observe behavior against a defined steady-state hypothesis. It is a scientific method for verifying that the system can self-heal and maintain user impact within acceptable bounds, and it typically is performed with a limited blast radius and continuous experimentation. The objective is not merely to find a breaking point, but to build resilience confidence by uncovering unknown architectural weaknesses before they manifest as real outages.

Why this answer

Chaos engineering is the practice of deliberately injecting controlled failures—such as killing instances, introducing latency, or cutting database connections—into a distributed system to proactively identify weaknesses and build resilience confidence. This approach aligns with Google Cloud's reliability principles, where tools like Chaos Monkey (part of the Simian Army) or Google's internal DiRT (Disaster Recovery Testing) are used to test system behavior under failure conditions.

Exam trap

Google Cloud often tests the distinction between 'destructive testing' and 'chaos engineering' by making candidates think any deliberate failure is destructive, but the key difference is that chaos engineering is controlled, hypothesis-driven, and aims to build resilience, not just find the breaking point.

How to eliminate wrong answers

Option A is wrong because destructive testing focuses on finding the breaking point of a system by pushing it to failure, often in a non-controlled manner, and does not emphasize controlled, proactive failure injection to build resilience confidence. Option C is wrong because penetration testing specifically targets security vulnerabilities (e.g., OWASP Top 10, SQL injection) and does not cover operational failures like network latency or instance termination. Option D is wrong because load testing verifies system performance under expected or peak traffic volumes (e.g., using tools like Locust or k6), not the system's response to injected failures like database disconnections or random instance kills.

Practice this question →
33
MCQhard

Refer to the exhibit. A team deployed this Cloud Run service. During a load test, the service receives high traffic, but the number of container instances never exceeds 10. What is the most likely cause?

A.The maxScale annotation limits the maximum number of instances to 10.
B.The minScale of 2 forces at least two instances, but not the max.
C.The containerConcurrency of 80 limits the number of concurrent requests per instance.
D.The CPU limit of 1 vCPU is too low to handle the traffic.
AnswerA

The `autoscaling.knative.dev/maxScale` annotation directly sets the upper bound on the number of instances that Cloud Run can create. With a value of 10, the service is hard-capped at 10 concurrent instances even if traffic surges. This overrides the default maximum (which is usually 100 or unlimited), so it is the correct reason the service cannot scale beyond 10.

Why this answer

The `maxScale` annotation in Cloud Run directly caps the maximum number of container instances that can be created. When the service receives high traffic but never exceeds 10 instances, it indicates that the `maxScale` annotation is set to 10, preventing further scaling even if demand increases. This is the most direct and likely cause among the options.

Exam trap

Google Cloud often tests the distinction between scaling limits (maxScale) and performance tuning parameters (containerConcurrency, CPU limits), leading candidates to mistakenly attribute a hard instance cap to concurrency or resource constraints rather than the explicit annotation.

How to eliminate wrong answers

Option B is wrong because `minScale` of 2 only ensures a minimum of two instances are always running, but it does not impose any upper limit; the service could scale beyond 10 if `maxScale` were higher. Option C is wrong because `containerConcurrency` of 80 limits how many concurrent requests each instance can handle, but it does not cap the total number of instances; the service could still scale out to more instances to handle the load. Option D is wrong because a CPU limit of 1 vCPU per instance might cause performance bottlenecks, but it does not prevent the service from creating more than 10 instances; Cloud Run can still scale horizontally to additional instances even if each has a low CPU limit.

Practice this question →
34
MCQhard

An SRE team is practicing 'chaos engineering' by simulating a zone-level failure in their staging environment. They find that their application does not automatically recover — traffic is not redirected and the service remains down. What architectural component is most likely missing?

A.The application needs more replicas in the failing zone to survive the failure
B.A load balancer with health checks across multiple zones is most likely missing — without it, there is no mechanism to detect the zone failure and automatically redirect traffic to healthy instances in surviving zones
C.The application needs a larger machine type to handle the full traffic load without the failed zone's capacity
D.Cloud Monitoring alerts need to be configured to notify the team when a zone fails, enabling manual traffic redirection
AnswerB

The load balancer is the key component. It must be configured with backend instances in multiple zones and health checks enabled. When the health check detects that zone A instances are unhealthy, it automatically removes them from the rotation and sends all traffic to healthy instances in zones B and C. Without the load balancer, clients connect directly to zone A and have no fallback.

Why this answer

In a zone-level failure, traffic cannot be redirected to healthy instances in surviving zones without a load balancer that performs health checks across multiple zones. Google Cloud's external or internal load balancers (e.g., HTTP(S) Load Balancer, TCP/UDP Network Load Balancer) use health checks to detect unhealthy instances and automatically route traffic only to healthy backends. Without this component, the application has no mechanism to detect the zone failure and reroute traffic, leaving the service down.

Exam trap

The trap here is that candidates may confuse 'scaling up' (larger machine types or more replicas) with 'resilience through load balancing', failing to recognize that without a load balancer with health checks, no amount of capacity in surviving zones will automatically redirect traffic.

How to eliminate wrong answers

Option A is wrong because adding more replicas in the failing zone does not help when the entire zone is unavailable; replicas in that zone would also be down. Option C is wrong because a larger machine type does not solve the lack of automatic traffic redirection; it only increases capacity in surviving zones, but without a load balancer, traffic is still not redirected. Option D is wrong because Cloud Monitoring alerts only notify the team of the failure; they do not automatically redirect traffic, and manual redirection is not a scalable or reliable solution for chaos engineering scenarios.

Practice this question →
35
MCQhard

A financial services company is migrating its on-premises monitoring system to Google Cloud. They need to collect metrics, logs, and traces from multiple projects and provide a unified view for their operations team. Security requires that logs containing sensitive data be stored with additional encryption and access controls. Which combination of services should they use?

A.Cloud Monitoring, Cloud Logging, and Cloud Trace with Logging's _Required and _Default buckets.
B.Cloud Monitoring, Cloud Logging, and Cloud Trace with a custom sink to a BigQuery dataset that uses CMEK.
C.Cloud Monitoring and Cloud Logging with Log Analytics.
D.Cloud Monitoring, Cloud Logging, and Cloud Trace with Cloud Audit Logs.
AnswerB

A custom log sink routes selected log entries to a user-controlled destination, here a BigQuery dataset encrypted with CMEK, enabling the customer to manage and rotate the encryption keys via Cloud KMS. Pairing this with Cloud Monitoring for resource metrics and Cloud Trace for distributed request spanning gives complete observability: logs, metrics, and traces are unified. The CMEK-protected BigQuery dataset also allows fine-grained IAM access control and retention management, satisfying both encryption and least-privilege requirements.

Why this answer

The company needs to collect metrics, logs, and traces (requiring Cloud Monitoring, Cloud Logging, and Cloud Trace) and must store logs containing sensitive data with additional encryption and access controls. A custom sink to BigQuery with CMEK provides customer-managed encryption keys for the BigQuery dataset, and BigQuery's native access controls (IAM, row-level security) satisfy the requirement for additional access controls beyond the default Logging buckets.

Exam trap

Google Cloud often tests the misconception that the _Required and _Default buckets are sufficient for compliance, but they lack CMEK and granular access controls, which are essential for sensitive data handling.

How to eliminate wrong answers

Option A is wrong because the _Required and _Default buckets are built-in Logging storage buckets that use Google-managed encryption keys (GMEK) by default and do not provide the additional encryption (CMEK) or granular access controls required for sensitive data. Option C is wrong because it omits Cloud Trace entirely, which is needed for collecting traces, and Log Analytics alone does not provide the separate, encrypted storage with custom access controls for sensitive logs. Option D is wrong because Cloud Audit Logs are a specific type of log (administrative activity, data access, etc.) and not a storage or encryption mechanism; they do not enable CMEK or custom access controls for sensitive data.

Practice this question →
36
MCQeasy

A developer needs to debug a production issue by analyzing logs from multiple microservices. Which Google Cloud service should they use to filter and search logs in real time?

A.Cloud Monitoring
B.Error Reporting
C.Cloud Logging
D.Cloud Debugger
AnswerC

Cloud Logging is the correct service because it is purpose-built for ingesting, storing, searching, and analyzing logs in real time. It offers a powerful query language, filters, and the ability to view logs from a single VM, container, or Kubernetes cluster, making it the ideal tool for debugging a production issue. Cloud Logging also integrates with Cloud Monitoring and Error Reporting, but it alone provides the comprehensive log analysis functionality described in the scenario.

Why this answer

Cloud Logging (formerly Stackdriver Logging) is the correct service because it provides a centralized log management system that can ingest logs from multiple microservices, filter them using advanced queries, and search them in real time. Its Logs Explorer interface supports custom filters, labels, and timestamps, enabling developers to pinpoint production issues across distributed services without delay.

Exam trap

Google Cloud often tests the distinction between log management (Cloud Logging) and error aggregation (Error Reporting), leading candidates to choose Error Reporting when the question explicitly asks for filtering and searching logs in real time.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring focuses on metrics, uptime checks, and alerting policies, not on filtering or searching raw log data in real time. Option B is wrong because Error Reporting automatically aggregates and analyzes application errors (e.g., stack traces) but does not provide a general-purpose log search or filtering capability for arbitrary log entries. Option D is wrong because Cloud Debugger allows you to inspect the state of a running application (e.g., capture snapshots and logpoints) without stopping it, but it is not designed for centralized log aggregation, filtering, or real-time search across multiple microservices.

Practice this question →
37
MCQhard

A company's cloud cost has grown significantly. A FinOps analysis reveals the largest waste category is idle Cloud SQL instances — 12 database instances that were provisioned for projects that have since ended, but were never deleted. What process failure most directly caused this waste?

A.The company should have used a cheaper database service instead of Cloud SQL
B.The absence of a resource decommissioning process: when projects end, there is no formal step to identify and delete associated cloud resources, allowing idle infrastructure to persist and accrue costs indefinitely
C.Cloud SQL pricing is too high compared to on-premises databases, making any unused capacity expensive
D.The database administrators forgot to enable automatic deletion for idle Cloud SQL instances
AnswerB

This is the root cause. FinOps best practice requires a defined lifecycle process: when a project is closed or a service is decommissioned, associated cloud resources are explicitly identified and deleted. Without this step, idle resources accumulate. The fix is process: add resource cleanup to the project closure checklist and automate detection of idle resources.

Why this answer

The root cause is the lack of a formal resource decommissioning process. When projects end, there is no automated or manual step to identify and delete associated Cloud SQL instances, so idle databases continue to incur costs. In Google Cloud, Cloud SQL instances do not auto-delete; they persist until explicitly removed, making a decommissioning workflow essential to prevent waste.

Exam trap

The GCDL exam often tests the concept that cloud resources are not automatically cleaned up when projects end, and candidates mistakenly think technical features like auto-deletion or cheaper services are the solution, rather than recognizing the need for a process-driven decommissioning workflow.

How to eliminate wrong answers

Option A is wrong because the waste is not due to the choice of database service; Cloud SQL is appropriate for relational workloads, and the issue is that instances are idle, not that a cheaper service would solve the problem of forgotten resources. Option C is wrong because comparing Cloud SQL pricing to on-premises databases is irrelevant; the waste is from unused capacity, not from the pricing model itself. Option D is wrong because Cloud SQL does not have an 'automatic deletion' feature for idle instances; the responsibility lies with the organization to implement lifecycle management, not with a missing configuration toggle.

Practice this question →
38
MCQmedium

A company is migrating to Google Cloud and wants to reduce operational overhead for managing their infrastructure. Which Google Cloud service allows them to define infrastructure as code and automate provisioning?

A.Cloud Deployment Manager
B.Google Cloud SDK
C.Cloud Console
D.Cloud Shell
AnswerA

Cloud Deployment Manager is Google Cloud's native Infrastructure as Code (IaC) service, allowing you to define your entire infrastructure in declarative YAML or Python templates. Once deployed, it treats templates as the source of truth, handling incremental updates, dependencies, and idempotent rollbacks automatically. This aligns perfectly with a migration goal to reduce operational overhead by making resource provisioning repeatable, auditable, and version-controllable.

Why this answer

Cloud Deployment Manager is the correct answer because it is a Google Cloud service that allows you to define your infrastructure as code using declarative templates (in YAML, Python, or Jinja2). It automates the provisioning and management of Google Cloud resources, reducing manual operational overhead by enabling repeatable, version-controlled deployments.

Exam trap

The trap here is that candidates confuse Cloud Deployment Manager with general-purpose tools like Cloud SDK or Cloud Shell, assuming any command-line or scripting tool can achieve infrastructure-as-code automation, but only Deployment Manager provides declarative, managed provisioning.

How to eliminate wrong answers

Option B (Google Cloud SDK) is wrong because it is a command-line toolset for interacting with Google Cloud services, not a service for defining infrastructure as code or automating provisioning. Option C (Cloud Console) is wrong because it is a web-based GUI for managing resources manually, which does not support infrastructure-as-code definitions or automated provisioning. Option D (Cloud Shell) is wrong because it is a browser-based terminal environment with pre-installed tools, not a service for defining or automating infrastructure deployment.

Practice this question →
39
MCQeasy

A company has a Google Cloud environment with 50 projects and 200 engineers. The security team wants to ensure that a new security policy — requiring all Cloud Storage buckets to have uniform bucket-level access enabled — applies to all existing and future buckets across all projects. Which approach scales to the entire organization?

A.Send an email to all 200 engineers explaining the policy and asking them to manually enable uniform bucket-level access on their buckets
B.Apply an Organization Policy constraint ('storage.uniformBucketLevelAccess') at the organization level to enforce the setting automatically across all current and future projects and buckets
C.Create a Cloud Function that checks bucket configurations hourly and enables uniform access on non-compliant buckets
D.Grant the security team Owner access to all 50 projects so they can manually enforce the policy in each project
AnswerB

Organization Policy is the scalable solution. By applying the constraint at the organization level, it cascades to all 50 projects automatically. New projects created in the future also inherit the constraint. No per-project configuration or per-engineer action required.

Why this answer

Organization Policy constraints, such as `storage.uniformBucketLevelAccess`, are enforced at the organization level and automatically apply to all existing and future projects and resources within the organization. This ensures uniform compliance without manual intervention, scaling seamlessly across 50 projects and 200 engineers.

Exam trap

The GCDL exam often tests the distinction between reactive remediation (e.g., Cloud Functions) and proactive enforcement (e.g., Organization Policies), where candidates may choose a technically functional but less scalable or secure option like C because it seems automated, missing the requirement for organization-wide, preventive enforcement.

How to eliminate wrong answers

Option A is wrong because relying on manual action from 200 engineers is error-prone, unscalable, and does not guarantee enforcement for future buckets. Option C is wrong because a Cloud Function that periodically checks and remediates buckets is reactive, not preventive, and introduces latency and potential gaps between checks; it also does not enforce the policy on new buckets before they are created. Option D is wrong because granting Owner access to the security team for all 50 projects violates the principle of least privilege, creates a security risk, and still requires manual effort to apply the policy to each bucket, which does not scale.

Practice this question →
40
MCQmedium

A company uses committed use discounts (CUDs) for its production workload baseline. An engineer proposes also using sustained use discounts (SUDs) for the same VMs. Why is this incorrect?

A.CUDs and SUDs can be combined on the same VMs — applying both gives the maximum possible discount
B.CUDs and SUDs are mutually exclusive: VMs already covered by committed use discounts don't accrue sustained use discounts — you receive only the CUD, not both
C.SUDs cannot be applied to production workloads — they are only available for development environments
D.Applying both CUDs and SUDs creates a billing conflict that could result in Google charging the company more than on-demand pricing
AnswerB

This is correct. CUDs are pre-purchased commitments that replace (not supplement) the SUD credit system. When a CUD commitment covers compute usage, that usage is billed at the CUD rate, not the on-demand rate that would otherwise accumulate SUD credits. Stacking is not possible.

Why this answer

Committed use discounts (CUDs) and sustained use discounts (SUDs) are mutually exclusive on the same VM. When a VM is covered by a CUD, it does not accrue SUDs; only the CUD discount is applied. This prevents double-discounting and ensures billing consistency.

Exam trap

The trap here is that candidates may assume discounts are additive or combinable, similar to how some cloud providers allow stacking, but Google Cloud explicitly makes CUDs and SUDs mutually exclusive to prevent double-discounting.

How to eliminate wrong answers

Option A is wrong because CUDs and SUDs cannot be combined on the same VMs; they are mutually exclusive, so applying both does not give the maximum possible discount. Option C is wrong because SUDs are available for all workloads, including production, not just development environments. Option D is wrong because applying both CUDs and SUDs does not create a billing conflict that results in higher charges than on-demand pricing; instead, the system simply applies only the CUD and ignores SUD accrual.

Practice this question →
41
MCQmedium

An operations team is performing a post-incident review after a production outage. The team lead insists that the review must follow a 'blameless postmortem' approach. What does this mean, and why is it important for organizational learning?

A.A blameless postmortem assigns full responsibility to the automated systems involved, not to human engineers, which protects the team from accountability
B.A blameless postmortem focuses on systemic root causes and improvement opportunities rather than individual fault — creating psychological safety for honest disclosure and leading to more effective prevention of future incidents
C.A blameless postmortem means the incident is not formally documented to protect employees' privacy and career records
D.A blameless postmortem can only be conducted by senior management who have authority to make systemic improvements
AnswerB

This captures both dimensions: what blameless means (systemic focus, not individual blame) and why it matters (psychological safety enables honest disclosure — people share full details when they don't fear punishment). SRE culture pioneered this approach, which produces better learning than punitive reviews.

Why this answer

A blameless postmortem in Google Cloud operations (and SRE practice) shifts focus from individual human error to systemic root causes, such as misconfigured alerting thresholds, insufficient canary deployments, or gaps in monitoring coverage. This approach fosters psychological safety, encouraging engineers to report all contributing factors without fear of reprisal, which leads to more effective incident prevention and aligns with Google's Site Reliability Engineering (SRE) principles of learning from failures.

Exam trap

Google Cloud often tests the misconception that 'blameless' means 'no accountability' or 'no documentation', but the correct understanding is that it shifts accountability from individuals to systemic improvements while still requiring thorough documentation and follow-up actions.

How to eliminate wrong answers

Option A is wrong because a blameless postmortem does not assign responsibility to automated systems; instead, it examines both human and system factors to identify systemic improvements, and it does not protect the team from accountability—it promotes accountability for learning. Option C is wrong because a blameless postmortem is formally documented (e.g., in a postmortem template stored in Google Cloud Storage or a shared drive) to capture findings and action items, not to protect privacy or career records—privacy is a side effect, not the purpose. Option D is wrong because a blameless postmortem can be conducted by any team member, including individual contributors, not only senior management; the goal is to involve those closest to the incident for accurate root cause analysis.

Practice this question →
42
Multi-Selecthard

A company uses Cloud Monitoring to collect metrics from their applications running on Google Kubernetes Engine (GKE). They want to create custom dashboards and set up alerting policies. Which THREE capabilities are available in Cloud Monitoring? (Choose THREE.)

Select 3 answers
A.Query logs using Logging Query Language
B.Automatically remediate incidents with Cloud Functions
C.Define custom metrics via the Monitoring API
D.Set up alerting policies based on metric thresholds
E.Create uptime checks for external URLs
AnswersC, D, E

The Monitoring API exposes a `timeSeries.create` method that enables you to write custom metrics, such as application-specific counters, gauges, or histograms, into Cloud Monitoring. These custom metrics then appear in dashboards and can be referenced in alerting policies alongside system metrics. This is a core extension point for monitoring anything not automatically collected by Google Cloud's built-in integrations.

Why this answer

The Cloud Monitoring API allows you to define and write custom metrics, which can then be used in dashboards and alerting policies. This is essential for capturing application-specific data that is not automatically collected by the default GKE integration, such as business KPIs or custom performance counters.

Exam trap

The trap here is that candidates confuse Cloud Monitoring with Cloud Logging, mistakenly thinking that log querying (Option A) is a core Monitoring feature, when in fact Monitoring is metric-centric and uses the Metrics Explorer, not the Logs Explorer.

Practice this question →
43
MCQhard

A digital media company hosts video content globally. They want to reduce origin server load and deliver content faster to viewers worldwide. Their current architecture routes all viewer requests directly to the origin servers in `us-central1`, causing high latency for viewers in Asia and Europe. Which Google Cloud networking capability addresses this?

A.Deploy identical origin servers in every Google Cloud region globally.
B.Enable Cloud CDN to cache video content at Google's global edge PoPs, serving viewers from the nearest location.
C.Use Cloud VPN to route viewer traffic through a direct tunnel to the origin servers.
D.Increase the origin servers' network bandwidth to handle more simultaneous viewer connections.
AnswerB

Cloud CDN leverages Google's global edge points of presence (PoPs) to cache and serve video content from the location geographically nearest to each viewer. When an Asian viewer requests a video, the request is routed to a nearby edge cache rather than traversing the long-haul network path to us-central1, which dramatically reduces round-trip time and jitter. Additionally, because edge caches absorb the bulk of repeated requests, the origin servers see far fewer direct hits, which reduces origin load and allows the infrastructure to scale cost-effectively for global audiences.

Why this answer

Cloud CDN uses Google's global edge Points of Presence (PoPs) to cache video content closer to viewers, reducing latency and offloading origin servers. When a viewer requests content, Cloud CDN serves it from the nearest edge cache if available, avoiding a direct trip to the origin in us-central1. This directly addresses the high latency for viewers in Asia and Europe without requiring server replication or bandwidth increases.

Exam trap

The GCDL exam often tests the misconception that 'more bandwidth' or 'replicating servers' is the primary solution for global latency, when in fact edge caching (Cloud CDN) is the correct, cost-effective approach for static and dynamic content delivery.

How to eliminate wrong answers

Option A is wrong because deploying identical origin servers in every region is an expensive and operationally complex solution that duplicates infrastructure unnecessarily; Cloud CDN achieves the same latency reduction using caching at edge locations without full server replication. Option C is wrong because Cloud VPN creates an encrypted tunnel for private connectivity between networks but does not cache content or reduce latency for global viewers; it only secures traffic routing, not accelerate delivery. Option D is wrong because increasing origin server bandwidth does not reduce the physical distance between viewers and the server; it only handles more concurrent connections, leaving high latency for distant viewers unresolved.

Practice this question →
44
MCQhard

Google Cloud's infrastructure is designed to be highly available across multiple failure domains. What are 'availability zones' in Google Cloud, and how do they differ from 'regions'?

A.Zones are continents; regions are individual countries within a continent.
B.A region is a geographic area containing multiple isolated zones; zones have independent failure domains but low-latency connectivity within the region.
C.Zones and regions are different terms for the same thing — Google uses them interchangeably.
D.A zone is a global resource; a region is a local data center.
AnswerB

A GCP region is a geographic area, typically a city or metropolitan area, that hosts at least three zones, each a physically separate data center with independent power, cooling, and network connectivity. These zones are isolated failure domains: an outage in one zone does not impair the others, which is the foundation for building high availability within a single region. At the same time, zones in a region are interconnected by low-latency links (commonly under 5 ms round trip), enabling synchronous replication and active-active workload designs across zones without cross-country delays. Thus, the combination of isolation and low latency lets you survive zone failures while maintaining fast performance.

Why this answer

In Google Cloud, a region is a specific geographic location composed of multiple zones, each of which is an isolated failure domain with independent power, cooling, and networking. Zones within the same region are connected by low-latency, high-bandwidth links, enabling high availability and fault tolerance for applications. This design ensures that a failure in one zone does not affect resources in another zone within the same region.

Exam trap

The trap here is that candidates often confuse zones with regions, thinking they are synonymous or hierarchical in a simplistic way (e.g., zones as sub-regions), rather than understanding that zones are independent failure domains within a region with low-latency interconnects.

How to eliminate wrong answers

Option A is wrong because zones are not continents; they are discrete data center clusters within a region, and regions are not individual countries but broader geographic areas that may span multiple countries or states. Option C is wrong because zones and regions are distinct concepts in Google Cloud; they are not interchangeable terms, and using them as such would lead to incorrect architectural decisions. Option D is wrong because a zone is not a global resource; it is a local deployment area within a region, and a region is not a single local data center but a collection of zones.

Practice this question →
45
MCQeasy

A developer is troubleshooting a slow response from a Cloud Run service. Which Google Cloud service can they use to trace requests across microservices?

A.Cloud Profiler
B.Cloud Trace
C.Cloud Logging
D.Cloud Debugger
AnswerB

Cloud Trace collects and aggregates latency data (trace spans) from distributed services, allowing developers to view the end-to-end journey of a single request, including delays in each service, RPC calls, and external API calls. It provides a waterfall view, which directly helps diagnose slow responses by identifying the bottleneck span. This makes it the correct tool for troubleshooting response latency.

Why this answer

Cloud Trace is the correct service because it is specifically designed for distributed tracing, collecting latency data from applications and displaying it in a trace timeline. It can trace requests as they propagate across multiple microservices, including Cloud Run services, by using trace context propagation headers (e.g., `X-Cloud-Trace-Context`). This allows the developer to identify bottlenecks and slow components in a request path.

Exam trap

The trap here is that candidates often confuse Cloud Trace with Cloud Logging, thinking that log aggregation alone can reconstruct request paths, but Cloud Trace is the only service that provides distributed tracing with explicit span context propagation across microservices.

How to eliminate wrong answers

Option A is wrong because Cloud Profiler is a statistical, low-overhead profiler that identifies which code paths consume the most CPU or memory, not a tool for tracing individual request flows across microservices. Option C is wrong because Cloud Logging aggregates and stores log entries but does not provide end-to-end request tracing or visualize the path of a single request across services. Option D is wrong because Cloud Debugger allows you to inspect the state of a running application at a specific code point without stopping it, but it does not trace request propagation or measure latency across services.

Practice this question →
46
MCQmedium

A cloud team receives an alert that a critical production service's error rate has spiked. Following incident response best practices, what is the correct first priority action?

A.Identify and fix the root cause before taking any other action to ensure the fix is complete
B.Mitigate user impact immediately (e.g., rollback, traffic rerouting, scaling) while beginning parallel investigation of the root cause
C.Wait to understand the full scope of the issue and inform all stakeholders before taking any technical action
D.Escalate to senior leadership and wait for their approval before making any production changes
AnswerB

Mitigation first is the correct incident response approach. Stop the bleeding before diagnosing the cause. If a recent deployment caused the spike, roll back immediately. If it's a capacity issue, scale up. Investigation into root cause runs in parallel but mitigation is prioritized.

Why this answer

Incident response best practices prioritize reducing user impact first. In Google Cloud, this could involve rolling back a deployment via Cloud Deploy, rerouting traffic with a load balancer, or scaling up instances with Managed Instance Groups, all while a parallel investigation into the root cause begins. This aligns with the SRE principle of 'error budget' and the 'mitigate before diagnose' approach.

Exam trap

The trap here is that candidates confuse 'root cause analysis' with 'first response' — Google Cloud often tests the principle that immediate mitigation (e.g., rollback, scaling) takes precedence over diagnosis, even if the fix is temporary.

How to eliminate wrong answers

Option A is wrong because it violates the incident response principle of 'stop the bleeding' first; waiting to fix the root cause before mitigating impact prolongs user downtime and can violate SLAs. Option C is wrong because waiting to understand the full scope before taking action delays mitigation, increasing user impact and potentially breaching SLOs; parallel investigation is key. Option D is wrong because escalating for approval before acting introduces unnecessary latency; incident response requires immediate technical action to restore service, with post-incident review for leadership.

Practice this question →
47
MCQmedium

A company wants to proactively identify underutilized Compute Engine VMs (high provisioned capacity but low actual usage) to reduce costs. Which Google Cloud tool provides recommendations for right-sizing VMs?

A.Cloud Monitoring — set alerts for low CPU utilization.
B.Active Assist Recommender — ML-based VM rightsizing recommendations.
C.Cloud Asset Inventory — lists all VMs and their configurations.
D.Cloud Billing budgets — set spending limits to prevent overspend.
AnswerB

Active Assist Recommender is the correct service because it uses machine learning trained on near-real-time utilization metrics from Compute Engine, including CPU, memory, network, and disk I/O, to generate specific rightsizing recommendations for each VM. For example, it may suggest moving from n2-standard-8 to n2-standard-4 based on sustained low usage, and it also provides an estimated monthly savings and a confidence score for every recommendation. These recommendations are actionable directly from the console or via the Recommender API, allowing you to apply the machine type change in one click or through infrastructure-as-code. This is precisely the targeted, data-driven guidance the scenario asks for—not just raw metrics or aggregate alerts.

Why this answer

Google Cloud's Active Assist provides intelligent recommendations including VM rightsizing recommendations. These are powered by ML analysis of actual VM CPU and memory utilization over the past 8 days. The recommendations appear in the Cloud Console (Compute Engine → VM instances → Recommendations) and in the Recommender API.

Rightsizing recommendations suggest optimal machine types based on observed usage, often identifying VMs that can be downsized to save significant costs.

Practice this question →
48
Matchingmedium

Match each Google Cloud security concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Identity and Access Management – fine-grained access control

Key Management Service for encryption keys

DDoS protection and web application firewall

Perimeter security to prevent data exfiltration

Centralized vulnerability and threat monitoring

Why these pairings

The correct matches are Cloud IAM (access control), Cloud KMS (key management), Cloud Security Command Center (threat detection), and Cloud DLP (data loss prevention). Common confusions include mixing up IAM with Security Command Center or KMS with Cloud Armor.

Practice this question →
49
Drag & Dropmedium

Drag and drop the steps to recover a Compute Engine VM from a snapshot in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The recovery process involves using the snapshot to create a disk, detaching the old boot disk, attaching the new one, and starting the VM.

Practice this question →
50
MCQhard

A global gaming company uses Cloud Spanner for their leaderboard. They notice that write latency spikes during peak hours. The database is currently deployed in a single region. Which scaling strategy should they implement to reduce write latency globally?

A.Use Cloud Spanner multi-region configuration.
B.Implement application-level caching with Memorystore.
C.Change to Cloud Bigtable for higher throughput.
D.Add more nodes to the existing Spanner instance.
AnswerA

Cloud Spanner multi-region configurations replicate each tablet across chosen regions and let you designate a default leader region for writes. Because every write commit is coordinated by the Paxos leader and its synchronous quorum, placing that leader near your gaming company's player-facing service reduces the network distance (RTT) for leaderboard score updates. Multi-region configurations also add regional and read-only replicas, so reads can be served close to players while write latency from remote locations drops substantially.

Why this answer

Cloud Spanner's multi-region configuration is designed to reduce write latency for globally distributed users by placing write-capable replicas in multiple geographic regions. This allows writes to be committed at the nearest replica, leveraging Spanner's TrueTime and Paxos-based replication to maintain strong consistency across regions. A single-region deployment forces all writes to a single location, causing high latency for distant clients during peak hours.

Exam trap

Google Cloud often tests the misconception that scaling a database horizontally by adding nodes always reduces latency, but in a single-region Spanner setup, adding nodes only increases throughput and storage, not geographic proximity, which is the root cause of high write latency for global users.

How to eliminate wrong answers

Option B is wrong because application-level caching with Memorystore does not reduce write latency to the database; it only improves read performance for cached data, and writes still must go to the single-region Spanner instance. Option C is wrong because Cloud Bigtable is optimized for high-throughput, low-latency reads and writes for analytical workloads, but it does not support strong transactional consistency or SQL queries, making it unsuitable for a leaderboard that requires real-time, consistent updates. Option D is wrong because adding more nodes to the existing single-region Spanner instance increases throughput and storage capacity but does not reduce write latency for clients far from that region; the write path still requires consensus across replicas in the same geographic location.

Practice this question →
51
MCQeasy

Google Cloud's operations suite includes Cloud Monitoring for metrics. What is the difference between 'monitoring' and 'observability' in cloud operations?

A.Monitoring and observability are identical terms — both describe collecting and analyzing system metrics.
B.Monitoring tracks predefined metrics and alerts on known conditions; observability is the system property enabling engineers to understand any internal state from its outputs (metrics, logs, traces).
C.Monitoring is for production; observability is for development and testing environments.
D.Observability only applies to AI systems; monitoring is for traditional applications.
AnswerB

This is the correct distinction. Monitoring is an active practice of tracking predefined metrics (e.g., request latency, queue depth) and comparing them against thresholds to trigger alerts for known or expected failure conditions. Observability is a passive system property — the degree to which a system's internal state can be inferred from its external outputs (structured logs, metrics, traces) without having to instrument it for every specific scenario. Proper observability requires the three pillars — metrics, logs, and traces — to be correlated so that when a metric goes out of range, engineers can trace through requests and inspect logs to understand why, even for never-before-seen failures.

Why this answer

Monitoring and observability are distinct concepts in cloud operations. Monitoring involves tracking predefined metrics and setting alerts for known failure conditions, while observability is a system property that allows engineers to understand any internal state by analyzing outputs like metrics, logs, and traces. In Google Cloud, Cloud Monitoring provides monitoring capabilities, but achieving true observability requires integrating Cloud Logging and Cloud Trace to explore unknown issues.

Exam trap

Google Cloud often tests the misconception that monitoring and observability are interchangeable terms, but the trap here is that monitoring is reactive to known conditions, while observability is a proactive property for diagnosing unknown issues.

How to eliminate wrong answers

Option A is wrong because monitoring and observability are not identical; monitoring is a subset of observability, focusing on known metrics, whereas observability enables exploration of unknown states. Option C is wrong because observability is not limited to development and testing; it is critical in production to debug complex, unpredictable issues. Option D is wrong because observability applies to all systems, not just AI, and monitoring is used across all application types, not just traditional ones.

Practice this question →
52
MCQeasy

A company wants to reduce its Google Cloud costs without reducing its workload capacity. The team identifies that several production VMs consistently use less than 30% of their allocated CPU and memory. What is the most straightforward cost optimization action?

A.Delete the under-utilized VMs since low utilization indicates they are no longer needed
B.Right-size the VMs by migrating to smaller machine types that match actual CPU and memory consumption, reducing costs proportionally
C.Purchase Committed Use Discounts for the over-provisioned VMs to reduce their per-hour cost
D.Enable sustained use discounts by ensuring VMs run continuously throughout the month
AnswerB

Right-sizing is the direct action. If VMs use 30% of their resources, a smaller machine type that provides the resources actually needed (with some headroom for spikes) costs significantly less. Active Assist proactively surfaces right-sizing recommendations with projected savings.

Why this answer

Right-sizing VMs by migrating to smaller machine types that match actual CPU and memory consumption directly reduces the cost per hour while maintaining the same workload capacity. Since the VMs are consistently under-utilized, this approach eliminates wasted resources without affecting performance or availability.

Exam trap

Google Cloud often tests the misconception that deleting under-utilized VMs is the simplest cost-saving action, but the question explicitly states workload capacity must be maintained, making right-sizing the correct approach.

How to eliminate wrong answers

Option A is wrong because deleting under-utilized VMs would reduce workload capacity, contradicting the requirement to maintain capacity; low utilization does not mean the VMs are unnecessary. Option C is wrong because Committed Use Discounts (CUDs) reduce the per-hour cost of existing machine types but do not address the root cause of over-provisioning; you would still pay for unused capacity. Option D is wrong because sustained use discounts are automatically applied for VMs running >25% of a month and do not require enabling; they also do not reduce costs from over-provisioned resources.

Practice this question →
53
MCQmedium

You are monitoring Compute Engine instances with Cloud Monitoring. You notice that autoscaling is not triggering even though CPU utilization is above 80% for several minutes. The managed instance group has autoscaling based on CPU utilization with a target of 0.8. What is the most likely cause?

A.The maximum number of instances is already reached.
B.The autoscaler is disabled.
C.The minimum number of instances is set too high.
D.The cool-down period is too long.
AnswerA

The Managed Instance Group (MIG) autoscaler's scaling decision is fundamentally constrained by the group's `maxNumReplicas`/max size. When the current running instance count equals this upper bound, the autoscaler will not add new VMs even if the aggregated CPU utilization remains persistently above the target threshold, because that would violate the configured capacity limit. In this state, the autoscaler is effectively 'capped' and any observed lack of scale-out is the intended, expected behavior, not a failure of the monitoring or autoscaling logic.

Why this answer

The most likely cause is that the managed instance group has already reached its configured maximum number of instances. When the maximum instance count is hit, the autoscaler cannot add more instances even if CPU utilization exceeds the target of 0.8 (80%). This is a common boundary condition in autoscaling logic where the scaling policy is overridden by the hard limit.

Exam trap

The trap here is that candidates often focus on the CPU target and cool-down settings, overlooking the hard boundary of the maximum instance count, which is a fundamental constraint in autoscaling logic.

How to eliminate wrong answers

Option B is wrong because if the autoscaler were disabled, no scaling events would occur at all, but the question states that autoscaling is not triggering despite high CPU, implying the autoscaler is enabled but blocked. Option C is wrong because a high minimum number of instances would cause the autoscaler to keep instances running, not prevent it from scaling up; it would actually ensure a baseline, not block scaling. Option D is wrong because a long cool-down period delays scaling actions but does not permanently prevent them; after the cool-down expires, the autoscaler would still trigger if CPU remains high.

Practice this question →
54
MCQmedium

A company's application experiences a P1 (critical) production incident at 2 AM on a Sunday. The on-call engineer resolves the issue after 3 hours but isn't sure which team members to contact or what steps to follow during an incident. What operational practice and tooling would have helped manage this incident better?

A.Increase the application's max_instances so it scales to handle the issue automatically.
B.Establish a documented incident response process with defined roles, escalation paths, and runbooks, supported by on-call rotation tooling and Cloud Monitoring alerting.
C.Move all production deployments to Sunday nights to avoid weekday incident risk.
D.Disable monitoring alerts to prevent false alarms that wake engineers unnecessarily.
AnswerB

A documented incident response process with defined roles, escalation paths, and runbooks creates a repeatable, predictable method to manage production disruptions. On-call rotation tooling ensures there is always a responsible engineer who can be alerted immediately, and Cloud Monitoring alerts trigger that rotation based on SLO-oriented metrics. This combination directly addresses the root cause of the issue—the lack of a coordinated response—by turning an unmanaged outage into a structured recovery with clear ownership and steps.

Why this answer

A documented incident response process with defined roles, escalation paths, and runbooks ensures that the on-call engineer knows exactly whom to contact and what steps to follow during a P1 incident. Combined with on-call rotation tooling (e.g., PagerDuty, Opsgenie) and Cloud Monitoring alerting, this practice reduces mean time to acknowledge (MTTA) and mean time to resolve (MTTR) by providing clear, repeatable procedures. Without such a process, the engineer wasted time determining the response, which a runbook would have eliminated.

Exam trap

Google Cloud often tests the misconception that scaling or automation alone can replace a documented incident response process, but the question explicitly asks about operational practice and tooling for managing the incident, not just fixing the technical issue.

How to eliminate wrong answers

Option A is wrong because increasing max_instances only addresses scaling under load, not the lack of an incident response process; it does not help the engineer know whom to contact or what steps to follow. Option C is wrong because moving deployments to Sunday nights does not resolve the core issue of missing incident management procedures; it merely shifts the timing and could increase risk if a deployment causes the incident. Option D is wrong because disabling monitoring alerts would prevent detection of the incident altogether, worsening the problem rather than improving the response process.

Practice this question →
55
MCQmedium

A product team is discussing how to handle a planned 48-hour maintenance window for a critical customer-facing service. The SRE team argues the maintenance window is unnecessary with proper cloud architecture. Which cloud capability eliminates the need for planned downtime maintenance windows?

A.Longer maintenance windows scheduled during off-peak hours to minimize customer impact
B.Zero-downtime deployment strategies like rolling updates and blue/green deployments, combined with cloud live migration for infrastructure maintenance
C.Notifying customers in advance of the maintenance window and offering service credits for the downtime
D.Backing up all data before the maintenance window to ensure recovery if something goes wrong
AnswerB

This is the architectural answer to planned downtime. Rolling updates deploy new code gradually (some instances get new version while others serve traffic). Blue/green deployments switch traffic atomically. Live migration moves VMs between physical hosts for maintenance without rebooting. Together, these eliminate the need for maintenance windows.

Why this answer

Cloud platforms like Google Cloud support zero-downtime deployment strategies (rolling updates, blue/green deployments) and live migration for infrastructure maintenance. Live migration transparently moves running VMs between hosts without interrupting the OS or applications, while blue/green deployments allow traffic to be switched to a fully updated environment before the old one is taken down. Together, these capabilities eliminate the need for planned downtime maintenance windows entirely.

Exam trap

The trap here is that candidates confuse 'reducing impact' (options A, C, D) with 'eliminating downtime' (option B), failing to recognize that only architectural strategies like live migration and zero-downtime deployments remove the need for a maintenance window altogether.

How to eliminate wrong answers

Option A is wrong because scheduling longer maintenance windows during off-peak hours still requires planned downtime, which contradicts the goal of eliminating it entirely. Option C is wrong because notifying customers and offering service credits does not prevent downtime; it only compensates for it after the fact. Option D is wrong because backing up data before a maintenance window is a recovery measure, not a prevention strategy, and does not eliminate the need for downtime during the maintenance.

Practice this question →
56
MCQmedium

A company's cloud costs have grown faster than its business. The FinOps team is implementing cloud cost governance. Which practice most effectively ensures that individual teams are accountable for their cloud spending?

A.Requiring all teams to use only the cheapest available cloud service options regardless of technical requirements
B.Implementing consistent resource labeling and chargeback reporting so each team's cloud spending is visible and attributed to them
C.Consolidating all cloud accounts under a single centralized IT team that controls all cloud resource creation
D.Disabling all non-production environments to eliminate spending outside of production
AnswerB

Labeling (attaching team/product/cost center metadata to every cloud resource) enables per-team cost attribution from billing data. Chargeback transfers the cost to the team's budget; showback provides visibility. Both create accountability by making spending visible and personally consequential to the team that incurs it.

Why this answer

Implementing consistent resource labeling and chargeback reporting directly enables cost attribution to individual teams. In Google Cloud, labels are key-value pairs attached to resources, and when combined with billing export to BigQuery, they allow granular cost breakdowns per team. This creates clear accountability by making each team's spending visible and chargeable back to their budget, which is the core principle of cloud cost governance.

Exam trap

Google Cloud often tests the misconception that cost governance is about restricting spending (options A, C, D) rather than enabling visibility and accountability through attribution mechanisms like labeling and chargeback.

How to eliminate wrong answers

Option A is wrong because forcing all teams to use the cheapest cloud service options regardless of technical requirements can lead to performance degradation, security vulnerabilities, or non-compliance, and it does not foster accountability—it imposes a blanket restriction that ignores workload-specific needs. Option C is wrong because consolidating all cloud accounts under a single centralized IT team that controls all resource creation removes team autonomy and creates a bottleneck, which often leads to shadow IT as teams bypass controls, and it does not make individual teams accountable for their spending. Option D is wrong because disabling all non-production environments eliminates testing and development, which are essential for innovation and quality assurance, and it does not address cost governance—it only cuts costs at the expense of business operations.

Practice this question →
57
MCQhard

A company uses Google Cloud across 5 teams, 20 projects, and 3 regions. They want to enforce a standard that all resources include specific labels (e.g., `team`, `environment`, `cost-center`) for cost attribution and governance. What is the most scalable way to enforce this labeling standard?

A.Send monthly reminders to all teams via email to add labels to their resources.
B.Enforce labeling through IaC templates with required label variables in CI/CD pipelines, and use Cloud Asset Inventory to audit compliance.
C.Manually add labels to all existing and new resources through the Cloud Console.
D.Grant only project owners permission to create resources, and rely on them to enforce labeling.
AnswerB

Enforcing labels through Infrastructure as Code (e.g., Terraform or Deployment Manager) makes labels a mandatory input in your templates, so any resource that does not include required label keys fails the plan/apply step. CI/CD pipelines can run additional policy checks (such as `terraform plan -var` validation or a custom script) to detect missing labels before deployment, preventing unlabeled resources from ever being created. Cloud Asset Inventory then provides a continuously updated searchable view of all assets and their labels, allowing you to audit compliance across all 20 projects and quickly identify any drift introduced by out-of-band changes. This combination of prevention at creation and detection afterward is the only fully automated and scalable approach.

Why this answer

It combines Infrastructure as Code (IaC) templates with required label variables in CI/CD pipelines to enforce labeling at resource creation time, and uses Cloud Asset Inventory to audit and detect non-compliant resources. This approach is scalable across 5 teams, 20 projects, and 3 regions because it automates enforcement and provides continuous compliance monitoring without manual intervention.

Exam trap

The trap here is that candidates may choose a manual or human-dependent option (like A or D) because they underestimate the scale and automation requirements of a multi-team, multi-project environment, failing to recognize that only IaC with automated auditing provides scalable enforcement.

How to eliminate wrong answers

Option A is wrong because sending monthly reminders is a manual, reactive process that does not prevent non-compliant resources from being created, and it does not scale across multiple teams and projects. Option C is wrong because manually adding labels through the Cloud Console is error-prone, does not scale to 20 projects and 3 regions, and cannot enforce labeling on new resources automatically. Option D is wrong because relying solely on project owners to enforce labeling is not scalable or auditable; it depends on human compliance and does not provide automated enforcement or detection of violations.

Practice this question →
58
Matchingmedium

Match each Google Cloud serverless compute option to its characteristic.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Event-driven, short-lived functions

Container-based, scales to zero

Platform as a Service (PaaS) with automatic scaling

Orchestration of services and APIs

Event routing and management service

Why these pairings

The correct matches are: Cloud Functions for event-driven execution, Cloud Run for containerized HTTP services, and App Engine for managed web applications. Common confusions involve swapping the event-driven nature of Cloud Functions with the container-based approach of Cloud Run, or pairing App Engine with event-driven triggers instead of web app hosting.

Practice this question →
59
MCQeasy

An operations team wants to receive an automated alert when their web application's HTTP error rate exceeds 5% for more than 5 minutes. Which Google Cloud product is used to configure this type of metric-based alert?

A.Cloud Logging, by configuring a log-based metric and email notification
B.Cloud Monitoring, by creating an alerting policy on the HTTP error rate metric with a 5-minute evaluation window and notification channel
C.Cloud Trace, by setting a trace sampling threshold for error requests
D.Security Command Center, by configuring a finding for high error rates
AnswerB

Cloud Monitoring is the correct service. An alerting policy specifies: the metric to watch (HTTP error rate), the threshold (5%), the evaluation window (5 minutes), and the notification channel (email, PagerDuty, Slack, etc.). This is a core Cloud Monitoring capability.

Why this answer

Cloud Monitoring is the correct service because it is purpose-built for creating alerting policies based on metrics like HTTP error rates. You can define a condition that triggers when the error rate exceeds 5% for a specified evaluation window (e.g., 5 minutes) and route the alert through a notification channel (e.g., email, Slack). This directly matches the requirement for a metric-based alert with a time-based threshold.

Exam trap

Google Cloud often tests the misconception that Cloud Logging can directly send alerts, but in reality, Cloud Logging only stores logs and log-based metrics; the alerting policy must always be configured in Cloud Monitoring.

How to eliminate wrong answers

Option A is wrong because Cloud Logging is used for storing and querying log data, not for creating metric-based alerts on HTTP error rates; while log-based metrics can be created, the alert itself must be configured in Cloud Monitoring, and Cloud Logging does not natively support email notification channels for alerts. Option C is wrong because Cloud Trace is a distributed tracing tool for analyzing request latency and performance, not for monitoring error rates or triggering alerts based on percentage thresholds. Option D is wrong because Security Command Center is a security and risk management service that provides findings for vulnerabilities and threats, not for operational metric-based alerting on web application error rates.

Practice this question →
60
MCQhard

A company's SRE team sets an SLO of 99.5% monthly availability for a non-critical internal tool. A business stakeholder argues the target should be 99.99%. The SRE team pushes back. Which SRE argument best supports keeping the 99.5% target?

A.Higher SLOs are always more expensive to achieve and the company cannot afford cloud infrastructure that provides 99.99% availability
B.For a non-critical internal tool, 99.99% reliability requires disproportionate engineering investment (redundancy, 24/7 on-call, chaos testing) compared to its business value; 99.5% matches the actual reliability need while preserving engineering capacity for higher-value work
C.Google Cloud cannot provide 99.99% availability for any service, so the SLO must be kept lower
D.The team should set 99.5% now and plan to increase it to 99.99% next quarter when the tool becomes more popular
AnswerB

This is the SRE argument. Reliability is not free — achieving 99.99% requires architectural complexity, 24/7 on-call readiness, and ongoing reliability engineering. For an internal tool, this investment would consume engineering time that could build features users value more. The SLO should match what the business actually needs, not maximize reliability for its own sake.

Why this answer

Ly applies the SRE principle of aligning SLOs with business value. For a non-critical internal tool, the cost of achieving 99.99% availability—including redundant infrastructure, 24/7 on-call rotations, and chaos engineering—far exceeds the marginal benefit over 99.5%. This preserves engineering capacity for higher-value work, which is a core tenet of Google's SRE approach to error budgets and cost-benefit analysis.

Exam trap

Google Cloud often tests the misconception that higher SLOs are always better or that cloud providers universally guarantee high availability, when the correct SRE approach is to set SLOs based on the actual user experience and business impact, not arbitrary targets.

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes higher SLOs are always more expensive; the real issue is disproportionate cost relative to business value, not absolute affordability. Option C is wrong because Google Cloud does offer services with 99.99% availability (e.g., Cloud Spanner multi-region configurations), so the statement is factually incorrect. Option D is wrong because it suggests a planned future increase without justification; SLOs should be set based on current reliability needs and error budget policy, not arbitrary future popularity.

Practice this question →
61
Multi-Selectmedium

Which TWO statements correctly describe Cloud Run scaling behavior?

Select 2 answers
A.The maximum number of instances can be set to 'default' which is unlimited.
B.You can set a minimum number of instances to ensure zero cold starts.
C.You can define a target concurrency to control how many requests each container instance handles.
D.The number of container instances can be scaled to zero when there is no traffic.
E.Autoscaling uses CPU and memory utilization to make decisions.
AnswersC, D

Cloud Run's container concurrency setting defines the maximum number of simultaneous requests each instance can process. Autoscaling uses this concurrency target to decide when to add or remove instances, ensuring that requests are distributed without overloading a single container. By adjusting this value, you can trade off between latency and resource efficiency, as lower concurrency increases instance count while higher concurrency packs more requests per instance.

Why this answer

Cloud Run allows you to set a target concurrency (the number of simultaneous requests a single container instance can handle). This is a key scaling parameter that controls how many requests are routed to each instance before Cloud Run spins up additional instances. By default, concurrency is set to 80, but you can adjust it up to 1000 or set it to 1 for sequential processing.

Exam trap

Google Cloud often tests the misconception that Cloud Run uses CPU or memory utilization for autoscaling, when in fact it uses request concurrency as the primary metric, and candidates may incorrectly select Option E because they associate autoscaling with resource metrics from other services.

Practice this question →
62
MCQhard

A company is evaluating whether to adopt a multi-cloud strategy (using two or more cloud providers for different workloads). An engineer lists the following arguments: (1) resilience against a single cloud provider outage, (2) negotiating leverage on pricing, (3) using best-of-breed services from each provider. A cloud architect cautions that multi-cloud also introduces significant challenges. What is the most significant operational challenge of a multi-cloud approach?

A.Multi-cloud requires purchasing separate hardware for each cloud provider's environment
B.Significantly increased operational complexity: teams need expertise in multiple providers' tools, security models, and APIs, while governance, monitoring, and cost management must span inconsistent environments
C.Cloud providers refuse to allow customers to use competing providers simultaneously
D.Multi-cloud makes it impossible to use any managed services because applications must be portable across providers
AnswerB

This is the primary challenge. Every cloud provider has different services, CLIs, IAM systems, networking models, pricing, and monitoring tools. Maintaining expertise and governance across multiple providers dramatically increases the operational burden and requires larger, more specialized teams. The benefits must be weighed against this real cost.

Why this answer

Multi-cloud environments inherently increase operational complexity. Teams must master distinct APIs, security models (e.g., IAM policies differ between AWS and GCP), monitoring tools (e.g., CloudWatch vs. Cloud Monitoring), and cost management consoles.

Governance and compliance must be enforced consistently across heterogeneous platforms, which often requires custom tooling or third-party solutions, making day-to-day operations significantly more challenging than a single-cloud approach.

Exam trap

The trap here is that candidates may underestimate operational complexity and instead focus on perceived hardware or vendor lock-in issues, but the GCDL exam emphasizes that managing multiple distinct cloud environments is the primary operational challenge.

How to eliminate wrong answers

Option A is wrong because multi-cloud does not require purchasing separate hardware; cloud providers abstract the underlying infrastructure, and customers interact via APIs and virtualized resources. Option C is wrong because cloud providers do not prohibit customers from using competing providers; multi-cloud is a common and supported architecture. Option D is wrong because multi-cloud does not make managed services impossible; applications can use provider-specific managed services (e.g., GCP Cloud SQL, AWS RDS) while abstracting portability via containers or service meshes, though portability is not a strict requirement.

Practice this question →
63
MCQeasy

A cloud architect is reviewing logs from a production incident. She wants to search all log entries across multiple Google Cloud projects for error messages containing a specific string. Which Google Cloud product enables centralized log searching and analysis across an entire organization?

A.Cloud Monitoring, which provides metric dashboards and alerting
B.Cloud Logging, which centralizes logs from all Google Cloud services and projects and supports powerful filtering and search queries across an organization
C.BigQuery, by exporting logs to a dataset and running SQL queries to find matching error entries
D.Cloud Trace, which provides distributed request tracing for latency analysis
AnswerB

Cloud Logging is the correct answer. It aggregates logs from all sources (Compute Engine, Cloud Run, GKE, App Engine, etc.) across all projects into a centralized store. Its query language allows searching for specific text strings, error levels, time ranges, and resource attributes across the entire organization.

Why this answer

Cloud Logging (formerly Stackdriver Logging) is the Google Cloud service designed to ingest, store, and analyze log data from all Google Cloud services and projects. It supports centralized log aggregation across an entire organization via aggregated sinks and the Logs Explorer, enabling powerful filtering and search queries (e.g., using the `textPayload` or `jsonPayload` fields) to find specific error strings across multiple projects without needing to export data elsewhere.

Exam trap

Google Cloud often tests the distinction between native log search (Cloud Logging) and log export/analysis (BigQuery), tempting candidates to choose BigQuery because they know SQL, but the question specifically asks for a product that enables centralized searching without requiring an export step.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring focuses on metrics, dashboards, and alerting based on time-series data, not on searching raw log entries for specific error strings. Option C is wrong because while BigQuery can query exported logs via SQL, it is not a native centralized log search tool; it requires an additional export step and does not provide real-time log searching across the organization without manual setup. Option D is wrong because Cloud Trace is designed for distributed request tracing and latency analysis, not for searching log entries for error messages.

Practice this question →
64
MCQeasy

A company's web service has a Service Level Objective (SLO) of 99.9% monthly availability. In a 30-day month, how many minutes of downtime are allowed before the SLO is violated?

A.~4.3 minutes
B.~43.2 minutes
C.~7.2 hours
D.~8.6 hours
AnswerB

In a 30-day month there are 43,200 minutes (30 × 24 × 60). 99.9% availability permits 0.1% downtime, so the error budget is 0.001 × 43,200 = 43.2 minutes. This is the classic 'three nines' SLO calculation and implies that a service can be unavailable for a total of 43 minutes and 12 seconds per month while still meeting the target.

Why this answer

The SLO of 99.9% monthly availability means the service can be unavailable for 0.1% of the total monthly time. In a 30-day month, total minutes are 30 × 24 × 60 = 43,200 minutes. 0.1% of 43,200 minutes is 43.2 minutes, so option B is correct.

Exam trap

The trap here is that candidates often confuse 99.9% with 99.99% (four nines) and incorrectly calculate ~4.3 minutes, or they mistakenly compute 0.1% of 30 days in hours (0.072 hours) and then misread it as 7.2 hours.

How to eliminate wrong answers

Option A is wrong because ~4.3 minutes corresponds to 99.99% availability (0.01% of 43,200 minutes), not 99.9%. Option C is wrong because ~7.2 hours (432 minutes) corresponds to 99% availability (1% of 43,200 minutes). Option D is wrong because ~8.6 hours (516 minutes) is not a standard SLO calculation; it might arise from miscomputing 0.1% of 30 days in hours (0.1% of 720 hours = 0.72 hours, not 8.6 hours).

Practice this question →
65
MCQmedium

A company's application experiences traffic spikes every weekday morning when employees log in at 9 AM. The team wants their infrastructure to automatically handle these spikes without manual intervention and without over-provisioning resources all day. Which Google Cloud capability addresses this?

A.Purchase reserved capacity for peak load and configure it to be active only on weekdays.
B.Configure autoscaling on the application's infrastructure to automatically scale up for load and scale down during off-peak hours.
C.Deploy additional VMs manually each weekday morning and terminate them at night.
D.Use Cloud Monitoring to send an email alert when CPU exceeds 80% so the team can manually scale.
AnswerB

Configuring autoscaling on the application's infrastructure directly addresses the requirement for automatic response to load. An autoscaler continuously monitors metrics such as CPU utilization, request count, or custom application metrics and dynamically adjusts the number of VM instances in a managed instance group. For the predictable 9 AM weekday spike, you can combine scheduled autoscaling (proactively adding capacity before the spike) with reactive autoscaling (handling unexpected bursts in real time). When traffic decreases during off-peak hours, the autoscaler automatically terminates excess instances, ensuring cost efficiency without human involvement.

Why this answer

Google Cloud's managed instance groups (MIGs) with autoscaling can automatically adjust the number of VM instances based on load metrics (e.g., CPU utilization, requests per second). This handles the 9 AM traffic spike without manual intervention and avoids over-provisioning during off-peak hours by scaling down when demand decreases.

Exam trap

The trap here is that candidates confuse 'reserved capacity' (a billing commitment) with 'autoscaling' (an operational scaling mechanism), or they think manual or alert-based actions satisfy the 'automatic' requirement, but The GCDL exam specifically tests the distinction between automated scaling policies and manual or notification-driven processes.

How to eliminate wrong answers

Option A is wrong because reserved capacity (committed use discounts) is a pricing model for consistent, long-term usage, not a mechanism to dynamically activate resources only on weekdays; it does not automatically handle spikes. Option C is wrong because manually deploying and terminating VMs each weekday contradicts the requirement for 'automatic' handling without manual intervention. Option D is wrong because Cloud Monitoring alerts require human action to scale, which is not automatic and introduces delay, failing the 'without manual intervention' requirement.

Practice this question →
66
MCQmedium

An SRE team has a monthly error budget of 43 minutes (99.9% SLO). In the first week of the month, a deployment causes a 50-minute outage. What should the SRE team do for the remainder of the month, and why?

A.Immediately deploy a hotfix to restore features that were rolled back during the outage.
B.Freeze feature deployments for the rest of the month, focus on reliability improvements, and investigate the deployment process that caused the outage.
C.Negotiate with stakeholders to increase the SLO to 99.5% to get more error budget.
D.Continue deploying features normally — the outage was a one-time event and won't happen again.
AnswerB

With the error budget exhausted, the SLO is already at risk of being violated; continuing to ship features would only deepen the reliability debt. An SRE response to budget exhaustion is to declare a freeze on feature deployments and redirect all engineering effort to reliability improvements and root-cause analysis. Investigating the deployment process—not just the immediate failure—prevents the same defect from recurring, while reliability work replenishes the budget by reducing future error rates. This is the correct, disciplined response because it treats the budget as a hard control, not a suggestion.

Why this answer

The team has already consumed more than the entire monthly error budget (50 minutes used vs. 43 minutes allowed). To avoid violating the 99.9% SLO for the rest of the month, they must freeze feature deployments and focus on reliability improvements. This is a core SRE practice: when the error budget is exhausted, the team shifts from feature velocity to stability, investigating the root cause and hardening the deployment process.

Exam trap

The GCDL exam often tests the misconception that you can 'negotiate' or 'increase' the SLO to fix an error budget deficit, but increasing the SLO actually tightens the budget, and the correct response is to halt feature deployments until the next budget window.

How to eliminate wrong answers

Option A is wrong because deploying a hotfix to restore rolled-back features would introduce further change risk when the error budget is already negative, potentially causing additional downtime and SLO violations. Option C is wrong because negotiating to increase the SLO to 99.5% (which actually reduces the error budget to ~21.6 minutes per month) would make the situation worse, not better; the team needs more error budget, not less. Option D is wrong because continuing normal deployments ignores the fact that the error budget is exhausted; treating a 50-minute outage as a one-time event is a common fallacy that ignores the statistical reality of SLOs and the need to preserve remaining budget for unforeseen incidents.

Practice this question →
67
MCQmedium

A company runs a web application on Compute Engine instances behind a managed instance group with autoscaling based on CPU utilization. After a marketing campaign, traffic spikes and the autoscaler adds instances quickly, but the application becomes slow. What is the most likely cause?

A.Autoscaler uses CPU utilization but the application is memory-bound
B.Instances are in different zones causing inter-zone latency
C.Autoscaling cooldown period is too short
D.Health check interval is too long
AnswerA

The autoscaler adds instances based on CPU utilization, but if the application is memory-bound, additional instances will still contend for the same memory resources, and each new instance adds per-instance memory overhead. The bottleneck remains, so scaling horizontally on a mismatched metric does not address the root cause; memory stays saturated, and the application continues to experience slowness.

Why this answer

The autoscaler adds instances based on CPU utilization, but if the application is memory-bound, adding more instances does not alleviate memory pressure. Each new instance still runs the same memory-intensive workload, so CPU may remain low while memory is exhausted, causing slowdowns. The autoscaler fails to address the actual bottleneck, leading to poor performance despite scaling out.

Exam trap

The trap here is that candidates assume CPU utilization is always the correct metric for scaling, but the question tests the understanding that autoscaling only works well when the chosen metric matches the actual bottleneck of the application.

How to eliminate wrong answers

Option B is wrong because managed instance groups with autoscaling can span multiple zones, but inter-zone latency within the same region is negligible (typically <1ms) and would not cause significant slowdowns. Option C is wrong because a cooldown period that is too short would cause the autoscaler to add instances too aggressively, not make the application slow; it might lead to over-provisioning or thrashing, but not directly to performance degradation. Option D is wrong because a health check interval that is too long delays detection of unhealthy instances, but does not cause the application to become slow; it affects availability, not performance under load.

Practice this question →
68
MCQeasy

A large online retailer operates a microservices-based e-commerce platform on Google Kubernetes Engine (GKE) across multiple zones. The application consists of several stateless services that handle customer traffic, inventory, and order processing. Recently, the company migrated its relational database to Cloud Spanner to achieve global scalability and strong consistency. After the migration, during peak shopping periods (e.g., Black Friday), the application experiences significant performance degradation. The operations team monitors CPU utilization of the pods and finds it consistently below 60% even under heavy load. However, Cloud Spanner metrics show high query latency and increased number of transactions waiting for lock conflicts. The team suspects that the bottleneck is now the database, not the compute. The application is designed to scale horizontally by adding more pod replicas. The team wants to ensure that scaling decisions are based on the actual performance bottleneck. What should they do?

A.Scale the GKE cluster to use larger node instances.
B.Increase the CPU request limit for the pods to allow higher CPU usage.
C.Reduce the number of pods to decrease Spanner load.
D.Modify the Horizontal Pod Autoscaler (HPA) to scale based on a custom metric that reflects Cloud Spanner query latency.
AnswerD

Configuring the Horizontal Pod Autoscaler to use a custom metric based on Cloud Spanner query latency ensures that the number of pods scales in direct response to the real bottleneck. You can expose a metric such as the 99th percentile query latency from Spanner via Google Cloud Monitoring, and the HPA can use this via the Kubernetes Metrics API. When Spanner latency increases, the autoscaler adds more pods to distribute outstanding queries, reducing per-pod concurrency and preventing timeouts. This is preferable to CPU-based autoscaling because it captures database-side health and aligns scaling decisions with the actual user-facing performance.

Why this answer

The Horizontal Pod Autoscaler (HPA) can be configured to scale based on custom metrics, such as Cloud Spanner query latency. Since the bottleneck is the database, scaling pods based on CPU utilization (which remains low) would not resolve the issue; instead, scaling based on Spanner latency ensures that the application adds replicas only when the database can handle more connections, reducing lock contention and improving overall performance.

Exam trap

Google Cloud often tests the misconception that CPU utilization is always the correct metric for scaling, but in this scenario, the bottleneck is the database, so candidates must recognize that custom metrics (like Spanner latency) are needed to scale the application appropriately.

How to eliminate wrong answers

Option A is wrong because scaling the GKE cluster to use larger node instances increases compute resources, but the bottleneck is the database (Cloud Spanner), not CPU or memory; larger nodes would not reduce Spanner query latency or lock conflicts. Option B is wrong because increasing the CPU request limit for pods does not address the database bottleneck; it would allow pods to consume more CPU, but CPU utilization is already below 60%, so this change would not improve Spanner performance and could waste resources. Option C is wrong because reducing the number of pods would decrease the load on Spanner, but it would also reduce the application's ability to handle customer traffic, potentially causing service degradation; the goal is to scale based on the actual bottleneck, not to arbitrarily reduce capacity.

Practice this question →
69
MCQeasy

A company has a stateful application running on Compute Engine. They want to scale horizontally while preserving state. Which configuration should they use?

A.Use Cloud Run with volumes.
B.Unmanaged instance group.
C.Managed instance group with stateful configuration.
D.Managed instance group with autoscaling and no stateful configuration.
AnswerC

A managed instance group with stateful configuration is the correct choice because it combines autoscaling with per-instance preservation of boot disks, data disks, and instance names. Through per-instance configs, you can mark certain VMs as stateful, preventing the autoscaler from deleting them during scale-in while still allowing scale-out. This keeps the application's persistent state intact across the group's lifecycle, enabling horizontal scaling without losing data.

Why this answer

A managed instance group (MIG) with stateful configuration preserves instance-specific state (such as disks, hostnames, and metadata) across autohealing and rolling updates. This allows the stateful application to scale horizontally while maintaining its persistent data, as each instance retains its unique state even when the group is resized or instances are recreated.

Exam trap

The trap here is that candidates often assume all managed instance groups automatically preserve state, but without explicit stateful configuration, MIGs treat instances as ephemeral and will delete persistent disks on instance deletion or during rolling updates.

How to eliminate wrong answers

Option A is wrong because Cloud Run is a serverless platform designed for stateless containers; while it supports volumes, they are ephemeral or read-only (e.g., Cloud Storage FUSE or NFS), and Cloud Run does not natively preserve instance-level state across scaling events or container restarts. Option B is wrong because an unmanaged instance group does not provide autohealing, autoscaling, or stateful configuration; it requires manual management and cannot automatically preserve state during horizontal scaling. Option D is wrong because a managed instance group with autoscaling and no stateful configuration treats all instances as stateless; when instances are terminated or recreated, any local state (e.g., data on persistent disks) is lost, making it unsuitable for stateful applications.

Practice this question →
70
MCQeasy

A company wants to optimize Cloud Storage costs for a bucket containing 100 TB of access logs. The logs from the last 7 days are frequently analyzed; logs from 8–90 days are occasionally reviewed; logs older than 90 days are archived for compliance but rarely accessed. What is the most cost-effective storage class configuration?

A.Store all 100 TB in Standard storage for consistent access performance.
B.Configure lifecycle rules: Standard (0-7 days) → Nearline (8-90 days) → Archive (90+ days).
C.Delete all logs older than 7 days to minimize storage costs.
D.Store all logs in Archive storage since most are rarely accessed.
AnswerB

This is the correct approach because Cloud Storage lifecycle rules automate the transition of objects based on age, letting you match storage costs to real access patterns. The 0-7 day window in Standard supports immediate diagnosis and troubleshooting, the 8-90 day window in Nearline provides a low-cost option for occasional review, and the 90+ day window in Archive satisfies long-term compliance retention at the lowest possible storage price. Each class has different retrieval costs and minimum durations, and these boundaries align the cost structure with the operational and regulatory requirements.

Why this answer

It aligns the storage class with the access patterns of the logs: Standard for frequently accessed recent data, Nearline for occasional access, and Archive for rarely accessed compliance data. This minimizes costs by using cheaper storage for older data while maintaining performance for active analysis. Lifecycle rules automate the transition, ensuring no manual intervention is needed.

Exam trap

Google Cloud often tests the misconception that Archive storage is always the cheapest option, ignoring the retrieval costs and latency for frequently accessed data, leading candidates to choose Option D.

How to eliminate wrong answers

Option A is wrong because storing all 100 TB in Standard storage is unnecessarily expensive for logs older than 7 days that are rarely accessed. Option C is wrong because deleting logs older than 7 days violates compliance requirements and loses data that may be needed for audits or occasional review. Option D is wrong because storing all logs in Archive storage would cause high retrieval costs and latency for the frequently accessed last 7 days of logs, making it impractical for active analysis.

Practice this question →
71
MCQeasy

A company's cloud environment has grown rapidly and the team is struggling to understand what cloud resources exist across dozens of projects. Which Google Cloud product provides a unified inventory of all cloud assets across an organization's projects and folders?

A.Cloud Billing console, which lists all resources that have incurred charges
B.Cloud Asset Inventory, which provides a searchable, unified inventory of all resources and IAM policies across an organization's projects and folders
C.Google Cloud Console project dashboard, which shows resources within a single project
D.Security Command Center, which lists security vulnerabilities in cloud resources
AnswerB

Cloud Asset Inventory is the correct service. It maintains a complete, searchable catalog of all resources (and their configurations) across the entire organization, supports historical queries, and integrates with policy analysis tools. This is the purpose-built service for organizational resource visibility.

Why this answer

Cloud Asset Inventory is the correct answer because it is the Google Cloud service specifically designed to provide a unified, searchable inventory of all cloud assets (resources and IAM policies) across an organization's projects, folders, and organization nodes. It supports real-time and historical snapshots, enabling teams to discover and track resources as the environment scales. This directly addresses the need to understand what resources exist across dozens of projects.

Exam trap

The GCDL exam often tests the distinction between a unified inventory service (Cloud Asset Inventory) and a security-focused tool (Security Command Center), leading candidates to mistakenly choose the latter because they associate 'inventory' with security asset management.

How to eliminate wrong answers

Option A is wrong because the Cloud Billing console only lists resources that have incurred charges, not a comprehensive inventory of all assets (including free-tier or non-billable resources), and it does not provide a unified view across projects and folders. Option C is wrong because the Google Cloud Console project dashboard shows resources only within a single project, not across dozens of projects and folders as required. Option D is wrong because Security Command Center focuses on security vulnerabilities and threats, not on providing a unified inventory of all cloud assets.

Practice this question →
72
MCQhard

A company's application is composed of 15 microservices. When a performance issue occurs, the team struggles to determine which service is causing latency since request traces span multiple services. Which Google Cloud service helps identify which specific service in a microservices chain is causing slowdowns?

A.Cloud Logging — search logs for error messages across all 15 services.
B.Cloud Trace — captures distributed request traces showing end-to-end latency across all microservices.
C.Cloud Monitoring dashboards — create per-service CPU utilization graphs.
D.Security Command Center — scan for misconfigurations causing performance issues.
AnswerB

Cloud Trace is purpose-built for distributed performance debugging: it captures an end-to-end trace for each sampled request, recording each service call as a span with parent-child relationships to reconstruct the exact request path across your 15 microservices. The Gantt chart view shows the duration of every span, the critical path, and the service-to-service latency, so you can immediately spot which service added the most time to a slow request. Cloud Trace also correlates with Cloud Logging via trace IDs, letting you inspect error logs within the same trace. This makes it the only option that directly answers 'which service is the latency culprit?' for a specific request flow.

Why this answer

Cloud Trace is designed specifically for distributed tracing in microservices architectures. It captures end-to-end latency data for each request as it traverses multiple services, allowing you to pinpoint which service in the chain is introducing the most delay. This directly addresses the problem of identifying the specific service causing slowdowns in a 15-service application.

Exam trap

The trap here is that candidates confuse Cloud Logging (which shows error messages) with Cloud Trace (which shows latency timing), or assume CPU utilization graphs (Cloud Monitoring) can pinpoint request-level slowdowns, when only distributed tracing can reveal the exact service in the chain causing the delay.

How to eliminate wrong answers

Option A is wrong because Cloud Logging is for aggregating and searching log entries, not for tracing request latency across services; it cannot show the per-service timing breakdown needed to identify the slowest service. Option C is wrong because Cloud Monitoring dashboards showing per-service CPU utilization can indicate resource pressure but do not trace individual requests across services, so they cannot reveal which service in a specific request chain is causing latency. Option D is wrong because Security Command Center focuses on security misconfigurations and vulnerabilities, not on performance latency or distributed tracing.

Practice this question →
73
MCQmedium

A company uses Google Cloud and wants to understand their monthly cloud spend before the invoice arrives, track spending trends, and identify the top cost drivers across all services. Which built-in Google Cloud tool provides this visibility?

A.Cloud Monitoring dashboards with cost metrics.
B.Cloud Billing reports and cost breakdown in the Billing console.
C.Cloud Asset Inventory — it lists all resources and their costs.
D.Google Cloud pricing calculator — it shows estimated costs.
AnswerB

Cloud Billing reports and cost breakdown in the Billing console are the system of record for actual spend. These pre-built reports show cost by service, project, SKU, and labels using metered usage data, and they also provide spend forecasts. For deeper custom analysis, you can export billing data to BigQuery, but the console itself already gives a native, authoritative view of incurred charges.

Why this answer

Cloud Billing reports and cost breakdown in the Billing console provide built-in, out-of-the-box visibility into monthly spend before the invoice arrives, spending trends, and top cost drivers across all services. This tool aggregates billing data from all projects and services, allowing you to filter by time range, project, service, or SKU, and view cost trends and breakdowns without additional configuration.

Exam trap

The GCDL exam often tests the misconception that Cloud Monitoring can natively show cost metrics, but in reality, cost metrics require billing export to BigQuery and custom dashboard setup, whereas Cloud Billing reports provide this visibility immediately without additional configuration.

How to eliminate wrong answers

Option A is wrong because Cloud Monitoring dashboards with cost metrics require you to export billing data to BigQuery and then create custom dashboards, which is not a built-in, out-of-the-box solution for immediate cost visibility. Option C is wrong because Cloud Asset Inventory lists all resources and their metadata, but it does not provide cost data or spending trends; it is designed for asset discovery and governance, not cost analysis. Option D is wrong because the Google Cloud pricing calculator is a planning tool used to estimate costs before deployment, not a tool for viewing actual incurred spend or tracking trends.

Practice this question →
74
MCQhard

A platform engineering team is designing a self-service cloud environment for development teams. They want developers to be able to provision approved cloud resources quickly without waiting for central IT approval for every request, while still ensuring compliance with security and cost policies. Which architectural approach best balances developer agility with governance?

A.Require all resource provisioning requests to be submitted as tickets to the central IT team for manual review and approval before any resources are created
B.Give all developers Owner access to all Google Cloud projects so they can provision any resources without delays
C.Provide a self-service catalog of pre-approved, policy-compliant infrastructure templates with automated provisioning, budget alerts, and org policy guardrails — enabling developer agility while enforcing compliance automatically
D.Allow developers to provision resources freely in a shared sandbox project only, keeping production entirely controlled by central IT
AnswerC

This is the platform engineering approach: build the rails, not the roads. Pre-approved templates (Terraform modules, Config Connector blueprints) let developers self-serve within defined boundaries. Org policies prevent non-compliant configurations. Budget alerts enforce cost controls. Developers move fast; governance is automated, not manual.

Why this answer

It uses a self-service catalog with pre-approved, policy-compliant templates (e.g., Deployment Manager or Terraform configurations) combined with Organization Policy Service guardrails and automated budget alerts. This approach allows developers to provision resources on demand while enforcing security and cost policies automatically, balancing agility with governance without manual bottlenecks.

Exam trap

Google Cloud often tests the misconception that giving developers full access (Option B) or restricting them to a sandbox (Option D) are acceptable trade-offs, when in fact the correct answer requires a policy-as-code approach that enforces guardrails automatically without manual intervention.

How to eliminate wrong answers

Option A is wrong because requiring manual ticket-based approval for every request creates a central IT bottleneck that destroys developer agility, contradicting the goal of self-service provisioning. Option B is wrong because giving all developers Owner access to all projects violates the principle of least privilege, bypasses all governance controls, and creates severe security and compliance risks. Option D is wrong because restricting developers to a shared sandbox project only does not address their need to provision approved resources in production-like environments; it still forces central IT control for production, failing to balance agility with governance across the full lifecycle.

Practice this question →
75
MCQeasy

A company wants to automatically scale their Compute Engine managed instance group based on the number of requests per second. Which metric should they use?

A.CPU utilization
B.HTTP load balancing serving capacity
C.Instance group size
D.custom metric from Cloud Monitoring
AnswerD

A custom metric from Cloud Monitoring can capture application-level signals like requests per second or queue depth, which are directly proportional to user demand. Exporting such a metric via the Cloud Monitoring API and configuring an autoscaling policy on it allows precise, workload-aware scaling that reflects the true load pattern rather than relying on incidental infrastructure indicators.

Why this answer

The company needs to scale based on requests per second, which is a custom application-level metric. Cloud Monitoring allows you to create custom metrics from your application, and managed instance groups can use these custom metrics for autoscaling, enabling precise scaling based on actual request throughput rather than proxy indicators.

Exam trap

The trap here is that candidates often confuse 'HTTP load balancing serving capacity' with request rate, but that metric measures the load balancer's backend capacity utilization (a ratio), not the raw number of requests per second, which requires a custom application metric.

How to eliminate wrong answers

Option A is wrong because CPU utilization is a system-level metric that does not directly correlate with requests per second; an instance could be CPU-bound for other reasons, leading to inaccurate scaling. Option B is wrong because HTTP load balancing serving capacity is a metric related to the load balancer's capacity, not the number of requests per second hitting the application; it measures backend capacity utilization, not request rate. Option C is wrong because instance group size is a static count of instances, not a metric that drives scaling decisions; using it as a scaling metric would create a circular dependency.

Practice this question →
Page 1 of 2 · 83 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Scaling with Google Cloud operations questions.

Start 20-question session