Challenge - 5 Problems
Kafka Disaster Recovery Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
❓ Predict Output
intermediate2:00remaining
Kafka Consumer Group Offset Behavior After Broker Failure
Consider a Kafka consumer group consuming from a topic with 3 partitions. The consumer commits offsets automatically every 5 seconds. If one broker hosting a partition leader fails and the leader is moved to another broker, what will be the output of the following code snippet that prints the last committed offset for each partition after the failover?
Kafka
from kafka import KafkaConsumer consumer = KafkaConsumer( 'my_topic', group_id='my_group', bootstrap_servers=['broker1:9092', 'broker2:9092', 'broker3:9092'], enable_auto_commit=True, auto_commit_interval_ms=5000 ) # Simulate reading messages for _ in range(10): msg = next(consumer) print(f'Partition: {msg.partition}, Offset: {msg.offset}') # After broker failure and leader election committed = {partition: consumer.committed(partition) for partition in consumer.assignment()} print(committed)
Attempts:
2 left
💡 Hint
Think about how Kafka stores committed offsets in __consumer_offsets topic and how leader election affects offset availability.
✗ Incorrect
Kafka stores committed offsets in an internal topic replicated across brokers. When a broker fails and a new leader is elected, the committed offsets remain available and unchanged. Therefore, the consumer can retrieve the last committed offsets as before the failure.
🧠 Conceptual
intermediate1:30remaining
Understanding Kafka Replication Factor Impact on Disaster Recovery
In Kafka, what is the primary benefit of setting a replication factor greater than 1 for a topic in the context of disaster recovery?
Attempts:
2 left
💡 Hint
Think about how Kafka handles broker failures and data loss prevention.
✗ Incorrect
Replication factor controls how many copies of each partition exist on different brokers. Having multiple copies ensures that if one broker fails, another broker has the data, preventing data loss and enabling recovery.
🔧 Debug
advanced2:00remaining
Identify the Cause of Data Loss in Kafka After Broker Crash
A Kafka topic has replication factor 3 and min.insync.replicas set to 2. Producers use acks='all'. After a broker crash, some messages are missing from the topic. Which code snippet below best explains why data loss occurred?
Kafka
producer = KafkaProducer(
bootstrap_servers=['broker1:9092', 'broker2:9092', 'broker3:9092'],
acks='all',
retries=0
)
# Sending messages
producer.send('my_topic', b'message1')
producer.flush()Attempts:
2 left
💡 Hint
Consider how producer retries affect message delivery guarantees.
✗ Incorrect
With retries=0, if a broker is down during send, the producer does not retry sending the message, causing message loss even though acks='all' and min.insync.replicas=2 are set.
📝 Syntax
advanced1:30remaining
Identify the Syntax Error in Kafka Topic Configuration Code
Which of the following Kafka topic creation code snippets contains a syntax error that would prevent the topic from being created?
Attempts:
2 left
💡 Hint
Check the data types of the parameters passed to NewTopic.
✗ Incorrect
The replication_factor parameter must be an integer. Passing it as a string causes a type error and prevents topic creation.
🚀 Application
expert3:00remaining
Designing a Kafka Disaster Recovery Plan for Multi-Region Deployment
You are tasked with designing a disaster recovery plan for a Kafka deployment spanning two geographic regions. Which approach below best ensures minimal data loss and quick recovery if one region fails?
Attempts:
2 left
💡 Hint
Consider how Kafka supports cross-region replication and automated failover.
✗ Incorrect
MirrorMaker 2 is designed for replicating Kafka topics between clusters asynchronously, enabling disaster recovery with minimal data loss and automated failover.