Storing the Data

A retail catalog could sit in Cloud SQL, Firestore, or BigQuery, and nothing about the data's shape decides which is right. What decides is how the data is read and written: a transactional workload (OLTP, many small consistent reads and writes) wants an operational database, while an analytical workload (OLAP, large scans that aggregate millions of rows) wants a warehouse. So this domain runs on one habit: name the access pattern first, then name the store. The second half of that habit, and the through-line that ties all four subtopics together, is that once data has landed you do not copy it again to read or govern it. BigQuery reads Cloud Storage files in place, BigLake adds governed access over those same files, Knowledge Catalog (formerly Dataplex Universal Catalog) catalogs assets where they already live, and BigQuery sharing (formerly Analytics Hub) distributes a dataset as a read-only link with no copy. The classic exam trap is the instinct to consolidate, to move blobs into a database or to centralize every team's data into one dataset before you can use it; the platform answer almost always governs or queries the distributed copy in place instead.

Read the four subtopics as one arc. You start with Selecting Storage, the decision tree that maps an access pattern to a managed service: Cloud SQL or AlloyDB for regional OLTP relational, Spanner when the relational workload must go global with strong consistency, Bigtable for wide-column key-value at high throughput, Firestore for real-time documents, Memorystore as a cache and never the system of record, BigQuery for OLAP, and Cloud Storage for blobs. The next two subtopics zoom into the two analytical stores that question writers lean on hardest. Data Warehouse is BigQuery's design discipline: denormalize into wide tables, model one-to-many with an ARRAY of STRUCT instead of a join, and partition to skip data while you cluster to sort within it, all to cut the bytes a query scans. Data Lake is the Cloud Storage side: there is no "Lake" service to provision, so you land raw files in buckets, pick a storage class per access frequency, query them in place with external or BigLake tables, and discover and govern them with Dataplex, the lake-scoped governance plane (Knowledge Catalog, in the next step, is the org-wide catalog above it). Data Platform pulls up one more level to the governed layer over both lakes and warehouses, where Knowledge Catalog discovers and governs assets across services and BigQuery sharing distributes datasets as products. Walk a multi-part storage question along this arc to see which subtopic owns it.

Storage questions usually leave two options that would technically function, and the instinct the exam rewards is to avoid moving and duplicating data. Reach for the most-managed and most-serverless service the workload tolerates, because the exam favors BigQuery and Firestore and Cloud Storage over running and tuning your own infrastructure. Among answers that meet the requirement, prefer the one that reads or governs data where it already lives: a BigLake external table over loading lake files into the warehouse, a BigQuery sharing listing over copying a dataset to the consumer, governing assets in place with Knowledge Catalog over consolidating them into one store first. Then size cost to the access pattern you chose, since each store bills on the dimension that matches its pattern, and let lifecycle policies and table expiration age stale data down automatically rather than moving it by hand. The duplicating answer is usually the wrong one.