41. Worst-case response time of the lowest task
Fixed-priority preemptive tasks (C, T) in priority order: T1 = (1, 4), T2 = (2, 6), T3 = (3, 12), deadlines equal to periods. Using response time analysis R = C3 + Σ ceil(R/Ti) × Ci, what is the worst-case response time of T3?
- A.10
- B.6
- C.12
- D.7
Show answer
Answer: A. 10
Start with R = 3 + 1 + 2 = 6. Then R = 3 + ceil(6/4)×1 + ceil(6/6)×2 = 7, then 3 + 2 + 4 = 9, then 3 + 3 + 4 = 10, and 3 + ceil(10/4) + 2×ceil(10/6) = 10 again, so it converges at 10. Since 10 ≤ 12, T3 meets its deadline.
42. Above the RM bound but still schedulable
A task set has utilisation 0.83, above the 3-task rate monotonic bound of about 0.78. What can you conclude?
- A.The task set is sure to miss deadlines under rate monotonic
- B.The task set is schedulable, because 0.83 is below 1.0
- C.Nothing yet; the bound is only sufficient, so run an exact test
- D.The design must move to round-robin scheduling instead
Show answer
Answer: C. Nothing yet; the bound is only sufficient, so run an exact test
The Liu and Layland bound is sufficient but not necessary: sets under it always pass, sets above it may still pass. Response time analysis gives an exact answer for fixed priorities. Harmonic periods, for example, can be schedulable up to 100%.
43. Network throughput collapses
With FreeRTOS+TCP, the IP task is priority 2, the Ethernet driver task priority 4, and the app task that reads sockets priority 3. Throughput is poor. What ordering is usually recommended?
- A.Driver task highest, then the IP task, then app tasks
- B.App task highest, then the driver, then the IP task
- C.All three tasks at the same priority, time sliced
- D.The IP task at the idle priority, the rest above it
Show answer
Answer: A. Driver task highest, then the IP task, then app tasks
The driver must move frames in and out quickly, and the IP task must process them before app tasks consume data. If an app task outranks the IP task, it can starve the stack it is waiting on. FreeRTOS+TCP docs recommend this order.
44. Jitter of tick-driven periodic tasks
Periodic tasks are released by the 1 kHz tick, and a higher-priority task sometimes runs 300 µs at the same tick. What is the start jitter of a lower task released on that tick?
- A.Exactly 0 µs, because the tick is exact
- B.Up to 1 ms every time
- C.About 300 ms
- D.Up to about 300 µs, plus any ISR and switch time
Show answer
Answer: D. Up to about 300 µs, plus any ISR and switch time
All tasks released on a tick become ready together, and the highest runs first. The lower task can start up to the higher task run time later, about 300 µs, plus kernel and ISR overhead. If that matters, trigger the critical task from its own hardware timer.
45. Deadline shorter than period
Task A has period 100 ms but deadline 5 ms after release. Task B has period 20 ms and deadline 20 ms. Which priority order fits deadline monotonic scheduling?
- A.B above A, because B has the shorter period
- B.A above B, because A has the shorter deadline
- C.Equal priorities with time slicing
- D.Whichever has the longer run time first
Show answer
Answer: B. A above B, because A has the shorter deadline
When deadlines are shorter than periods, deadline monotonic ordering, by relative deadline, is optimal among fixed priorities. A must finish within 5 ms, so it ranks above B even though it runs less often. Rate monotonic would rank them the wrong way.
46. Cooperative Zephyr thread hogs the CPU
A Zephyr thread at priority -2 runs a 50 ms checksum loop. Higher-numbered preemptible threads, including the BLE host thread, miss timing. What helps most?
- A.Make it preemptible, or k_yield inside the loop
- B.Give the BLE host thread a priority of 20
- C.Turn on CONFIG_TIMESLICING for all threads
- D.Raise the system tick rate to 10 kHz
Show answer
Answer: A. Make it preemptible, or k_yield inside the loop
A cooperative thread is never preempted by other threads, so a long loop holds the CPU for its full length. Time slicing does not apply to it. Make it preemptible with a low priority, or break the loop up with yields if it must stay cooperative.
47. Critical Pod cannot schedule on a full cluster
The cluster is full. A new payments Pod with a high PriorityClass is created and other Pods without a priority class are running. What will the scheduler try?
- A.Wait until the autoscaler adds a node, never evicting
- B.Evict lower-priority Pods on a node so payments can fit
- C.Place payments over the node capacity for a short time
- D.Reject payments because the ResourceQuota is full
Show answer
Answer: B. Evict lower-priority Pods on a node so payments can fit
If a pending Pod cannot fit, the scheduler looks for a node where removing lower-priority Pods would make room, and preempts them gracefully. Pods without a PriorityClass get the default priority, usually 0. Use this carefully, and protect important lower-priority work with PDBs.
48. Filtering by now() in a task
A daily Airflow task loads "yesterday’s" rows using datetime.now() − 1 day. Why is this a problem for reruns and backfills?
- A.datetime.now() is not allowed inside Airflow tasks
- B.It makes the task run twice each day
- C.Reruns load the wrong day; use the run’s data interval
- D.Airflow converts now() to the DAG start date
Show answer
Answer: C. Reruns load the wrong day; use the run’s data interval
A rerun of last Monday’s run would load the day before today, not the day before Monday. Using the run’s data_interval_start and data_interval_end (or logical date) ties each run to a fixed period, so reruns and backfills are deterministic.
49. Cron with both day fields set
A DAG uses schedule "0 9 1 * 1", meant as "9 AM on the 1st if it is a Monday". When does it actually run?
- A.Only when the 1st of a month is a Monday
- B.On the 1st of every month and on every Monday
- C.Only on Mondays
- D.Only on the 1st of each month
Show answer
Answer: B. On the 1st of every month and on every Monday
In standard cron, when both day-of-month and day-of-week are restricted, a day matches if either one matches. So this runs on every Monday and also on every 1st. For "1st and Monday" you need a custom timetable or a check inside the DAG.
50. Tasks waiting while workers sit idle
Celery workers are mostly idle, yet several tasks of DAG finance_close stay in the scheduled state for an hour. They all use pool="warehouse", which has 3 slots. What should you check first?
- A.Whether the broker has run out of disk
- B.Whether other tasks hold all 3 warehouse slots
- C.Whether the DAG file has a syntax error
- D.Whether the tasks have retries set to 0
Show answer
Answer: B. Whether other tasks hold all 3 warehouse slots
A task leaves the scheduled state only when the scheduler can give it a pool slot and other limits allow it. If long tasks from other DAGs hold all 3 warehouse slots, these tasks wait however idle the workers are. Check the Pools page for running and queued slots, and consider priority_weight for urgent work.
51. Doubled rows after a retry
A task runs INSERT INTO sales SELECT ... for the day, then fails while refreshing a summary. The retry succeeds, and that day's sales now appear twice. What is the right fix?
INSERT INTO sales SELECT * FROM staging WHERE dt = '{{ ds }}';
REFRESH MATERIALIZED VIEW sales_summary; -- failed here- A.Set retries=0 so the task never runs twice
- B.Delete the day's rows, then insert, in one transaction
- C.Use a pool with only one slot for the task
- D.Run the summary refresh before the insert step
Show answer
Answer: B. Delete the day's rows, then insert, in one transaction
Airflow reruns the whole task on retry, so every task must be safe to run twice. Deleting the rows for dt = ds and inserting them again (or MERGE / partition overwrite) makes the step idempotent. Removing retries only hides the problem until someone clears the task.
52. Effective priority of a root task
All tasks have priority_weight=1 and the default weight_rule="downstream". What is the effective priority of a?
a >> [b, c]
b >> d
- A.1
- B.2
- C.3
- D.4
Show answer
Answer: D. 4
With the downstream rule, a task's effective weight is its own weight plus the weights of all its downstream tasks. a has b, c and d below it, so 1 + 1 + 1 + 1 = 4. This makes the scheduler favour tasks that unblock the most work.
53. Mapping over 2,000 items
list_ids returns 2,000 ids and score.expand(id=list_ids()) follows. With default settings, what happens?
- A.The run fails because 2,000 exceeds max_map_length (1024)
- B.2,000 mapped instances run normally
- C.Only the first 1024 ids are processed
- D.The instances are created in batches of 1024 silently
Show answer
Answer: A. The run fails because 2,000 exceeds max_map_length (1024)
[core] max_map_length defaults to 1024, and a mapping input longer than that raises an error instead of being cut. Raise the setting if you really need it, or better, map over batches of ids so you have fewer, larger task instances.
54. Consumer DAG ran with no new data
A producer task declares outlets=[Asset("s3://dw/orders")]. Today it found no new orders, wrote nothing, and succeeded. The consumer DAG still ran. Why?
- A.Asset events fire on a fixed timer every day
- B.The consumer runs whenever any producer task fails
- C.An event is logged on task success, not on data change
- D.The consumer reads S3 modification times itself
Show answer
Answer: C. An event is logged on task success, not on data change
Airflow does not inspect the data. When a task with an outlet succeeds, Airflow records an asset event, and consumer DAGs scheduled on that asset are triggered. If no new data should mean no event, skip the task or emit events only when something was written.
55. Run when either feed updates
A DAG should run whenever either the UAE feed or the India feed asset is updated, not wait for both. How is the schedule written?
- A.schedule=[uae_feed, india_feed]
- B.schedule=(uae_feed | india_feed)
- C.schedule=(uae_feed & india_feed)
- D.schedule="uae_feed or india_feed"
Show answer
Answer: B. schedule=(uae_feed | india_feed)
A plain list of assets means all must update. Asset expressions use | for "any of" and & for "all of", so (uae_feed | india_feed) triggers on either. A string is read as a cron or preset, not as assets.
56. Summing results of mapped tasks
count_rows is mapped over 12 files and returns an int each. A normal downstream task total(counts) receives count_rows's output. What is counts?
counts = count_rows.expand(path=files)
total(counts)
- A.Only the value from the last mapped instance
- B.A sequence of the 12 returned ints
- C.The sum of the 12 ints, added by Airflow
- D.None, because mapped tasks cannot return values
Show answer
Answer: B. A sequence of the 12 returned ints
A non-mapped task that consumes a mapped task's output gets a lazy sequence of all the mapped return values, in map index order. total can then call sum(counts). This is the standard map-reduce pattern in Airflow.
57. Large XComs without filling the database
Teams keep returning medium-sized results (5–50 MB) from tasks and the metadata database is suffering. Which setup keeps the TaskFlow style but moves large values out of the database?
- A.Raise the database disk size each month
- B.Ban all return values in code review
- C.Store results in Airflow Variables instead
- D.An object storage XCom backend with a size threshold
Show answer
Answer: D. An object storage XCom backend with a size threshold
A custom XCom backend, such as the object storage backend in the common.io provider, writes values above a threshold to S3 or GCS and keeps only a reference in the database. Small values stay in the database, and task code does not change.
58. Two runs overwriting one temp file
With max_active_runs=4 during a backfill, a task writes /tmp/extract.csv on a shared volume and the next task loads it. Some days load another day's data. What is the fix?
- A.Set retries=3 on the load task
- B.Use a pool with 4 slots
- C.Raise execution_timeout on both tasks
- D.Include the run id or ds in the file path
Show answer
Answer: D. Include the run id or ds in the file path
Parallel runs share the same fixed path, so one run overwrites the file another run is about to load. Making paths unique per run, for example /tmp/extract_{{ ds_nodash }}.csv or a run_id folder, keeps runs isolated and safe to rerun.
59. ds moved by a day after a timetable change
A daily midnight DAG moves from CronDataIntervalTimetable to CronTriggerTimetable. For the run that starts at 00:00 on 11 March 2026, what is {{ ds }} now?
- A.2026-03-11
- B.2026-03-10, same as before
- C.2026-03-12
- D.Empty, because ds is not set
Show answer
Answer: A. 2026-03-11
CronDataIntervalTimetable runs at the end of the interval, so the midnight run on 11 March has logical date 10 March. CronTriggerTimetable has no interval and its logical date is the trigger time itself, 11 March. Queries filtered on ds shift by a day unless you adjust them.
60. Finishing old runs before new ones
During a 30-day backfill, Airflow starts the first task of many runs before finishing any run, so complete days appear slowly. Which weight_rule makes later tasks of started runs go first?
- A.weight_rule="downstream"
- B.weight_rule="absolute" with weight 0
- C.weight_rule="upstream"
- D.weight_rule="random"
Show answer
Answer: C. weight_rule="upstream"
With the default downstream rule, early tasks get the highest weight, so the scheduler prefers starting new runs. With upstream, a task's weight includes all tasks above it, so tasks deep in a DAG win and in-flight runs finish sooner. There is no random rule.
