Cloud Digital Leader Scaling with Google Cloud operations Practice Question

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?

⚠ Common exam trap

Many exam-takers 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.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

`loadbalancing/https/request_count` filtered by backend service and region.

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.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
`compute/instance/cpu/utilization` per instance group.
Why it's wrong here
compute/instance/cpu/utilization per instance group measures the average or maximum CPU busy percentage of each VM, which is affected by application code, instance size, and unrelated background processes. It is an indirect, lagging signal: a few computationally expensive requests can peg CPU while the request counter remains low, and conversely highly-optimized backends can handle thousands of requests at negligible CPU. Because it is not an attribute of the load balancer or the request itself, it cannot reveal how traffic is distributed across regions or backend services.
✓
`loadbalancing/https/request_count` filtered by backend service and region.
Why this is correct
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.
✗
`networking/vm_flow/egress_bytes_count` per VM.
Why it's wrong here
networking/vm_flow/egress_bytes_count per VM tracks the number of bytes sent from a VM's network interface, which is a function of payload sizes, compression, and data streaming, not of how many distinct client requests arrived. A backend that streams large videos will emit enormous egress bytes while serving relatively few requests, whereas a backend that serves many small JSON responses may show low byte counts. Hence this metric cannot act as a proxy for request count distribution, because it confounds application response size with load balancer routing.
✗
`logging/log_entry_count` filtered by region.
Why it's wrong here
Log entry count (logging/log_entry_count) reflects the number of log records ingested by Cloud Logging across a project, not the number of HTTP requests processed by a load balancer. This volume varies with logging verbosity, audit log scope, and the behavior of all services producing logs, so filtering by region does not isolate load balancer traffic distribution. A single noisy application could inflate the count in one region while masking the actual request mix, making it impossible to draw conclusions about routing or backend balancing.

Visual reference

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question