Metrics and dashboards in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Metric Types in Google Cloud Monitoring

Which metric type in Google Cloud Monitoring is best suited to track the total number of requests received by a web server over time?

A Cumulative metric, because it counts the total number of events since a start time.

B Gauge metric, because it measures the current value at a point in time.

C Delta metric, because it measures the change between two points in time.

D Distribution metric, because it shows the distribution of latency values.

💡 Hint

Think about a metric that keeps adding up over time without resetting.

A cumulative metric counts the total number of events from a start time, making it ideal for tracking total requests over time. Gauges show current values, deltas show changes between points, and distributions show value spreads.

❓ Architecture

intermediate

Designing a Dashboard for Latency Monitoring

You want to create a Google Cloud Monitoring dashboard that shows the 95th percentile latency of an API over the last hour. Which chart type and aggregation method should you use?

A Use a line chart with 95th percentile aggregation over the last hour.

B Use a bar chart with sum aggregation over the last hour.

C Use a line chart with mean aggregation over the last hour.

D Use a pie chart with max aggregation over the last hour.

💡 Hint

Percentiles help understand latency distribution, and line charts show trends over time.

A line chart with 95th percentile aggregation shows how latency behaves at the high end over time, which is useful for performance monitoring. Mean or sum do not capture percentile behavior, and pie charts are not suitable for time series.

❓ security

advanced

Securing Access to Monitoring Dashboards

Which IAM role should you assign to a user to allow them to view Google Cloud Monitoring dashboards but prevent them from modifying any metrics or alert policies?

A roles/owner

B roles/monitoring.viewer

C roles/monitoring.admin

D roles/monitoring.editor

💡 Hint

Look for the role that grants read-only access to monitoring data.

The roles/monitoring.viewer role allows users to view dashboards and metrics without permission to change configurations. Editor and admin roles allow modifications, and owner has full project control.

❓ Configuration

advanced

Configuring Alerting Policies for CPU Usage

You want to create an alerting policy that triggers if the average CPU usage of a Compute Engine instance exceeds 80% for 5 continuous minutes. Which configuration correctly sets this condition?

A Metric: compute.googleapis.com/instance/cpu/utilization, Aggregation: max, Condition: above 80 for 5 minutes

B Metric: compute.googleapis.com/instance/cpu/usage_time, Aggregation: sum, Condition: above 80 for 5 minutes

C Metric: compute.googleapis.com/instance/cpu/utilization, Aggregation: mean, Condition: above 0.8 for 5 minutes

D Metric: compute.googleapis.com/instance/cpu/usage_time, Aggregation: mean, Condition: above 0.8 for 5 minutes

💡 Hint

CPU utilization is a ratio between 0 and 1, so thresholds should match that scale.

The metric compute.googleapis.com/instance/cpu/utilization measures CPU usage as a fraction (0 to 1). Using mean aggregation and threshold 0.8 (80%) for 5 minutes matches the requirement. Usage_time is cumulative CPU time, not a percentage.

✅ Best Practice

expert

Optimizing Dashboard Performance with Large Metrics Data

You manage a dashboard with multiple charts showing high-cardinality metrics from thousands of instances. The dashboard loads slowly. Which approach best improves dashboard performance without losing critical data?

A Increase the refresh rate to update charts every 10 seconds instead of every minute.

B Reduce the time range displayed to the last 1 hour instead of 7 days.

C Remove percentile aggregations and use only mean aggregations for all charts.

D Use metric filters to aggregate data by instance group instead of individual instances.

💡 Hint

Aggregating data reduces the number of time series and improves load times.

Aggregating metrics by instance group reduces the number of time series, improving dashboard load times while preserving meaningful data. Reducing time range helps but may lose historical context. Removing percentiles loses important insights. Increasing refresh rate worsens performance.

Practice

1. What is the main purpose of a dashboard in Google Cloud Monitoring?

easy

A. To visually display metrics and help monitor cloud resources

B. To store data permanently for backup

C. To write code for cloud functions

D. To manage user permissions

Solution

1. Step 1: Understand what dashboards do

   Dashboards show visual summaries of metrics to help users watch cloud resources easily.

2. Step 2: Identify the correct purpose

   Among the options, only displaying metrics visually matches the dashboard's role.

