View Full Confluent CCDAK Exam Dumps and Practice Test Dumps

 

Question 41

Which Kafka setting controls the default number of partitions for new topics?

1. log.retention.bytes
2. num.network.threads
3. default.replication.factor
4. num.partitions

Correct Answer: 4

Explanation:

The num.partitions broker setting defines the default partition count for topics created without an explicitly specified number of partitions. Partition count is an important architectural decision because it affects producer distribution, consumer parallelism, storage layout, and future scalability. It should not be confused with default.replication.factor, which controls the default number of replicas. Existing topics are not automatically redesigned simply because this broker default changes. CCDAK architects should establish suitable topic-creation practices and avoid relying blindly on defaults when workloads have specific throughput, ordering, or consumer-concurrency requirements.

Question 42

Which setting defines the default replication factor for automatically created topics?

1. num.partitions
2. default.replication.factor
3. message.max.bytes
4. log.segment.bytes

Correct Answer: 2

Explanation:

default.replication.factor specifies the default replication factor applied when topics are created without an explicitly defined replication factor. A higher replication factor provides more copies of partition data and can improve fault tolerance, but it also increases storage and network requirements. This setting is separate from num.partitions, which determines the default number of partitions. CCDAK architects should establish explicit topic-management practices because default values may not satisfy the durability requirements of every workload. Replication factor should be considered together with acknowledgment settings, minimum ISR requirements, infrastructure topology, and recovery expectations.

Question 43

Which Kafka setting limits the largest record batch accepted by a broker?

1. message.max.bytes
2. offsets.topic.replication.factor
3. auto.create.topics.enable
4. controlled.shutdown.enable

Correct Answer: 1

Explanation:

message.max.bytes defines the maximum size of a record batch that a Kafka broker will accept for a topic, subject to related configuration limits. Large event payloads can require coordinated configuration between producers, brokers, and consumers. Increasing message-size limits may also increase memory pressure, network usage, and processing costs. CCDAK architects should generally evaluate whether oversized events should instead be represented through references to external objects. When large messages are unavoidable, all relevant limits must be reviewed so producers do not successfully create requests that downstream broker or consumer configurations cannot handle.

Question 44

Which broker setting controls automatic topic creation?

1. log.cleaner.enable
2. auto.create.topics.enable
3. delete.topic.enable
4. offsets.retention.minutes

Correct Answer: 2

Explanation:

auto.create.topics.enable controls whether Kafka automatically creates a topic when a client references a topic that does not already exist under conditions where automatic creation is supported. Disabling automatic creation can provide stronger governance because topics must be explicitly provisioned with intended partitions, replication, retention, and other policies. Automatic creation can be convenient in development environments but may create incorrectly configured topics in production. CCDAK architects should consider operational governance, naming standards, security, and infrastructure-as-code practices when deciding whether automatic topic creation fits the environment.

Question 45

Which Kafka broker feature continuously cleans compacted log segments?

1. Log cleaner
2. Fetch manager
3. Replica checker
4. Offset manager

Correct Answer: 1

Explanation:

The Kafka log cleaner performs background compaction of logs configured with a compaction cleanup policy. It identifies older records that have been superseded by newer records with the same key and rewrites segments to reduce obsolete data. The cleaner operates independently from ordinary producer and consumer request processing. Its activity can consume disk and CPU resources, so workload characteristics matter when sizing brokers. CCDAK architects using compacted topics should understand that compaction is asynchronous rather than an immediate deletion operation, and applications should not assume obsolete records disappear instantly.

Question 46

Which topic is internally used to store consumer group offsets?

1. __consumer_offsets
2. __transaction_state
3. _schemas
4. __connect_configs

Correct Answer: 1

Explanation:

Kafka stores consumer group offset information in the internal __consumer_offsets topic. This internal topic allows Kafka to persist committed offsets so consumers can recover their processing position after restarts or rebalances. It is distinct from _schemas, which is associated with Schema Registry, and other internal topics used by different Confluent components. CCDAK architects should understand internal topics because their replication, partitioning, and retention characteristics contribute to cluster reliability. Offset management is particularly important for consumer recovery, group coordination, and processing semantics.

Question 47

Which internal topic stores Kafka transaction state information?

1. __consumer_offsets
2. __transaction_state
3. _schemas
4. __connect_offsets

Correct Answer: 2

Explanation:

