Free Kafka Platform Interview Practice Questions: Streams on OpenShift

These 25 original IT Mastery practice questions cover seven Kafka platform architecture and operations topics. The set contains 18 single-answer questions and seven Select TWO questions. Read the requested answer count before responding.

This is independent professional-skills and interview preparation, not an official certification exam. These are not official exam questions, copied live-exam content or exam dumps. The sample length, topic weights and interaction mix are editorial choices; there is no official time limit or passing score for this track.

Try each question before revealing its explanation. Explain the deciding evidence in your own words. Version-specific examples use Red Hat Streams 3.2, its Kafka 4.2 baseline and OpenShift 4.20; Quarkus examples identify the separate client baseline where it matters.

Practice-set coverage

Practice questions

Questions 1-25

Question 1

Topic: Operator-managed deployment and platform delivery

An architecture team is replacing a Kafka proof of concept before onboarding its first production workload. The existing deployment uses upstream Strimzi and community Apache Kafka images. No existing data must be retained, and the first workload does not require schemas.

All production components must have approved vendor support.

Which deployment decision best meets the production support requirement?

Options:

• A. Install the Streams 3.2 OLM operator, continue with Apache Kafka 4.2 images, and defer Registry deployment.

• B. Retain upstream Strimzi, switch brokers to the Red Hat Kafka 4.2 runtime, and defer Registry deployment.

• C. Install the Streams 3.2 OLM operator and its Red Hat Kafka runtime, then deploy Registry in the same production phase.

• D. Replace the PoC with the Streams 3.2 OLM operator and its Red Hat Kafka 4.2 runtime; defer Registry deployment.

Best answer: D

Explanation: Vendor support applies to the approved combination of platform, management operator, and managed runtime. OpenShift supplies the container platform, while the Red Hat Streams for Apache Kafka operator manages the Red Hat-built Kafka runtime. A supported broker image does not extend coverage to an upstream operator, and a supported operator does not make substituted community broker images supported.

The Red Hat build of Apicurio Registry is an optional integration product with its own deployment and support boundary. Technical interoperability does not satisfy the stated requirement when support approval remains pending. Because the first workload needs no registry and the PoC contains no data requiring migration, the supported operator-runtime pair can replace it directly.

Why each option fits or fails:

A. Substituting community Kafka images creates an operator-runtime combination not covered by the supplied support matrix.

B. Retaining upstream Strimzi leaves the management component outside the listed Red Hat support baseline, even with Red Hat broker images.

C. Deploying Registry immediately treats validated interoperability as support approval, contrary to the stated production requirement.

D. This uses the supported operator-runtime combination while excluding the optional Registry product whose support approval is pending.

Question 2

Topic: Operator-managed deployment and platform delivery

Red Hat Streams for Apache Kafka 3.2 uses the kafka.strimzi.io/v1 API. GitOps owns the custom resources, while the User Operator owns generated credential Secrets.

Current relevant configuration:

apiVersion: kafka.strimzi.io/v1
kind: Kafka
spec:
  kafka:
    config:
      log.retention.hours: 168
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaTopic
metadata:
  name: orders
spec:
  config:
    retention.ms: "86400000"
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaUser
metadata:
  name: orders-app
spec:
  authentication:
    type: scram-sha-512

The approved change sets the broker default to 72 hours, the orders topic to 14 days, and orders-app to certificate authentication on an existing TLS client listener. Other required fields are valid and omitted.

Which GitOps correction assigns each change to the appropriate operator?

Options:

• A. Set 336 in Kafka (Cluster), 259200000 in KafkaTopic (Topic), and tls in KafkaUser (User).

• B. Set 72 in Kafka (Cluster), 1209600000 in KafkaTopic (Topic), and replace the user Secret through GitOps.

• C. Set 72 in Kafka (Cluster), 1209600000 in KafkaTopic (Topic), and tls in KafkaUser (User).

• D. Set 72 in Kafka (Cluster), 1209600000 in KafkaTopic (Topic), and switch the listener authentication in Kafka (Cluster).

Best answer: C

Explanation: The Cluster Operator reconciles broker configuration from the Kafka resource, while the Topic Operator reconciles topic-specific configuration from KafkaTopic. Therefore, the 72-hour default belongs in Kafka.spec.kafka.config, and the 14-day override belongs in KafkaTopic.spec.config; 14 days equals 1,209,600,000 milliseconds. The User Operator reconciles authentication settings from KafkaUser and generates the corresponding credential Secret. Changing the user to authentication.type: tls requests a client certificate through that desired-state resource.

Generated Secrets are reconciliation outputs, and listener authentication defines endpoint-wide behavior rather than one user’s credential type.

Why each option fits or fails:

A. Reversed retention scopes applies 14 days as the broker default and only 3 days to the orders topic.

B. Direct Secret replacement changes an operator-generated output that can be overwritten during reconciliation.

C. Each value is placed in the custom resource reconciled by the operator responsible for that resource type.

D. Listener modification changes cluster endpoint behavior and does not request a certificate for the individual user.

Question 3

Topic: Operator-managed deployment and platform delivery

An architect reviews a GitOps promotion proposal. The standard requires one environment-neutral base, explicit overlays for infrastructure differences, and a stable workload contract.

Which TWO conclusions should the architect make?

Options:

• A. Keep environment-specific topic names while applying the production infrastructure overlay.

• B. Standardize broker capacity in the base while overlaying other infrastructure values.

• C. Move storage, bootstrap host, and TLS secret references into each overlay.

• D. Restore the production topic name while retaining TLS client authentication.

• E. Create a separate production base while preserving the approved workload contract.

Correct answers: C and D

Explanation: Configuration promotion separates invariant desired state from environment-specific infrastructure. The shared base should hold reviewed Kafka settings that apply everywhere, while overlays explicitly supply storage classes, external endpoints, certificate references, and capacity. Otherwise, production would inherit development storage, DNS, and certificate values.

The workload contract is a separate concern. Applications should retain the approved logical topic name and TLS authentication across environments, while obtaining the environment-specific bootstrap endpoint through deployment configuration. Production already has its approved replica count, so that value needs no correction. Creating another base would duplicate common configuration rather than promote the same reviewed configuration.

Why each option fits or fails:

A. Environment-specific topic names change the workload contract even when the infrastructure overlay is otherwise accurate.

B. Shared broker capacity conflicts with the explicitly different environment sizing represented by the production overlay.

C. These infrastructure values differ by environment and therefore do not belong in the environment-neutral base.

D. Production must preserve the approved order-events-v1 workload contract and its TLS authentication requirement.

E. A separate production base duplicates shared configuration and weakens the reviewed promotion path.