3. Final Answer:

   To visually display metrics and help monitor cloud resources -> Option A

4. Quick Check:

   Dashboard = Visual metric display [OK]

Hint: Dashboards show data visually, not store or code [OK]

Common Mistakes:

• Confusing dashboards with storage or coding tools
• Thinking dashboards manage permissions

2. Which of the following is the correct way to filter CPU usage metric in a Google Cloud Monitoring dashboard widget?

easy

A. filter: cpu_usage_metric

B. metric = "cpu_usage"

C. metric.type = "compute.googleapis.com/instance/cpu/utilization"

D. metric.cpu = "usage"

Solution

1. Step 1: Recall correct metric filter syntax

   Google Cloud Monitoring uses metric.type with full metric names like "compute.googleapis.com/instance/cpu/utilization".

2. Step 2: Match options to syntax

   Only metric.type = "compute.googleapis.com/instance/cpu/utilization" uses the correct full metric.type format.

3. Final Answer:

   metric.type = "compute.googleapis.com/instance/cpu/utilization" -> Option C

4. Quick Check:

   Correct metric filter uses metric.type with full name [OK]

Hint: Use full metric.type path for filters [OK]

Common Mistakes:

• Using incomplete or shorthand metric names
• Wrong filter keywords like 'filter:' or 'metric.cpu'

3. Given this snippet for a dashboard widget filter:
metric.type = "compute.googleapis.com/instance/disk/read_bytes_count" AND resource.label.instance_id = "12345"
What does this filter show?

medium

A. Disk read bytes count for instance with ID 12345

B. CPU usage for instance 12345

C. Network bytes sent by instance 12345

D. Disk write bytes count for instance 12345

Solution

1. Step 1: Analyze metric.type value

   The metric is "disk/read_bytes_count", which means bytes read from disk.

2. Step 2: Check resource label filter

   The filter limits data to instance with ID "12345".

3. Final Answer:

   Disk read bytes count for instance with ID 12345 -> Option A

4. Quick Check:

   Disk read bytes + instance filter = Disk read bytes count for instance with ID 12345 [OK]

Hint: Match metric.type and resource label to understand filter [OK]

Common Mistakes:

• Confusing read bytes with write bytes
• Mixing disk metrics with CPU or network

4. You created a dashboard widget but it shows no data. Which of these is the most likely cause?

medium

A. The user has read access to the project

B. The dashboard widget is set to refresh every 5 seconds

C. The dashboard has more than 5 widgets

D. The metric filter uses an incorrect metric type name

Solution

1. Step 1: Identify common reasons for no data

   Incorrect metric type names cause filters to match no data, so widget shows empty.

2. Step 2: Evaluate other options

   Refresh rate or widget count do not prevent data display; read access is needed but assumed correct here.

3. Final Answer:

   The metric filter uses an incorrect metric type name -> Option D

4. Quick Check:

   No data usually means wrong metric filter [OK]

Hint: Check metric type spelling if no data shows [OK]

Common Mistakes:

• Blaming refresh rate or widget count
• Ignoring permission issues but assuming access is correct

5. You want to create a dashboard showing both CPU utilization and network bytes sent for multiple instances, but only for instances tagged with "env:production". Which approach is best?

hard

A. Create a widget with a filter for "env:production" but only for disk metrics

B. Create two widgets with filters for CPU and network metrics, each filtering resource labels for "env:production"

C. Create a widget filtering only CPU metrics for all instances, ignoring network metrics

D. Create one widget showing CPU and network metrics without filters, then manually check instance tags

Solution

1. Step 1: Understand the requirement

   You need to show two different metrics (CPU and network) filtered by instance tag "env:production".

2. Step 2: Choose filtering and widget setup

   Best practice is separate widgets for each metric with proper filters on resource labels for the tag.

3. Step 3: Evaluate other options

   Options A, B, and C either miss filtering, use wrong metrics, or ignore one of the required metrics.

4. Final Answer:

   Create two widgets with filters for CPU and network metrics, each filtering resource labels for "env:production" -> Option B

5. Quick Check:

   Separate widgets + correct filters = best dashboard [OK]

Hint: Use separate widgets with filters for each metric [OK]

Common Mistakes:

• Trying to combine unrelated metrics in one widget without filters
• Ignoring resource label filters for tags
• Showing irrelevant metrics