Introduction

When people ask for the "current config" in Kafka, they usually mean one of two things: the explicit overrides stored for a broker or topic, or the effective value Kafka is actually using after defaults are combined with overrides. Those are related, but they are not the same, and that distinction matters when you are debugging retention, replication, or quota behavior.

What "Current Config" Means in Kafka

Kafka configuration comes from more than one place:

• static broker settings in broker configuration files
• dynamic broker configuration stored in Kafka metadata
• topic-level overrides
• client-side producer and consumer properties
• built-in defaults when nothing else overrides them

That means a single command may not show the whole story. A topic might show no custom retention value and still behave differently because it inherits a broker-level default.

Inspecting Topic and Broker Overrides from the CLI

The normal starting point is kafka-configs.sh. It is useful when you want to inspect topic-level or broker-level configuration that was explicitly set.

Describe a topic configuration:

1bin/kafka-configs.sh \
2  --bootstrap-server localhost:9092 \
3  --entity-type topics \
4  --entity-name orders \
5  --describe

Describe a broker configuration:

1bin/kafka-configs.sh \
2  --bootstrap-server localhost:9092 \
3  --entity-type brokers \
4  --entity-name 0 \
5  --describe

Those commands are especially useful for settings such as retention.ms, cleanup.policy, or throttling limits.

The important nuance is that this view is best understood as "what has been explicitly configured here" rather than "every value Kafka will use in every context." A topic may inherit a broker default even when the topic itself shows no override.

Reading Effective Values with the Admin Client

If you want a programmatic view, the Kafka Admin client is the cleaner approach. It lets you ask Kafka for configuration entries and inspect where each one came from.

1import java.util.List;
2import java.util.Map;
3import java.util.Properties;
4import org.apache.kafka.clients.admin.AdminClient;
5import org.apache.kafka.clients.admin.AdminClientConfig;
6import org.apache.kafka.clients.admin.Config;
7import org.apache.kafka.clients.admin.ConfigEntry;
8import org.apache.kafka.common.config.ConfigResource;
9
10public class DescribeTopicConfig {
11    public static void main(String[] args) throws Exception {
12        Properties props = new Properties();
13        props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
14
15        try (AdminClient admin = AdminClient.create(props)) {
16            ConfigResource topic = new ConfigResource(
17                ConfigResource.Type.TOPIC,
18                "orders"
19            );
20
21            Map<ConfigResource, Config> result =
22                admin.describeConfigs(List.of(topic)).all().get();
23
24            for (ConfigEntry entry : result.get(topic).entries()) {
25                System.out.printf(
26                    "%s = %s (source=%s)%n",
27                    entry.name(),
28                    entry.value(),
29                    entry.source()
30                );
31            }
32        }
33    }
34}

The source field is useful because it tells you whether a setting is a default, a topic override, or another source. That is often the missing piece when a value looks wrong in CLI output.

Client Config Is Separate

Producer and consumer configuration is not something Kafka brokers can fully reveal back to you. If a consumer uses max.poll.records=500 or a producer uses acks=all, those are client application settings. To inspect them, you usually need:

• the application properties file
• environment variables
• deployment manifests
• the code that builds the client properties

So if someone says "Kafka is configured this way," always ask whether they mean broker, topic, or client.

Common Pitfalls

• Assuming topic config output shows every effective value, including inherited defaults.
• Forgetting that producer and consumer settings live in the client, not in broker metadata.
• Debugging a retention issue at the topic level when the value is inherited from a broker default.
• Changing configuration without recording whether it was static, dynamic, or application-side.
• Treating "current config" as one thing when Kafka actually has several configuration scopes.

Summary

• Kafka configuration exists at broker, topic, and client levels.
• 'kafka-configs.sh is the fastest way to inspect explicit topic and broker settings.'
• The Admin client is better when you need to inspect configuration sources programmatically.
• Effective behavior may come from inherited defaults, not just explicit overrides.
• Always distinguish broker config from application-side producer and consumer properties.