Question 4

Topic: Operator-managed deployment and platform delivery

A team uses GitOps to manage its Red Hat Streams for Apache Kafka Subscription. No upgrade InstallPlan currently exists.

Current state:

• Channel: stable-3.1
• installPlanApproval: Automatic
• Installed operator: 3.1

Verified evidence:

• Operator 3.2 is available only through stable-3.2.
• The catalog shows a supported direct 3.1-to-3.2 upgrade.
• Operator 3.2 supports the currently pinned Kafka runtime.

The CAB must review the generated plan before the Saturday change window. The Kafka runtime upgrade is scheduled separately for the following week.

Which update sequence best meets these requirements?

Options:

• A. Set Manual, retain the current channel, set the 3.2 starting CSV, approve the resulting plan Saturday, and keep Kafka pinned.

• B. Set Manual, change channels, review the pending plan, approve it Saturday, and keep the Kafka version pinned.

• C. Change channels, review the automatically approved plan, set Manual Saturday, and keep the Kafka version pinned.

• D. Set Manual, change channels, review and approve the plan now, defer its operator rollout until Saturday, and keep Kafka pinned.

Best answer: B

Explanation: OLM provides an explicit update gate through the Subscription’s installPlanApproval: Manual setting. The team should commit that policy before changing to the target channel. OLM can then resolve the supported upgrade and create an unapproved InstallPlan for CAB inspection. During the change window, the team sets the plan’s spec.approved value to true and verifies the CSV and operator rollout.

Operator approval does not schedule or approve a Kafka runtime change. Because the existing runtime remains supported and pinned in the Kafka resource, its upgrade can proceed through a separate reviewed change after the operator update succeeds.

Why each option fits or fails:

A. A starting CSV cannot select an update that is absent from the Subscription’s current channel.

B. Manual approval must be established before channel resolution so the generated operator upgrade remains pending until the approved window.

C. Changing channels while approval remains automatic can approve and start the operator update before the team establishes its gate.

D. Approving a manual plan immediately authorizes installation immediately; OLM does not defer execution until a future window.

Question 5

Topic: Kafka architecture and data guarantees

A Red Hat Streams for Apache Kafka cluster uses three controller-only KRaft nodes and three brokers.

Incident evidence:

• c1, c2, and c3 are mutually isolated; c1 remains reachable from brokers.
• c1 reports that it cannot obtain a controller majority.
• Topic creation times out, while cached clients continue using the unchanged inventory-0 leader on b2.
• Broker b1, the leader for orders-0, then stops.
• Replicas on b2 and b3 contain data through b1’s last high watermark, but no new leader appears.

Which TWO conclusions are supported?

Options:

• A. orders-0 remains leaderless because controller quorum loss blocks election from surviving replicas.

• B. The metadata quorum is unavailable because no two controllers can communicate.

• C. Continued inventory-0 traffic proves the metadata quorum still has a controller majority.

• D. The topic-creation timeout indicates the brokers lack enough in-sync partition replicas.

• E. A new orders-0 leader should be elected because two current replicas survive.

Correct answers: A and B

Explanation: KRaft metadata availability depends on a majority of controller voters, independently of partition replica count. With three mutually isolated controllers, no node can form the required two-voter majority, even though brokers can reach c1. Metadata changes such as topic creation and partition leader election therefore cannot complete.

Controller-quorum loss does not immediately stop every established data-plane operation. Clients with cached metadata may continue using an unchanged, responsive partition leader, as observed for inventory-0. After b1 fails, b2 and b3 hold current replicas, but they cannot appoint a replacement leader themselves. Controller reachability, partition leadership, and replica health must be evaluated separately.

Why each option fits or fails:

A. Current replicas cannot become the partition leader without a functioning controller quorum to perform the election.

B. A three-controller quorum requires at least two communicating voters for a majority.

C. Continued inventory-0 traffic confirms an existing leader remains usable, not that controller voters have a majority.

D. Topic creation changes cluster metadata, so its timeout does not establish an ISR shortage on brokers.

E. Surviving current replicas are eligible leader candidates, but their count cannot replace the controller election process.

Question 6

Topic: Kafka architecture and data guarantees

A Kafka topic has replication factor 3. Broker 3 is outside the ISR during storage repair, and broker 2 then becomes unavailable. Broker 1 remains leader.

Current state:

• ISR count: 1
• min.insync.replicas=2
• Producer acks=all
• Writes receive NotEnoughReplicas

Requirement: New acknowledged writes must tolerate one replica failure; a temporary write outage is acceptable. An operator proposes lowering min.insync.replicas to 1.

Which response best meets the requirement?

Options:

• A. Lower minimum ISR to one, keep acks=all, and resume writes on the surviving leader.

• B. Keep minimum ISR at two, change to acks=1, and resume writes on the surviving leader.

• C. Keep both settings, recover one replica, and resume writes when ISR reaches two.

• D. Keep both settings, restart one replica, and resume writes when its broker process is healthy.

Best answer: C

Explanation: Replication factor describes the assigned replica count, whereas ISR describes replicas currently caught up enough to participate in acknowledgments. With acks=all, the leader requires acknowledgment from the current ISR, and min.insync.replicas=2 prevents writes when only one ISR member remains. This preserves the requirement that each newly acknowledged record exist on at least two in-sync replicas.

Lowering the minimum ISR to 1 restores availability, but a write could then be acknowledged while stored only on the surviving leader. A permanent failure of that replica before another catches up could lose the acknowledged record. Recovery is not complete merely because a broker process is healthy; the replica must rejoin the ISR.

Why each option fits or fails:

A. Lower minimum ISR restores writes but removes one-replica-failure tolerance while only the leader remains in sync.

B. Use acks=1 permits leader-only acknowledgment and does not retain the intended minimum-ISR durability gate.

C. With one ISR member, min.insync.replicas=2 rejects acks=all writes until another replica catches up and rejoins.

D. Trust broker health overlooks replica lag; a running broker might not yet have rejoined the ISR.

Question 7

Topic: Kafka architecture and data guarantees

A team is replacing a six-partition orders topic before a seasonal peak. Load testing under the production replication, acknowledgment, and compression settings found:

• Projected peak traffic: 30 MiB/s
• Sustainable write capacity: 5 MiB/s per partition
• Consumer capacity: 4 MiB/s per instance
• Required capacity increment over projected peak: 20% for both ingestion and processing, so size for 36 MiB/s
• Required active consumers: 9 in one consumer group
• Customer IDs are high-cardinality keys; per-customer ordering is required. Load testing confirmed that projected customer-key traffic is sufficiently balanced under the intended partitioner for aggregate capacity sizing, with no hot key exceeding the stated per-partition or per-consumer capacity.

