ExamFinch.com My Study

Study guide

6.4 Building, Modifying & Sharing Looker Dashboards

Practice this exam

Google Cloud Associate Data Practitioner Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

About the Associate Data Practitioner Exam

2 Chapter 1: Data Processing Paradigms & Ingestion Strategies

1.1 ETL, ELT, and ETLT Transformation Paradigms 1.2 Data Transfer and Migration Tools 1.3 Data Quality, Cleaning, and Validation

3 Chapter 2: Data Formats & Storage Solution Selection

2.1 File Formats & Serialization Characteristics 2.2 Cloud Storage Buckets, Location Types & Storage Classes 2.3 Selecting Google Cloud Databases and Storage Services

4 Chapter 3: Loading Data & Modern Ingestion Architectures

3.1 Batch Loading Data into BigQuery 3.2 Streaming Ingestion & Deduplication Patterns 3.3 BigQuery External Tables, BigLake & Federated Queries 3.4 Schema Definition & Evolution for Loaded Data

5 Chapter 4: BigQuery SQL Analytics & Query Foundations

4.1 BigQuery SQL Syntax & Analytical Functions 4.2 Complex Data Types: Arrays, Structs, and JSON 4.3 Answering Business Questions with BigQuery: Worked Analyses

6 Chapter 5: BigQuery Performance Optimization & Cost Governance

5.1 Table Partitioning Strategies 5.2 Table Clustering & Data Skipping 5.3 Query Optimization, Execution Plans, and Cost Controls

7 Chapter 6: Interactive Analysis, Notebooks & Visual Presentation

6.1 Exploratory Analysis with Jupyter & Colab Enterprise 6.2 Looker Studio (Data Studio) Reporting & Dashboard Design 6.3 Enterprise BI with Looker & LookML Foundations 6.4 Building, Modifying & Sharing Looker Dashboards

8 Chapter 7: Machine Learning with BigQuery ML & Vertex AI

7.1 Planning an ML Project: BigQuery ML, AutoML, or Pretrained Models? 7.2 Creating, Training & Evaluating Models with BigQuery ML 7.3 Running Inference and Organizing Models in Model Registry 7.4 Using Pretrained Gemini Models from BigQuery with Remote Connections

9 Chapter 8: Pipeline Engines & Transformation Services

8.1 Transformation Engine Selection Matrix 8.2 Apache Beam & Cloud Dataflow Core Concepts 8.3 Stream Processing: Windowing, Watermarks, and Triggers

10 Chapter 9: Workflow Orchestration, Automation & Monitoring

9.1 SQL Pipelines with Dataform & Scheduled Queries 9.2 Workflow Orchestration with Cloud Composer & Workflows 9.3 Event-Driven Ingestion: Pub/Sub to BigQuery & Eventarc Triggers 9.4 Monitoring Pipelines: Dataflow Job UI, Cloud Logging & Cloud Monitoring

11 Chapter 10: Access Control, Governance & Data Sharing

10.1 IAM Principles & Role Hierarchies for Data Services 10.2 Cloud Storage Security & Access Controls 10.3 Fine-Grained Security: Column-Level & Row-Level Controls 10.4 Secure Data Sharing with Analytics Hub (BigQuery Sharing)

12 Chapter 11: Lifecycle Management, Reliability & Compliance

11.1 Object Lifecycle Management & Storage Tiering 11.2 High Availability & Disaster Recovery Architectures 11.3 Data Retention, Time Travel, and Point-in-Time Recovery 11.4 Encryption Key Management & Privacy Compliance

6.4 Building, Modifying & Sharing Looker Dashboards

Key Takeaways Explain This Topic AI

Looker has user-defined dashboards built in the browser and LookML dashboards stored as code in a Git-backed project.

Dashboards are built from Explores: pick dimensions and measures, filter, visualize, then save to a dashboard tile or as a Look.

Content access (folder View or Manage Access, Edit) is separate from data access (roles with model sets, and access filters tied to user attributes).

Schedules deliver dashboards as PDF or PNG on a timetable, and alerts notify users when a tile crosses a threshold.

LookML edits made in Development Mode stay private until they are validated, committed, and deployed to production.

Last updated: October 2026

6.4 Building, Modifying & Sharing Looker Dashboards

Core Focus: Exam section 2.2 is titled "Visualize data and create dashboards in Looker." Section 6.3 explained the LookML model behind Looker. This section covers what an analyst does on top of it: building dashboards from Explores, changing them, sharing and scheduling them safely, and making small LookML edits that change what users see.

Two Kinds of Looker Dashboards

User-defined dashboards LookML dashboards

Created by Any user with the right permissions, in the browser Developers, in .dashboard.lookml files in a LookML project

  • Stored in Folders (personal or shared) The project's Git repository; shown in the LookML dashboards folder
  • Changed by Editing in the UI Editing code, then committing and deploying

