September 7, 2026 · 7 min read
TL;DR: The word baseline appears in 53 of the bank's answer options: 17 keyed, 36 wrong. The keyed ones either check a deliverable against a baseline or raise a change request because reality has moved away from one. The wrong ones adjust a baseline that has not moved, or raise a change request about a problem that is not a baseline problem at all.
A baseline is an approved reference point, and the exam treats it with something close to reverence. That is why so many distractors involve touching one. The candidate reasoning is "something changed, so update the baseline," and it is backwards.
Twice, in two different modes.
Mode one: check against it. A designer hands over a finished document to submit to the customer, and the project manager, skimming it, thinks it is shorter than experience would suggest. Four options: call the team member in for a meeting, check the deliverable against the scope baseline, perform quality control, or call the functional manager. Keyed is the scope baseline.
The reasoning is careful. The document is only shorter than expected, and that expectation is the project manager's own judgment rather than a documented requirement, so nothing yet establishes anything is missing. The scope baseline, meaning the project scope statement, the WBS and the WBS dictionary, is what the document was actually required to contain. Checking it either confirms a real gap or shows the expectation was mistaken, and either way it protects the working relationship with the designer.
Mode two: change it, because it no longer describes reality. Resistant stakeholders confirm their doubt is about the durability of a regulatory approval timeline, and the project manager finds the doubt is well founded: the timeline the project has been planning against is optimistic by several months. Keyed is raising a change request to revise the schedule baseline. Once a concern is confirmed rather than merely heard, it stops being information to gather and becomes a baseline that no longer reflects reality, and that only gets fixed through change control.
The distractors there are all forms of not doing it. Reassure the stakeholders the original timeline will hold, which commits to a date the project manager now knows is unrealistic. Ask regulatory affairs to expedite without adjusting the schedule. Note the concern in the stakeholder register and revisit at the next review.
No. Only changes that alter an approved baseline need formal evaluation, and the item testing this is the sharpest in the set.
Three suggestions arrive in the same week on a facility extension: a supplier offers a two-day-faster delivery slot at no extra cost, an electrician proposes swapping a specified fixture for a functionally identical one at the same price, and the construction team proposes rerouting a power connection.
Keyed: sort the three by whether they alter an approved baseline, and route only the rerouting proposal toward formal evaluation. The faster delivery and the equivalent-fixture swap do not touch approved scope, schedule, or cost, so they are logged and actioned. The rerouting alters the approved connection point, so it needs impact analysis before any decision.
Both wrong extremes are offered. Treat all three the same way, because each involves a change to how the work is done. Refer all three to the change control board. The first buries the board in trivia or lets a real change slip through informally; the second buries the board in trivia outright.
Common trap: answering a baseline question with the change management plan when the configuration management plan is what you need. One bank item asks what you check first when stakeholders request alterations to scope, cost, and schedule and you must work out which need formal approval. The change management plan is the closest miss and it loses. The configuration management plan identifies which artifacts are configuration items under baseline control, meaning which specific elements are frozen. Only once you know a request touches a baselined item does the change management plan, which describes how such a change is raised and approved, become relevant. Reaching for it first assumes the answer to the question you were asked.
Whenever the baseline has not actually moved, or the problem is something other than a baseline problem. Four examples from the bank.
| Scenario | Baseline option offered | Keyed instead |
|---|---|---|
| Deliverable arrives early, threat to critical path recedes | Update the schedule baseline | Review the risk register, lower that risk's ranking |
| Sponsor says the team does not grasp the requirements | Show them the plan with the scope baseline | Build a high-level prototype and review it together |
| Programme chartered on one benefit, funders now name another | Change request against the scope baseline before the next gate | Restate the purpose, agree it with sponsor and funders, put it to the crews |
| Requests arriving, unclear which need approval | Check the change management plan | Check the configuration management plan first |
The early-delivery row is the purest example. A deliverable arrives ahead of its due date. Nothing about the approved schedule has changed, so there is nothing to rebaseline. What changed is a risk's probability, and the keyed answer lowers its ranking.
The programme row is subtler and worth reading twice. A water authority's meter-replacement programme was chartered to cut field visits, but a new tariff has made read accuracy the benefit the funders now name, and the crews still plan every route around visit counts. Raising a change request against the scope baseline looks responsible. It loses to restating the programme's purpose with the sponsor and funders, because the mismatch is between two stated purposes, not between the plan and its baseline. Processing a change request would leave the chartered outcome on record while the crews get a new target with no stated reason for it.
That is the whole pattern in one item. Before you touch a baseline, establish that the baseline is what is broken.
When is checking the scope baseline the keyed answer? When you suspect a deliverable is incomplete but the only evidence is your own expectation. The bank keys checking the deliverable against the scope baseline, which establishes what was actually required before anyone is confronted.
Does every change go through the change control board? No, and one bank item turns entirely on that. Only changes that alter an approved baseline need formal evaluation. Operational adjustments that touch no baseline are logged and actioned.
Which plan tells you whether something is under baseline control? The configuration management plan. It identifies which artifacts are configuration items under baseline control. The change management plan tells you how to change one, which is only relevant once you know a baseline is involved.
What makes up the scope baseline? The project scope statement, the WBS, and the WBS dictionary. The bank's keyed explanation names all three, which is why checking against it answers a question about what a deliverable was required to contain.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: The Project Management Plan: What's In It, Who Owns It, and What a Baseline Actually Is and Change Requests: Who Approves What, and When You Need One At All. Change control is mapped on the Business Environment study page.
When is checking the scope baseline the keyed answer?
When you suspect a deliverable is incomplete but the only evidence is your own expectation. The bank keys checking the deliverable against the scope baseline, which establishes what was actually required before anyone is confronted.
Does every change go through the change control board?
No, and one bank item turns entirely on that. Only changes that alter an approved baseline need formal evaluation. Operational adjustments that touch no baseline are logged and actioned.
Which plan tells you whether something is under baseline control?
The configuration management plan. It identifies which artifacts are configuration items under baseline control. The change management plan tells you how to change one, which is only relevant once you know a baseline is involved.