Testing & observability (apps)

4 h
requires KFK-05

From your world. dbt test + CI gates, and the lag/freshness monitors you already run on a warehouse

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz KFK-10.

1How is the lag of a consumer group for a partition defined? AThe number of consumers currently in the group. Bend_offset (log end offset / high watermark) minus the committed offset of the group for that partition. CThe time since the last message was produced. DThe in-memory position of the consumer minus the first offset in the log.

2Why compute lag from the COMMITTED offset and not from the current in-memory position of the consumer? AThe in-memory position is always zero. BThe committed offset is where a restarted or rebalanced member resumes, so it shows the durable progress of the group. CThe committed offset is faster to read. DThere is no difference. They are always equal.

3A nightly batch producer feeds a topic. Every night lag spikes to 50,000 and then drains to 0 within an hour. What is the best alerting rule? APage whenever lag > 1,000. BPage when lag is high AND not decreasing over several intervals (stuck). Do not page on the instantaneous spike. CNever alert on lag for this topic. DPage on every produced record.

5Which of these should live in the FAST unit layer (plain data, no broker) and not in an integration test? (Select all that apply.) (select all that apply) AA function that computes lag from committed and end offsets. BAn alert rule that maps lag to ok/warn/page. CVerifying that the app actually commits offsets to a real broker after processing. DA record transform / serializer.

6You want to read the committed offsets of a consumer group and the end offsets of the partitions WITHOUT joining the group. Which admin APIs do that? Alist_consumer_group_offsets for committed offsets, and list_offsets (latest spec) for end offsets. Bsubscribe() and poll() in a loop. Cdescribe_topics only. DThere is no way without joining the group.

7A consumer group shows a high rebalance rate and growing lag. Which configuration is the most likely cause? Acompression.type is set to zstd. BProcessing a batch takes longer than max.poll.interval.ms, so the member is evicted and the group rebalances repeatedly. Cacks=all on the producer. DThe topic has too few partitions.

8Why make the alert RULE itself a pure, tested function and not only wire it into a dashboard? ADashboards cannot display numbers. BSo you can prove with unit tests that it fires exactly when it should and stays quiet otherwise. This is the same practice as the warn/error severity of a dbt test. CPure functions use less memory on the broker. DIt lets the broker evaluate the rule.