Sample questions
St Streaming Joins TablesDifficulty 1
In Apache Kafka Streams 4.1, what does a KStream represent?
- aA bounded, offline dataset loaded once at application startup
- bA changelog where each new record for a key overwrites the previous value for that key
- cA fully replicated snapshot of a topic held by every application instance
- dAn unbounded sequence of independent records, each treated as a new event✓
Explanation:KStream models the topic as a record stream: every incoming record is a distinct, independent event, regardless of its key — there's no concept of one record replacing another for the same key. That's the KTable/GlobalKTable interpretation, not KStream's.
St Streaming Joins TablesDifficulty 1
In Apache Kafka Streams 4.1, what does a KTable represent?
- aAn unbounded sequence of independent records, each treated as a new event
- bA read-only, in-memory cache populated once at startup and not touched again
- cA changelog where a new record updates the key's value, and null deletes it✓
- dA fully replicated copy of a topic that every application instance materializes locally
Explanation:KTable interprets the underlying topic as a changelog: each record is an upsert for its key (last value wins), and a record with a null value acts as a tombstone that removes the key. Option d describes GlobalKTable, not KTable.
St Streaming Joins TablesDifficulty 2
In Apache Kafka Streams 4.1, what distinguishes a GlobalKTable from a regular KTable?
- aEvery instance materializes the entire topic, not just its assigned partitions✓
- bA GlobalKTable can only be joined with another GlobalKTable, not with a KStream
- cA GlobalKTable stops receiving updates after the application starts
- dA GlobalKTable stores its data purely in memory without persisting a changelog
Explanation:A regular KTable's state is partitioned like the rest of the topology — each instance only holds the partitions assigned to it. A GlobalKTable's topic is fully consumed by every instance, so each one holds a complete local copy of the table.
St Streaming Joins TablesDifficulty 1
In Apache Kafka Streams 4.1, what is the primary purpose of a state store's changelog topic?
- aTo let downstream consumer applications read the store's current state directly
- bTo durably back the local state store for restore after a crash or migration✓
- cTo record which consumer group offsets have been committed for the store
- dTo log every interactive query issued against the store for auditing
Explanation:Every change applied to a persistent state store is also written to its changelog topic. If a task moves to a new instance or restarts after a failure, Kafka Streams replays that changelog to rebuild the store's contents before processing resumes.
St Streaming Joins TablesDifficulty 2
In Apache Kafka Streams 4.1, what cleanup policy is configured on a non-windowed state store's changelog topic?
- a
cleanup.policy=delete, so old records expire after a retention period - b
cleanup.policy=compact,delete combined with a fixed 24-hour retention - cNo cleanup policy; the topic grows without bound
- d
cleanup.policy=compact, so only the latest record per key is retained✓
Explanation:A non-windowed store's changelog mirrors the store's key-value contents, so Kafka Streams sets it to log compaction — Kafka retains only the latest record per key, which is exactly what's needed to restore the store's current state.
St Streaming Joins TablesDifficulty 2
In Apache Kafka Streams 4.1, why is a repartition topic sometimes created before a join or aggregation?
- aTo reduce the number of partitions when the source topic has too many
- bTo create a backup copy of the source topic for disaster recovery
- cTo move re-keyed records onto their correct partition✓
- dTo convert a KTable back into a KStream before writing to a sink
Explanation:Joins and aggregations require records to be co-partitioned by key. If an upstream operation changes the key, Kafka Streams inserts an internal repartition topic so the data gets reshuffled onto the partition that matches the new key.