Which design uses the smallest partition count that satisfies all requirements?

Options:

• A. Configure 9 partitions, retain customer keys, and run 9 consumers.

• B. Configure 6 partitions, retain customer keys, and run 9 consumers.

• C. Configure 8 partitions, retain customer keys, and run 8 consumers.

• D. Configure 10 partitions, retain customer keys, and run 10 consumers.

Best answer: A

Explanation: The specified 20% capacity increment makes the sizing rate 30 MiB/s multiplied by 1.20, or 36 MiB/s. Ingestion therefore needs ceil(36 / 5) = 8 partitions, while processing needs ceil(36 / 4) = 9 consumer instances. A consumer group also requires at least nine partitions to keep nine consumers active because a partition is assigned to only one group member. The largest requirement is therefore nine partitions. Continuing to use customer ID as the key preserves ordering within each customer. The stated load-test distribution, rather than high key cardinality alone, supports applying the aggregate capacity calculation across partitions. Partition sizing depends on measured workload capacity; there is no universal optimal count.

Why each option fits or fails:

A. Nine partitions satisfy the processing calculation and allow all nine consumers to receive assignments while preserving key-based ordering.

B. Six partitions provide insufficient write and processing capacity, and three of the nine consumers would receive no partition.

C. Eight partitions satisfy measured write throughput but provide only 32 MiB/s of measured processing capacity and leave one consumer inactive.

D. Ten partitions meet the capacity requirements but exceed the stated smallest-count requirement.

Question 8

Topic: On-premises capacity and performance

An architect is sizing an on-premises Red Hat Streams for Apache Kafka cluster for a new application. A production trace shows this daily workload:

• Payload mix: 80% at 1 KiB and 20% at 5 KiB
• Measured compression ratio: 0.55
• Retention: 7 days; replication factor: 3
• No compaction

Use binary units. The profile excludes Kafka storage overhead, consumer reads, key skew, growth and failure headroom. The proposed nodes have not been benchmarked.

Which response provides the best-supported capacity estimate?

Options:

• A. Use 17.8 TiB and 23.2 MiB/s as workload baselines; measure the missing factors and benchmark the proposed nodes before purchase.

• B. Use 17.8 TiB and 23.2 MiB/s as final requirements; add filesystem reserve, select nodes from vendor ratings, and validate reads afterward.

• C. Use 40.1 TiB and 23.2 MiB/s as workload baselines; measure the missing factors and benchmark the proposed nodes before purchase.

• D. Use 5.9 TiB and 23.2 MiB/s as workload baselines; measure the missing factors and benchmark the proposed nodes before purchase.

Best answer: A

Explanation: The weighted average payload is 1.8 KiB. The daily event count is 921.6 million, producing about 0.85 TiB of compressed payload per day. Seven days with replication factor 3 requires approximately 17.8 TiB of replicated payload storage. Peak compressed client ingress is 24,000 × 1.8 × 0.55 KiB/s, or about 23.2 MiB/s.

These figures exclude record and index overhead, filesystem reserve, replication traffic, consumer reads and replays, partition skew, growth, and failure capacity. Representative node benchmarking is also needed to translate workload rates into disk, network, CPU, and node requirements.

Payload arithmetic is therefore a planning baseline, not a hardware commitment.

Why each option fits or fails:

A. The weighted profile yields these payload baselines, while missing operational measurements prevent treating them as a hardware commitment.

B. Treating 17.8 TiB as final bypasses the missing workload measurements and representative infrastructure benchmark.

C. The 40.1 TiB estimate incorrectly applies the four-hour peak rate to every hour of the retention period.

D. The 5.9 TiB estimate counts only one retained copy and omits replication factor 3.

Question 9

Topic: On-premises capacity and performance

A production KafkaNodePool gives each broker its own persistent volume. Only one broker pod mounts a volume at a time, and the storage driver supports detaching and reattaching a volume during rescheduling.

Per-broker requirements:

• Sustained write throughput: >= 400 MiB/s
• p99 fsync latency: <= 10 ms
• Dynamic PVC provisioning
• Existing data must survive worker replacement

Storage test results:

Which TWO conclusions are supported by the evidence?

Options:

• A. ReadWriteMany is required for broker pod rescheduling.

• B. san-block meets all stated production requirements.

• C. ReadWriteOnce meets the broker PVC access requirement.

• D. nas-file meets all stated production requirements.

• E. local-nvme meets all stated production requirements.

Correct answers: B and C

Explanation: Storage selection must satisfy every measured workload and recovery constraint. san-block is the only tested class that provides at least 400 MiB/s, stays within the 10 ms p99 fsync limit, provisions dynamically, and preserves data for reattachment after worker replacement.

Kafka brokers normally use separate PVCs, with one broker pod mounting each volume. Rescheduling does not inherently require ReadWriteMany; a suitable ReadWriteOnce volume can be detached from the failed or fenced node and attached to the replacement node. The NAS class offers broader access but misses the latency objective, while local NVMe loses access to the existing data when its host fails.

Why each option fits or fails:

A. ReadWriteMany: Sequential detach and reattach supports rescheduling without concurrent multi-node access.

B. It satisfies the throughput, latency, provisioning, access, and worker-loss requirements.

C. Each PVC has one broker owner and can be reattached after detachment, so concurrent multi-node mounting is unnecessary.

D. NAS file: Its throughput and durability qualify, but 14 ms p99 latency exceeds the 10 ms limit.

E. Local NVMe: Its performance is sufficient, but host failure makes the existing PVC data unavailable.

Question 10

Topic: On-premises capacity and performance

A three-broker Kafka cluster places each broker on a separate 16-core OpenShift worker. Produce p99 latency has risen above the 75 ms objective.

All brokers show similar results. Leader distribution, disk latency, and garbage collection are healthy. Capacity policy requires retaining the 2-core scheduling request but permits a 4-core limit. Changes must be made through the reviewed KafkaNodePool source.

Which response best addresses the latency?

Options:

• A. Raise the CPU limit to 4 cores, retain the request, and verify latency.

• B. Rebalance partition leaders across brokers, retain CPU settings, and verify latency.

• C. Move broker pods to the least-used workers, retain CPU settings, and verify latency.

• D. Raise the CPU request to 2.5 cores, retain the limit, and verify latency.

Best answer: A

Explanation: An OpenShift CPU request is primarily a scheduling reservation and influences CPU shares during contention. A CPU limit becomes an enforced cgroup runtime quota. Here, broker usage remains near 2.5 cores while throttling and latency are high, even though each worker has substantial unused CPU. This evidence identifies the container limit as the effective ceiling.

