Practice Designing Databases Questions Now

Start a timed practice session focusing on Designing and Planning Cloud Database Solutions topics from the PCDBE question bank.

Start PCDBE Practice Quiz →

PCDBE Designing Databases Question Bank (13 Questions)

Browse all 13 practice questions covering Designing and Planning Cloud Database Solutions for the PCDBE certification exam. Each question includes the full answer and a detailed explanation to help you understand the concepts.

Question 1Designing and Planning Cloud Database Solutions
How do you choose between Cloud SQL, AlloyDB, Spanner, and Firestore?
AAlways use one
BCloud SQL: standard relational. AlloyDB: high-performance PostgreSQL. Spanner: global-scale relational. Firestore: serverless document NoSQL. Choose based on scale, consistency, and data model needs.✓
CAll the same
DOnly use Spanner
Show Answer & Explanation
Correct Answer: B
Explanation:
Decision tree: Relational + regional → Cloud SQL (lowest cost). Relational + high-perf PostgreSQL → AlloyDB (4x faster). Relational + global → Spanner (99.999% SLA). Document/NoSQL + serverless → Firestore (mobile/web). Key-value + low-latency → Bigtable. Consider: scale, consistency, cost, and expertise.
Question 2Managing and Administering Cloud Databases
How should you design a Cloud Spanner schema to avoid hotspots?
AUse auto-incrementing integer primary keys
BUse UUIDs, hash-based keys, or bit-reversed sequences as primary keys — avoid monotonically increasing keys that cause all writes to concentrate on one node✓
CUse timestamps as primary keys
DUse the same key for all rows
Show Answer & Explanation
Correct Answer: B
Explanation:
Spanner key design: avoid sequential keys (auto-increment, timestamps) — all writes go to one split. Good patterns: UUIDv4 (random distribution), ShardId + sequential (shard across N prefixes), bit-reversed sequence. Interleaved tables: parent-child co-location (Orders → OrderItems interleaved — stored together for efficient joins). Secondary indexes: also subject to hotspotting rules. Monitor: Cloud Monitoring → Spanner → read/write latency per split.
Question 3Designing and Planning Cloud Database Solutions
A company needs a PostgreSQL-compatible database with high availability and strong consistency. When should you recommend Cloud Spanner over AlloyDB?
AAlways use AlloyDB for PostgreSQL
BCloud Spanner when the workload requires global distribution, horizontal write scaling, or 99.999% SLA — AlloyDB when the workload is regional and benefits from full PostgreSQL compatibility✓
CThey are identical
DUse Cloud SQL instead
Show Answer & Explanation
Correct Answer: B
Explanation:
Spanner vs AlloyDB: Spanner: multi-region, horizontal write scaling, 99.999% SLA, Spanner SQL (PostgreSQL interface limited). AlloyDB: regional, full PostgreSQL compatibility, 4x throughput, columnar engine for analytics, Vertex AI integration. Choose Spanner: global apps, financial transactions, unlimited horizontal scaling. Choose AlloyDB: PostgreSQL ecosystem (extensions, tools), HTAP workloads, regional deployment.
Question 4Designing and Planning Cloud Database Solutions
How do you design a Cloud Bigtable schema for an IoT time-series application?
AUse device ID as row key
BRow key: deviceId#reverseTimestamp (allows latest-first scans per device), column families for sensor types, avoid tall and narrow tables — design for read patterns✓
CStore each reading as a separate table
DUse auto-generated row keys
Show Answer & Explanation
Correct Answer: B
Explanation:
Bigtable IoT schema: Row key: deviceId#reverseTimestamp (Long.MAX_VALUE - timestamp). Why reverse: scan returns latest first (most common read pattern). Column families: group by access pattern (sensor_data, metadata). Column qualifiers: sensor names (temperature, humidity). Avoid: timestamp-only keys (hotspot on recent time), very wide rows (too many columns per row). Pre-splitting: distribute initial load across nodes. GC policy: age-based (keep last 30 days).
Question 5Designing and Planning Cloud Database Solutions
What factors determine the choice between Cloud SQL, Spanner, and AlloyDB?
ACost only
BScale requirements (regional vs. global), consistency needs, PostgreSQL compatibility, and performance requirements✓
CVendor preference
DTeam size
Show Answer & Explanation
Correct Answer: B
Explanation:
Cloud SQL: regional, familiar MySQL/PostgreSQL. Spanner: global, horizontal scaling, strong consistency. AlloyDB: PostgreSQL-compatible, high performance analytical + transactional on managed infrastructure.
Question 6Designing and Planning Cloud Database Solutions
When should you choose AlloyDB over standard Cloud SQL for PostgreSQL?
AAlways use Cloud SQL
BAlloyDB for high-performance HTAP workloads — 4x transaction throughput, 100x faster analytics via columnar engine, and Vertex AI integration for ML predictions in SQL✓
CAlloyDB replaces Cloud Spanner
DAlloyDB is for MySQL only
Show Answer & Explanation
Correct Answer: B
Explanation:
AlloyDB vs Cloud SQL: AlloyDB: 4x transaction throughput, 100x analytics (automatic columnar engine), 99.99% availability, Vertex AI integration (ML.PREDICT in SQL). Use: high-performance PostgreSQL, mixed transactional/analytical, ML-enriched queries. Cloud SQL: standard PostgreSQL, lower cost, simpler workloads. AlloyDB: disaggregated storage (compute and storage scale independently). Both: fully managed, PostgreSQL compatible.
Question 7Managing and Administering Cloud Databases
How do you perform a zero-downtime schema change in Cloud Spanner?
ADrop and recreate the table
BUse DDL statements (ALTER TABLE) — Spanner applies schema changes online without blocking reads or writes, though large changes may take time to propagate across splits✓
CSchedule maintenance downtime
DCreate a new database and migrate
Show Answer & Explanation
Correct Answer: B
Explanation:
Spanner schema changes: online, non-blocking. ALTER TABLE ADD COLUMN: instant (backfill happens in background). CREATE INDEX: online, background build (may take minutes to hours for large tables — backfill while serving traffic). Schema change limits: max 25 concurrent DDL operations. Best practice: batch related changes, monitor via Cloud Monitoring, avoid schema changes during peak traffic. Long-running: CREATE INDEX on large tables, adding NOT NULL columns with backfill.
Question 8Monitoring and Troubleshooting
What monitoring capabilities does AlloyDB provide beyond standard Cloud SQL?
ASame as Cloud SQL
BAlloyDB provides: Query Insights with AI-powered recommendations, columnar engine statistics, automated index recommendations, and instance-level disaggregated compute/storage metrics✓
CNo monitoring available
DOnly third-party monitoring
Show Answer & Explanation
Correct Answer: B
Explanation:
AlloyDB monitoring: 1) Query Insights: top queries, AI-powered optimization recommendations. 2) Columnar engine: hit rate, data cached, acceleration metrics. 3) Index advisor: automated recommendations for missing indexes. 4) Compute metrics: per-instance CPU, memory, connections (disaggregated from storage). 5) Storage metrics: used, IOPS, throughput. 6) Replication: lag, status. 7) Integration: Cloud Monitoring, custom dashboards and alerts.
Question 9Migrating Data Solutions
How do you migrate from Cloud SQL for PostgreSQL to AlloyDB?
AThey're incompatible
BDMS continuous migration (Cloud SQL → AlloyDB), or pg_dump/pg_restore for smaller databases — AlloyDB is PostgreSQL-compatible so schema and data transfer directly✓
CRecreate the application
DExport to CSV and reimport
Show Answer & Explanation
Correct Answer: B
Explanation:
Cloud SQL → AlloyDB: 1) DMS: continuous replication (minimal downtime). Create migration job: source=Cloud SQL, destination=AlloyDB. 2) pg_dump/pg_restore: for smaller DBs or during maintenance window. 3) Schema: compatible (AlloyDB = PostgreSQL 14/15). 4) Extensions: most supported (verify specific extensions). 5) Connection: update connection strings (AlloyDB uses different instance format). 6) Testing: verify query performance (may be faster with columnar engine).
Question 10Designing and Planning Cloud Database Solutions
When should you choose Firestore over Cloud SQL?
AFor complex SQL joins across many tables
BFor flexible schema, document-oriented data with real-time sync to mobile/web clients✓
CFor OLAP analytics
DFor batch data processing
Show Answer & Explanation
Correct Answer: B
Explanation:
Firestore excels at document-oriented data with flexible schemas, real-time synchronization to mobile/web clients, offline support, and automatic scaling without connection management.
Question 11Designing and Planning Cloud Database Solutions
How do you choose between Firestore and Bigtable?
AThey're interchangeable
BFirestore: document database for application data with real-time sync and offline support. Bigtable: wide-column for high-throughput analytics, IoT, and time-series data.✓
CFirestore is for analytics
DBigtable is for mobile apps
Show Answer & Explanation
Correct Answer: B
Explanation:
Firestore: hierarchical documents, real-time listeners, offline mobile support, complex queries, <10TB typical. Bigtable: wide-column, single-key access pattern, high throughput (millions of rows/sec), time-series/IoT/analytics, petabyte-scale.
Question 12Designing Scalable and Highly Available Database Solutions
What is AlloyDB and how does it compare to Cloud SQL?
ASame product
BAlloyDB: PostgreSQL-compatible, Google-designed storage layer with 4x throughput and up to 100x faster analytical queries than standard PostgreSQL. Cloud SQL: standard managed PostgreSQL/MySQL/SQL Server.✓
CCloud SQL is faster
DAlloyDB supports MySQL
Show Answer & Explanation
Correct Answer: B
Explanation:
AlloyDB: PostgreSQL-compatible, disaggregated compute+storage architecture. Advantages: 4x throughput (OLTP), 100x analytical queries (columnar engine), 99.99% SLA (regional), automated ML-based tuning. Cloud SQL: standard managed RDBMS, simpler, lower cost, multi-engine (PostgreSQL, MySQL, SQL Server). Choose AlloyDB for: high-performance PostgreSQL needs.
Question 13Designing Scalable and Highly Available Database Solutions
What is Firestore and when to choose it over Bigtable?
ASame purpose
BFirestore: document database (hierarchical JSON-like documents), serverless, strong consistency, real-time listeners. Choose over Bigtable for: mobile/web apps, hierarchical data, and complex queries on smaller datasets (< TB scale).✓
CAlways use Bigtable
DAlways use Firestore
Show Answer & Explanation
Correct Answer: B
Explanation:
Firestore: document model (collections → documents → fields/subcollections). Features: real-time listeners (data sync to clients), offline support (mobile SDKs), strong consistency, and composite indexes. Scale: automatic, 0 to millions of operations. Choose Firestore: mobile/web apps, hierarchical data, real-time sync, and <10 TB. Choose Bigtable: time-series, IoT, wide-column, >10 TB, and high-throughput analytics. Choose Spanner: relational with global distribution.

