PDE Maintaining and Automating Data Workloads Practice Question
Your organization runs a Cloud Composer 2 environment that executes dozens of DAGs. Several DAGs share a connection to an external REST API that enforces a rate limit of 100 requests per minute. During peak hours, DAGs fail with HTTP 429 errors. You want to prevent these failures without changing the external API's limits. What should you do?
⚠ Common exam trap
The trap here is treating retries or per-DAG concurrency limits as a substitute for a cross-DAG concurrency control like an Airflow pool.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create an Airflow pool with a limited number of slots and assign the affected tasks to that pool.
Airflow pools provide a shared concurrency limit that spans DAGs. Sizing a pool to keep total in-flight API calls under the provider's rate limit prevents 429 responses. Increasing workers, limiting per-DAG active runs, or relying on retries does not coordinate request volume across the many DAGs that share the external API.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the number of Celery workers in the Composer environment.
Why it's wrong here
Adding workers increases parallelism, which would send more concurrent requests to the API and worsen the 429 errors. More workers do not impose any rate limiting. This change addresses throughput capacity, not the concurrency ceiling imposed by the external API.
- ✗
Set the DAG's max_active_runs to 1 for each affected DAG.
Why it's wrong here
max_active_runs limits overlapping runs of a single DAG, but multiple distinct DAGs calling the same API would still run concurrently. The rate limit is shared across DAGs, so per-DAG limits do not aggregate. This setting does not coordinate concurrency across different DAGs.
- ✗
Add exponential backoff retries to the API-calling tasks.
Why it's wrong here
Retries with backoff can reduce repeated failures, but they do not prevent the initial 429 responses caused by too many concurrent requests. Under sustained load, retries add more traffic and may deepen throttling. Backoff is a mitigation for transient errors, not a concurrency control mechanism.
- ✓
Create an Airflow pool with a limited number of slots and assign the affected tasks to that pool.
Why this is correct
Airflow pools limit the number of concurrent task instances that can use a set of slots. By creating a pool sized to stay under the API's rate limit and assigning the API-calling tasks to it, you throttle concurrency across all DAGs. This directly prevents exceeding 100 requests per minute without modifying the external service.
About these practice questions
Courseiva writes every PDE question from scratch — 747 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This PDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PDE exam.