skip to content

How do you inspect the effective configuration of a topic or broker, and what is the difference between --describe and --describe --all?

level: middleimportance: should knowfreq 45%

answer

  1. --describe = only explicit overrides
  2. --describe --all = full effective + source
  3. ConfigSource / isDefault / isSensitive / isReadOnly
  4. kafka-topics --describe for layout + overrides
  5. AdminClient.describeConfigs for tooling

basics

~10 s

Use kafka-configs --describe with --entity-type and --entity-name. By default it shows only explicitly-set overrides. Adding --all also lists inherited defaults and each value's source, giving the full effective config.

solid answer

~40 s

kafka-configs.sh --describe lists the configs of an entity. Without --all it shows only the configs explicitly set on that entity — the dynamic overrides — which is concise but hides everything inherited. With --all it returns every config including built-in and inherited defaults, plus each value's ConfigSource and whether it is read-only/sensitive, so you see the true effective value and where it came from. For topics you can also use kafka-topics.sh --describe to view configs alongside partition/replica layout. For programmatic access, AdminClient.describeConfigs returns ConfigEntry objects with source, isDefault, isSensitive, and isReadOnly flags. The practical rule: --describe answers "what did someone override?", --describe --all answers "what value is actually in effect and why?".

go deeper

for a junior

Know --describe shows a topic/broker's overrides and --all adds inherited defaults.

for a middle

Explain the override-vs-effective distinction and read the ConfigSource to find origin.

for a senior

Use sources to debug per-broker divergence and choose CLI vs AdminClient appropriately.

for a principal

Build config-observability/drift tooling on AdminClient.describeConfigs across the fleet.

## Goal: know the value actually in effect An entity's **effective config** is the value Kafka will actually use after applying the precedence hierarchy. Inspecting it is essential when debugging retention, replication, or security behavior. ## --describe (default) ``` kafka-configs.sh --bootstrap-server b:9092 \ --entity-type topics --entity-name orders --describe ``` This prints only the configs **explicitly set** on `orders` — i.e. its dynamic overrides. If the topic has no overrides, output is essentially empty even though the topic obviously has retention, cleanup policy, etc. (those are inherited and not shown). ## --describe --all ``` kafka-configs.sh ... --entity-type topics --entity-name orders --describe --all ``` Now you get **every** config: the overrides, plus inherited broker defaults, plus built-in defaults. Each line includes: - the **value**, - the **ConfigSource** (e.g. `DYNAMIC_TOPIC_CONFIG`, `DEFAULT_CONFIG`, `STATIC_BROKER_CONFIG`), - flags like `sensitive=true` (value redacted) and `read-only`. This is how you answer "the topic is expiring data too fast — what is retention.ms and where is it coming from?". ## Brokers Same flags with `--entity-type brokers --entity-name <id>` (or `--entity-default` for the cluster default view). `--all` shows the full broker effective config with sources, which is invaluable when values differ across brokers. ## kafka-topics.sh alternative ``` kafka-topics.sh --bootstrap-server b:9092 --describe --topic orders ``` Shows partitions, replicas, ISR, leaders **and** the topic's config overrides — handy for a quick combined view, though it shows overrides, not the full inherited set. ## Programmatic: AdminClient `AdminClient.describeConfigs(Collection<ConfigResource>)` returns `Config` → `ConfigEntry` objects exposing `name`, `value`, `source()` (a `ConfigSource` enum), `isDefault()`, `isSensitive()`, `isReadOnly()`. This is what you build tooling and drift-detection on. ## Edge cases - Sensitive values are redacted in both CLI and AdminClient output (`isSensitive()==true`, value null). - Without `--all`, an empty result does **not** mean misconfiguration — it means no explicit overrides. - Effective values can differ per broker; always describe the specific broker id when investigating divergence.

  • A topic --describe shows nothing. Does that mean the topic has no retention configured?
    No. --describe only shows explicit overrides; the topic still inherits broker/built-in defaults. Use --describe --all to see the effective retention and its source.
  • How would you build automated config-drift detection?
    Use AdminClient.describeConfigs to read ConfigEntry objects (value + source + flags) per entity and compare against a desired baseline, alerting on differences.

saying these in an interview costs you the question

  • Assuming an empty --describe output means the config is unset/broken — it just means no overrides.
  • Believing --describe shows the full effective config — it only shows overrides without --all.
  • Expecting sensitive values to appear in describe output.

context

resolving links…