A company runs a MongoDB-compatible workload on Amazon DocumentDB. They notice that many read requests are returning stale data even though reads are directed to the primary instance. What is the MOST likely cause?
If the read preference is set to 'secondaryPreferred' or similar, reads may go to secondary replicas which are eventually consistent.
Why this answer
The most likely cause of stale reads from the primary instance is that the application is using a read preference that allows secondary reads. In Amazon DocumentDB, even if the connection string specifies the primary endpoint, the MongoDB driver's read preference setting (e.g., `secondaryPreferred` or `nearest`) can cause reads to be served from replica instances, which may have replication lag and thus return stale data. The default read preference is `primary`, but if the application explicitly sets a different preference, reads can be directed to secondaries without the developer realizing it.
Exam trap
The trap here is that candidates assume connecting to the primary endpoint always guarantees primary reads, but the MongoDB driver's read preference setting can silently redirect reads to secondaries, causing stale data even when the endpoint is correct.
How to eliminate wrong answers
Option A is wrong because session pinning to a secondary replica does not occur when the application explicitly requests the primary; DocumentDB's replica set driver handles failover and read preference, not arbitrary pinning. Option C is wrong because high CPU utilization on the primary delays writes but does not cause stale reads on the primary itself; stale reads occur only when reading from a secondary with replication lag. Option D is wrong because DocumentDB uses a single, strongly consistent storage volume for all instances in the cluster; there is no 'eventually consistent configuration' for primary reads, and primary reads are always strongly consistent.