Domain 2 - Scope unconfirmed (placeholder): verifying facts, versions, and preconditions
This domain's official title is also unconfirmed. What can be taught safely here is the verification discipline that any AB-410 candidate needs, because the most expensive mistakes in a technical exam come from confident recall of an outdated or misattributed fact.
Every factual claim you intend to rely on should carry three tags: a source (primary vendor documentation, not a forum post), a version (the release the claim applies to), and a status (generally available, preview, deprecated, or retired). A fact missing any of the three is a hypothesis, not knowledge. When a question hinges on whether a capability is available, the status tag decides the answer more often than the feature description does.
Traps to expect. Deprecation versus removal - a capability may be deprecated but still functional, and questions exploit that gap. Edition and licensing gates - a feature that exists in the product but not in the tier the stem describes. Precondition mismatch - two options are both technically sound, but only one has its prerequisites satisfied by the scenario. Preview-stage behaviour, where limits and defaults differ from the generally available version.
Rule of thumb. When two options survive your first pass, stop comparing the options to each other and compare each one to the stem's stated constraints. Score each option on: does the scenario satisfy its preconditions, is it in scope for the described edition, and is it current in the target version? The option that survives all three wins; if neither survives, re-read the stem - you have missed a constraint, not a fact.
Log unresolved claims with the tag that is missing so a later review can close them quickly. Precision about what you do not know is itself a scoring skill.