September 6, 2026 · 9 min read
TL;DR: Scope questions are usually requirements questions. The scope baseline is the scope statement, the WBS, and the WBS dictionary approved together, and it is the thing you consult before you agree or refuse. When a stakeholder insists a feature was promised, the keyed answer is almost never yes or no; it is to check what was actually agreed and come back with the answer.
Ask a candidate what scope questions test and most will say scope creep. Then they meet a stakeholder in a hospital renovation scenario who is certain the equipment features they expected were part of the deal, four options that all sound like something a reasonable project manager might say, and no mention of creep anywhere. The exam is testing something narrower and more useful: whether you know where the agreed scope is written down, and whether you look before you answer.
The scope baseline is three approved artifacts, not one: the project scope statement, the work breakdown structure, and the WBS dictionary. Approved together, changed only through change control.
That last property is what makes it useful in a scenario. A baseline is a fixed reference, so it can settle an argument about what was agreed. The three pieces do different jobs, and questions exploit the difference:
| Artifact | What it holds | The question it answers |
|---|---|---|
| Project scope statement | The project, its deliverables, and its exclusions | What are the boundaries of this project? |
| Work breakdown structure | The deliverables decomposed into work packages | What are all the pieces of work? |
| WBS dictionary | Per package: full description, who owns it, acceptance criteria, resources | What exactly am I building, and when is it done? |
| Requirements traceability matrix | Each requirement linked to its origin and its deliverable | Where did this requirement come from? |
The exclusions in the scope statement matter as much as the inclusions. A boundary is only a boundary if it says what falls outside it, and a scenario that mentions something was explicitly excluded has usually just handed you the answer.
Common trap: reaching for the scope statement when a team member asks what they are meant to be working on. In this bank, a landscape architect on a botanical-garden redevelopment asks exactly that, and the keyed answer is the WBS dictionary, because the question lists its standard contents: a detailed description of the work, who it is assigned to, the acceptance criteria, and the resource requirements. The scope statement is offered as a distractor and describes the project, not the work package. The traceability matrix is offered too, and it tells you where a requirement came from, not how to build it.
Check the requirements documentation, the traceability matrix, and the scope baseline before you respond. Two very different situations produce identical complaints, and the project documents are the only thing that tells them apart.
Here is the scenario, and it repays reading slowly. During a hospital wing renovation, a key stakeholder tells the project manager that advanced equipment features they expected do not appear in the preliminary designs. Four options follow. Assure the stakeholder their expectations will be built into the design. Have the team add the features to the design and the scope. Arrange a presentation on current status and upcoming milestones. Or review the project plan and update the stakeholder.
The keyed answer is the last one, and the reasoning generalises well beyond scope. Either the features were agreed and have been omitted, which is a defect to fix, or they were never agreed and the expectation was formed somewhere else, which is a conversation to have and possibly a change request to raise. Those need opposite responses. Assuring the stakeholder commits the project to work that may never have been in scope. Adding the features to the design skips change control. A status presentation answers a question nobody asked. Only the requirements documentation, the traceability matrix, and the scope baseline can establish which world you are in, and this bank explains why each of the other three fails rather than simply marking them wrong.
That is the shape of most scope questions here: not a trick, but a test of whether you reach for evidence before you reach for a decision.
No, and the gap between those two things is where a family of questions lives. Internal testing establishes that the deliverable works. Acceptance establishes that it is the right deliverable, and only the customer can say so.
Worth noting if you are studying from older material: PMBOK 8 folded inspection into Validate Scope, so there is no separate Control Quality process to contrast it with any more. The distinction that survives is not between two process names, it is between two questions. Does it work, and is it what you asked for?
A payment service in this bank makes the point. It passes internal tests, but the customer is abroad and unavailable to validate it. The tempting option is to deploy to production since it meets the technical requirements and passed internal quality checks, then get validation afterwards. The keyed answer is to present it to a customer representative or proxy who can give preliminary validation until the customer is ready. Passing your own tests answers your own question, not the customer's, and shipping on the strength of it converts an open acceptance question into a deployed one.
Common trap: answering a complaint about deliverables by adding features. When a sponsor says deliverables are not matching requirements and expectations, this bank keys performing scope control to verify the deliverables meet the project objectives, and names the tempting alternative for what it is: making sure the next deliverables have enough features to meet expectations is gold plating done under pressure. Unrequested work carries cost and risk while earning no acceptance, which is exactly why the bank flags that distractor by name.
What is the scope baseline made of? The project scope statement, the WBS, and the WBS dictionary, approved together and changed only through change control.
What is the difference between the scope statement and the WBS dictionary? The scope statement describes the project, its deliverables, and its exclusions. The WBS dictionary describes one work package: the work itself, its owner, its acceptance criteria, and the resources it needs.
A stakeholder says a feature they expected is missing. What should you do first? Check the requirements documentation, the traceability matrix, and the scope baseline. Both agreeing and refusing are answers given before you know whether the item was ever in scope.
Is scope creep a big part of the exam? Less than candidates expect. Of the 104 scope-tagged questions in this bank, 54 turn on requirements and only 6 mention scope creep at all.
The 104 scope questions in PMP Practice sit inside a bank of 2,141 re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and each wrong answer carries the reasoning that makes it wrong, explained rather than just marked. Start the free 20-question sample with no card and no signup.
Related: Change requests: who approves what · Quality: prevention, inspection, and cost of quality · Process domain study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
What is the scope baseline made of?
Three artifacts approved together: the project scope statement, the work breakdown structure, and the WBS dictionary. Because it is a baseline, it changes only through approved change control, which is what makes it the reference point for deciding whether a requested item was ever in scope.
What is the difference between the scope statement and the WBS dictionary?
The scope statement describes the project, its deliverables, and its exclusions. The WBS dictionary is the detail behind each box of the WBS: a full description of the work, who is responsible, the acceptance criteria, and the resources required. A team member asking exactly what they are meant to build needs the dictionary, not the statement.
A stakeholder says a feature they expected is missing. What should you do first?
Check the requirements documentation, the traceability matrix, and the scope baseline before responding. There are two possible explanations, an agreed item that was omitted or an expectation that was never agreed, and only the project documents distinguish them. Promising the feature and refusing it are both answers given before the facts are in.
Is scope creep a big part of the exam?
Less than candidates expect. In this bank of 2,141 questions, 54 of the 104 scope-tagged records turn on requirements, 27 on the WBS, and 13 on traceability, while only 6 mention scope creep and 2 mention gold plating. Scope questions mostly test whether you can establish what was agreed, not whether you can name the failure mode.