Configuration best practices in Kafka - Cheat Sheet & Quick Revision

Recall & Review

beginner

Why should you avoid hardcoding configuration values in Kafka applications?

Hardcoding configuration values makes it difficult to change settings without modifying code. It reduces flexibility and can cause errors when deploying in different environments.

beginner

What is the benefit of using external configuration files in Kafka setups?

External configuration files allow you to change settings without changing code. They help manage different environments like development, testing, and production easily.

intermediate

How does setting appropriate retention policies improve Kafka performance?

Retention policies control how long data stays in Kafka topics. Setting them properly prevents disk space issues and ensures important data is available as needed.

intermediate

Why is it important to secure sensitive configuration data like passwords in Kafka?

Sensitive data should be protected to prevent unauthorized access. Using tools like environment variables or secret managers keeps credentials safe and reduces security risks.

advanced

What role does monitoring configuration changes play in Kafka operations?

Monitoring configuration changes helps detect unintended or harmful updates quickly. It supports stability and helps troubleshoot issues faster.

Which method is best for managing Kafka configuration across multiple environments?

A Using external configuration files or environment variables

B Hardcoding values in the application code

C Changing Kafka source code

D Manually editing Kafka broker files each time

Using external configuration files or environment variables allows easy changes without code edits and supports multiple environments.

What does the retention policy in Kafka control?

A How long messages are stored in a topic

B The number of partitions in a topic

C How many consumers can read a topic

D The security level of the topic

Retention policy defines how long Kafka keeps messages before deleting them.

Why should sensitive Kafka configuration data be stored securely?

A To improve message throughput

B To prevent unauthorized access and data leaks

C To reduce disk usage

D To speed up consumer processing

Securing sensitive data like passwords prevents unauthorized access and protects the system.

What is a good practice when updating Kafka configuration in production?

A Ignore configuration backups

B Update directly without testing

C Restart Kafka without saving changes

D Test changes in a staging environment first

Testing configuration changes in staging helps avoid production issues.

How can monitoring configuration changes help Kafka operations?

A By automatically fixing bugs

B By reducing network latency

C By detecting unintended changes quickly

D By increasing message size

Monitoring helps spot unwanted changes early, improving stability.

Explain why using environment variables or external files is preferred over hardcoding Kafka configurations.

Think about how you would change settings when moving from development to production.

Describe how retention policies affect Kafka storage and performance.

Consider what happens if messages never get deleted.

Practice

1. Which of the following is a key benefit of following Kafka configuration best practices?

easy

A. Allows Kafka to run without any network connection

B. Automatic code generation for Kafka producers

C. Eliminates the need for monitoring Kafka brokers

D. Improved speed, safety, and reliability of Kafka clusters

Solution

1. Step 1: Understand Kafka configuration goals

   Kafka configs are designed to improve performance, safety, and reliability.

2. Step 2: Evaluate each option

   Only Improved speed, safety, and reliability of Kafka clusters correctly states the benefits of good Kafka configs.

3. Final Answer:

   Improved speed, safety, and reliability of Kafka clusters -> Option D

4. Quick Check:

   Kafka config benefits = Improved speed, safety, reliability [OK]

Hint: Remember: good configs make Kafka faster and safer [OK]

Common Mistakes:

• Thinking configs generate code automatically
• Assuming configs remove need for monitoring
• Believing Kafka works offline without network

2. Which of the following is the correct syntax to set a Kafka configuration property in a properties file?

easy

A. bootstrap.servers = localhost:9092

B. bootstrap.servers: localhost:9092

C. bootstrap.servers -> localhost:9092

D. bootstrap.servers localhost:9092

Solution

1. Step 1: Recall Kafka config file syntax

   Kafka uses key=value pairs in properties files.

2. Step 2: Match syntax to options

   Only bootstrap.servers = localhost:9092 uses the correct key=value format.

3. Final Answer:

   bootstrap.servers = localhost:9092 -> Option A

4. Quick Check:

   Kafka config syntax = key=value [OK]

Hint: Kafka configs use key=value pairs, not colons or arrows [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using arrow symbols
• Omitting the equals sign

3. Given the following Kafka producer configuration snippet, what will be the value of acks used by the producer?

acks=all
retries=3
linger.ms=5

medium

A. "all" meaning the leader waits for all replicas to acknowledge

B. "0" meaning no acknowledgments are required

C. "1" meaning only the leader acknowledges

D. An error because "all" is not a valid value

Solution

1. Step 1: Understand the meaning of acks=all

   In Kafka, acks=all means leader waits for all replicas to confirm the message.

2. Step 2: Check options against this meaning

   "all" meaning the leader waits for all replicas to acknowledge correctly describes acks=all behavior.

3. Final Answer:

   "all" meaning the leader waits for all replicas to acknowledge -> Option A

4. Quick Check:

   acks=all means wait for all replicas [OK]

Hint: Remember: acks=all waits for all replicas to confirm [OK]

Common Mistakes:

• Confusing acks=all with acks=0 or acks=1
• Thinking 'all' is invalid
• Assuming no acknowledgments are needed

4. You have set log.retention.hours=168 in your Kafka broker config, but logs are not retained for 7 days as expected. What is a likely cause?

medium

A. The log.retention.hours value must be set in minutes

B. The log.retention.bytes setting is limiting retention by size

C. Kafka does not support retention configuration

D. The broker needs to be restarted for changes to take effect

Solution

1. Step 1: Understand retention config interaction

   Kafka retention can be limited by time or size; size limit can override time.

2. Step 2: Analyze options

   The log.retention.bytes setting is limiting retention by size correctly identifies size limit as a possible cause.

3. Final Answer:

   The log.retention.bytes setting is limiting retention by size -> Option B

4. Quick Check:

   Retention limited by size overrides time [OK]

Hint: Check size limits when time-based retention seems ignored [OK]

Common Mistakes:

• Assuming retention.hours must be in minutes
• Believing Kafka ignores retention settings
• Forgetting to restart broker (not always needed)

5. You want to safely update Kafka broker configurations without downtime. Which approach follows best practices?

hard

A. Update configs on all brokers simultaneously and restart all at once

B. Stop the entire Kafka cluster, update configs, then restart all brokers

C. Update configs on one broker at a time, restart it, then move to next

D. Change configs dynamically without any restarts or backups

Solution

1. Step 1: Understand safe config update practices

   Updating one broker at a time avoids cluster downtime and data loss.

2. Step 2: Evaluate options for safety and availability

   Update configs on one broker at a time, restart it, then move to next follows the best practice of rolling updates with restarts.

3. Final Answer:

   Update configs on one broker at a time, restart it, then move to next -> Option C

4. Quick Check:

   Rolling updates = safer config changes [OK]

Hint: Update brokers one by one to avoid downtime [OK]

Common Mistakes:

• Restarting all brokers simultaneously causing downtime
• Stopping entire cluster unnecessarily
• Changing configs without backups or restarts