Common distractors

A distractor is a wrong option written to look right. Good exam questions have good distractors: options that would work in a slightly different situation, that solve part of the problem, or that use the right product in the wrong way. When Hana reviewed her diagnostic, Elena asked her to sort her 17 wrong answers by why she had chosen them. Almost none were cases where Hana had no idea. Most were cases where she picked an option that was nearly right. Learning the common shapes of distractors turns many of those near misses into marks.

This lesson names ten distractor patterns that appear on Microsoft role-based exams and gives a DP-800 example of each. It ends with a short routine for testing options against them.

1. The partial solution

The most common distractor meets one requirement and ignores another. A question asks for a search that finds paraphrased reviews and exact product codes; vector search alone finds the first but can miss the second. A question asks for embeddings refreshed within a minute without slowing inserts; a trigger meets the minute but slows inserts. The defence is to list the requirements before reading the options, then cross each one off for every option. If any requirement is left uncrossed, the option is wrong, however attractive the rest of it is.

2. The right feature on the wrong platform

DP-800 covers four platforms whose feature sets and release statuses differ. An option can name a feature that is exactly right on Azure SQL Database but needs a preview switch, or a different update policy, somewhere else. Vector indexes and VECTOR_SEARCH are generally available in Azure SQL Database but a preview in SQL Server 2025. sp_invoke_external_rest_endpoint is on by default in Azure SQL Database and Fabric but must be enabled in SQL Server 2025 and Managed Instance. Memory-optimized tables in Azure SQL Database need the Premium or Business Critical tier. When a scenario names its platform, check every option against that platform.

3. Works, but breaks least privilege

Security distractors often work perfectly and grant too much. Adding the app's identity to db_owner makes every permission error disappear. Granting SELECT on the base table lets the API read member data. Connecting an MCP server with an administrator login gives Copilot full context. Each of these meets the functional requirement and fails the unstated one: the exam assumes least privilege unless told otherwise. When a question asks for permissions, prefer the narrowest grant that works, such as EXECUTE on one procedure, and prefer views or procedures with ownership chaining over table grants.

4. Works, but adds load or cost

Some options meet every functional requirement but do so expensively. Polling a table every second for changes works but loads the database. Recomputing every embedding nightly keeps them fresh enough but calls the model millions of times for a few hundred changes. Using the largest embedding model gives good results at higher storage and search cost. When a question includes words like 'minimize', 'reduce cost' or 'without affecting', those words are the requirement that eliminates the expensive options.

5. The outdated method

Older methods often still work, which makes them good distractors. Storing JSON in nvarchar with an ISJSON check works, but the native json type is the modern answer on platforms that have it. Storing an API key in a credential with a SECRET works, but a managed identity is preferred. Using TOP_N inside VECTOR_SEARCH is the older syntax; current indexes need SELECT TOP (n) WITH APPROXIMATE and return an error with TOP_N. Calling a model with a CLR assembly or an external script is far more complex than sp_invoke_external_rest_endpoint or AI_GENERATE_EMBEDDINGS. If two options both work, the exam usually wants the current, simpler one.

6. The near-synonym

Some distractors swap a feature for its close relative. JSON_QUERY for JSON_VALUE. RANK for DENSE_RANK. Change tracking for change data capture. Dynamic Data Masking for Always Encrypted. Temporal for ledger. Filter predicate for block predicate. Each pair is related enough that a rushed reader sees the word and moves on. Lesson 4 to lesson 7 listed the pairs that matter; the defence is to know, for each pair, the one sentence that separates them.

7. Too much

Another pattern offers an option that does everything asked and much more, such as moving the whole database to a new platform when one setting would do, or building a custom service when a built-in feature exists. Exam questions usually reward the smallest change that meets the requirements. If the goal is to let store managers see only their store's transactions, a Row-Level Security policy is the answer; splitting the table into 23 store tables is not.

8. The order problem