The __transaction_state internal topic stores information used by Kafka’s transaction coordinator to maintain transactional state. Kafka transactions require coordination so that transaction outcomes can be tracked and transactional records can be handled correctly by participating clients. This internal topic is therefore important to transactional producer functionality. It differs from __consumer_offsets, which stores committed consumer offsets. CCDAK architects designing transactional workloads should understand that transaction coordination introduces additional internal state and operational considerations, including appropriate replication and availability of the internal topic.

Question 48

Which Confluent component stores connector configuration and status in Kafka?

1. Control Center
2. Schema Registry
3. Kafka Connect
4. ksqlDB

Correct Answer: 3

Explanation:

Kafka Connect distributed mode uses internal Kafka topics to persist connector configuration, offsets, and status information. These topics allow multiple Connect workers to coordinate and recover connector state when individual workers restart or fail. Proper replication and configuration of these internal topics are important for reliable Connect deployments. Control Center can monitor Connect environments but does not replace Connect’s internal state mechanism. CCDAK architects should treat Connect’s internal topics as part of the platform architecture rather than ordinary application topics, especially when planning disaster recovery and worker replacement.

Question 49

Which Kafka Connect internal topic stores source connector offsets?

1. __connect-offsets
2. __consumer_offsets
3. __transaction_state
4. _schemas

Correct Answer: 1

Explanation:

Kafka Connect uses the __connect-offsets internal topic to persist connector offsets. These offsets allow source connectors to remember their position in an external system and continue processing appropriately after worker restarts or task reassignment. The topic is especially important for source integrations because it contributes to continuity and recovery. Kafka’s __consumer_offsets serves a different purpose for consumer groups. CCDAK architects should configure Connect internal topics with suitable replication and availability because losing connector state can complicate recovery and potentially affect data movement behavior.

Question 50

Which Schema Registry concept identifies a unique schema version?

1. Subject name
2. Schema ID
3. Topic partition
4. Consumer offset

Correct Answer: 2

Explanation:

Schema Registry assigns a schema ID that clients can use to identify a registered schema. The ID is associated with a particular schema definition under the Registry’s schema management model. Subject names provide logical organization for schema versions, while Kafka partitions and offsets belong to Kafka’s messaging layer. Schema IDs allow serializers and deserializers to efficiently reference schema definitions rather than embedding complete schema text with every record. CCDAK architects should understand how schema IDs, subjects, compatibility rules, and serialization formats work together to support reliable data contracts.

Question 51

What does Schema Registry compatibility protect against?

1. Broker disk failure
2. Consumer lag
3. Incompatible schema evolution
4. Partition leadership changes

Correct Answer: 3

Explanation:

Schema Registry compatibility rules help control whether a new schema version can safely coexist with previous versions according to the selected compatibility policy. This reduces the risk that producers introduce schema changes that existing consumers cannot process. Compatibility is concerned with data contracts rather than broker availability or partition leadership. Policies can be configured according to organizational requirements, including backward, forward, or full compatibility models. CCDAK architects should select compatibility behavior based on producer-consumer evolution patterns and deployment sequencing rather than assuming every schema change is automatically safe.

Question 52

Which serialization format uses a compact binary representation with a schema?

1. JSON
2. CSV
3. Avro
4. Plain text

Correct Answer: 3

Explanation:

Apache Avro is a schema-based binary serialization format commonly used with Kafka and Confluent environments. Avro encodes data compactly and works well with Schema Registry for managing schema evolution. Compared with text-oriented formats, binary serialization can reduce message size and provide stronger structural contracts. The schema itself is managed separately through Schema Registry in typical Confluent deployments, while records reference the appropriate schema information. CCDAK architects should evaluate serialization format according to interoperability, payload size, schema evolution, language support, and operational requirements rather than selecting a format solely on convenience.

Question 53

Which Kafka Connect deployment mode supports multiple cooperating workers?

1. Distributed mode
2. Standalone-only mode
3. Embedded mode
4. Local batch mode

Correct Answer: 1

Explanation:

Kafka Connect distributed mode allows multiple workers to operate together as a coordinated Connect cluster. Connector tasks can be distributed among workers, providing scalability and improved resilience compared with a single standalone process. Distributed deployments also use Kafka topics to maintain connector configuration, status, and offset information. Standalone mode is generally simpler and is often appropriate for development or limited use cases. CCDAK architects should select distributed mode when connector workloads require horizontal scaling, task redistribution, or higher operational resilience.

Question 54

Which Kafka Connect setting identifies the worker cluster group?

1. key.converter
2. group.id
3. value.converter
4. offset.flush.timeout.ms

