Free Astronomer Apache Airflow 3 Fundamentals practice test

A DAG run is a specific execution of a DAG for a given logical/execution date, and it contains the task instances for that run. The DAG file (B) is the definition, an operator (C) defines a task, and the scheduler (D) is a component, not a run.

The metadata database persists Airflow's state — DAG runs, task instance states, connections, variables, XComs, and history. It doesn't execute task code (B), render the UI (C, that's the webserver), or cache datasets (D).

Airflow's role is orchestration: it schedules and coordinates tasks that usually push work to external systems (warehouses, Spark, cloud APIs). It doesn't do the heavy processing in its scheduler (B), replace external compute (C), or limit tasks to SQL (D) — tasks can run Python, Bash, and many operators.

Airflow is a workflow orchestration platform: you define pipelines as code (DAGs), and it schedules and monitors their execution. It's not a file store (D), a database engine (A), or an in-memory data-processing engine (C) — it orchestrates tasks that may call such systems.

The Webserver serves the Airflow UI, where users inspect DAGs, view task states and logs, and trigger runs. Scheduling (D) is the Scheduler's job, execution (B) is the Executor/workers', and state storage (A) is the metadata database's.

DAGs are Python files placed in the DAGs folder; the Scheduler and Webserver parse these files to build the DAG structure. They aren't stored only as binary in the database (A), kept solely in executor memory (C), or in browser storage (B).

schedule=None means the DAG is only run when manually triggered (or triggered by another DAG), with no automatic schedule. @daily (B), '* * * * *' (C, every minute), and @hourly (D) all define automatic schedules.

start_date establishes the point from which Airflow begins scheduling DAG runs (the first logical date considered). It's not the file creation time (B), a task timeout (C), or a UI color setting (D).

With @hourly, a start_date yesterday, and catchup=True, Airflow schedules a run for each hourly interval from the start_date to the present (backfill). It doesn't run once (C), every minute (A), or never (D).

The logical date marks the data interval a run covers; because of scheduling, a run for a given interval typically executes at the END of that interval, so the logical date differs from the actual run time. It's not the finish time (A), file timestamp (B), or server uptime (C).

default_args is a dictionary of parameters (e.g., owner, retries, retry_delay, email_on_failure) applied to every task in the DAG unless overridden. It's not solely the schedule (A), a data store (C), or a server config (B).

The >> operator sets a downstream dependency: task_a >> task_b means task_a runs first and task_b depends on it. task_a << task_b (B) is the reverse, and == (D) and + (A) are not dependency operators.

Setting catchup=False makes Airflow schedule only from the current interval forward, skipping historical backfill. A future start_date (B) delays all runs, schedule=None (C) disables scheduling entirely, and deleting the database (D) is destructive and wrong.

An operator is a predefined template for a unit of work (e.g., run Bash, run Python, transfer data); when you instantiate an operator in a DAG, you create a task. It's not the scheduler (B), a connection (C), or the UI (D).

XComs (cross-communications) let tasks push and pull small pieces of data (like an ID or a value) to share between them. They are NOT meant for large data (C) — use external storage for that; they don't define schedules (A) or render the UI (B).

A sensor is an operator that waits (polls) until a condition is true — a file exists, a partition lands, a time is reached — then allows downstream tasks to proceed. It's not a dashboard (B), index (C), or executor (D).

all_success means the task runs only if every upstream task succeeded, and it is the default trigger rule. one_failed (B) triggers when an upstream fails, all_done (D) triggers when upstreams finish regardless of outcome, and 'dummy' (A) is not a standard trigger rule.

A failed-state task ran and errored; the next step is to open its logs to find the cause. It doesn't mean scheduled (B), succeeded (C), or undefined (D) — those are different states/situations.

The Airflow UI is the main observability tool: Graph for structure, Grid/Calendar for history, per-task states, and logs — plus actions to trigger and clear tasks. It's not limited to starting the scheduler (C), it does show logs (A), and it is interactive, not read-only (B).

airflow dags trigger <dag_id> starts a manual DAG run. dags delete (D) removes DAG records, tasks clear (C) clears task state, and db reset (A) wipes the metadata database — none simply triggers a run.