These two are consistently confused — and CBAP exams test them precisely because of that confusion.
Verify requirements (Task 5.2): Are the requirements written correctly? Does each one meet quality standards — is it clear, unambiguous, testable, consistent? This is an internal quality check. You're not asking the stakeholder whether the requirement is right. You're checking whether the artifact itself is well-formed.
Validate requirements (Task 5.3): Do the requirements solve the right problem? Will the solution, if built to spec, actually achieve the desired business outcome? This requires stakeholder involvement — you're checking against the real-world need, not against documentation standards.
The mnemonic: verify = build the thing right; validate = build the right thing.
In practice: a requirements set can be perfectly verified (every requirement is testable, unambiguous, and complete) and still fail validation (because the solution they describe doesn't actually address the business need). This happens more often than you'd think — especially when the BA focused on documenting what stakeholders asked for rather than probing whether those requests actually solve the underlying problem.
I've seen this pattern: stakeholder asks for feature X, BA writes crystal-clear requirements for X, the team builds X — and the business problem remains because X addressed a symptom, not the cause. Validation would have caught this.
Exam tip: CBAP scenario questions often present requirements that are technically clear but solve the wrong problem. Identifying that as a validation failure (not verification) is the correct answer.