Walk through creating a cluster link and the key link-level configurations you'd set, including security to the source.
answer
- Link created on destination, names the source
- bootstrap.servers + security.protocol + sasl.jaas.config
- auto.create.mirror.topics.enable + filter/prefix
- Destination = client of source (needs network reach)
- Describe/alter/delete = first-class object
basics
~20 sOn the destination, you create a named link pointing at the source's bootstrap servers and security settings, then create mirror topics on that link. Key configs include the source bootstrap/security (SASL/SSL), whether to auto-create mirror topics, and the offset/ACL sync flags.
solid answer
~50 sYou create the link on the **destination** cluster, giving it a name and a config file describing the source: `bootstrap.servers` of the source, plus the security to authenticate to it — `security.protocol` (e.g. SASL_SSL), `sasl.mechanism` (e.g. PLAIN/OAUTHBEARER), `sasl.jaas.config`, and TLS truststore settings. The destination brokers use these to fetch from the source. Then you create mirror topics bound to source topics over the link, optionally enabling `auto.create.mirror.topics.enable` so new source topics matching a prefix/filter are mirrored automatically. You'd also commonly set `consumer.offset.sync.enable` + `consumer.offset.group.filters`, `acl.sync.enable` + `acl.filters`, and tuning like fetch/replication settings. Networking must allow the destination brokers to reach the source's advertised listeners. In Confluent Cloud the same is expressed via the CLI/REST/Terraform; on Confluent Platform via `kafka-cluster-links` / `confluent` CLI with a properties file. The link is a first-class, reconfigurable object you can describe, alter, and delete.
go deeper
Know a link is created on the destination, points at the source, and carries mirror topics.
List the connection configs (bootstrap + security) and the idea of auto-creating mirror topics.
Explain the full config surface, that the destination is a client of the source, and networking/credential failure modes.
Standardize link provisioning (Terraform), security posture (key rotation, PrivateLink), and filter governance across many links.
## Where the link lives A **cluster link** is created and managed on the **destination** cluster, because the destination's brokers are the ones that initiate the connection and **pull** data from the source. You give the link a **name** (used when creating mirror topics) and a set of **link configs**. ## Core link configs ### Connecting to the source - **`bootstrap.servers`** — the source cluster's bootstrap endpoint the destination connects to. - **`security.protocol`** — typically `SASL_SSL` in Confluent Cloud, or `SSL`/`SASL_PLAINTEXT` on-prem. - **`sasl.mechanism`** — e.g. `PLAIN`, `OAUTHBEARER`, `SCRAM-SHA-256`. - **`sasl.jaas.config`** — the credential (API key/secret, or username/password) the destination uses to authenticate to the source. - TLS settings — `ssl.truststore.location`/`...password` (or system trust) so the destination trusts the source's certs. These are exactly the client security properties you'd give any Kafka client, because the destination brokers act as a client of the source. ### Behavior configs - **`auto.create.mirror.topics.enable`** — when true, source topics matching a configured filter/prefix get mirror topics created automatically (otherwise you create each mirror topic explicitly). - **`consumer.offset.sync.enable`** + **`consumer.offset.group.filters`** + **`consumer.offset.sync.ms`** — consumer offset sync. - **`acl.sync.enable`** + **`acl.filters`** — ACL sync. - Replication/fetch tuning and connection settings (e.g., how the link batches/fetches). ## Creating mirror topics Once the link exists, you create mirror topics bound to it: each names a **source topic** and the **link**, and the destination starts pulling. With auto-create on, this happens for matching topics without manual steps. ## Networking The destination brokers must have **network reachability** to the source's advertised listeners (VPC peering, PrivateLink, public endpoints, etc.). A common failure is a link that authenticates but can't actually reach broker listeners. ## Tooling - **Confluent Platform**: `confluent cluster link` / `kafka-cluster-links` CLI with a `--config-file` (properties). - **Confluent Cloud**: `confluent kafka link create ... --source-cluster ... --config-file ...`, REST API, or Terraform provider. ## Lifecycle The link is a durable, named object: you can **describe**, **alter** (update configs), **list mirror topics**, and **delete** it. Deleting a link stops mirroring for all its mirror topics. ## Edge cases - Wrong/expired source credentials → link exists but mirroring stalls; check link status. - Mismatched security protocol vs the source listener → connection failures. - Auto-create filters that are too broad can mirror unintended topics (and consume quota).
- Why do link configs look like Kafka client security properties (security.protocol, sasl.jaas.config)?Because the destination brokers act as a client of the source cluster — they connect and fetch like a consumer would — so they need the same authentication and TLS settings any client uses to reach the source.
- What does auto.create.mirror.topics.enable do, and what's a risk?It automatically creates mirror topics for source topics matching a configured filter/prefix, so new topics are picked up without manual steps. The risk is an overly broad filter mirroring unintended topics and consuming storage/quota.
saying these in an interview costs you the question
- Creating the link on the source cluster
- Forgetting the destination needs network reachability to the source listeners
- Omitting source security config and assuming it 'just connects'
- Treating the link as ephemeral rather than a durable, alterable object