The reviewed KafkaNodePool configuration should retain the required 2-core request and raise the limit to the permitted 4 cores through a controlled rolling update. Afterward, compare throttled periods, broker CPU usage, and produce p99 latency. Spare node capacity cannot help a container while its existing CPU quota continues to throttle it.

Why each option fits or fails:

A. The limit enforces the observed runtime ceiling, while the request controls scheduling reservation rather than available burst CPU.

B. Rebalancing leaders is unsupported by the evidence because broker load and leader distribution are already balanced.

C. Moving pods does not remove their cgroup quota, and the current workers already have spare CPU.

D. Raising only the request changes scheduling reservation but leaves the 2.5-core runtime ceiling unchanged.

Question 11

Topic: Connectivity security and governance

A consumer in a partner DMZ must access a Red Hat Streams for Apache Kafka cluster through an external TLS Route listener. Bootstrap succeeds, but the consumer receives no records.

Observed:

• Metadata returns three broker Route hostnames on port 443.
• DNS resolves every hostname to the OpenShift ingress address.
• Unrestricted clients complete TLS hostname validation to every Route.
• The DMZ egress gateway permits TLS SNI only for the bootstrap hostname.

INFO Bootstrap TLS handshake completed
INFO Broker 0: kafka-0.apps.example.com:443
INFO Broker 1: kafka-1.apps.example.com:443
WARN Connection to node 0 timed out

Which response should the architect recommend?

Options:

• A. Add topic Describe and Read ACLs before changing network access.

• B. Allow outbound TLS to every advertised broker Route hostname.

• C. Advertise the bootstrap Route hostname for every broker connection.

• D. Rotate the Route certificate before changing the egress policy.

Best answer: B

Explanation: A Kafka bootstrap server is a discovery endpoint, not a proxy for all subsequent traffic. After obtaining metadata, the consumer connects directly to the advertised endpoint of each broker that leads its required partitions. With an OpenShift Route listener, these broker endpoints have distinct hostnames even when they resolve to the same ingress address. The DMZ gateway therefore must permit TLS SNI for the bootstrap hostname and every advertised broker Route hostname.

DNS, Route availability, and certificate validation have already been verified. The timeouts occur because the gateway blocks the broker connections before Kafka authorization can be evaluated. Reusing the bootstrap hostname would also prevent the ingress router from selecting the intended per-broker Route.

Why each option fits or fails:

A. Change ACLs affects Kafka authorization only after the client establishes a broker connection.

B. Kafka clients must connect to the individual broker endpoints returned during metadata discovery.

C. Reuse bootstrap confuses metadata discovery with the broker-specific connections required after discovery.

D. Rotate certificates does not address a network timeout when existing certificates already pass hostname validation.

Question 12

Topic: Connectivity security and governance

A Red Hat Streams for Apache Kafka 3.2 cluster uses external TLS routes. The bootstrap connection succeeds, but the client fails after metadata returns broker-0.kafka.apps.example.com.

Certificate evidence:

• Listener certificate SAN: kafka-bootstrap.apps.example.com
• Certificate is currently within its validity period
• Server sends the leaf and issuing CA certificates
• Client truststore contains the corporate root CA

SSLHandshakeException: No subject alternative DNS name matching
broker-0.kafka.apps.example.com found

Public DNS and advertised broker names cannot change, and hostname verification must remain enabled. Which response best addresses the failure?

Options:

• A. Add the presented root and intermediate certificates to the client truststore.

• B. Disable hostname verification while retaining the current certificate chain.

• C. Reissue the listener certificate with SANs for all advertised external hostnames.

• D. Renew the listener certificate while retaining its current SAN entries.

Best answer: C

Explanation: TLS trust validation and hostname verification are separate checks. The client trusts the corporate root, receives the issuing certificate, and reports a hostname-specific error rather than an unknown issuer or expired certificate. After bootstrap, Kafka clients connect directly to broker addresses returned in metadata. The certificate presented on that connection therefore needs a SAN matching broker-0.kafka.apps.example.com and every other advertised external broker hostname.

Reissuing the listener certificate with the required SANs preserves certificate-chain validation and hostname verification while supporting the fixed external addresses.

Why each option fits or fails:

A. Adding CA certificates does not correct a SAN mismatch when the existing certificate path is already trusted.

B. Disabling hostname verification conceals the identity failure and violates the stated security requirement.

C. The certificate must identify each fixed hostname that clients use for bootstrap and subsequent broker connections.

D. Renewing the same SAN set changes certificate validity dates but leaves the broker hostname unmatched.

Question 13

Topic: Connectivity security and governance

A settlement client uses mTLS to reach a Kafka listener on TCP 9093. The following is the only ingress policy selecting the broker pods:

spec:
  podSelector:
    matchLabels:
      strimzi.io/name: orders-kafka
  policyTypes: [Ingress]
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kafka-access: "true"
      podSelector:
        matchLabels:
          role: kafka-client
    ports:
    - protocol: TCP
      port: 9093

Evidence:

• Namespace payments has kafka-access=true.
• The client pod lacks role=kafka-client.
• No egress policy selects the client pod.
• DNS resolves, but TCP 9093 times out before TLS negotiation.
• The same image, configuration and mTLS identity consume the same topic from a pod matching both selectors.

Which TWO conclusions are supported?

Options:

• A. The identity requires a namespace-specific Kafka ACL for payments.

• B. The namespace label alone satisfies the ingress peer, indicating a listener failure.

• C. The failure occurs before Kafka can evaluate the identity’s ACLs.

• D. The client namespace requires an egress allow rule for TCP 9093.

• E. The client pod must match role=kafka-client to satisfy the ingress peer.

Correct answers: C and E

Explanation: A NetworkPolicy peer containing both a namespaceSelector and a podSelector applies them together. The source namespace qualifies, but the source pod does not, so the broker ingress policy denies its traffic. Because no egress policy selects the client pod, egress is not isolated by the supplied evidence.

Kafka authorization occurs after TCP connectivity, TLS negotiation and authentication. A TCP timeout therefore cannot demonstrate an ACL denial. The successful test using the same identity against the same topic further confirms that changing Kafka authorization is unsupported. The decisive requirement is admitting the client pod through the OpenShift network-policy layer.

Why each option fits or fails:

A. Namespace-specific ACL confuses OpenShift network controls with Kafka authorization, which has not yet been reached.

B. Namespace label alone fails because selectors within the same ingress peer are combined, not treated as alternatives.

C. The TCP timeout precedes TLS, authentication and Kafka authorization.

