Free Professional Cloud Database Engineer practice test: 30 questions with answers

A regional high-availability instance keeps a standby in another zone that replicates synchronously, so failover avoids data loss and keeps downtime short. Single-zone backups need a slow manual restore, a same-zone replica fails with its zone, and a bigger machine in one zone does not protect against a zone outage.

Cloud Spanner multi-region configurations provide synchronous replication with strong consistency across regions, which matches the requirement. Asynchronous replicas can serve stale reads and do not give globally consistent transactions, and Memorystore is a cache rather than a transactional database.

Point-in-time recovery with write-ahead log retention over seven days allows restoring to any second in that window. Nightly exports and manual backups give fixed recovery points only, and an hourly replica cannot reach an arbitrary second.

A UUID or bit-reversed sequence spreads new writes across the key space and avoids the hotspot caused by monotonically increasing keys. Sequential and timestamp-prefixed keys concentrate writes, and a fixed key puts every row in one place.

Sequential row keys direct reads and writes to a narrow key range, which hotspots one node. Salting or reversing the key spreads the load across the table. The cache option does not prevent data loss, column families do not fix key hotspots, and removing the timestamp loses ordering that time-series queries need.

The Standard tier of Memorystore for Redis provides a replica and automatic failover. Memcached has no replication, a bucket is not a cache, and a local process without replication loses its data on restart.

A regional instance with automatic failover and read replicas in a second region both protect availability across zones or regions. Single-zone placement and backups on the same VM disk create single points of failure, and turning off backups removes the recovery path.

AlloyDB is PostgreSQL-compatible and its read pools offload read traffic from the primary. It is not a document database, it supports SQL, and it offers high availability options rather than being limited to one zone.

Change data capture pipelines stream changes from the sources into BigQuery, which keeps reporting current without heavy queries against the operational systems. Daily manual exports are stale and manual, dual writes risk inconsistency, and direct dashboard queries add load to production.

Query insights show the slowest queries and the load they place on the instance, which is what the team needs to find the cause. Storage logs, billing reports and uptime checks do not show query-level performance.

The Cloud SQL Client role allows connecting to the instance without permission to modify it, which matches the requirement. Cloud SQL Admin and Project Owner allow configuration changes, and billing viewer rights do not grant database connections.

The maintenance window sets the day and hour for updates, which lets the team schedule disruption at a quiet time. Storage type, replica count and IP range do not control when maintenance happens.

The instance configuration selects regional or multi-region placement and sets processing capacity, which determine availability and cost. A database name, column order and client time zone do not change placement or availability.

Private IP attached to the VPC through private services access means the instance is reachable only inside the VPC. A public address with a firewall rule still exposes an endpoint, and Cloud NAT and replicas do not restrict where connections originate.

Documented data flows with named owners allow changes to be reviewed in advance, and a single operations view over each database's monitoring keeps the solution visible. Shared passwords, full admin rights and same-zone backups weaken security or resilience.

A Cloud Monitoring alerting policy on the CPU metric, with a duration condition and notification channels, alerts on sustained high CPU. A budget alert tracks spend, log exports are reviewed late, and an uptime check only fires when the instance is down.

Cross-region read replicas serve reads close to users while the primary handles writes, which matches the requirement. Independent instances have diverging data, a single region adds latency for the second region, and restoring a backup for each read is impractical.

Testing in a staging copy, keeping a backup for rollback and deploying in a planned window reduces risk to the production database. Changing production first, writing the rollback afterwards and skipping tests all expose production before the change is proven.

Stale reads and read timestamps let a query read a consistent older snapshot without taking locks, which suits reporting on past states. Foreign keys enforce integrity, partitioning and indexes speed up access, and none of them reads a past snapshot.

Read replicas add read capacity while the primary keeps handling writes, which matches the requirement. A larger primary does not add read capacity on replicas, turning off backups removes recovery, and writing reports into the primary adds load.

Replicating to a second cluster in another zone or region, with app profiles controlling routing, improves availability. A larger single cluster still fails with its zone, a cache does not survive a zone failure, and turning off backups removes recovery.

Firestore in Native mode supports real-time listeners and offline sync for client apps, which matches the requirement. Datastore mode does not provide real-time listeners, Bigtable is not a client sync store, and Memorystore is a cache rather than a synchronised data store.

Deletion protection stops an instance being removed by accident, and retention settings with separately restricted backups keep recovery points safe. Owner rights for every developer, same-project backups and disabled audit logs all make accidental or malicious loss easier.

Database Migration Service replicates continuously from the source and supports a planned cutover, which keeps downtime short. Nightly dumps require a long outage, manual file copies are fragile, and scripts without validation risk silent data loss.

Datastream captures changes from the source database and delivers them to BigQuery as a continuous stream. File transfers copy whole files on a schedule, hourly queries load the source repeatedly, and Pub/Sub does not capture database changes by itself.

Comparing row counts, checksums and sample records between source and target shows whether the data matches. Disk size says nothing about correctness, checking one table leaves the rest unverified, and accepting data without checks removes the evidence the cutover depends on.

Rehosting the same engine on Cloud SQL keeps the application change minimal, and optimisation can follow once the move is stable. Rewriting queries or changing engines first adds risk, and changing the engine and the data layer together makes faults hard to isolate.

Continuous replication keeps the target current, so the only downtime is the short freeze and promotion at cutover. A daytime export and import, an empty target, and a snapshot restored without prior replication all require longer write downtime or lose data.

Running key queries on both sides and testing the target read-only with production-like data both reveal mismatches before the cutover. Skipping performance tests, comparing only counts and testing after cutover all find problems too late or miss them.

An assessment of the schema and stored code identifies the incompatibilities and the effort needed before any data moves. Moving data first, rewriting queries blind and skipping the assessment each create avoidable rework.