This question tests whether you treat delivery guarantees as end-to-end properties of a pipeline — producer, broker, consumer, and the consumer's side effects — rather than a switch on the broker. That framing is the answer.
At-least-once is what you get the moment you add retries. The producer sends a message; the broker stores it and replies; if the ack is lost on the wire, the producer retries and the broker stores it twice. The consumer reads it, processes it, commits its offset; if it crashes between processing and commit, it reads and processes it again. Duplicates are a normal, expected outcome; the contract is "you will see every message at least once", and correctness comes from the consumer being idempotent — same input, same output, no double side effect.
Exactly-once is not a stronger delivery mode. A machine cannot distinguish "my message never arrived" from "my message arrived but the ack was lost", so pure delivery can never guarantee exactly one copy. Real exactly-once is an engineering construction that combines three mechanisms: idempotent producers (Kafka's producer ID + per-partition sequence numbers let the broker deduplicate retries), transactional coordination so the broker commit and the consumer's offset commit are atomic, and — the critical part — making the side effect itself atomic with consumption. Write to an outbox table in the same transaction as your business data, then publish from the outbox; the consumer dedupes by event ID. A payment is exactly-once only when the charge is guarded by an idempotency key the storage layer enforces.
Walk the numbers: with at-least-once, an intermittent network blip at 1% loss on a pipeline moving 10k msgs/s produces ~100 duplicate deliveries per second that your consumers must absorb. With idempotency keys and dedupe, those become no-ops — but you paid latency and storage for the dedupe state.
The tradeoff to name: exactly-once costs throughput, coordination, and state — it turns delivery into a distributed transaction. Most systems don't need it: retries plus idempotent consumers get you "effectively once" at a fraction of the cost. Say it explicitly: "at-least-once with idempotent processing is the default; exactly-once is what you buy when duplicate side effects are genuinely unacceptable — payments, not notifications."