D. Missing egress rule is unsupported because no egress NetworkPolicy selects and isolates the client pod.

E. The namespace and pod selectors in the same peer are both required.

Question 14

Topic: Integration services and application onboarding

A production Connect deployment must survive one worker loss and one broker loss. The Kafka cluster has three brokers, and broker-side topic auto-creation is disabled. Platform policy requires Connect internal topics to be pre-provisioned by platform administrators and does not permit worker principals to create topics. The worker principal currently has ACLs only for application topics.

The submitted Streams 3.2 resource contains:

spec:
  replicas: 3
  bootstrapServers: core-kafka-bootstrap:9093
  config:
    group.id: orders-connect
    config.storage.topic: orders-connect-config
    offset.storage.topic: orders-connect-offsets
    status.storage.topic: orders-connect-status

The three internal topics do not exist. Which TWO changes are required before approving the deployment?

Options:

• A. Keep the four worker settings in spec.config because every replica receives the same configuration.

• B. Replace distributed mode with standalone workers sharing one persistent volume for local offsets.

• C. Set .spec.groupId and the three .spec.*StorageTopic fields instead of their spec.config counterparts.

• D. Pre-create correctly partitioned, compacted RF3 internal topics and grant the principal topic and group ACLs.

• E. Give each replica a distinct group ID while retaining the same three internal topics.

Correct answers: C and D

Explanation: Distributed Kafka Connect workers coordinate through one shared group and store configuration, offsets, and status in Kafka internal topics. In the Streams 3.2 v1 API, their names belong in .spec.groupId, .spec.configStorageTopic, .spec.offsetStorageTopic, and .spec.statusStorageTopic.

Broker-side automatic topic creation being disabled does not by itself prevent Connect from explicitly creating internal topics through the Admin API. Here, platform policy denies topic creation to worker principals and requires pre-provisioning, so the internal topics must be created by an administrator. They should use compaction, suitable partition counts, and replication factor 3 to preserve state through one broker loss. The worker principal also needs Kafka authorization for the internal topics and group coordination. Worker replicas do not replicate this state through pod storage.

Standalone local offsets can support development, but they do not provide distributed assignment and recovery for this production requirement.

Why each option fits or fails:

A. Keeping the names under spec.config uses the older worker-property layout rather than the required v1 resource fields.

B. A shared local-offset volume does not safely replace Kafka-backed coordination and internal state for distributed workers.

C. The v1 KafkaConnect API defines the distributed worker identity and internal topic names as top-level specification fields.

D. The workers need durable replicated internal topics and authorization to access them and coordinate through the shared group.

E. Separate group IDs prevent the replicas from operating as one distributed Connect cluster and coordinating task assignments.

Question 15

Topic: Integration services and application onboarding

A Debezium PostgreSQL source connector stops capturing changes. The goal is to resume from its existing position without affecting other connectors or starting a new snapshot.

Current state:

Connect REST API: 200 OK
Worker pods: 3/3 Ready
Internal topics: all replicas in sync
Connector state: RUNNING
Task 0 state: FAILED
Task trace: DebeziumException: Failed to connect to database
Cause: PSQLException: FATAL: password authentication failed

The database password was recently rotated, but the connector still references the old credential. The source offset is readable, and the DBA confirms the required WAL remains available.

Which response best meets the goal?

Options:

• A. Update the database credential, verify access from Connect, and restart the failed task from its stored offset.

• B. Update the database credential, recreate the connector with a new snapshot, and deduplicate downstream records.

• C. Update the database credential, reset the source offset to latest, and restart the connector to skip the backlog.

• D. Roll all Connect worker pods, verify group rebalancing, and retain the unchanged connector configuration and offsets.

Best answer: A

Explanation: Kafka Connect reports worker, connector, and task health independently. Ready workers and healthy internal topics show that the Connect cluster remains available, but they do not prove that every task can process data. The task trace and stale credential localize this failure to PostgreSQL authentication.

Because the stored source offset is valid and the required WAL is retained, the credential should be corrected and database access verified from the worker context. Restarting the affected task then allows it to continue from its recovery position while minimizing impact on other connectors. Moving the task to another worker would preserve the authentication failure, while resetting offsets or taking a new snapshot would violate the recovery constraints.

Why each option fits or fails:

A. The dependency credential caused the failure, while the valid offset and retained WAL allow task-level recovery without a new snapshot.

B. New snapshot performs an unnecessary rebuild and risks duplicate downstream records despite valid recovery state.

C. Latest offset reset skips retained source changes and violates the requirement to avoid data loss.

D. Worker rollout merely reassigns the task; the unchanged database credential will fail on another healthy worker.

Question 16

Topic: Integration services and application onboarding

An architect is onboarding a new Avro topic with these requirements:

• Red Hat build of Apicurio Registry is the approved registry service.
• Clients must retain Confluent Avro serializers and their magic-byte plus 4-byte schema-ID framing.
• Testing confirms Apicurio’s Confluent-compatible endpoint supports the required registration and lookup operations.
• No historical schema IDs must be preserved.

Which integration should the architect select?

Options:

• A. Use Apicurio’s native endpoint with replacement Apicurio serializers.

• B. Use Apicurio’s native endpoint with the current Confluent serializers.

• C. Use Apicurio’s compatibility endpoint with the current Confluent serializers.

• D. Use Confluent Schema Registry with the current Confluent serializers.

Best answer: C

Explanation: Registry API compatibility and serializer wire format are separate integration boundaries. Storing Avro schemas does not make registry implementations or serializer protocols interchangeable. Here, clients must retain Confluent serializers and Confluent framing, while Apicurio Registry is the approved service. Its tested Confluent-compatible endpoint provides the registration and lookup contract those serializers expect. Because the topic is new, historical schema-ID preservation is not an additional migration concern.

The key is to match the serializer to a compatible API endpoint rather than selecting a registry solely because it stores the same schema format.

Why each option fits or fails:

A. Replacing the serializers violates the client and wire-format requirements, even though native Apicurio integration supports Avro.

B. Apicurio’s native endpoint does not expose the Confluent API contract expected by the unchanged serializers.

C. The compatibility endpoint preserves the required Confluent serializer API contract and wire framing while using the approved registry.

D. Confluent Schema Registry fits the existing serializers but does not satisfy the approved registry-service requirement.

Question 17

Topic: Production lifecycle resilience and incident response

An on-call team reviews a 10-minute window. Select the TWO alerting conclusions independently supported by the evidence.

Alert policy: Trigger a broker-health alert when under-replicated partitions remain above zero for 5 minutes.

Workload objectives:

• Payments: produce acknowledgment p99 <= 250 ms; errors < 1%.
• Inventory: oldest unprocessed record <= 60 seconds; no record-count lag objective.

