Confluent CCDAK Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for Confluent Certified Developer for Apache Kafka (CCDAK) topics such as partitions, ordering, producers, consumers, offsets, retries, idempotence, transactions, schemas, and runtime troubleshooting. The prompts emphasize client behavior and delivery semantics rather than Kafka vocabulary alone.

Where these questions fit in the CCDAK guide

The sample set below is part of the Confluent CCDAK guide path:

• Confluent certification hub
• CCDAK exam guide
• CCDAK cheat sheet
• CCDAK study plan
• CCDAK FAQ
• CCDAK resources
• CCDAK glossary

CCDAK Kafka developer sample questions

Work through each prompt before opening the explanation. CCDAK questions usually reward answers that preserve partition ordering, offset correctness, schema compatibility, and delivery guarantees before tuning for convenience.

Question 1

Topic: Preserving order for a customer stream

An application publishes account events and requires events for the same customer to be processed in order. Events for different customers can process in parallel. What producer design best fits?

• A. Send every event without a key so Kafka randomly balances all records.
• B. Use a stable customer identifier as the record key so events for the same customer go to the same partition.
• C. Create one topic per event because topics guarantee global ordering across all partitions.
• D. Increase the consumer group size until ordering is guaranteed across all customers.

Best answer: B

Explanation: Kafka ordering is partition-scoped. A stable key routes related records to the same partition so per-customer order can be preserved while other customers still parallelize.

Why the other choices are weaker:

• A spreads related records and can break per-customer order.
• C misstates the ordering model and creates unmanageable topic sprawl.
• D affects consumption parallelism, not producer partitioning guarantees.

What this tests: keys, partitions, ordering, parallelism, and producer design.

Related topics: Partitioning; Keys; Ordering; Producer

Question 2

Topic: Retry safety for producers

A producer sees intermittent broker timeouts. The team wants retries but needs to reduce duplicate writes caused by retry ambiguity. Which setting or design direction is strongest?

• A. Disable acknowledgments so the producer never waits for broker confirmation.
• B. Set retries to zero because all retry behavior is unsafe.
• C. Enable idempotent producer behavior and keep retry-related settings compatible with safe delivery semantics.
• D. Use a new random key for every retry attempt.

Best answer: C

Explanation: Idempotent producer behavior is designed to reduce duplicates across retries when configured correctly. The exam usually rewards preserving semantics before improving throughput.

Why the other choices are weaker:

• A weakens durability and confirmation.
• B avoids duplicates by sacrificing resilience to transient failures.
• D breaks partitioning consistency and ordering assumptions.

What this tests: retries, idempotence, acknowledgments, duplicate risk, and producer reliability.

Related topics: Idempotence; Retries; Acks; Reliability

Question 3

Topic: Offset commit timing

A consumer processes records and writes results to an external database. The team wants to avoid marking records complete before the database write succeeds. Which offset strategy is strongest?

• A. Commit offsets before processing begins so lag stays low.
• B. Never commit offsets because Kafka automatically knows which records reached the database.
• C. Reset offsets to earliest after every successful poll.
• D. Commit offsets only after processing and the external write have succeeded.

Best answer: D

Explanation: Committing after successful processing prevents the consumer from advancing past work that has not safely completed. This is a common offset-versus-side-effect trap.

Why the other choices are weaker:

• A risks data loss if processing fails after the commit.
• B ignores that Kafka does not track external side effects automatically.
• C causes repeated reprocessing and does not express completion state correctly.

What this tests: consumer offsets, commits, side effects, at-least-once behavior, and processing safety.

Related topics: Offsets; Consumers; Commits; Side effects

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by Confluent or any certification body.