Correct Answer: 2

Explanation:

In Kafka Connect distributed mode, group.id identifies the Connect worker cluster. Workers using the same group ID coordinate as members of the same Connect cluster and participate in task assignment and management. Converter settings define how connector keys and values are serialized, while offset-related settings control state persistence behavior. Choosing a distinct and meaningful group ID is important when multiple independent Connect clusters operate against the same Kafka environment. CCDAK architects should ensure workers intended to cooperate use consistent cluster-level configuration while separate environments receive distinct identities.

Question 55

Which Kafka Connect component transforms records between processing stages?

1. Worker protocol
2. Single Message Transform
3. Schema Registry server
4. Consumer group coordinator

Correct Answer: 2

Explanation:

Kafka Connect Single Message Transforms, commonly called SMTs, modify individual records as they pass through a connector pipeline. They can perform operations such as changing field names, extracting fields, filtering information, or modifying record structure, depending on the available transformation. SMTs are lightweight record-level transformations and are not intended to replace full stream-processing applications. CCDAK architects should use them when simple per-record adjustments are sufficient and avoid placing complex business logic into connector configuration. This keeps integration architecture easier to understand and maintain.

Question 56

Which Confluent tool provides SQL-based stream processing?

1. Schema Registry
2. ksqlDB
3. Control Center
4. REST Proxy

Correct Answer: 2

Explanation:

ksqlDB provides SQL-based processing for Kafka streams and tables. It allows developers and architects to express transformations, filters, joins, aggregations, and materialized views using SQL-like statements rather than implementing every operation directly in application code. Because ksqlDB operates continuously on event streams, it is well suited to real-time processing scenarios. Schema Registry handles schemas, Control Center focuses on monitoring and management, and REST Proxy exposes Kafka functionality through HTTP. CCDAK architects should consider ksqlDB when streaming logic can be clearly represented through declarative SQL processing.

Question 57

Which ksqlDB construct represents continuously changing keyed state?

1. Table
2. Connector
3. Topic partition
4. Producer batch

Correct Answer: 1

Explanation:

A ksqlDB table represents changing state associated with keys and can be updated as new events arrive. Tables are useful for representing the latest known state derived from streams or other tables. Streams, by contrast, represent sequences of events. This distinction matters when designing joins and queries because streams and tables have different semantic meanings. CCDAK architects should determine whether a workload needs event history, current keyed state, or both. Correctly modeling the data as a stream or table helps produce more predictable processing behavior and query results.

Question 58

Which Kafka client API is designed for building producers?

1. Consumer API
2. Admin API
3. Producer API
4. Streams API

Correct Answer: 3

Explanation:

The Kafka Producer API is the client interface used by applications that publish records to Kafka topics. It supports operations such as sending records, handling acknowledgments, configuring retries, and selecting partitions through producer behavior. The Consumer API retrieves records, the Admin API manages Kafka resources, and the Streams API supports stream-processing applications. CCDAK architects should understand the responsibilities of each API because application architecture often combines several Kafka capabilities. Producer design decisions involving batching, compression, acknowledgments, idempotence, and partitioning can significantly influence overall system performance.

Question 59

Which Kafka API is intended for administrative cluster operations?

1. Streams API
2. Producer API
3. Admin API
4. Consumer API

Correct Answer: 3

Explanation:

The Kafka Admin API provides programmatic access to administrative operations such as creating topics, describing resources, altering configurations, and managing certain cluster metadata. It allows applications and automation tools to perform Kafka administration without manually invoking command-line utilities. The Producer and Consumer APIs focus on application data flow, while the Streams API provides stream-processing abstractions. CCDAK architects should consider the Admin API when building automated provisioning or operational tooling, particularly in environments where Kafka resources are managed through deployment pipelines or custom platform services.

Question 60

Which Kafka client API supports stateful stream processing?

1. Admin API
2. Streams API
3. Producer API
4. Consumer API

Correct Answer: 2

Explanation:

The Kafka Streams API provides abstractions for building applications that process Kafka records continuously. It supports operations such as transformations, joins, aggregations, and stateful processing while integrating closely with Kafka topics and partitions. Stateful stream-processing applications can maintain local state stores and recover state through Kafka-backed mechanisms. The Admin API manages cluster resources, while Producer and Consumer APIs provide lower-level data publication and consumption capabilities. CCDAK architects should evaluate Kafka Streams when application requirements involve embedded stream-processing logic that needs scalable partition-based processing and local state management.