Evidence:

• 24 under-replicated partitions for 8 minutes.
• Broker Produce p99 is 420 ms; errors are 2.2%.
• Broker Fetch latency and errors remain normal.
• Payment client p99 is 480 ms; errors are 2.4%.
• Inventory lag rose to 40,000 records, but oldest-record age is 18 seconds and consumption is 1.3 times ingress.

Options:

• A. Trigger broker health for the sustained ISR degradation.

• B. Trigger payment impact for the breached producer workload objectives.

• C. Trigger disk saturation as the confirmed broker fault.

• D. Trigger inventory impact for the increased record-count lag.

• E. Trigger fetch impact from the elevated Produce request latency.

Correct answers: A and B

Explanation: Broker-health alerts and workload-impact alerts answer different questions. The sustained under-replicated partitions meet the explicit broker-symptom threshold, indicating an ISR problem even if some workloads remain healthy. Payments show direct user impact because both client acknowledgment latency and request errors exceed their objectives.

Inventory’s record-count lag increase does not establish impact: its oldest record is within the 60-second objective, and consumption exceeds ingress, indicating recovery. Elevated Produce metrics do not demonstrate Fetch degradation, and no disk evidence confirms saturation. Effective alerting pairs infrastructure symptoms with workload-specific objectives instead of assuming every lag increase represents a broker failure.

Why each option fits or fails:

A. The under-replicated partitions persisted beyond the five-minute broker-health threshold.

B. Payment acknowledgment latency and error rate both exceed their stated objectives.

C. Disk saturation is unconfirmed because no disk utilization, latency, or queue evidence is provided.

D. Inventory lag count is not an objective breach because record age remains acceptable and the consumer is catching up.

E. Fetch impact is unsupported because Fetch latency and errors remain normal despite degraded Produce requests.

Question 18

Topic: Production lifecycle resilience and incident response

A three-broker Kafka cluster uses replication factor 3, min.insync.replicas=2, and producer acks=all. Ten minutes after a GitOps change reduced each broker’s CPU limit from 4 cores to 1 core:

• All broker pods remain Ready, and the active KRaft controller is unchanged.
• CPU throttled periods increased from 3% to 68%.
• Replica-fetch latency increased from 80 ms to 4.5 seconds.
• Many partition ISRs shrank to one replica.
• Producers report NOT_ENOUGH_REPLICAS.

Which hypothesis and read-only check should be prioritized?

Options:

• A. Prioritize PVC latency; correlate volume latency, log-flush time, and ISR transitions per broker.

• B. Prioritize CPU throttling; correlate throttled periods, replica-fetch latency, and ISR transitions per broker.

• C. Prioritize inter-broker packet loss; correlate retransmits, replica connection errors, and ISR transitions per broker.

• D. Prioritize controller instability; correlate quorum elections, heartbeat failures, and ISR transitions per broker.

Best answer: B

Explanation: Kafka rejects writes using acks=all when an affected partition’s ISR falls below min.insync.replicas. Pod readiness only shows that containers pass their probes; it does not prove that followers can replicate quickly enough. Here, CPU throttling rose immediately after the limit reduction, replica-fetch latency increased, and ISRs then contracted. Correlating these measurements per broker and timestamp is a safe, read-only way to confirm the causal sequence before changing the deployment. Stable controller leadership also makes metadata-quorum instability less likely.

The key distinction is between process availability and sufficient broker performance to maintain the required ISR.

Why each option fits or fails:

A. PVC latency could delay replication, but no storage change or disk evidence supports it as strongly as the measured CPU throttling.

B. The CPU limit change and aligned throttling, fetch latency, and ISR shrinkage directly support replica starvation as the write failure cause.

C. Packet loss could shrink ISRs, but connection errors or retransmits would be expected before prioritizing that hypothesis.

D. Controller instability is inconsistent with stable controller leadership and does not best explain the sharp replica-fetch latency increase.

Question 19

Topic: Production lifecycle resilience and incident response

An OpenShift 4.20 production cluster runs the Red Hat Streams 3.1 Cluster Operator and a KRaft cluster on Kafka 4.1. OLM approval is manual.

Goal: Reach Streams 3.2, Kafka 4.2, and its target metadata feature level while preserving runtime rollback during a seven-day soak.

Validated guidance states:

• The 3.2 operator supports both runtimes; the 3.1 operator does not support Kafka 4.2.
• Kafka 4.1 rollback remains possible while the current metadata feature level is retained.
• BOM-managed Kafka 4.0 clients are validated with both runtimes.

Which upgrade plan best follows the supported path?

Options:

• A. Approve Streams 3.2, verify Kafka 4.1 reconciliation, roll to Kafka 4.2, activate the target metadata level, then complete the soak.

• B. Approve Streams 3.2, verify Kafka 4.1 reconciliation, roll to Kafka 4.2, complete the soak, then retain current metadata for the clients.

• C. Roll to Kafka 4.2, approve Streams 3.2, verify reconciliation, complete the soak, then activate the target metadata level.

• D. Approve Streams 3.2, verify Kafka 4.1 reconciliation, roll to Kafka 4.2, complete the soak, then activate the target metadata level.

Best answer: D

Explanation: A supported Kafka upgrade separates three lifecycle steps: Cluster Operator compatibility, runtime replacement, and metadata feature activation. First approve the Streams 3.2 OLM upgrade and verify that the new operator reconciles the existing Kafka 4.1 cluster. Next update the Kafka runtime and allow the KRaft controllers and brokers to roll to 4.2. Retaining the current metadata feature level during the seven-day soak preserves the documented runtime rollback path. After workload, quorum, and reconciliation checks succeed, activate the target metadata level.

Kafka client versions do not need to match the broker version. The validated BOM-managed 4.0 clients therefore neither block the runtime upgrade nor justify delaying metadata activation after the soak.

Why each option fits or fails:

A. Activating metadata before the soak completes removes the required runtime rollback capability too early.

B. Retaining old metadata for 4.0 clients incorrectly assumes client and broker feature versions must match and leaves the upgrade incomplete.

C. Rolling Kafka first places the 4.2 runtime under an operator that does not support managing it.

D. Upgrading the compatible operator first and delaying metadata activation preserves supported reconciliation and runtime rollback throughout the soak.

Question 20

Topic: Production lifecycle resilience and incident response

A manufacturer runs Red Hat Streams for Apache Kafka in site A and has a separate OpenShift cluster in site B.

Objectives:

• Kafka event RPO: 5 minutes
• Business service RTO: 45 minutes
• Only one site may accept producer writes
• Consumers tolerate duplicate replay using idempotency keys

