Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Restoring Cloud Composer Across Regions with Snapshots
Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
Your enterprise runs critical batch data processing pipelines orchestrated by Cloud Composer in the us-central1 region. You are tasked with designing a cross-region disaster recovery (DR) architecture that can restore workflow orchestration in us-east4 if an entire region experiences an outage.
The design must satisfy the following criteria:
- Maintain DAG execution history and pipeline state across regions.
- Ensure configuration consistency and minimize workflow restoration time.
- Prevent inconsistent data states caused by re-executing tasks that ran after the last backup.
Which strategy should you implement?
Explanations
Configure scheduled environment snapshots to a multi-region Cloud Storage bucket, deploy a failover Cloud Composer environment in us-east4 with identical Airflow and Composer versions, design DAG tasks to be idempotent, and load the latest snapshot into the failover environment upon failure.
Configure scheduled environment snapshots to a multi-region Cloud Storage bucket, deploy a failover Cloud Composer environment in us-east4 with identical Airflow and Composer versions, design DAG tasks to be idempotent, and load the latest snapshot into the failover environment upon failure.
What Environment Snapshots for Cloud Composer Are
Cloud Composer environment snapshots capture the complete state of an Airflow environment, including the Airflow metadata database, environment variables, connections, and user configurations. These snapshots can be exported directly into a Cloud Storage bucket and imported into a new or pre-provisioned standby environment in another region.
How It Meets the Requirements
- Preserve DAG execution history: Loading an environment snapshot restores the Airflow metadata database, preserving previous DAG run states, task statuses, variable configurations, and historical metrics.
- Ensure configuration consistency: Deploying a standby or failover environment in
us-east4running the exact same Cloud Composer and Airflow version and build prevents compatibility and library mismatch issues during restoration. - Prevent inconsistent data states with idempotency: Because tasks executed between the snapshot creation time and the outage may re-execute upon loading the snapshot, designing tasks to be idempotent ensures that repeated executions do not cause duplicate records or corrupted state.
- Multi-region storage accessibility: Storing snapshots in a multi-region or secondary-region bucket guarantees that the snapshot artifacts remain accessible even when the primary region is offline.
Key Advantages
- Consistent State Transfer: Restores complex Airflow state including active connections, variables, and DAG run records.
- Low Recovery Time Objective (RTO): Having a pre-created warm standby environment allows rapid restoration via the
gcloud composer environments snapshots loadoperation. - Decoupled Failure Domains: Cross-region snapshot storage ensures full operational isolation between
us-central1andus-east4.
Why This Is Optimal
Cloud Composer does not support native multi-region active-active cluster clustering. Scheduled snapshots combined with an identically configured failover environment and idempotent DAG tasks provide the standard, Google-recommended cross-region disaster recovery pattern.
Deploy Cloud Composer in High Resilience mode in us-central1, which automatically replicates the Airflow metadata database to secondary regions and handles automatic cross-region failover.
Deploy Cloud Composer in High Resilience mode in us-central1, which automatically replicates the Airflow metadata database to secondary regions and handles automatic cross-region failover.
What Cloud Composer High Resilience Mode Is
High Resilience mode in Cloud Composer distributes the environment's control plane, schedulers, web servers, and the underlying Cloud SQL Airflow database across multiple zones within a single Google Cloud region.
Why It Doesn't Meet the Requirement
- Fails regional DR: High Resilience mode provides multi-zonal high availability within a single region (such as
us-central1), not cross-region failover. If the entire region experiences an outage, the multi-zonal database and schedulers in that region become unreachable. - No automatic cross-region replication: Cloud Composer does not replicate its tenant metadata database across different geographic regions automatically.
Key Characteristics and Limitations
- Distributes schedulers and database instances across two separate zones in the same region.
- Automatically recovers tasks and reschedules workers when a single zone fails.
- Remains vulnerable to complete regional data center outages.
This Answer Would Be Correct If
The requirement was to protect against isolated zonal failures within the primary region without deploying infrastructure in a secondary region.
Deploy dual active-active Cloud Composer environments in us-central1 and us-east4 behind a global Cloud Load Balancer to automatically route and distribute DAG scheduling tasks evenly between regions.
Deploy dual active-active Cloud Composer environments in us-central1 and us-east4 behind a global Cloud Load Balancer to automatically route and distribute DAG scheduling tasks evenly between regions.
What Cloud Load Balancing with Multi-Region Backends Is
Cloud Load Balancing distributes incoming HTTP(S) or TCP/UDP network traffic across backend services running in multiple regions globally based on latency and backend capacity.
Why It Doesn't Meet the Requirement
- Incompatible with Airflow Architecture: Airflow schedulers require a centralized metadata database to manage task states, execution locks, and dependency graphs. Running two independent active-active Cloud Composer environments against the same workflow schedules without shared state leads to duplicate executions, race conditions, and split-brain scenarios.
- Load Balancers do not orchestrate batch jobs: Cloud Load Balancing routes external client network requests (such as web traffic or API calls); it does not coordinate internal Airflow cron schedules, task queues, or worker executions.
Key Characteristics and Limitations
- Cloud Load Balancing manages incoming network traffic, not cron-triggered batch workflows.
- Active-active Airflow deployments across regions without unified database coordination cause conflicting executions.
- Web server interfaces and REST APIs can be load balanced, but workflow orchestration logic cannot be transparently split across independent Airflow clusters.
This Answer Would Be Correct If
You were load-balancing external API requests across stateless web applications deployed across multiple regions.
Configure Regional Persistent Disks to synchronously replicate the Cloud Composer environment bucket and database storage from us-central1 to us-east4, then force-attach the replicated disk to a Compute Engine instance.
Configure Regional Persistent Disks to synchronously replicate the Cloud Composer environment bucket and database storage from us-central1 to us-east4, then force-attach the replicated disk to a Compute Engine instance.
What Regional Persistent Disks Are
Regional Persistent Disk (Regional PD) provides synchronous block storage replication across two zones within the same Google Cloud region. It allows VMs to fail over storage access between zones with a Recovery Point Objective (RPO) of zero.
Why It Doesn't Meet the Requirement
- Regional scope limit: Regional Persistent Disks replicate synchronously between two zones in one region; they cannot replicate synchronously or span across distinct geographic regions like
us-central1andus-east4. - Managed service abstraction: Cloud Composer is a managed service where the Airflow database runs inside a Google-managed tenant project Cloud SQL instance, and the DAG assets reside in Cloud Storage, neither of which allows raw block-level disk detachment and force-attachment by users.
Key Characteristics and Limitations
- Restricts replication to intra-region zonal pairs.
- Intended for Compute Engine virtual machines and self-managed workloads, not managed Cloud Composer control planes.
- High write latency over cross-region distances makes synchronous regional disk replication physically impractical across distant regions.
This Answer Would Be Correct If
You were hosting a custom, self-managed Airflow scheduler on standalone Compute Engine instances requiring zonal block storage failover within a single region.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 1,353 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
AdvancedProfessional Data Engineer
Dataflow Regional Execution Without Zone Pinning
Running jobs in multiple regions or zones
AdvancedProfessional Data Engineer
Dataflow FlexRS Data Locality
Running jobs in multiple regions or zones
AdvancedProfessional Data Engineer
Looker Model, Row, and Field-Level Security
Publishing reports and visualizations
AdvancedProfessional Data Engineer
Resource Location Restriction Non-Retroactive
Regional considerations (data sovereignty) for data access and storage
AdvancedProfessional Data Engineer
Tree-AH Leaf Nodes To Search Percent Recall
Preparing unstructured data for embeddings and retrieval-augmented generation (RAG)
FundamentalAssociate Data Practitioner
Zonal High Availability with Cross-Region Disaster Recovery
Distinguish between primary and secondary data storage location type (e.g., regions, dual-regions, multi-regions, zones) for data redundancy
Last updated Validated