4.2.2. Querying, Backing Up, and Restoring Data Instances
💡 First Principle: Every managed database on Google Cloud separates "day-to-day interaction" (querying) from "protecting against loss" (backup/restore) as distinct operational surfaces, and the exam tests whether you know the specific mechanism for each across different data products.
Executing queries against Cloud SQL, BigQuery, Bigtable, Spanner, Firestore, or AlloyDB uses each product's native query interface (standard SQL for the relational products, product-specific query languages for Bigtable/Firestore). Backing up and restoring database instances is available across all of these managed products, typically via automated recurring backups plus on-demand manual backups, with a restore operation targeting a chosen instance (which may be the original or a new one, depending on the recovery scenario). Reviewing job status for asynchronous operations like Dataflow pipeline runs or BigQuery load/query jobs happens through each service's own job-monitoring interface, since these operations don't complete instantly and need their own status-tracking surface.
⚠️ Exam Trap: A scenario describing wanting to test a database restore without risking the production instance is testing whether you know a restore can target a brand-new instance rather than overwriting the source — restoring into a new instance is the safe, standard approach for testing recovery procedures.
Reflection Question: Why does restoring into a new instance, rather than overwriting the original, matter specifically when a team wants to validate that a backup is actually recoverable before trusting it in a real incident?