In ordering questions, the distractor is the right steps in the wrong order. Creating the external model before the credential fails. Deploying to production before running integration tests defeats the pipeline. Creating a vector index on an empty table fails because current indexes need at least 100 rows. Granting permission to a user before creating it fails. The defence, as in lesson 2, is to ask what each step depends on.

9. The misread scope

Some wrong options are right for a different scope than the one asked. A database scoped configuration versus a server setting. A schema grant versus an object grant. A server-level audit versus a database-level audit. A DAB global cache setting versus an entity setting. When the question says 'only for the reporting database' or 'only the Offer entity', the scope is the requirement. An option that changes more than the stated scope is usually wrong even though it achieves the effect.

10. The absolute word

Words such as always, never, all and only are signs to slow down. 'Vector search always finds the nearest results' is false for approximate search. 'Dynamic Data Masking prevents all users from seeing values' is false for users with UNMASK. 'Change event streaming is generally available on all platforms' is false. Statements in technical exams are rarely absolute, so an option with an absolute claim is often, though not always, a distractor. When an absolute statement is true, it is usually a definition: 'A json column always stores valid JSON' is true because the type validates its values.

A routine for testing options

Elena gives Hana a routine for the questions she is not immediately sure of. First, write or think the requirements as a short list, including any cost, privilege or platform words. Second, for each option, check the requirements one by one and stop at the first failure. Third, if two options survive, check them against the ten patterns: is one a partial solution, an outdated method, a near-synonym, too much, or the wrong scope? Fourth, if two still survive, choose the one that is simpler and more current, and move on. The routine takes about a minute, and it is meant for perhaps one question in five; most questions should be answered faster.

Distractors in case studies

Case studies add two distractor patterns of their own. The first is the requirement placed far away: an option meets everything in the question and the nearby requirements, but breaks one stated in another tab, such as a technical constraint that the company must stay on SQL Server 2025 on its own hardware, or a requirement to minimize additional services. Hana met exactly this in lesson 10. The defence is to keep a short list of every requirement on the whiteboard, one or two words each, and to glance at the whole list before confirming each answer.

The second is the true but irrelevant option: a statement about the company that is correct and useful but does not answer the question asked. If the question asks how to secure the API, an option describing how to speed up the search might be accurate for the company and still be wrong for the question. Reading the last sentence of each question twice, and asking 'does this option answer that sentence?', removes most of these.

Building your own distractor list

The patterns in this lesson are general. Each candidate also has personal patterns, and these matter more. Hana's error log from the diagnostic showed that she tends to pick the newest feature even when the scenario rules it out, for example choosing change event streaming because it is modern when the requirement was a lightweight sync that change tracking does better. She also tends to under-read ordering questions, getting the steps right but placing the permission grant before the user exists. Naming these habits is half of fixing them.

Elena asks Hana to keep a short list at the top of her error log: her three most frequent personal patterns, updated after each practice set. Before each simulation she reads the list. In the exam she cannot take it in, but she can remember three items, and when she is unsure of an answer she checks it against them. 'Am I choosing this because it is new?' and 'Have I placed every step after the thing it depends on?' are questions she now asks automatically.

The list changes as she improves. By the third simulation, the 'newest feature' habit has gone from her errors, and a new one has appeared: misreading 'minimize' as 'maximize' late in the session when tired. That leads to a practical change in the pacing plan, with a ten-second pause and a slow breath at each checkpoint, so that fatigue does not quietly become a source of errors in the last half hour.

A quick self-test

To check that the patterns have stuck, Elena gives Hana ten options from old practice questions with the questions hidden, and asks her only to name the pattern each might represent: partial, platform, privilege, cost, outdated, near-synonym, too much, order, scope or absolute. It takes five minutes, and it trains the reflex that matters on the day, which is to look at an option and ask what could be wrong with it before deciding that it is right. Hana names nine of ten correctly on the first try; the tenth was a scope trap she labelled as too much, which Elena points out is a close cousin and an understandable slip.