Microservices MCQs multiple-choice questions with answers & explanations

Answer: C (It goes half-open and lets a few trial calls through)

After the wait duration the breaker moves to half-open and permits a limited number of trial calls. If they succeed it closes; if they fail it opens again. Jumping straight to closed would risk flooding a service that is still recovering, and breakers recover automatically rather than needing a manual reset.

try it in the quiz →

Answer: A (Records are ordered within each partition only)

Kafka orders records only within a partition; there is no total order across the partitions of a topic. To keep all events for one entity in order, give them the same key so they hash to the same partition.

try it in the quiz →

Answer: D (Six instances get one partition each; two sit idle)

Within a consumer group, each partition is assigned to exactly one consumer, so the partition count caps parallelism and extra consumers stay idle. Kafka never adds partitions on its own, and receiving every record is what happens across separate groups, not within one.

try it in the quiz →

Answer: B (A transactional outbox read by a message relay)

This is the dual-write problem. With a transactional outbox, the event is written to an outbox table in the same local transaction as the order, and a relay (polling or CDC) publishes it afterwards. Publishing first just moves the failure window, and in-request retries or in-memory buffers lose the event if the process crashes.

try it in the quiz →

Answer: C (Participants block, holding locks, if the coordinator fails)

2PC does provide atomicity, but a participant that has voted yes must hold its locks until it learns the outcome, so a coordinator failure can leave it blocked. It also needs every participant available to commit, and many NoSQL stores and brokers do not support XA. That is why sagas are the usual alternative.

try it in the quiz →

Answer: A (A compensating step releases the reserved stock)

Each saga step commits its own local transaction, so there is nothing left for a database to roll back. The saga runs compensating transactions to semantically undo the completed steps. Voting belongs to two-phase commit, and retrying a declined payment forever would never finish.

try it in the quiz →

Answer: D (POST)

HTTP semantics define GET, PUT and DELETE as idempotent: repeating them has the same effect as sending them once. POST is not, so a retried POST can create duplicates unless the server supports something like an idempotency key.

try it in the quiz →

Answer: B (The broker redelivers it, so the handler runs twice)

Without an acknowledgement, the broker assumes the message was not processed and delivers it again, so the same message is handled twice. That is why consumers must be idempotent. The broker knows nothing about your database, and messages normally reach a DLQ only after repeated failures.

try it in the quiz →

Answer: C (Kubernetes restarts every pod, making the outage worse)

A failing liveness probe makes the kubelet restart the container, so a dependency outage restarts every pod at once, and they may keep crash-looping. Leaving the Service endpoints is what a failing readiness probe does. Liveness should check only the process itself.

try it in the quiz →

Answer: A (So clients that failed together do not retry in sync)

Without jitter, every client that failed at the same moment retries at the same moments, sending synchronized waves of load at a recovering service. Randomizing each wait spreads retries out. Doubling the wait is what exponential backoff itself does, and preventing duplicates is the job of idempotency, not jitter.

try it in the quiz →

Answer: C (27)

Retries multiply across layers: 3 client attempts × 3 attempts from A × 3 attempts from B = 27 calls to C. This retry amplification is why you retry at one layer only, cap attempts, and use retry budgets or circuit breakers.

try it in the quiz →

Answer: B (Consistency versus availability)

During a partition, a system must either refuse some requests to stay consistent (CP) or keep answering with possibly stale data (AP). Partition tolerance is not optional in a real network, which is why "pick two of three" is misleading. Latency versus consistency is the PACELC trade-off when there is no partition.

try it in the quiz →

Answer: D (Latency versus consistency)

PACELC says: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. Even without failures, waiting for replicas to confirm each write improves consistency but adds latency. Availability versus consistency is the trade-off during a partition.

try it in the quiz →

Answer: A (Keep a local copy updated from customer events)

A service must not read another service's database, even read-only, because that couples it to the owner's internal schema. Replicating just the needed fields from the owner's events (or calling its API) keeps ownership clear, at the cost of eventual consistency.

try it in the quiz →

Answer: D (Stops sending Service traffic to it)

A failing readiness probe removes the pod from the endpoints of matching Services, so it stops receiving traffic, but the container keeps running. Restarting the container is the response to a failing liveness probe.

try it in the quiz →

Answer: B (Move features to new services one slice at a time)

A facade in front of the monolith routes requests, and capabilities move to new services one slice at a time until the monolith can be retired. Each step is small and reversible, unlike a big-bang rewrite.

try it in the quiz →

Answer: C (Reads may briefly lag behind the latest writes)

Because the view is updated from events after the write commits, it is eventually consistent: a query right after a change may see old data. Read models can usually be rebuilt by replaying events, and the point of CQRS is that commands and queries use separate models.

try it in the quiz →

Answer: B (The card may be charged twice by the external API)

Kafka transactions commit the output records and the consumer offset atomically, and read_committed consumers never see aborted output, so the result topic does not end up with duplicates. The external API call is outside the transaction, though, so it can repeat after a crash; it needs an idempotency key.

try it in the quiz →

Answer: A (The bucket capacity)

A full bucket holds capacity tokens, so a client can spend them all in one burst; after that, requests are limited to the refill rate. The refill rate sets the long-run average, not the burst size.

try it in the quiz →

Answer: D (Return the stored result of the first attempt)

The point of an idempotency key is that repeats of the same logical operation return the original outcome without redoing the work. The server stores the result against the key and replays it; it rejects the key only if it is reused with a different request body.

try it in the quiz →

Answer: C (The client is also verified by its certificate)

In ordinary TLS only the server proves its identity. With mTLS both sides present certificates, so each service knows which service it is talking to. It proves service identity, not end-user permissions, so tokens and authorization checks are still needed.

try it in the quiz →

Answer: B (Through the DNS name of a Kubernetes Service)

A Kubernetes Service has a stable DNS name and virtual IP, and traffic is routed to its ready pods: server-side discovery built into the platform. Client-side registries like Eureka work but are usually unnecessary on Kubernetes, and pod IPs change too often to hard-code.

try it in the quiz →