First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.
Continue in the practice tool above to load more questions, 50 at a time.
Question 1The Airflow UI
In the Airflow UI, which page lists every DAG the scheduler has discovered along with its tags, owner, and recent run status?
- The Graph view of a single run
- The DAGs page Correct answer.
- The Browse XComs page
- The Admin Connections page
Explanation
The DAGs page is the top-level inventory of all DAGs discovered by the scheduler and shows summary columns such as tags, owner, schedule, and last run state. It is the natural starting point for navigating to an individual DAG. Other pages either show task-level artifacts or configuration records.
Question 2The Airflow UI
An operator wants to see the dependency structure of a single DAG run, including which tasks succeeded or failed, in a box-and-arrow layout. Which view should they open?
- The Audit Log
- The Code view
- The Gantt view
- The Graph view Correct answer.
Explanation
The Graph view renders tasks as nodes connected by dependency edges, coloring each node by its state for the selected run. It is the standard way to inspect upstream and downstream relationships at a glance. Gantt shows duration over time, Code shows source, and the Audit Log records user actions.
Question 3The Airflow UI
Which UI view displays task durations as horizontal bars laid out on a time axis, making it easy to spot the longest-running tasks in a run?
- The DAGs page
- The Variables page
- The Graph view
- The Gantt view Correct answer.
Explanation
The Gantt view charts each task instance as a bar spanning its start and end times, so relative durations and scheduling gaps become visible. This helps identify bottlenecks within a run. The Graph view emphasizes topology rather than elapsed time.
Question 4The Airflow UI
A user wants to re-run only the tasks that failed in the most recent run, without re-running the tasks that already succeeded. Which UI action supports this?
- Use Trigger DAG with a future logical date
- Use Clear on the failed tasks in the Graph view Correct answer.
- Use Mark Success on the entire DAG run
- Use Delete on the DAG from the DAGs page
Explanation
Clearing selected task instances resets their state so the scheduler will run them again, and clearing only the failed tasks leaves successful ones untouched. This is the standard UI workflow for partial recovery. Deleting the DAG removes it entirely, and marking success skips execution.
Question 5The Airflow UI
In the Grid view of a DAG, what do the small squares in each column represent?
- The retry count configured on the task
- The CPU usage recorded for that task
- Task instances for successive runs of that task Correct answer.
- The number of upstream dependencies for that task
Explanation
The Grid view lays out tasks as columns and runs as rows, and each square is a task instance colored by its state. Scanning a column shows the history of one task across runs. It does not encode dependency counts or resource metrics.
Question 6The Airflow UI
A task instance shows a purple/violet state in the UI after a run. What does that state indicate?
- The task was removed from the DAG
- The task is currently running
- The task failed
- The task was skipped Correct answer.
Explanation
In Airflow's state coloring, skipped task instances are shown in a light purple/pink tone. This typically happens when a branching operator or a trigger rule causes the task not to execute. Failure is red, running is light green, and removed tasks are gray.
Question 7The Airflow UI
Where in the UI can an operator inspect the rendered command, logs, and try number for one specific task instance?
- The Admin > Pools page
- The Browse > SLA Misses page
- The Task Instance detail panel opened from the Grid or Graph view Correct answer.
- The DAGs page filter bar
Explanation
Clicking a task instance in the Grid or Graph view opens a detail panel with tabs for logs, rendered templates, the try history, and attributes. This is where per-attempt diagnostics live. Pools, SLA misses, and filters are unrelated global pages.
Question 8The Airflow UI
A team needs to confirm which rendered value a templated parameter received at runtime. Which UI feature shows the template output for a task instance?
- The Browse > Variables page
- The Calendar view of the DAG
- The Rendered Template tab in the task instance panel Correct answer.
- The Plugins page
Explanation
Airflow stores the rendered fields of each task instance, and the Rendered Template tab displays the final values after Jinja evaluation. This is essential for debugging templates that depend on runtime context. Calendar, Variables, and Plugins do not expose per-instance rendering.
Question 9The Airflow UI
Which UI location lets an administrator create and edit connection records used by hooks and operators?
- The DAG Code view
- Admin > Connections Correct answer.
- Browse > XComs
- Browse > Task Instances
Explanation
Connection records, including host, login, and password fields, are managed under Admin > Connections. Operators reference them by connection ID at runtime. XComs and Task Instances are run artifacts, and the Code view shows DAG source.
Question 10The Airflow UI
An engineer wants to store a small reusable configuration value that many DAGs can read by key. Which UI page manages this?
- Admin > Connections
- Browse > DAG Runs
- Browse > SLA Misses
- Admin > Variables Correct answer.
Explanation
Variables are global key/value pairs managed under Admin > Variables and readable from templates or code. They suit small shared configuration such as environment names or thresholds. Connections hold credentials, and the Browse pages list run metadata.
Question 11The Airflow UI
A DAG is paused and a user clicks the trigger button on the DAGs page. What is the effect?
- The DAG's schedule is changed to manual
- A manual run is created even though the DAG is paused Correct answer.
- Nothing happens until the DAG is unpaused
- All existing runs are cleared
Explanation
The trigger button creates a manual DAG run for the current time regardless of the paused flag, because it is an explicit user action. The scheduler will still not create scheduled runs while the DAG is paused. Triggering does not alter the schedule or delete history.
Question 12The Airflow UI
What does the pause/unpause toggle on the DAGs page control?
- Whether the scheduler creates new scheduled runs for that DAG Correct answer.
- Whether users can view the DAG's logs
- Whether the DAG's tasks can be cleared
- Whether the DAG file is parsed at all
Explanation
Pausing a DAG stops the scheduler from creating new scheduled runs while preserving history and letting manual triggers proceed. The DAG file is still parsed so the UI keeps showing it. Viewing logs and clearing tasks remain available.
Question 13The Airflow UI
A user needs to find which DAG runs breached their SLA deadline. Which UI page is designed for this?
- Browse > XComs
- The Graph view
- Browse > SLA Misses Correct answer.
- Admin > Pools
Explanation
The SLA Misses page aggregates task instances that missed their configured service-level deadlines, along with the DAG and run. It is the dedicated reporting surface for SLA breaches. Pools, XComs, and Graph serve different purposes.
Question 14The Airflow UI
An operator wants to see the raw source code of a DAG directly in the browser. Which view provides this?
- The Gantt view
- The Calendar view
- The Code view Correct answer.
- The Task Instance panel
Explanation
The Code view displays the DAG file's source as parsed by Airflow, which helps confirm what the scheduler actually loaded. It is read-only in the UI. Gantt and Calendar are run-oriented, and the Task Instance panel is per-task.
Question 15The Airflow UI
A task instance is stuck in a queued state and an operator wants to force it to be considered successful without running it. Which UI action accomplishes this?
- Trigger the DAG again
- Delete the DAG run
- Clear the task instance
- Mark Success on the task instance Correct answer.
Explanation
Mark Success sets the task instance state directly, which lets downstream tasks proceed under their trigger rules. It records a state without executing the task. Clearing would schedule a real run, and triggering or deleting affects whole runs.
Question 16The Airflow UI
In the Graph view, what does clicking a task node primarily allow a user to do?
- Change the DAG's schedule interval
- Edit the connection used by the task
- Open the task instance details and available actions for that task Correct answer.
- Reorder the tasks in the DAG
Explanation
Selecting a node in the Graph view opens details for that task instance, including logs, rendered fields, and actions such as clear or mark state. Structural edits like schedule changes are made in the DAG file, not the graph.
Question 17The Airflow UI
A user filters the DAGs page by tag. What is the result?
- All DAGs are listed but runs are hidden
- Tasks with that tag are highlighted in the Graph view
- Only DAGs carrying that tag are listed Correct answer.
- The tag is applied to every DAG in the list
Explanation
Tags are DAG-level labels, and the tag filter narrows the DAGs list to those that include the selected tag. It does not modify DAGs or task highlighting. This helps large installations group DAGs by team or domain.
Question 18The Airflow UI
Which UI page would an administrator use to review actions such as who cleared a task or changed a variable?
- The Gantt view
- Browse > Audit Log Correct answer.
- Browse > DAG Runs
- Admin > Pools
Explanation
The Audit Log records user-initiated actions in the UI and API, including clears, variable edits, and connection changes, with timestamps and user identity. It supports accountability and troubleshooting. DAG Runs, Pools, and Gantt show execution or capacity data, not user actions.
Question 19The Airflow UI
An operator sees a task instance in the 'upstream_failed' state. What does this state communicate in the UI?
- The task did not run because a required upstream task failed Correct answer.
- The task exceeded its configured retry limit
- The task was intentionally skipped by a branch operator
- The task itself raised an exception during execution
Explanation
Upstream_failed means the scheduler determined that a dependency did not succeed, so this task was never executed. It points the investigator toward the failing ancestor rather than this task's own code. A direct exception yields failed, and a branch skip yields skipped.
Question 20The Airflow UI
A DAG that previously appeared in the UI has vanished from the DAGs page after an edit. Which explanation is most consistent with the UI behavior?
- The file now fails to import, so the scheduler no longer registers the DAG Correct answer.
- The DAG was automatically paused by the UI
- The tag filter was applied to the DAG
- The DAG's runs were cleared from the Browse page
Explanation
Airflow only shows DAGs that parse successfully; an import-time error removes the DAG from the scheduler's registry and therefore from the UI. The import errors are surfaced separately so the syntax or dependency issue can be fixed. Pausing, clearing runs, or tagging does not remove a DAG from the list.
Question 21The Airflow UI
Two runs of the same DAG exist, and a user wants to compare how long a specific task took in each. Which UI approach directly supports this comparison?
- Open the task's history from the Grid view and compare durations across runs Correct answer.
- Open Browse > XComs and compare message sizes
- Open Admin > Connections and inspect the task's hook
- Open the Code view and read the task definition
Explanation
The Grid view exposes per-task history, letting a user select a task and review its instances across runs with durations and states. This is the intended UI path for comparing repeated executions. Code, Connections, and XComs do not present duration history.
Question 22The Airflow UI
A task instance is in the 'up_for_retry' state. What should an operator conclude from this UI state?
- The task was removed from the DAG definition
- The task succeeded but its downstream tasks have not started
- The task failed an attempt but has retries remaining and will run again Correct answer.
- The task is waiting for a pool slot before its first attempt
Explanation
Up_for_retry indicates that an attempt did not succeed and the retry policy allows another try, so the scheduler will requeue it after the retry delay. It is distinct from queued, which precedes a first or subsequent attempt, and from failed, which is terminal. Removed tasks appear as removed.
Question 23The Airflow UI
A user wants to inspect the value a task pushed for a downstream task to consume. Which UI page lists these messages?
- Browse > XComs Correct answer.
- Browse > SLA Misses
- Admin > Pools
- Admin > Variables
Explanation
XComs are the key/value messages tasks push and pull, and Browse > XComs lists them with the producing task, key, and value. This lets users verify what data flowed between tasks. Variables are global config, and SLA Misses and Pools serve unrelated functions.
Question 24The Airflow CLI
Which Airflow CLI command starts the scheduler process in the foreground?
- airflow initdb
- airflow scheduler Correct answer.
- airflow trigger_dag
- airflow webserver
Explanation
The scheduler subcommand launches the scheduler component that parses DAG files and queues task instances for execution. It runs in the foreground by default, so it is normally managed by a process supervisor in production. The webserver command serves the UI instead of scheduling work.
Question 25The Airflow CLI
Which command lists the DAGs that Airflow has discovered in its metadata database?
- airflow tasks list
- airflow dag show
- airflow dags list Correct answer.
- airflow list_dags
Explanation
In Airflow 2.x the grouped CLI exposes DAG operations under `airflow dags`, and `airflow dags list` prints every DAG the scheduler has serialized. The older flat command `list_dags` was removed in the 2.0 CLI reorganization. Subcommands like `tasks list` operate on tasks within a single DAG.
Question 26The Airflow CLI
What does `airflow dags trigger my_dag` do by default?
- Creates a manual DAG run using the current timestamp as the logical date Correct answer.
- Pauses the DAG until the next scheduled interval
- Re-parses the DAG file and prints its task list
- Deletes the most recent DAG run for that DAG
Explanation
Triggering a DAG from the CLI enqueues a manual run, and without an explicit execution date argument the run uses the current time as its logical date. It does not alter the DAG's schedule or pause state. Use `--exec-date` to supply a specific logical date instead.
Question 27The Airflow CLI
Which command displays the rendered template fields of a single task instance?
- airflow tasks render Correct answer.
- airflow tasks state
- airflow dags show
- airflow tasks test
Explanation
`airflow tasks render` prints the templated fields of a task instance after Jinja rendering, which is useful for debugging template errors. It requires a DAG ID, task ID, and execution date. The `test` command actually executes the task locally instead of only showing rendered output.
Question 28The Airflow CLI
Which option makes `airflow dags list` output machine-readable JSON?
- --output json Correct answer.
- --machine
- --format json
- --json
Explanation
The grouped DAG commands support `--output` with values such as `json`, `table`, or `plain`, so `airflow dags list --output json` yields structured output. This is convenient for scripting and CI checks. The other flags are not recognized by the CLI parser.
Question 29The Airflow CLI
Which command clears task instances for a DAG so they can be re-run?
- airflow tasks reset
- airflow tasks clear Correct answer.
- airflow dags clear
- airflow tasks rerun
Explanation
`airflow tasks clear` resets the state of matching task instances, allowing the scheduler to run them again. It supports flags such as `--start-date`, `--end-date`, `--only-failed`, and `--yes`. Clearing is the CLI equivalent of the Clear action in the UI.
Question 30The Airflow CLI
What is the purpose of the `airflow db init` command?
- Seed the database with sample example DAGs
- Reset all DAG run history to a clean state
- Back up the metadata database to a file
- Create the metadata database tables and apply migrations Correct answer.
Explanation
`airflow db init` initializes the metadata database by creating the schema and running migrations, and it is typically executed once before first startup. In older versions this was named `initdb`. It does not load example DAGs or clear run history.
Question 31The Airflow CLI
An operator needs to run a single task locally without recording its state in the metadata database. Which command fits?
- airflow tasks test my_dag my_task 2024-01-01 Correct answer.
- airflow tasks run my_dag my_task 2024-01-01
- airflow tasks state my_dag my_task 2024-01-01
- airflow dags trigger my_dag
Explanation
`airflow tasks test` executes the task in isolation and prints logs to the console without writing a task instance state to the database. It is the standard way to debug a task locally. `tasks run` performs a real run that records state, which is not what the operator wants.
Question 32The Airflow CLI
A developer wants to check whether a DAG file has import errors without opening the UI. Which command is most appropriate?
- airflow dags validate
- airflow dags report
- airflow dags list-import-errors Correct answer.
- airflow dags parse --errors
Explanation
`airflow dags list-import-errors` shows DAG files that failed to import along with the error details recorded by the scheduler. It is the CLI counterpart to the import errors view in the UI. Dedicated parse or validate subcommands are not part of the standard grouped CLI.
Question 33The Airflow CLI
Which command shows the resolved configuration values Airflow is currently using, including defaults from airflow.cfg and environment variables?
- airflow config get-value
- airflow info
- airflow settings show
- airflow config list Correct answer.
Explanation
`airflow config list` prints every configuration option with its effective value after merging defaults, airflow.cfg, and environment variables. It also flags options changed from their defaults. `config get-value` retrieves only one specific option, not the full resolved set.
Question 34The Airflow CLI
A team wants to pause a DAG from a deployment script so the scheduler stops creating new runs. Which command achieves this?
- airflow dags disable my_dag
- airflow dags set-state my_dag paused
- airflow dags pause my_dag Correct answer.
- airflow dags update my_dag --paused
Explanation
`airflow dags pause` sets the DAG's is_paused flag to true so the scheduler stops scheduling new runs while preserving history. The inverse is `airflow dags unpause`. The other command forms are not valid subcommands in the grouped CLI.
Question 35The Airflow CLI
Which flag on `airflow tasks clear` restricts clearing to task instances that previously failed?
- --only-failed Correct answer.
- --state failed
- --failed-only
- --filter failed
Explanation
`airflow tasks clear` accepts `--only-failed`, which clears only task instances whose current state is failed. This avoids resetting successful tasks during a targeted retry. The other flag spellings are not recognized by the CLI.
Question 36The Airflow CLI
How can a user supply a specific logical date when triggering a DAG from the CLI?
- Pass the date to the --exec-date flag Correct answer.
- Pass the date as the second positional argument to dags trigger
- Use the --logical-date flag on dags trigger
- Set the AIRFLOW_EXEC_DATE environment variable
Explanation
`airflow dags trigger` accepts `--exec-date` (also `-e`) to set the logical date of the manual run instead of defaulting to now. Supplying it makes backfills and reruns deterministic. The other mechanisms are not supported by the command.
Question 37The Airflow CLI
Which command prints the Airflow version along with environment diagnostics such as Python path and executor?
- airflow version --verbose
- airflow info Correct answer.
- airflow config list
- airflow doctor
Explanation
`airflow info` reports the Airflow version plus diagnostics like the Python executable, executor, and configuration file paths. It is useful when filing support requests. `airflow version` prints only the version string.
Question 38The Airflow CLI
A user runs `airflow tasks states-for-dag-run my_dag manual__2024-01-01T00:00:00+00:00`. What does the output contain?
- The state of each task instance in that specific DAG run Correct answer.
- The scheduler logs for that run
- The state of each DAG run for that DAG
- The rendered templates of every task in the run
Explanation
`states-for-dag-run` lists the task instances belonging to one DAG run identified by its run ID and reports each one's state. It is scoped to a single run rather than the whole DAG history. Rendered templates and scheduler logs require different commands.
Question 39The Airflow CLI
Which command executes a full backfill of a DAG over a date range from the CLI?
- airflow dags trigger my_dag --start-date 2024-01-01 --end-date 2024-01-07
- airflow dags rerun my_dag --start-date 2024-01-01 --end-date 2024-01-07
- airflow tasks clear my_dag --start-date 2024-01-01 --end-date 2024-01-07
- airflow dags backfill my_dag --start-date 2024-01-01 --end-date 2024-01-07 Correct answer.
Explanation
`airflow dags backfill` runs a DAG for each schedule interval in the given date range, creating historical runs without waiting for the scheduler. It accepts `--start-date` and `--end-date` plus options like `--reset-dagruns`. Triggering a DAG creates only one run regardless of the range.
Question 40The Airflow CLI
Which command lists the tasks defined in a DAG along with their operators?
- airflow tasks list my_dag --tree Correct answer.
- airflow dags show my_dag --tasks
- airflow dags list-tasks my_dag
- airflow tasks show my_dag
Explanation
`airflow tasks list` prints the tasks of a DAG, and the `--tree` flag renders them in a dependency tree so operator names and structure are visible. It requires the DAG ID as an argument. The other command forms are not valid subcommands.
Question 41The Airflow CLI
A CI pipeline needs to fail if any DAG has import errors. Which approach best uses the CLI for this check?
- Run `airflow db init` and fail when tables already exist
- Run `airflow dags list-import-errors` and fail when its output is non-empty Correct answer.
- Run `airflow tasks test` on every task and fail on any warning
- Run `airflow dags list` and fail when the exit code is zero
Explanation
`airflow dags list-import-errors` reports files that failed to import, so a non-empty result signals a broken DAG and the pipeline can exit non-zero. This catches syntax and import problems before deployment. The other commands either do not surface import errors or have unrelated semantics.
Question 42The Airflow CLI
An engineer needs to inspect the effective value of a single config option, such as the executor, without dumping the whole config. Which command is correct?
- airflow config show core executor
- airflow info --key core.executor
- airflow config list core.executor
- airflow config get-value core executor Correct answer.
Explanation
`airflow config get-value` takes a section and a key and prints only that resolved value, which is ideal for scripting. It reflects defaults, airflow.cfg, and environment overrides. The other forms are not valid CLI syntax.
Question 43The Airflow CLI
Which command deletes the metadata database tables and recreates them, and why is it dangerous in production?
- `airflow db init` destroys all DAG run history
- `airflow db reset` destroys all DAG run and task history Correct answer.
- `airflow db migrate` truncates task instance records
- `airflow db clean` drops every table and recreates them
Explanation
`airflow db reset` drops and recreates the schema, erasing all run, task, and log metadata, so it must never be run against a production database. `db clean` removes old records by age rather than dropping tables. `db migrate` only applies schema migrations.
Question 44The Airflow CLI
A run ID like `manual__2024-01-01T00:00:00+00:00` is passed to `airflow tasks states-for-dag-run`. What does the command require besides the DAG ID and run ID?
- The task ID of the instance to inspect
- Nothing else; the run ID uniquely identifies the DAG run Correct answer.
- The --tree flag to expand dependencies
- A separate --exec-date flag matching the run ID
Explanation
The run ID encodes the run type and logical date and uniquely identifies the DAG run within the DAG, so only the DAG ID and run ID are needed. The command then lists every task instance in that run. No extra date or task flags are required.
Question 45The Airflow CLI
Which statement best explains why `airflow tasks test` is preferred over `airflow tasks run` when debugging a task's logic locally?
- It records state so the scheduler can resume the run afterward
- It bypasses Jinja rendering so raw template strings are shown
- It forces all upstream tasks to succeed before executing
- It executes the task without persisting state or depending on a scheduler-managed run Correct answer.
Explanation
`tasks test` runs the task callable in isolation and prints logs without writing task instance state, so experiments do not pollute the metadata database or interfere with scheduled runs. `tasks run` is used by executors for real runs and persists state. Rendering still occurs during a test run.
Question 46The Airflow CLI
A backfill needs to rerun intervals whose DAG runs already exist and are marked successful. Which flag should be added to `airflow dags backfill`?
- --ignore-existing
- --force
- --only-failed
- --reset-dagruns Correct answer.
Explanation
`--reset-dagruns` clears existing DAG runs in the backfill range before recreating them, so previously successful intervals are executed again. Without it, existing runs are left untouched. The other flags are not the documented mechanism for this behavior.
Question 47Airflow use cases
Which Airflow use case best fits a workflow that must run the same transformation for each of 40 customer files once per night?
- A branch operator that selects one file per run
- A dynamically mapped task group that expands over the file list Correct answer.
- A single task with a Python loop that processes all files sequentially
- A sensor that waits for each file and then exits
Explanation
Dynamic task mapping expands a task into one instance per input item at runtime, which is the intended pattern for repeating identical work over a variable collection. It keeps each file's processing independently retryable and visible in the UI. A single loop hides per-item failures inside one task.
Question 48Airflow use cases
A team wants Airflow to orchestrate a long-running Spark job that executes on a separate cluster. What is the appropriate division of responsibility?
- Airflow replaces the cluster scheduler for the duration of the job
- Airflow stores the job's intermediate shuffle data between tasks
- Airflow executes the Spark driver and holds the job open for its duration
- Airflow triggers and monitors the job while Spark performs the computation Correct answer.
Explanation
Airflow is an orchestrator: it schedules, triggers, and tracks the state of external work rather than performing heavy computation itself. Submitting a job to a Spark cluster and polling or waiting for completion is the standard integration pattern. Compute and shuffle storage remain the cluster's responsibility.
Question 49Airflow use cases
Which scenario is a poor fit for Airflow?
- A nightly batch pipeline combining several external systems
- A high-frequency stream processor handling sub-second events Correct answer.
- A scheduled report generated from a data warehouse
- A backfill of historical partitions after a logic fix
Explanation
Airflow is built for scheduled, mostly batch-oriented workflows and its scheduler operates on a coarse interval, so it is unsuitable for continuous low-latency stream processing. Streaming workloads belong to dedicated stream engines, with Airflow at most managing their deployment lifecycle. Batch, backfill, and reporting patterns are core Airflow use cases.
Question 50Airflow use cases
What is the primary purpose of an Airflow DAG?
- To define the schedule, dependencies, and tasks of a workflow as code Correct answer.
- To provision the compute infrastructure tasks run on
- To serve as the query engine for the metadata database
- To store the result rows produced by each task
Explanation
A DAG is a Python definition of a workflow: its tasks, their dependency edges, and scheduling configuration. It is version-controlled configuration rather than a data store or compute provider. Results and infrastructure are handled by external systems and executors.