Evidence:

• Site A uses replication factor 3 across three racks.
• One-way MirrorMaker 2 testing shows up to 2 minutes of replication lag and emits checkpoints every minute.
• Client switching takes 20 minutes when dependencies are pre-staged.
• Provisioning dependencies after a disaster takes 90 minutes.
• Nightly backups require 6 hours to restore.

Which disaster recovery design best meets the objectives?

Options:

• A. Run a warm standby in B with one-way replication and backups, provision dependencies after declaration, and redirect clients when provisioning completes.

• B. Run a warm standby in B with one-way replication and backups, pre-stage dependencies, and drill single-writer failover with replay handling.

• C. Keep Kafka only in A with rack replication and backups, pre-stage dependencies in B, and restore Kafka before redirecting clients.

• D. Run a warm standby in B with bidirectional replication and backups, pre-stage dependencies, and accept writes at both sites during normal operation.

Best answer: B

Explanation: Rack-aware replication provides availability for broker or rack failures within site A, but it cannot recover service after losing the entire site. A warm Kafka cluster in site B, fed by measured asynchronous replication, keeps expected data loss within the 5-minute RPO. Pre-staged application dependencies allow the tested 20-minute client switch to remain within the 45-minute RTO. MirrorMaker 2 checkpoints assist consumer recovery but do not guarantee identical offsets, so failover drills must validate translated positions and bounded duplicate replay. Backups remain useful for corruption or longer-term recovery, but their 6-hour restore time cannot be the primary DR mechanism.

Why each option fits or fails:

A. Provisioning after declaration requires 90 minutes before client switching, exceeding the 45-minute RTO.

B. Measured replication lag meets the RPO, while pre-staging and drilled client switching keep recovery within the RTO.

C. Backup-based recovery cannot meet either objective because local rack replication does not survive site loss and restoration takes 6 hours.

D. Active-active writing violates the requirement for one authoritative producer site and creates possible divergent records during replication.

Question 21

Topic: Event-driven application development

A Java service uses the Kafka 4.2 producer with acks=all, delivery.timeout.ms=10000, request.timeout.ms=8000, and linger.ms=0. Its API must return a CompletionStage that reports broker acknowledgment or any delivery failure. It must not flush or wait for acknowledgment per request.

CompletionStage<RecordMetadata> publish(ProducerRecord<String, byte[]> r) {
    var outcome = new CompletableFuture<RecordMetadata>();
    producer.send(r, (metadata, error) -> {
        if (error != null) System.err.println(error.getMessage());
    });
    outcome.complete(null);
    return outcome;
}

void stop() {
    accepting.set(false);
    producer.close(Duration.ofSeconds(2));
}

An ingress gate rejects new publish invocations once accepting is false; before stop() closes the producer, it waits for already admitted invocations to finish calling send(). An accepted record is one whose send() returned normally before close begins.

Shutdown must reject new sends, preserve the full delivery window for accepted records, and finish within 15 seconds. Which revision best meets these requirements?

Options:

• A. Complete the stage from callback metadata or error, map synchronous send exceptions to it, and close with a 2-second timeout.

• B. Complete the stage after a per-record flush, retain callback errors in logs, and close with a 12-second timeout.

• C. Complete the stage after send returns, map synchronous send exceptions to it, and close with a 12-second timeout.

• D. Complete the stage from callback metadata or error, map synchronous send exceptions to it, and close with a 12-second timeout.

Best answer: D

Explanation: KafkaProducer.send() is asynchronous. A normal return generally means the record was accepted into the local producer buffer, not that a broker acknowledged it. The callback receives either acknowledged record metadata or the terminal asynchronous failure, including expiration under the delivery deadline. A synchronous exception thrown by send() may occur before the record is queued, so it must separately complete the returned stage exceptionally.

After new sends are rejected, close(Duration) waits for outstanding work only up to its timeout. A 12-second close timeout accommodates the configured 10-second delivery window while remaining within the 15-second shutdown limit. A 2-second timeout could force termination of records that still had valid delivery time remaining.

Why each option fits or fails:

A. A two-second close timeout can terminate accepted records before their configured delivery deadline expires.

B. Per-record flushing blocks request processing and still hides callback failures from the caller.

C. Immediate completion reports local acceptance as success before any broker acknowledgment or terminal delivery result exists.

D. This exposes every send outcome while allowing accepted records to use their 10-second delivery window during shutdown.

Question 22

Topic: Event-driven application development

A Quarkus 3.27 application uses Mutiny. The supplier runs synchronously when each subscription starts, and no other subscribers exist.

AtomicInteger calls = new AtomicInteger();

Uni<String> lookup = Uni.createFrom().completionStage(() -> {
    int n = calls.incrementAndGet();
    return n == 1
        ? CompletableFuture.completedFuture("v" + n)
        : CompletableFuture.<String>failedFuture(
              new IllegalStateException("second"));
});

CompletionStage<String> first = lookup
    .onFailure().recoverWithItem("fallback")
    .subscribeAsCompletionStage();

CompletionStage<String> second =
    lookup.subscribeAsCompletionStage();

After both stages settle, which TWO conclusions are supported?

Options:

• A. The supplier runs twice, so calls reaches 2.

• B. first yields v1, while second completes exceptionally.

• C. second remains dormant until its result is explicitly awaited.

• D. The supplier runs once because both stages share the same execution.

• E. Both stages succeed because recovery modifies the shared Uni.

Correct answers: A and B

Explanation: A Uni describes asynchronous work, while subscription initiates that work. The supplier overload of completionStage obtains a new stage for every subscription. Each subscribeAsCompletionStage() call subscribes immediately, so the supplier runs twice and increments calls from 0 to 2.

Mutiny operators produce new pipelines rather than modifying the original Uni. Recovery is attached only to the pipeline assigned to first. Its subscription receives v1, so recovery is unnecessary. The separate subscription assigned to second invokes the supplier again, receives the failed future, and completes exceptionally. Awaiting a returned stage observes its outcome; it is not what starts this subscription.

Why each option fits or fails:

A. Each subscribeAsCompletionStage call creates a separate subscription and invokes the supplier.

B. The first subscription succeeds, whereas the second receives the failed future without a recovery operator.

C. Deferred until await confuses observing a stage with subscribing through subscribeAsCompletionStage().

D. Shared execution is unsupported because the supplier-based factory creates a stage separately for each subscription.

E. Shared recovery is unsupported because the recovery operator applies only to its derived pipeline.

Question 23

Topic: Event-driven application development