Best for Fast, self-service analysis and team dashboards Governed, version-controlled dashboards reused across instances

You can start with a user-defined dashboard and use Get LookML to copy its definition into a project when it needs version control.

Building a Dashboard from an Explore

Open an Explore (for example, Orders & Fulfillment Analysis ).

Pick fields: choose dimensions (such as Order Created Month , Region ) and measures (such as Total Gross Revenue ).

Filter: add filters such as Order Status is Complete and a date range.

Run and visualize: choose a column chart, line chart, table, single value, or map.

Save: save the query to a dashboard as a new tile, or save it as a Look (a saved, reusable report) and add the Look to dashboards.

Because every tile is generated from the LookML model, two tiles that use Total Gross Revenue always use the same definition. That consistency is the main reason to use Looker rather than per-report calculated fields.

Tiles, Filters, and Interactivity

Query tiles hold their own query; Look-linked tiles show a saved Look and change when the Look changes.

Text and Markdown tiles add headings and explanations.

Dashboard filters apply to every tile you map them to (choose the field each tile should filter on), so one date filter can drive the whole dashboard.

Cross-filtering lets a viewer click a bar or row to filter the other tiles by that value.

Drilling opens the detail rows behind a number, using the drill_fields defined in LookML.

Settings control auto-refresh, the dashboard time zone, and whether tiles run when the dashboard loads.

Modifying Dashboards

In Edit mode you can move and resize tiles, change a tile's visualization or query, add and remove filters, and rename the dashboard. Changes to a user-defined dashboard take effect when you save. Changes to a LookML dashboard follow the same development workflow as other LookML.

Sharing, Scheduling, and Access

Looker separates content access (who can see a dashboard in a folder) from data access (which models, Explores, fields, and rows a user can query).

  • Need Looker feature
  • Let a team view a dashboard Save it in a shared folder and give the team's group View access to the folder
  • Let a team edit it Give Manage Access, Edit on the folder
  • Hide a model or Explore from some users Roles built from permission sets and model sets
  • Show each user only their rows Access filters tied to user attributes (for example, region )

Send results on a timetable Schedules : deliver a dashboard as PDF or PNG (or data as CSV) to email and other destinations, optionally only when results exist

  • React to a threshold Alerts on a tile, such as "notify me when daily revenue drops below $50,000"
  • Organize content for an audience Boards that collect dashboards and Looks

Because queries run under the viewer's Looker permissions and access filters, one shared dashboard can safely show each regional manager only their region.

Making Simple LookML Changes

Exam section 2.2 also asks you to "manipulate simple LookML parameters to modify a data model." In LookML, a parameter is any key: value setting on a field, view, Explore, or model. The ones you are expected to change are simple:

  • Parameter What it changes Example
  • label The name users see label: "Gross Revenue (USD)"
  • description Hover help text description: "Completed orders only"
  • type How a field is calculated type: sum vs. type: average
  • sql The SQL expression behind the field sql: ${TABLE}.sale_price ;;
  • value_format_name Number formatting value_format_name: usd
  • hidden Hides a field from the field picker hidden: yes
  • filters Turns a measure into a filtered measure filters: [status: "Complete"]

drill_fields Detail fields shown when users drill drill_fields: [id, created_date, sale_price] measure: total_gross_revenue {

  • label: "Gross Revenue (USD)"
  • description: "Sum of sale price for completed order items"
  • type: sum
  • sql: ${sale_price} ;;
  • filters: [status: "Complete"]
  • value_format_name: usd
  • drill_fields: [id, created_date, sale_price]
  • }
  • dimension: internal_cost_code {
  • hidden: yes
  • sql: ${TABLE}.cost_code ;;
  • }

LookML also has a field type called parameter , which adds a user-selected input (for example, a "metric selector") that other fields read with Liquid templating. Recognize it, but most exam items focus on the field settings above.

The Development Workflow

Turn on Development Mode . You now work on your own Git branch; other users still see production.

Edit the view, model, or dashboard file.

Click Validate LookML to catch errors.

Commit your changes (and open a pull request if your team requires review).

Deploy to Production so everyone sees the change.

Common Exam Traps

"I changed the LookML, but nobody sees it." Changes in Development Mode are visible only to the developer until they are committed and deployed to production.

Sharing data versus sharing content: Moving a dashboard into a shared folder does not grant access to a model the viewer cannot query; data access comes from roles and access filters.

Copying formulas into tiles: Repeating a revenue formula in table calculations across dashboards recreates metric chaos. Define it once as a LookML measure.

Looker vs. Looker Studio: Governed dashboards on a semantic model point to Looker; quick, free reports from many sources point to Looker Studio (Section 6.2).