Architecting storage around the access patterns it must support

Choosing the right storage architecture on Google Cloud depends on how data will be accessed: by query pattern (analytical vs transactional), latency requirements, data structure, and access frequency. The Professional Data Engineer exam expects you to map access patterns, OLTP, OLAP, real-time serving, batch analytics, file-based ML training, to the correct storage service and schema design.

Must-know

• Cloud SQL and AlloyDB suit low-latency, transactional (OLTP) access with strong consistency and relational joins, while BigQuery is optimized for large-scale analytical (OLAP) scans, not row-level lookups.
• Bigtable is designed for high-throughput, low-latency key-based access patterns (time series, IoT, ad serving) and requires careful row-key design to avoid hotspotting and support range scans.
• Spanner supports globally distributed, strongly consistent transactional workloads that need horizontal scale beyond a single Cloud SQL instance, using interleaved tables and choice of primary keys to avoid hotspots.
• Cloud Storage is the default choice for unstructured/semi-structured data and staging (data lakes), with storage classes (Standard, Nearline, Coldline, Archive) chosen based on access frequency to optimize cost.
• Firestore/Datastore fit document-style, hierarchical access patterns for mobile/web apps needing flexible schema and offline sync, whereas Memorystore serves ultra-low-latency caching for frequently accessed data.
• A common gotcha: picking BigQuery for high-frequency single-row transactional updates (bad fit due to cost/latency) or Bigtable for ad hoc SQL analytics (lacks native SQL joins) indicates a mismatch between access pattern and storage engine.

Coverage checked against the published exam guide on Aug 11, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.