A team is validating a Kafka Streams 4.2 application with TopologyTestDriver before deploying it to Red Hat Streams for Apache Kafka. The release gate must verify the exact records read sequentially from the eligible-scores test output topic after piping the inputs in the order shown.

KStream<String, Integer> scores = builder.stream(
    "raw-scores",
    Consumed.with(Serdes.String(), Serdes.Integer()));

scores
    .map((key, value) ->
        KeyValue.pair(key.toUpperCase(), value * 10))
    .filter((key, value) -> value >= 100)
    .mapValues(value -> value + 1)
    .to("eligible-scores",
        Produced.with(Serdes.String(), Serdes.Integer()));

Input records, in order:

• (alice, 9)
• (bob, 10)
• (cara, 11)

Which output should the release test expect?

Options:

• A. Two records: [(BOB, 101), (CARA, 111)]

• B. Two records: [(bob, 101), (cara, 111)]

• C. One record: [(CARA, 111)]

• D. Two records: [(BOB, 100), (CARA, 110)]

Best answer: A

Explanation: Kafka Streams applies these stateless transformations sequentially to each record. The first mapping uppercases the key and multiplies the value by 10. Alice becomes (ALICE, 90) and is removed. Bob becomes (BOB, 100); because the filter uses the inclusive >= comparison, this boundary record remains. Cara becomes (CARA, 110) and also remains. The final value transformation preserves each key while adding 1, producing (BOB, 101) and (CARA, 111) in input order.

The key details are processor order, the inclusive boundary, and the fact that mapValues changes only values.

Why each option fits or fails:

A. The mapping occurs before the inclusive filter, and the final value transformation increments each surviving mapped value.

B. Original lowercase keys ignores that the first transformation replaces each key with its uppercase form.

C. Excluded boundary record treats >= 100 as a strict greater-than comparison, incorrectly removing Bob.

D. Missing final increment leaves the surviving mapped values at 100 and 110 instead of applying value + 1.

Question 24

Topic: Event-driven application development

A Red Hat Streams for Apache Kafka application must send normalized data to one child processor and preserve the original record for auditing. No downstream processor changes the records.

Input record: key acct-7, value " pending ", timestamp 1710000000000, headers trace=t-19 and stage=raw.

@Override
public void process(Record<String, String> record) {
    Record<String, String> normalized = record
        .withValue(record.value().trim().toUpperCase(Locale.ROOT))
        .withTimestamp(record.timestamp() + 5_000);
    normalized.headers().remove("stage");
    normalized.headers().add("stage",
        "normalized".getBytes(StandardCharsets.UTF_8));
    context.forward(normalized, "normalized-sink");
    context.forward(record, "audit-sink");
}

Which interpretation and action are best supported?

Options:

• A. The normalized child gets transformed fields; audit also gets the transformed value and timestamp. Copy the complete input record for audit.

• B. The normalized child gets transformed fields; audit keeps raw fields and raw headers. No extra header-container copy is needed.

• C. The normalized child gets transformed fields; audit keeps the raw value but inherits the adjusted timestamp. Reset audit metadata before forwarding.

• D. The normalized child gets transformed fields; audit keeps raw fields but receives the changed stage header. Investigate header serialization at the audit sink.

Best answer: B

Explanation: Typed Processor API Record methods such as withValue and withTimestamp create new record objects, so the normalized child receives key acct-7, value PENDING, and timestamp 1710000005000. Record construction copies the header collection into a new RecordHeaders. Removing and adding stage on the normalized record therefore does not change the input record’s header collection. The normalized child receives headers trace=t-19 and stage=normalized, while the audit child receives the original value, timestamp, and headers trace=t-19 and stage=raw.

The copy is not deep with respect to existing header value byte arrays, but this code performs collection-level remove and add operations rather than mutating an existing byte array. No additional header-container copy is required here.

Why each option fits or fails:

A. Whole-record aliasing is incorrect because withValue and withTimestamp return new records rather than modifying the input value or timestamp.

B. Record construction used by withValue and withTimestamp copies the header collection into a new RecordHeaders, so removing and adding stage on the derived record does not change the input record’s headers.

C. Timestamp inheritance is incorrect because the explicit timestamp belongs only to the normalized record; forwarding does not transfer it to the input record.

D. Shared changed headers is incorrect because record construction copies the header collection; removing and adding entries on the derived record does not alter the input record’s collection.

Question 25

Topic: Event-driven application development

A topology must preserve each order key, trim the status value, and convert it to uppercase.

Current deterministic test:

try (TopologyTestDriver driver =
        new TopologyTestDriver(buildTopology(), props)) {
    TestInputTopic<String, String> input =
        driver.createInputTopic("status-in",
            new StringSerializer(), new StringSerializer());
    TestOutputTopic<String, String> output =
        driver.createOutputTopic("status-out",
            new StringDeserializer(), new StringDeserializer());

    input.pipeInput("order-17", " PAID ");
    assertEquals(KeyValue.pair("order-17", "PAID"),
        output.readKeyValue());
}

The test passes and produces exactly one record. UAT instead receives ("order-17", "paid") after sending the lowercase value "paid". An isolated String serializer/deserializer round trip also preserves "paid" exactly.

Which additional fixture most directly provides deterministic evidence of a missing case-normalization transformation?

Options:

• A. Pipe ("order-17", "PAID"); expect ("order-17", "PAID").

• B. Pipe ("order-é", " PAID "); expect ("order-é", "PAID").

• C. Pipe ("order-17", " PAID "); expect ("order-17", "PAID").

• D. Pipe ("order-17", " paid "); expect ("order-17", "PAID").

Best answer: D

Explanation: Deterministic topology tests need fixtures that force each required transformation. The passing uppercase fixture proves trimming for that sample, but it cannot reveal whether uppercase conversion exists because the input is already uppercase. A lowercase, padded value must pass through both normalization rules, while readKeyValue() verifies key preservation and the exact transformed value.

If the topology emits "paid", the driver test fails without broker, deployment, or timing variables. The successful serializer round trip also makes a serialization defect less likely. This evidence establishes the behavior of the topology built by the test, but it does not prove that UAT deployed the same application artifact.

Why each option fits or fails:

A. The normalized input requires neither trimming nor case conversion, so a missing transformation remains hidden.

B. The non-ASCII key fixture examines key serialization and preservation, while its value is already uppercase.

C. The uppercase padded fixture repeats the existing trimming check without exercising case conversion.

D. The lowercase padded fixture exercises both required transformations while verifying the preserved key and exact output value.

Continue in the web app

Use IT Mastery for interactive Kafka Platform Architecture and Operations practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Kafka Platform Architecture and Operations on Web

Recall the key distinctions · Technical references · Report a question issue