Key Designing Databases Concepts for PCDBE

cloud sqlspannerfirestorebigtablealloydbdatabase designschema

PCDBE Designing Databases Exam Tips

Designing and Planning Cloud Database Solutions questions in PCDBE are typically scenario-based. Focus on service-level decision making aligned to official exam objectives. Priority concepts: cloud sql, spanner, firestore, bigtable, alloydb, database design.

What PCDBE Expects

Anchor your answer in select the most practical, secure, and scalable answer for the stated scenario.
Designing Databases scenarios for PCDBE are frequently mapped to Domain 1 (~26%), so read the objective carefully before picking controls or architecture.
Expect multi-service scenarios where Designing Databases interacts with IAM, networking, storage, or observability patterns rather than appearing as an isolated service question.
When two options are both technically valid, prefer the choice that best aligns with the exam's operational scope (Professional) and managed-service best practices.

High-Value Designing Databases Concepts

Know the core Designing Databases building blocks cold: cloud sql, spanner, firestore, bigtable.
Review the edge-case features and limits for alloydb, database design; these details are commonly used to differentiate answer choices.
Practice service-integration reasoning: how Designing Databases pairs with Managing Databases, Migration in real deployment patterns.
For PCDBE, explain why the chosen Designing Databases design meets reliability, security, and cost expectations better than the alternatives.

Common PCDBE Traps

Watch for answers that partially solve the requirement but miss operational constraints.
Questions in Designing and Planning often include distractors that look correct for Designing Databases but violate least-privilege, durability, or availability requirements.
Avoid picking options purely by feature name; validate data path, failure handling, and governance impact before answering.
If the prompt hints at automation or repeatability, eliminate manual-only operational answers first.

Fast Review Checklist

Can you compare at least two Designing Databases implementation paths and justify which one best fits the scenario?
Can you map the chosen answer back to Designing and Planning (~26%) outcomes for PCDBE?
Can you explain security and access boundaries for Designing Databases without relying on default-open assumptions?
Can you describe how Designing Databases integrates with Managing Databases and Migration during failure, scaling, and monitoring events?

Exam Domains Covering Designing Databases

Domain 1Designing and Planning~26%

Related Resources

🎯 Free PCDBE Mock Exam 📝 Managing Databases Questions 📝 Migration Questions

More PCDBE Study Resources

← PCDBE Study Hub 30-Day Study Plan Full Practice Exam

📐 Designing and Planning Cloud Database Solutions - PCDBE Practice Questions