Sample questions
St Kafka Connect Schema RegistryDifficulty 2
In Apache Kafka Connect, what is the main architectural difference between standalone mode and distributed mode?
- aDistributed mode shares config, offsets, and status in Kafka; standalone uses one process and a local source-offset file.✓
- bStandalone mode can only run sink connectors, while distributed mode can only run source connectors.
- cStandalone mode requires a Schema Registry to start, while distributed mode only works with schemaless converters.
- dStandalone mode assigns one task per topic partition, while distributed mode assigns exactly one task total.
Explanation:Standalone mode is a single-process deployment that persists its offsets to a local file, with no built-in fault tolerance or scaling. Distributed mode runs multiple worker processes that coordinate through Kafka topics, giving it fault tolerance and horizontal scaling. Option b, c, and d all invent restrictions that do not exist in either mode.
St Kafka Connect Schema RegistryDifficulty 2
In Kafka Connect terminology, what is the relationship between a connector and its tasks?
- aA connector and a task are two names for the same runtime object; the terms are used interchangeably.
- bA connector is a JVM process that hosts the Connect REST API, while a task is a separate JVM process for each source or sink.
- cA connector decides how to split work and produces task configs; the tasks are the units that actually move data.✓
- dA connector only runs in standalone mode, while tasks only exist in distributed mode.
Explanation:The connector instance is responsible for monitoring the external system and generating a set of task configurations; it does not consume or produce records itself. Tasks are the actual data-moving units that get scheduled onto workers. Option b confuses a task with a worker process, and option d invents a mode restriction that does not exist.
St Kafka Connect Schema RegistryDifficulty 2
What does the tasks.max connector configuration actually control?
- aIt fixes the exact number of tasks the connector creates, regardless of how the external source or sink can be divided.
- bIt is an upper bound; the connector may create fewer tasks if the source cannot be split that finely.✓
- cIt sets the number of Connect worker processes that must be started before the connector can run.
- dIt controls how many Kafka partitions the internal offset storage topic will have.
Explanation:tasks.max is a ceiling, not a guarantee. A connector's Connector.taskConfigs(int maxTasks) method decides how many task configs to actually generate, bounded by tasks.max but also by how finely the source or sink naturally splits (for example, the number of tables or files available). Option a overstates it as a fixed count, and c and d confuse it with worker count or internal topic partitioning.
St Kafka Connect Schema RegistryDifficulty 1
In distributed mode, what is stored in the internal config.storage.topic?
- aThe raw records produced by every source connector running on the cluster.
- bThe current running/paused/failed state of each connector and task.
- cThe last committed offsets for every source connector.
- dThe connector and task configurations submitted through the REST API, so any worker can pick them up.✓
Explanation:config.storage.topic is where Connect persists the configurations that were submitted via the REST API, which is what lets any worker in the cluster load a connector's configuration and take over its tasks. The status of connectors and tasks lives in status.storage.topic, and source offsets live in offset.storage.topic — options b and c describe those other two topics instead.
St Kafka Connect Schema RegistryDifficulty 1
What is the purpose of the internal offset.storage.topic in a distributed Kafka Connect cluster?
- aIt stores the consumer group offsets that sink connectors commit back to Kafka.
- bThe position each source connector has reached in the system it reads from, so Connect can resume after a restart.✓
- cIt stores a copy of every message a sink connector has written to its external system.
- dIt stores the REST API credentials used to submit new connector configurations.
Explanation:Source connectors read from systems that are not Kafka itself (a database, a file, an API), so Connect needs somewhere to remember how far each one has progressed. offset.storage.topic holds exactly that progress marker per source partition. Sink connectors do not use this topic for their own progress — they rely on the ordinary Kafka consumer group mechanism instead, which option a mixes up.
St Kafka Connect Schema RegistryDifficulty 1
What does the internal status.storage.topic in a distributed Connect cluster hold?
- aThe current running/paused/failed state of each connector and task, used for REST API status queries.✓
- bThe connector configurations that were submitted through the REST API.
- cThe offsets that source connectors have reached in the systems they read from.
- dA log of every record transformation applied by single message transforms.
Explanation:status.storage.topic is what the Connect REST API's /connectors/{name}/status endpoint reads from — it tracks whether each connector and task is running, paused, or failed, and on which worker. Configuration lives in config.storage.topic and source progress lives in offset.storage.topic, so b and c describe the wrong topics.