Free Confluent CCDAK practice test

At-least-once delivery commits offsets after processing; if a failure happens before the commit, the message is reprocessed on restart (possible duplicates). At-most-once (B) commits before processing (possible loss), exactly-once (A) avoids both with additional guarantees, and 'no-delivery' (C) isn't a semantic.

A rebalance redistributes partition assignments when group membership changes (a consumer joins, leaves, or fails) or the set of subscribed partitions changes. Producer acks (B), schema registration (C), and retention changes (D) don't trigger consumer-group rebalances.

A topic is a named logical event stream divided into partitions that are distributed (and replicated) across brokers for scalability and fault tolerance. A topic can have many partitions (not exactly one, B), partitions live on brokers not consumers (C), and topics are replicated per the replication factor (D).

Kafka's default partitioner hashes the key so all messages with the same key land in the same partition, and order is guaranteed within a partition. Different partitions (D) would break ordering, Kafka doesn't auto-deduplicate by key (B), and exactly-once (A) requires specific configuration.

The Schema Registry manages schemas for serialized messages and enforces compatibility rules as schemas evolve, so producers and consumers agree on data structure. Offsets (C) are stored in Kafka, it doesn't replace brokers (B), and it isn't a credential store (A).

The ISR is the set of replicas (including the leader) that are caught up with the leader within the allowed lag; acks=all waits for these. It's not consumer-side (A), a nightly backup (C), or failed replicas (B).

Each partition is assigned to exactly one consumer in the group, so with 3 partitions and 4 consumers, three consumers each get one partition and the fourth is idle (no partition to read). Partitions aren't shared (B, C), and the group starts fine (D).

acks=all means the leader waits for all in-sync replicas (ISR) to replicate the record before acknowledging, giving the strongest durability. acks=0 (B) waits for nothing, acks=1 (A) waits only for the leader, and option D is false — Kafka persists messages.

branch (split) divides a stream into multiple streams based on predicates — a stateless routing operation. aggregate (C) and reduce (D) are stateful, and windowedBy (A) applies windowing to an aggregation.

A running total per key requires a stateful aggregation (e.g., aggregate/reduce) backed by a state store that persists the accumulating value. Stateless map (B) and filter (C) don't accumulate state, and printing (D) doesn't compute totals.

flatMap maps each input record to zero, one, or many output records. filter (A) keeps or drops records (0 or 1), count (C) is a stateful aggregation, and peek (D) performs a side effect without changing the stream.

Kafka Streams backs each state store with a changelog topic in Kafka; if an instance fails, the state is restored by replaying the changelog on another instance. Local-disk-only (C) wouldn't survive instance loss, disabling state (B) loses data, and the Schema Registry (D) stores schemas, not state.

map transforms each record into exactly one output record (changing key and/or value) with no stored state — a stateless one-to-one operation. Aggregation (A) and joins (D) are stateful, and windowing (B) applies to aggregations.

Exactly-once processing uses Kafka transactions to atomically tie together consuming, state changes, and producing, so failures don't cause duplicate or lost effects. It doesn't stop rebalances (C), compress messages (B), or limit partitions (D).

Testing schema evolution means validating the new schema against the Schema Registry's configured compatibility mode (backward, forward, full) for that subject, so consumers won't break. Partition count (D), offsets (A), and disk size (B) are unrelated to schema compatibility.

Delivery semantics govern behavior under failures/retries (possible duplicates or loss), so tests should exercise those paths and confirm the app's handling (idempotency, deduplication, transactional processing). It doesn't change partitions (D), Regions (A), or Schema Registry config (C).

Verifying no-duplicates-on-retry behavior requires exercising the failure/retry path end-to-end (integration test) and asserting the output has no duplicates. Merely checking the config value (B) doesn't prove behavior, eyeballing logs (C) isn't a repeatable test, and skipping (D) leaves the guarantee unverified.

Distributed tracing follows a message/transaction across services and Kafka hops, exposing where latency accrues and where failures occur end-to-end. It doesn't store messages (B), replace metrics/logs (C) — the three are complementary — or alter replication (D).

Consumer lag is the gap between the log-end offset (latest produced) and the consumer's committed offset per partition — a key indicator of whether consumers are keeping up. It's not broker network latency (C), partition count (A), or producer batch size (B).

Automated, metric-based alerting on consumer lag notifies the team promptly when consumers fall behind a threshold. Manual daily checks (B) are slow and error-prone, changing retention (C) doesn't monitor lag, and disabling the group (D) stops processing.