Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise organization runs a mission-critical transactional application on a Google Cloud SQL instance. At 14:15 UTC, an administrator accidentally executes an erroneous batch update script that corrupts several production tables.
The database has daily automated backups configured at 02:00 UTC, and Point-in-Time Recovery (PITR) with continuous transaction logging is enabled. The technical recovery team establishes an objective to restore the database to its exact valid state at 14:14 UTC with minimal data loss (lowest possible RPO).
Which recovery procedure should the cloud architect execute?
Restore the Cloud SQL instance directly from the daily automated backup taken at 02:00 UTC to overwrite the existing production instance.
Execute a point-in-time recovery (PITR) targeting 14:14 UTC, which creates a new Cloud SQL instance from the preceding backup and applies transaction logs up to the specified timestamp.
Perform an in-place point-in-time recovery (PITR) on the existing Cloud SQL instance by specifying the recovery timestamp parameter as 14:14 UTC via the gcloud CLI.
Trigger a serverless database export to a Cloud Storage bucket, purge the corrupted rows manually in SQL, and import the export back into the instance.
Restore the Cloud SQL instance directly from the daily automated backup taken at 02:00 UTC to overwrite the existing production instance.
Execute a point-in-time recovery (PITR) targeting 14:14 UTC, which creates a new Cloud SQL instance from the preceding backup and applies transaction logs up to the specified timestamp.
Point-in-time recovery (PITR) is a continuous data protection mechanism in Cloud SQL that enables you to restore a database instance to an arbitrary historical second within your retention window. PITR leverages a combination of base automated backups and continuous transaction logs (such as binary logs for MySQL or write-ahead logs for PostgreSQL) to reconstruct the database state prior to an incident.
14:14 UTC (one minute prior to the corrupting script execution), Cloud SQL restores the base backup taken at 02:00 UTC and replays all committed transaction logs up to 14:14 UTC. This avoids losing the 12+ hours of valid business transactions executed between 02:00 UTC and 14:14 UTC.Performing a timestamp-based PITR clone is the standard Google Cloud architecture pattern for recovering from logical data corruption without sacrificing hours of intervening valid database transactions.
Perform an in-place point-in-time recovery (PITR) on the existing Cloud SQL instance by specifying the recovery timestamp parameter as 14:14 UTC via the gcloud CLI.
Trigger a serverless database export to a Cloud Storage bucket, purge the corrupted rows manually in SQL, and import the export back into the instance.