Free CCAC practice test: 30 questions with answers

Cluster linking keeps mirror topics on the standby cluster continuously synchronized, and failing them over makes them writable within minutes. The nightly export has a recovery point of up to a day, simultaneous dual writes create divergent copies, and waiting for the region to recover does not meet the requirement.

Active-active allows each region to serve local writes, but it introduces conflicting updates and cross-region ordering questions that the application must handle. Active-passive sends writes to one region at a time, so it avoids most conflict handling. The other options are wrong because active-active still needs replication and active-passive is not limited to one cloud.

Replicating only the non-personal summary topics keeps personal data in the EU while still giving the US team what it needs. Mirroring everything moves personal data out of the EU even with ACLs in place, and direct cross-region reads or nightly copies also transfer the raw personal data.

Kafka guarantees order only within a single partition, so events for one customer must use the same key and therefore land in the same partition. Replication does not add any global ordering across partitions or regions, and the destination does not re-sort records by timestamp.

Replication stores a full copy of the retained data in each region, and cluster linking does not need Connect workers. Mirror topics are read-only until promoted, active-active setups do not give a global total order, and distance from the cluster increases latency rather than reducing it.

A local cluster lets Singapore producers write with low latency, and cluster linking delivers the data to Virginia for analytics. A VPN does not remove the distance between the regions, local buffering delays data without fixing producer latency, and monthly batches discard the real-time sensor stream.

Mirror topics are read-only on the destination while they replicate from the source, and promoting one turns it into a regular writable topic. Mirror topics do not accept producer writes, do not copy only recent data, and do not rely on Kafka Connect source connectors.

Consumer offset synchronization copies committed consumer group offsets from the source cluster, so consumers resume at the correct position. Resetting to earliest reprocesses events, while new group IDs or recreated topics skip or restart processing in the wrong place.

Failover stops replication from the source immediately and turns the mirror into a regular, writable topic, without needing the source to be reachable. It does not delete the source topic, convert the topic into a Flink table, or reset consumer offsets.

Cluster linking creates mirror topics on the destination and replicates them without a separate Connect worker cluster. A custom Streams application or hourly CSV transfers add code to maintain or lose timeliness, and Replicator works but requires the Connect workers the team wants to avoid.

A cluster link stores the connection and replication settings between a source and destination cluster, and mirror topics are created over it. It is not a Connect worker group, a ksqlDB query, or a Schema Registry subject.

A planned migration pauses writes on the source and waits until the mirror topics hold every source record, so promotion does not leave data behind. Deleting the source, renaming consumer groups, or resetting schema IDs are not part of this step.

The fully managed PostgreSQL CDC Source connector runs on Confluent-managed infrastructure, so the team does not operate Connect workers. The self-managed Debezium option needs the team to run workers, and polling approaches miss row-level changes such as deletes while adding operational work.

tasks.max sets the upper bound on parallel tasks, which determines how much of the connector's work can run at the same time. It does not limit record size, control retry behaviour, or restrict the number of topics the connector uses.

Setting errors.tolerance to all lets the connector continue past bad records, and a dead letter queue keeps them for review. Changing tasks.max or the offset flush interval does not skip or store failed records, and stopping on every error halts the pipeline.

A dedicated service account with least-privilege permissions limits the damage from a leaked key and makes audits clear. Admin keys, shared keys, and credentials embedded in topic names expose more than the connector needs and are poor practice.

A sink connector assigns topic partitions to its tasks, so raising tasks.max lets more of them read in parallel, up to the partition count. Retention changes, consumer group changes, or extra partitions with a single task do not raise throughput in this way.

Fully managed connectors run on infrastructure that Confluent operates, and source connector progress is kept in Kafka so restarts resume correctly. Offsets are not kept on local disk, connector settings are not Schema Registry subjects, and customers do not install plugin jars on workers.

Under BACKWARD compatibility the new schema must read data written with the previous schema, so a new field needs a default value. A required field without a default, a type change, or a rename without an alias all break the reading of older records.

Schema Registry-aware serializers put a schema ID in the message, and deserializers use that ID to retrieve and cache the schema. Copying full schema text into each record is not how the registry works, and neither consumer offsets nor broker storage hold schemas.

Stream Catalog indexes Kafka resources and supports search and business tagging. Lineage maps relationships, Schema Registry manages schema versions, and ksqlDB processes streams, so none of them is the catalog.

Stream Lineage draws the graph of upstream and downstream relationships around topics, connectors and processing jobs. Compatibility settings, cluster link dashboards and task logs do not show that full map.

Schema linking synchronizes schemas and their versions between Schema Registry instances, so the secondary stays consistent. Lineage, consumer offset sync and client-side field level encryption do not copy schemas between registries.

A data contract pairs a schema with metadata and rules, so producers and consumers share the same expectations. Offsets, connector permissions and compute pool settings are operational details rather than the agreed data definition.

A tumbling window uses fixed, non-overlapping intervals, so each event belongs to exactly one window. Hopping windows overlap, session windows depend on inactivity gaps rather than fixed intervals, and global windows do not split events by time.

A watermark is the engine's estimate of event-time progress, and it is used to decide when a window can close. Watermarks do not encrypt records, choose partition counts, or store consumer offsets.

Flink checkpoints capture operator state and source positions consistently, so after a failure the job restarts from the last completed checkpoint without double counting. Rebuilding from the output topic, storing counts in Schema Registry, or starting from zero with a new group ID do not restore state correctly.

A stream records each event as a new row, and a table represents current state by keeping the latest value per key. The options that reverse these meanings, or confuse them with partition counts or schema subjects, are wrong.

Flink statements run on compute pools with bounded capacity, and ksqlDB pull queries return current state and end. A hopping window whose slide equals its size is the same as a tumbling window, so each event lands in one window; Flink supports event time without Schema Registry, and session windows close on inactivity gaps rather than record counts.

Keying routes all events with the same key to one parallel instance, so that instance holds the state for that key. Broadcasting copies events everywhere, windowing groups by time, and materializing writes to a subject, none of which partitions state by key.