Free CCDAK practice test: 30 questions with answers

Kafka Streams is a client library that runs inside the application and supports stateful aggregations through local state stores backed by changelog topics. Connect moves data between Kafka and external systems, the Admin API manages cluster resources, and a bare producer only publishes records with no aggregation support.

The Admin API handles management tasks such as creating topics, altering configurations, and inspecting consumer groups. The other descriptions belong to the Connect API, the Streams API, and the Producer API respectively.

Explicit creation lets the pipeline set partitions and replication factor deliberately, while auto-creation falls back to broker defaults. Consumers cannot choose a topic's partition count, and a producer's client configuration does not set the replication factor of a topic.

With cleanup.policy set to compact, Kafka keeps at least the latest record for every key in a partition and removes older values for that key. Time-based deletion is a different cleanup policy, while merging topics and deduplicating before sending are not behaviours of log compaction.

A KTable models a changelog in which the latest value per key is the current state, which suits profile enrichment. A KStream treats each record as an independent event, while changelog topics and producer buffers are storage and batching mechanisms rather than stream abstractions.

Source connectors import data into Kafka and sink connectors export it out, which is the core purpose of Connect. Workers can run on machines separate from the brokers, and single message transforms, not Streams topologies, modify records inside Connect.

Schema Registry stores schema versions and enforces compatibility rules whenever a new schema is registered. The other options manage state, topic retention, and consumer starting position, and none of them validates record schemas.

Kafka Connect source connectors read from external systems such as relational databases and write the rows into topics without custom code. A custom producer loop needs code the team wants to avoid, a Streams application expects its input to already be in Kafka, and a consumer group reads from Kafka rather than polling a database.

acks=all waits for the in-sync replicas to hold the record, and min.insync.replicas above one ensures more than one copy exists before the write is acknowledged. acks=0 waits for no broker, acks=1 waits only for the leader, and disabling retries does not add durability.

auto.offset.reset decides whether a consumer starts from the earliest available offset, the latest offset, or raises an error when no committed position exists. The other settings control offset commits, fetch batching, and how many records each poll returns.

Committing after the database write means a crash before the commit causes the record to be read again, so duplicates are possible but nothing is skipped. Committing before processing or sending commits without waiting can skip records, and auto-commit alone does not give exactly-once results against an external database.

linger.ms makes the producer wait a short time for more records so they can be grouped into one batch request. The other settings belong to consumers, governing group heartbeats, membership timeouts, and fetch sizes.

max.poll.interval.ms is the maximum time allowed between poll calls before the consumer is considered failed and leaves the group. The producer settings listed affect durability, batching, and compression, so they do not change group membership.

Idempotence lets the broker discard duplicate batches that a producer resends after a retry, and within the supported in-flight limit it preserves order within a partition. Atomic multi-topic writes require transactions, and read_committed is a consumer setting that idempotent producers do not depend on.

With read_committed, the consumer returns only committed transactional records and skips records from aborted transactions. The other settings configure producer delivery guarantees or starting offsets, and none of them filters aborted transactional data.

The cooperative sticky assignor performs incremental rebalancing, so consumers keep the partitions that do not move and only reassigned partitions pause. Producer acknowledgement and batch settings, and consumer fetch sizes, do not change how a group reassigns partitions.

Each stream task processes one partition of the input topic, so the partition count caps useful parallelism. Broker count, Schema Registry instances, and producer batch size do not set the number of tasks for an input topic.

Distributed mode lets workers that share a group.id form one cluster that balances connectors and tasks and reassigns them when a worker leaves. Standalone mode runs a single process with no failover, and pinning connectors to hosts prevents automatic reassignment.

When error tolerance is enabled, records that fail conversion or transformation can be sent to a dead letter queue topic instead of stopping the task. Offset storage, cross-cluster replication, and schema caching are handled by other mechanisms and are not the purpose of this topic.

Standby replicas keep up-to-date copies of state on other instances, and changelog topics let a store be restored from Kafka instead of starting empty. Disabling changelogs makes state unrecoverable, and a new application.id discards the link to existing state and forces reprocessing.

The application reset tool resets input topic offsets and cleans up the application's internal topics so it can reprocess its data. The other tools manage topic definitions, replica placement, and configuration values, and none of them handles Streams offsets and internal topics together.

Source connectors save how far they have read in the external system, so after a restart or rebalance they can continue without re-importing everything. Task limits, key conversion, and schema versions are controlled by other settings and components.

Under BACKWARD compatibility, a reader using the new schema must still read data written with the old schema, which works when the added field has a default. A missing value with no default cannot be filled in, and renamed or retyped fields no longer match the old data.

The consumer groups tool's describe option reports the committed offset, log end offset, and lag per partition for a group. The other tools create topics, change configuration values, and manage access rules, so none of them reports consumer progress.

An under-replicated partition has fewer in-sync replicas than assigned replicas, meaning some copies are behind. An offline partition has no leader at all, while compaction describes a cleanup policy and idle describes low traffic, so neither matches the alert.

Partition reassignment changes the replica list of each partition while the topic stays online. Deleting the topic loses its data, retries only affect delivery attempts, and adding partitions does not give existing partitions more replicas.

Keyed records are assigned by hashing the key modulo the partition count, so a new count can send a key to a different partition and split its history. The other statements are wrong: partitions can be added to a topic with data, consumers do not need a new group, and new partitions use the topic's replication factor.

Offsets can only be reset for a consumer group with no active members, so consumers must be stopped first. Compaction, broker restarts, and pausing producers have no bearing on whether a group's committed offsets can be changed.

With unclean leader election disabled, a lagging replica is never promoted, so the partition waits for an in-sync replica and committed records are not lost. Allowing an out-of-sync replica to lead keeps the partition available but risks data loss, and the other options describe behaviour Kafka does not perform.

Shorter retention removes old log segments under the delete policy, and compaction keeps only the latest value per key. Adding partitions spreads data across more logs without shrinking it, and consumer poll settings have no effect on what brokers store.