> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/en/quiz-collection/data-on-eks/05-kafka-connect-mirrormaker-quiz.md). # Part 5: Kafka Connect and MirrorMaker Quiz This quiz tests your understanding of Kafka Connect's source/sink connector model, distributed mode, Strimzi's `KafkaConnect`/`KafkaConnector` CRDs, and MirrorMaker 2's architecture and disaster recovery patterns. ## Multiple Choice Questions 1. A connector like Debezium, which reads a database's WAL/binlog and streams change events into Kafka, is what kind of connector? * A) Sink connector * B) Source connector * C) Filter connector * D) Transform connector
Show Answer **Answer: B) Source connector** **Explanation:** Source connectors pull data INTO Kafka from an external system. Debezium is the canonical example of a CDC (Change Data Capture) source connector: it reads a database's write-ahead log (or binlog) and streams row-level change events into Kafka. Sink connectors do the opposite — they push data OUT of Kafka into external systems like S3 or Elasticsearch.
2. What do the S3 Sink Connector and Elasticsearch Sink Connector have in common? * A) They pull data from an external system into Kafka * B) They push data from a Kafka topic out to an external system * C) They replicate data between topics * D) They manage consumer group offsets
Show Answer **Answer: B) They push data from a Kafka topic out to an external system** **Explanation:** Both the S3 Sink Connector and the Elasticsearch Sink Connector are sink connectors, meaning they push data accumulated in a Kafka topic out to an external system. S3 Sink Connector writes topic data to an S3 bucket in formats like JSON or Parquet, while Elasticsearch Sink Connector indexes topic data for search and analytics.
3. In Kafka Connect's distributed mode, what happens when one worker dies? * A) The entire Connect cluster stops * B) The dead worker's tasks are automatically rebalanced onto other surviving workers * C) The connector automatically switches to standalone mode * D) All offset information is reset
Show Answer **Answer: B) The dead worker's tasks are automatically rebalanced onto other surviving workers** **Explanation:** In distributed mode, multiple worker processes form a group that acts as a single Connect cluster, with a group coordinator distributing connectors and tasks across the workers. If a worker dies, the coordinator detects it and automatically rebalances that worker's tasks onto the remaining workers to maintain availability. This is the key difference from standalone mode, which runs as a single process with no high availability.
4. Why is Kafka Connect's standalone mode never used in Kubernetes/Strimzi environments? * A) It doesn't support a REST API * B) It has no high availability or horizontal scalability * C) It only supports source connectors * D) It doesn't support TLS
Show Answer **Answer: B) It has no high availability or horizontal scalability** **Explanation:** Standalone mode runs as a single process with a file-based offset store, designed for local development and testing. Since there is only one worker, there's no other worker to take over if it fails, and the workload can't be spread across multiple nodes. Because of these limitations, Kubernetes/Strimzi environments always run distributed mode, backed by multiple worker Pods.
5. What is the main advantage of using the `KafkaConnector` CRD in Strimzi? * A) It lets you manage connectors declaratively through GitOps instead of calling the REST API directly * B) It automatically writes connector plugin code for you * C) It converts distributed mode into standalone mode * D) It eliminates the need for an offset storage topic
Show Answer **Answer: A) It lets you manage connectors declaratively through GitOps instead of calling the REST API directly** **Explanation:** With the `KafkaConnector` CRD, you don't need to call the Connect REST API directly to create, delete, or reconfigure connectors — you declare the desired state in a YAML manifest, and the Strimzi Operator reconciles it against the actual connector state. This enables a GitOps workflow where connector configuration is version-controlled in a Git repository and deployed through code review/CI pipelines.
6. What annotation is required on a `KafkaConnect` resource to enable the `KafkaConnector` CRD for it? * A) `strimzi.io/kraft: enabled` * B) `strimzi.io/node-pools: enabled` * C) `strimzi.io/use-connector-resources: "true"` * D) `strimzi.io/connect-mode: distributed`
Show Answer **Answer: C) `strimzi.io/use-connector-resources: "true"`** **Explanation:** Adding the `strimzi.io/use-connector-resources: "true"` annotation to a `KafkaConnect` resource's metadata tells the Strimzi Operator to watch for `KafkaConnector` resources targeting that Connect cluster and reconcile them into real connectors. Without this annotation, creating `KafkaConnector` resources has no effect.
7. What characterizes Strimzi's recommended approach to building a custom image with connector plugins via `KafkaConnect.spec.build`? * A) You must write a Dockerfile by hand * B) You declare plugin artifact URLs, and the Operator builds and pushes the image to the registry you specify * C) Images can only be pushed to Docker Hub * D) It only works in standalone mode
Show Answer **Answer: B) You declare plugin artifact URLs, and the Operator builds and pushes the image to the registry you specify** **Explanation:** Strimzi's recommended pattern is to declaratively populate `KafkaConnect.spec.build` with an `output` (the target registry image and a push secret) and a list of `plugins` (each specifying tgz/zip/jar artifact URLs or Maven coordinates). No Dockerfile is required — the Strimzi Operator performs the build itself and pushes the resulting image to a registry such as Amazon ECR.
8. In MirrorMaker 2, which connector is responsible for translating a source cluster's consumer group offsets into the equivalent offsets on the target cluster? * A) MirrorSourceConnector * B) MirrorHeartbeatConnector * C) MirrorCheckpointConnector * D) MirrorTopicConnector
Show Answer **Answer: C) MirrorCheckpointConnector** **Explanation:** MirrorCheckpointConnector periodically translates a source cluster's consumer group offsets into the equivalent offsets on the target cluster and records them in a checkpoint topic. This offset translation is what lets a consumer group know "how far it had already processed" when it fails over to the DR cluster and needs to resume consumption. MirrorSourceConnector handles the actual replication of messages, topics, and ACLs, while MirrorHeartbeatConnector sends heartbeats indicating the replication pipeline is alive.
9. What naming convention does MirrorMaker 2's default `DefaultReplicationPolicy` use for remote topics? * A) `.` * B) `.` * C) `mirror-` * D) The original topic name unchanged
Show Answer **Answer: B) `.`** **Explanation:** `DefaultReplicationPolicy` names remote topics `.`. For example, replicating the `orders` topic from a cluster aliased `us-east-1` produces a remote topic named `us-east-1.orders` on the target cluster. Keeping the original name unchanged requires `IdentityReplicationPolicy` instead, which makes loop prevention harder in an active-active setup.
10. What is the core difference between the active-passive and active-active DR patterns? * A) Active-passive compresses data and active-active does not * B) Active-passive replicates one-way only, while active-active replicates bidirectionally and requires loop prevention * C) Active-active does not use MirrorMaker 2 * D) Only active-passive uses the KafkaConnector CRD
Show Answer **Answer: B) Active-passive replicates one-way only, while active-active replicates bidirectionally and requires loop prevention** **Explanation:** The active-passive pattern replicates one-way, from the primary cluster to the DR cluster, and the DR cluster normally sits idle. The active-active pattern replicates bidirectionally between both clusters so both regions can serve traffic, but this means a replicated topic could be mirrored right back to its origin cluster, causing an infinite loop, unless it's explicitly prevented through `replication.policy.class` and topic filters.
## Short Answer Questions 11. What is the name of the MirrorMaker 2 connector that periodically sends heartbeat messages to signal that the source cluster is alive and the replication pipeline is functioning?
Show Answer **Answer: MirrorHeartbeatConnector** **Explanation:** MirrorHeartbeatConnector periodically sends heartbeat messages indicating that the source cluster is operating normally and the replication pipeline has not been disrupted. If these heartbeats stop arriving for a period of time, that absence can be used as a signal to detect replication lag or a broken connection to the source cluster.
12. What are the names of the three internal topic configuration keys that Strimzi Kafka Connect's distributed workers use to store offsets, connector/task configuration, and task status? (e.g., offset.storage.topic)
Show Answer **Answer: `offset.storage.topic`, `config.storage.topic`, `status.storage.topic`** **Explanation:** Distributed-mode Connect workers use three internal topics: `offset.storage.topic` for offsets, `config.storage.topic` for connector/task configuration, and `status.storage.topic` for task status. If these topics are lost, every connector on the cluster loses its state, so production deployments must set their replication factor to at least 3.
13. What configuration key controls whether MirrorMaker 2 also syncs the source cluster's topic ACLs to the target cluster?
Show Answer **Answer: `sync.topic.acls.enabled`** **Explanation:** Setting `sync.topic.acls.enabled` to `true` causes the source cluster's topic ACLs to be synced to the target cluster as well, so access control policy doesn't need to be maintained twice. However, if the two clusters have different security postures — for example, if the DR cluster requires stricter access control — it may be safer to disable this and manage ACLs independently on each side.
14. What is the name of the metric MirrorMaker 2 exposes that reports the time from when a message was produced on the source cluster to when it was fully replicated to the target?
Show Answer **Answer: `replication-latency-ms`** **Explanation:** `replication-latency-ms` is one of MirrorMaker 2's core exposed metrics, reporting the elapsed time from when a message was produced on the source cluster to when it was fully replicated to the target cluster. Scraping this into Prometheus and alerting on it lets you continuously verify a replication lag SLA.
15. In Strimzi, what `spec` field on a `KafkaMirrorMaker2` resource specifies which of the configured clusters the MM2 worker Pods should use to store their own internal topics (offsets, configuration, etc.)?
Show Answer **Answer: `connectCluster`** **Explanation:** `KafkaMirrorMaker2.spec.connectCluster` points to one of the cluster aliases defined in `spec.clusters`, determining which cluster the MM2 worker Pods use to store their own Kafka Connect internal topics (offset, configuration, and status storage topics). This is typically set to the DR or target cluster.
## Hands-on Questions 16. Write a `KafkaConnector` resource for a Debezium PostgreSQL source connector that runs on a `KafkaConnect` cluster named `connect-cluster` (which has the `strimzi.io/use-connector-resources: "true"` annotation set). Limit it to a single task.
Show Answer **Answer:** ```yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: orders-db-source namespace: kafka labels: strimzi.io/cluster: connect-cluster spec: class: io.debezium.connector.postgresql.PostgresConnector tasksMax: 1 config: database.hostname: orders-db.xxxxxxx.us-east-1.rds.amazonaws.com database.port: 5432 database.user: debezium database.password: "${secrets:kafka/debezium-db-credentials:password}" database.dbname: orders topic.prefix: orders-db plugin.name: pgoutput slot.name: debezium_orders table.include.list: public.orders,public.order_items ``` **Explanation:** The `metadata.labels.strimzi.io/cluster: connect-cluster` label tells the Strimzi Operator which `KafkaConnect` cluster this `KafkaConnector` should run on. `spec.class` specifies the actual connector implementation class (the Debezium PostgreSQL connector), and `plugin.name: pgoutput` specifies PostgreSQL's logical replication output plugin. `tasksMax: 1` reflects the fact that a PostgreSQL source connector can only use a single replication slot, so its work cannot be parallelized across multiple tasks.
17. Write a `KafkaMirrorMaker2` resource that one-way replicates topics matching `orders.*` and `payments.*` from a cluster aliased `us-east-1` to a cluster aliased `dr-region`, also syncing consumer group offsets.
Show Answer **Answer:** ```yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: primary-to-dr namespace: kafka spec: version: 3.9.0 replicas: 3 connectCluster: dr-region clusters: - alias: us-east-1 bootstrapServers: primary-kafka-bootstrap.us-east-1.example.com:9093 - alias: dr-region bootstrapServers: dr-kafka-bootstrap.us-west-2.example.com:9093 config: config.storage.replication.factor: 3 offset.storage.replication.factor: 3 status.storage.replication.factor: 3 mirrors: - sourceCluster: us-east-1 targetCluster: dr-region sourceConnector: tasksMax: 5 config: replication.factor: 3 offset-syncs.topic.replication.factor: 3 sync.topic.acls.enabled: "true" heartbeatConnector: config: heartbeats.topic.replication.factor: 3 checkpointConnector: config: checkpoints.topic.replication.factor: 3 sync.group.offsets.enabled: "true" topicsPattern: "orders.*|payments.*" groupsPattern: "orders-consumer-.*" ``` **Explanation:** Each entry in the `mirrors` list defines one replication direction (`sourceCluster` to `targetCluster`). `topicsPattern` restricts replication to `orders.*` and `payments.*`, and setting `checkpointConnector.config.sync.group.offsets.enabled: "true"` causes the translated consumer group offsets to be written into the target cluster's `__consumer_offsets`. `connectCluster: dr-region` designates the DR region as the cluster where the MM2 workers store their internal topics.
18. Explain two settings you'd check to prevent a topic from being mirrored infinitely in a loop (A to B to A to B...) in an active-active configuration.
Show Answer **Answer:** 1. `replication.policy.class` — with the default `DefaultReplicationPolicy`, topics that already carry a remote-cluster prefix (`.`) are automatically excluded from further mirroring. 2. `topicsPattern` — narrowing the pattern on each mirror direction to explicitly include only the topics that actually need replication prevents unintended topics from being caught in a replication cycle. **Explanation:** `DefaultReplicationPolicy`'s naming convention (`.`) is itself the first line of defense against loops: if cluster B tries to mirror a topic like `A.orders` back to cluster A, MM2 recognizes it as an already-prefixed remote topic and does not re-mirror it. On top of that, explicitly narrowing `topicsPattern` for each mirror direction reduces the risk of a configuration mistake or an unusual topic naming pattern accidentally triggering a replication loop.
*** [Return to Learning Materials](/kubernetes/en/data-on-eks/kafka/05-kafka-connect-mirrormaker.md) | [Next Quiz: MSK Integration](/kubernetes/en/quiz-collection/data-on-eks/06-msk-integration-quiz.md)