Preparing & Using Data for Analysis
Everything here serves a governed result, never the raw warehouse table
Once data is stored and cleaned, the last 15% of the exam asks how you put it in front of people and machines without handing over the source. The single idea that ties this domain together: you publish a derived, controlled result that the consumer reads, while the underlying BigQuery table stays governed and untouched. A dashboard reads a precomputed materialized view, an ML model trains on features built in place, and a partner subscribes to a read-only linked dataset that points at your data rather than copying it. The trap this dodges is the reflex to grant read on the fact table or to export a copy for each consumer; in this domain the right answer almost always keeps one governed source and exposes only its output.
The domain unfolds in three steps: visualize, model, share
Read the three subtopics as one path from the warehouse outward. Data for Visualization is where you make a curated table fast and safe for BI tools to read, by serving precomputed results (a materialized view, a scheduled summary, a BI Engine in-memory reservation) and putting access controls on the table the tool touches. Data for AI & ML is where the same governed data feeds models, splitting into two lanes that share one rule of preparing data where it already lives: structured features trained with BigQuery ML, and unstructured text turned into embeddings (numeric vectors capturing meaning) for vector search and RAG (retrieval-augmented generation, feeding retrieved passages into a model's prompt). Sharing Data is where a result leaves your dataset, matched to who the consumer is, from an authorized view inside your org up to BigQuery sharing (formerly Analytics Hub) and data clean rooms across organizations.
When two answers both work, prefer the one that keeps the source single and governed
The exam rewards the option that exposes the least while copying the least. Reach for a view, a linked dataset, or an in-place model over duplicating data into a new table or loosening IAM on the source. Lean on the controls that travel with the data: column-level security with policy tags, row-level security, and dynamic data masking are enforced at query time on the source and keep applying through an authorized view, a shared linked dataset, or a clean room. So define those controls once on the governed table and let the serving, modelling, and sharing layers inherit them, rather than re-securing each copy.
Three ways data leaves the warehouse, and which subtopic owns each
| Consumer | What you publish | Stays governed because | Drill into |
|---|---|---|---|
| A BI tool or dashboard | A precomputed or in-memory result over a curated table | View and column/row controls sit on the table the tool reads | Data for Visualization |
| A model or AI application | Features or embeddings built in place on the source | Training and indexing run inside BigQuery or Vertex AI, no export | Data for AI & ML |
| Another team, partner, or org | An authorized view or read-only linked dataset, not the table | Source row/column security follows the share; no bytes copied | Sharing Data |