Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

Answer analysis

Option-by-option breakdown

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

• ✗

  Looker Studio, Google's free self-service data visualization tool

  Why it's wrong here

  Looker Studio is a free visualization tool that lets users build dashboards quickly by connecting directly to data sources, but it lacks a centralized semantic layer. Each analyst defines calculated fields and metrics locally in their own report, so the same dimension or measure can be aggregated differently (e.g., one uses SUM, another uses COUNT DISTINCT) without any cross-report consistency. While it supports 'data sources' as reusable building blocks, those are not centrally governed or version-controlled, and any user can modify them. Looker Studio therefore fails the core governance requirement of the question: a single, audited definition of a metric that all reports, dashboards, and teams must use.

• ✓

  Looker, with its LookML semantic layer for centrally governed, version-controlled metric definitions used consistently across all reports

  Why this is correct

  Looker's LookML semantic layer is precisely designed for governed analytics. Data engineers define business logic (what 'revenue' means, how to join tables) in LookML, which is version-controlled in Git. All Looker reports query through this layer, ensuring consistent definitions. This is the differentiated capability versus Looker Studio.

• ✗

  BigQuery, where analysts write shared SQL queries stored in the project

  Why it's wrong here

  BigQuery is a data warehouse, not a semantic governance layer. Storing shared SQL queries in a project gives analysts a common script library, but nothing enforces those queries as the canonical definition of a metric. Any analyst can edit a shared query, create a private variant, or bypass it entirely, so the same business term (e.g., 'revenue') can drift across reports. Looker's LookML, by contrast, hard-codes metric definitions in version-controlled files that all queries must pass through, making the warehouse itself an implementation detail rather than a source of governance.

• ✗

  Vertex AI, which provides a model registry for governing ML model definitions

  Why it's wrong here

  Vertex AI's model registry is purpose-built for managing machine learning artifacts—model versions, endpoints, and evaluation metrics—not for governing business intelligence metric definitions. It tracks the ML lifecycle, such as which model iteration is in production, but it has no concept of how 'revenue' or 'active customer' is calculated for dashboards. Attempting to use it for LookML-style semantic governance would be a category error, since the registry cannot enforce join logic, aggregation rules, or business terminology across a BI tool. The two systems solve unrelated problems: model operations versus enterprise-level reporting consistency.

Go deeper

Related to this question