September 6, 2026 · 8 min read
TL;DR: In this bank's 93 change-control questions, the most-keyed move is assessing the impact, at 26 times. Two tempting shortcuts fail hard: declining the change outright is offered 12 times and keyed once, and treating the change control board as a rubber stamp that approves what you file is keyed 4 times against 15 appearances as a distractor. The pattern is that the project manager quantifies, and whoever owns the baseline decides.
A stakeholder asks for extra features days before launch. They would genuinely improve the product and they would push the date. Most candidates can recite that this needs a change request. The questions are not testing that. They are testing what you do in the ninety seconds before the change request exists, and whether you understand that filing one is not the same as it being approved.
Assessing the impact, and it is not close. Across the 91 multiple-choice questions in this slice, an option that assesses, analyzes or quantifies the impact is keyed 26 times against 13 appearances as a distractor, the best ratio of any move in the topic.
Everything else in change control is downstream of it. You cannot write a useful change request without it, the board cannot decide without it, and the stakeholder cannot weigh their own request without it. One question puts the whole sequence on the table: a late change on a stadium access-control project has been quantified, and the rework would consume the remaining schedule float and exceed the approved cost baseline. The options are implement it anyway because the requester is senior, quietly absorb the overrun in contingency without telling the board, submit a formal change request presenting the quantified impact, or reject it unilaterally because it no longer fits the baseline.
The keyed answer submits the request with the numbers attached. The explanation draws the line exactly where the exam always draws it: once the impact is known and it breaches the approved baseline, accepting, deferring or declining is no longer the project manager's to decide alone. That is what the board exists to authorize, and the quantified impact is what makes the request decidable rather than a request to be argued about.
| Move | Keyed | Offered as a distractor | What it gets wrong when it fails |
|---|---|---|---|
| Assess or quantify the impact | 26 | 13 | Rarely wrong, occasionally too slow when a decision is already made |
| Submit a change request | 21 | 20 | Filed without the analysis that makes it decidable |
| Reject or decline the change | 1 | 11 | Spends the stakeholders' authority on their behalf |
| The board approves it | 4 | 15 | Treats a decision point as an automatic step |
| Inform stakeholders | 4 | 8 | Communicates instead of analyzing |
| Route it through the backlog | 5 | 4 | Right on agile projects inside agreed scope, wrong when a baseline moves |
Because the project manager is spending someone else's authority. This is the same principle that governs governance questions on this exam, and change control is where it bites hardest.
A brewery bottling-line project illustrates it cleanly. Midway through, the project manager learns of a new filler technology that would materially raise throughput but would add three weeks and increase the budget. Four options: adopt it straight away to capture the benefit, discuss the benefits and implications with the stakeholders before deciding, decline it to avoid scope creep and protect the plan, or commission a feasibility study.
Declining it feels disciplined. It is the answer a candidate picks after absorbing warnings about scope creep. The keyed answer discusses it with the stakeholders, and the explanation says why both easy answers fail together: the opportunity is paid for out of the time and cost baselines the stakeholders authorized, so pursuing it is their decision, not the project manager's to take on their behalf. Adopting it unilaterally spends their contingency without asking. Refusing it unilaterally denies them a benefit they might well have wanted to buy.
Common trap: treating "protect the baseline" as licence to say no. Guarding the baseline means guarding the process that changes it, not blocking changes at the door. In this bank, an option that rejects, denies or declines a request outright is offered 12 times and keyed once, and the explanations repeatedly describe the refusal in the same terms as unilateral approval, as the project manager making a call that belongs to the people who authorized the baseline. Both errors have the same shape. Only their direction differs.
No, and this is where a lot of otherwise-solid candidates lose marks. Submitting a change request is keyed 21 times here, which makes it feel like the safe answer. But an option asserting that the change control board approves it, or has approved it, is keyed 4 times against 15 appearances as a distractor.
The gap between those two numbers is the whole lesson. The request is a document you produce. The approval is a decision somebody else makes, and the exam writes distractors that quietly skip it.
Two other boundary cases are worth holding. When two stakeholders each insist their change is top priority, the keyed answer is that the project manager prioritizes them, because assessing what each change does to scope, schedule, cost, risk and benefit is the project manager's analytical work before anything reaches the board. And when work falls outside a subcontractor's statement of work, the keyed answer initiates a change request and reviews the contract to evaluate payment options before responding, because the contract's own terms constrain what the change can be. Negotiating the price first commits the project to terms nobody approved.
On agile projects the route changes but the principle does not. Reordering the backlog within agreed scope is the product owner's normal work and needs no change request, and options that push it through a board are distractors. What triggers change control is a baseline moving, not a conversation about priorities.
Can a project manager ever reject a change request? Not unilaterally. Declining or rejecting outright appears 12 times in this slice and is keyed once. The change spends baselines the stakeholders authorized, so the call is theirs.
Do I need a change request for everything? No. Reordering an agile backlog inside agreed scope needs none. What triggers change control is a change to an approved baseline: scope, schedule, cost, or a contractual statement of work.
Is submitting a change request the same as getting it approved? No. Submitting is keyed 21 times; an option asserting the board approves it is keyed 4 times against 15 as a distractor. The board is a decision point, not a formality.
What comes first, the impact analysis or the change request? The analysis, and the request carries it. Assessing the impact is the most-keyed move in this slice at 26 times, and it is what makes a request decidable.
The 93 change-control questions in this bank are certified against PMBOK 8 and the July 2026 exam content outline, and each explanation names which authority the wrong options quietly borrowed, every wrong answer explained rather than just marked wrong. Start the free 20-question sample with no card and no signup.
Related reading: Change Requests: Who Approves What and Project Governance: Who Decides What. The domain breakdown is on the Business Environment study page.
Sources: PMI, Project Management Professional (PMP) Exam Content Outline
Can a project manager ever reject a change request?
Not unilaterally, on this bank's evidence. Options that decline, deny or reject a request outright appear 12 times in the 91 multiple-choice questions filed under managing and controlling changes and are keyed once. The reasoning in the explanations is consistent: the change spends time and money from baselines that stakeholders authorized, so accepting or declining it is their call. The project manager's job is to make that call possible by quantifying what the change costs.
Do I need a change request for everything?
No, and the exam tests the boundary. On an agile project, reordering the product backlog inside the agreed scope is normal work for the product owner and needs no change request, and options routing that through a board are distractors. What triggers change control is a change to an approved baseline: scope, schedule, cost, or a contractual statement of work. If the baseline does not move, there is nothing to control.
Is submitting a change request the same as getting it approved?
No, and conflating them is one of the most common errors here. Submitting a change request is keyed 21 times in this slice, but an option saying the change control board approves or has approved it is keyed 4 times against 15 appearances as a distractor. The board is a decision point you take an analyzed change to, not a step that happens automatically once you file the paperwork.
What comes first, the impact analysis or the change request?
The analysis, in the sense that the request must carry it. Assessing or analyzing the impact is the single most-keyed move in this slice at 26 times. One question makes the sequence explicit: the project manager has already quantified that the rework would consume all remaining float and breach the cost baseline, and the keyed answer submits a formal change request presenting that quantified impact to the board. The quantification is what makes the request decidable.