Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
Your DevOps team is instrumenting an e-commerce application to export custom metrics to Google Cloud Monitoring using the Cloud Monitoring API. A previous version of the application caused severe cardinality explosion and quota exhaustion in Cloud Monitoring.
You need to define a new custom MetricDescriptor and label schema that strictly adheres to Google Cloud specifications while preventing high cardinality and optimizing resource consumption. Which design strategy should you implement?
Define low-cardinality labels such as payment_method and status_code using supported LabelDescriptor value types (STRING, BOOL, or INT64), while recording high-cardinality identifiers like user_id and order_id in Cloud Logging or Cloud Trace.
Modify the existing MetricDescriptor in-place whenever new transaction tracking labels are needed, relying on automatic schema migration to update existing time series.
Include user_id and transaction_id directly as STRING labels in the custom MetricDescriptor to enable granular per-user filtering directly inside Cloud Monitoring metric dashboards.
Generate dynamic label keys named after the unique user_id at runtime and set the LabelDescriptor value type to DOUBLE to capture latency numbers.
Define low-cardinality labels such as payment_method and status_code using supported LabelDescriptor value types (STRING, BOOL, or INT64), while recording high-cardinality identifiers like user_id and order_id in Cloud Logging or Cloud Trace.
In Google Cloud Monitoring, a MetricDescriptor defines the schema and metadata for a specific metric type (for example, custom.googleapis.com/checkout/transaction_count). Each metric is uniquely identified by the combination of its metric type and specific key-value pairs for all labels defined in its descriptor. The LabelDescriptor dictates the key name and data type (STRING, BOOL, or INT64) for each dimension.
StudyCerts
StudyCertspayment_method (e.g., credit_card, paypal) and status_code (e.g., 200, 500) keeps the total number of active time series manageable and prevents exceeding Cloud Monitoring API rate limits and memory quotas.STRING, BOOL, or INT64) and ensures valid label key syntax ([a-zA-Z][a-zA-Z0-9_]*).user_id, order_id, and transaction_id are redirected to Cloud Logging or distributed traces via Cloud Trace (or OpenTelemetry exemplars), where high-cardinality lookups are fully supported without inflating time series storage.Cloud Monitoring time series storage is optimized for time-series aggregation, not per-transaction record indexing. Separating metrics (telemetry aggregation) from logs and traces (event investigation) follows Google Cloud observability best practices.
Modify the existing MetricDescriptor in-place whenever new transaction tracking labels are needed, relying on automatic schema migration to update existing time series.
Include user_id and transaction_id directly as STRING labels in the custom MetricDescriptor to enable granular per-user filtering directly inside Cloud Monitoring metric dashboards.
Generate dynamic label keys named after the unique user_id at runtime and set the LabelDescriptor value type to DOUBLE to capture latency numbers.