While RBAC and Schema Registry are important for security and data governance, the core requirement for immutable, long-term retention is best met by Tiered Storage. This feature allows cost-effective storage of data in object storage (like S3) with immutable, append-only semantics for the configured retention period, preventing deletion and meeting regulatory audit trails. Log Compaction removes old data, violating the requirement, and RBAC alone does not prevent data deletion.

In a mature environment using Schema Registry, the most common cause for a new consumer failing to parse existing data is a mismatch in the serializer/deserializer (SerDes) configuration or an inability to resolve the schema ID from the Registry. The other options are less likely: wrong bootstrap servers would typically cause connection failures, offset reset applies to missing offsets, and max bytes issues would cause corruption, not structural mismatches.

A spike in bytes out without new consumers or a change in data in (BytesInPerSec) points to existing consumers reading the same data repeatedly. Frequent consumer failures and restarts cause the consumer to rejoin its group, often resetting its offset (depending on configuration) and re-fetching large batches of data, dramatically increasing outbound traffic. Lower `fetch.min.bytes` might increase request count but not necessarily total volume. Replication factor changes are a one-time event, not a sustained spike.

Kafka Streams uses an in-memory cache to buffer updates to KTables (like customer updates) for efficiency. If `cache.max.bytes.buffering` is set too high or the buffer isn’t full, updates might be held in cache and not applied to the state store immediately. An incoming order (KStream) would then join against the stale, pre-update state from the store. Tuning or disabling this cache ensures updates are processed promptly for time-sensitive joins. The other options affect performance and fault tolerance but not the fundamental timing of state updates relative to stream events.

When the source topic has log compaction enabled, old messages with the same key can be deleted, but ksqlDB’s Kafka Streams-based engine may reprocess the log from the beginning and see duplicate keys as new events if the previous value was compacted away. This leads to an inflated count in a stateful aggregation. The correct approach is to create the stream with `KAFKA` format and the source topic’s `cleanup.policy` in mind, or use a custom timestamp extractor. A missing `WINDOW` clause creates a global table, but that alone doesn’t cause count inflation; it’s the combination with compaction.

Cluster Linking uses an internal consumer to read from the source cluster. The `offset.syncs.topic` periodically writes the mirroring consumer’s position to a special topic in the destination cluster. `sync.group.offsets` ensures these offsets are committed back to the source cluster’s `__consumer_offsets` topic. This dual mechanism allows the link to recover from an outage by knowing exactly where it left off on both sides, preventing data loss (by resuming from the correct offset) and duplication (by not resetting the offset). The other options relate to general consumer or producer tuning, not the specific link recovery mechanism.

Confluent Cloud RBAC allows for granular permission assignment. The requirement is scoped to topics with a specific prefix. Creating a custom role with only the necessary permissions (`TopicWrite` for create/alter, `TopicDelete`) and assigning it at the granular resource pattern (`Teamx-*`) follows the principle of least privilege. `CloudClusterAdmin` is overly permissive. Assigning a custom role at the Cluster level would grant permissions on *all* topics. The `ResourceOwner` role includes many other permissions beyond topic management, such as managing ACLs/RBAC binds, which the team should not have.

Increasing `tasks.max` creates multiple connector tasks, which can run in parallel. Each task will run its own query against the source database (e.g., on a subset of data if partitioned correctly). This parallelizes the read load and can significantly increase throughput. Using `timestamp+incrementing` mode is more robust for catching updates but doesn’t inherently reduce load. Decreasing `batch.max.rows` would increase the number of queries, potentially making load worse. Switching to timestamp mode alone might not leverage the optimal indexing.

The `_confluent-command` topic is an internal topic managed by Confluent. The proper way to manage its retention is to apply standard Kafka topic configurations to it. You can set `retention.ms` (e.g., 7 days) and `cleanup.policy=delete` via dynamic broker configuration or the Topics API. This allows Kafka’s log cleaner to manage the topic size automatically and safely. Manually deleting files can corrupt the topic. Deleting the topic will break Confluent’s internal operations. Increasing replication does not address size.

While RBAC and Schema Registry are important for security and data governance, the core requirement for immutable, long-term retention is best met by Tiered Storage. This feature allows cost-effective storage of data in object storage (like S3) with immutable, append-only semantics for the configured retention period, preventing deletion and meeting regulatory audit trails. Log Compaction removes old data, violating the requirement, and RBAC alone does not prevent data deletion.0