Disaster recovery strategies in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding RTO and RPO in Disaster Recovery

Which statement correctly describes the difference between Recovery Time Objective (RTO) and Recovery Point Objective (RPO) in disaster recovery?

A RTO is the maximum acceptable time to restore services after a disaster; RPO is the maximum acceptable data loss measured in time.

B RTO is the maximum data loss allowed; RPO is the time it takes to restore services after a disaster.

C RTO and RPO both measure the time to restore services but in different units.

D RTO measures data loss in bytes; RPO measures downtime in hours.

💡 Hint

Think about what each objective aims to limit: downtime or data loss.

RTO defines how quickly you want to recover your system after a failure. RPO defines how much data loss is acceptable, measured by time since last backup.

❓ Architecture

intermediate

Choosing a Disaster Recovery Architecture in GCP

You want to design a disaster recovery solution for a critical application on Google Cloud Platform. The application requires minimal downtime and data loss. Which architecture best fits this need?

A Backup and restore: Periodic backups stored in Cloud Storage, restore when needed.

B Pilot light: Minimal critical components running in a secondary region, scaled up on disaster.

C Warm standby: A scaled-down version of the full environment running in a secondary region, ready to scale up.

D Cold standby: No resources running in the secondary region until disaster occurs.

💡 Hint

Consider which option balances readiness and cost for minimal downtime.

Warm standby keeps a scaled-down environment running, allowing quick scaling and minimal downtime, suitable for critical apps.

❓ Configuration

advanced

Configuring Cross-Region Replication for Cloud Storage

Which configuration snippet correctly enables cross-region replication for a Google Cloud Storage bucket named 'source-bucket' to replicate objects to 'destination-bucket' in another region?

GCP

gsutil versioning set on gs://source-bucket

# Replication configuration below

A gsutil bucket replication set --source=source-bucket --destination=destination-bucket --location=us-east1

B gsutil replication create gs://source-bucket gs://destination-bucket

C gsutil replication create --source=source-bucket --destination=destination-bucket --location=us-central1

D gsutil replication set --source=source-bucket --destination=destination-bucket --location=us-east1

💡 Hint

Check the correct gsutil command syntax for bucket replication creation.

The correct command is 'gsutil replication create gs://source-bucket gs://destination-bucket'.

❓ security

advanced

Securing Disaster Recovery Access in GCP

To ensure secure access to disaster recovery resources in a secondary region, which IAM policy practice is best?

A Grant all users the Editor role on the recovery project for quick access.

B Disable IAM policies on the recovery project to prevent accidental lockout.

C Assign Owner role to all team members on the recovery project to avoid delays.

D Use least privilege principle by granting only necessary roles to specific users or groups.

💡 Hint

Think about minimizing risk while allowing access.

Granting only necessary permissions to specific users follows best security practices and reduces risk.

❓ service_behavior

expert

Behavior of Multi-Region Failover with Cloud SQL

In a Cloud SQL instance configured with high availability across multiple regions, what happens automatically when the primary region becomes unavailable?

A Cloud SQL automatically fails over to the standby instance in the secondary region with minimal downtime.

B Cloud SQL requires manual intervention to switch to the standby instance in the secondary region.

C Cloud SQL stops serving traffic until the primary region is restored.

D Cloud SQL creates a new instance in a different region and migrates data automatically.

💡 Hint

Consider how managed services handle failover for high availability.

Cloud SQL automatically fails over to the standby instance in the secondary region with minimal downtime.