September 6, 2026 · 8 min read
TL;DR: Escalation is a tempting option and rarely the right one. Across this bank escalation is offered in 93 questions and keyed correct in nine. Ask two things: has the thing already happened (issue log, not risk register), and does clearing it need authority the project does not hold. If not, go and clear it.
A supplier module fails once a week, nobody can say why, and your increment has been held three weeks. Escalate to the executive sponsor, keep holding, ask the supplier to walk you through the logic, or work out exactly which functions actually depend on the broken part. Three of those wait on someone else. Only one moves work to the people waiting for it.
Escalate when removing the obstacle requires authority, funding or a decision the project does not hold. Everything below that line is yours to clear. The exam treats escalating a solvable problem as the same category of error as sitting on an unsolvable one.
That sounds obvious until you count how often candidates reach for it anyway. Of the 64 questions filed under removing impediments and managing issues in this bank, escalation shows up as an answer option in eleven and is keyed correct in two. Bank-wide the ratio holds: escalation is an option in 93 questions and the correct answer in nine.
The two keyed-correct cases in this slice are worth knowing by shape, because the stems announce themselves. In one, a compliance requirement has blown past the organization's own tolerance threshold and the customer contract carries a large late fee. In the other, upper management wants to pull critical specialists off a project the organization has itself called strategically important. Both stems put the problem above the project manager's authority in plain words before asking the question.
Common trap: treating escalation as the cautious choice. It is offered as a wrong answer in nine of these 64 records, and the explanations describe it the same way each time: it asks somebody else to solve a problem nobody has tried to solve yet. One scenario has a specialist available only two days a week, with the stem stating that two days is all the availability there is; the keyed answer agrees a working arrangement for those two days, and escalating that constraint to senior management is wrong because there is nothing above you to grant.
Find out what is causing it, then go to whoever owns the constraint. Those two moves carry most of the keyed answers in this slice, well ahead of logging, escalating or raising a change request.
Counting the keyed options across the 62 multiple-choice questions here:
| What the keyed answer does | Count |
|---|---|
| Establish the cause first (investigate, root cause, work out the real position) | 14 |
| Go to the party who owns the constraint (vendor, client, IT, the person's manager) | 15 |
| Record it in the issue log, paired with an owner or a next action | 7 |
| Escalate | 2 |
| Raise a change request | 1 |
A failed workstation in the middle of a six-iteration schedule is the cleanest example. The options are to hand the developer a service-desk ticket number, log it for the product owner, redistribute their work, or drive the fix with IT as a priority. The last one is keyed, and each of the other three is explained rather than just marked: they leave the impediment exactly where it was and move the cost somewhere else.
There is a second, quieter pattern in the same slice. One scenario has a team that raised fourteen impediments in two months, nine still open with no recorded update, and has now gone silent in three consecutive coordination meetings. The keyed answer is to work through the nine open items and let the team see them finished. Adding an impediments column to the status report and reminding people that reporting is expected are both offered, and both collect the same silence in a new format. The reporting route had become the impediment.
A risk is uncertain and in the future. An issue has already happened and is affecting the project now. When a risk materializes it moves out of the risk register and into the issue log, with an owner and a target date attached.
This is one of the few genuinely mechanical distinctions in the domain, and the bank tests it by offering the wrong log. Four questions in this slice put "add it to the risk register" or "log it as a risk" in front of a problem the stem has already described as happening. One asks where to record the termination of an unreliable supplier's contract, with the lessons learned register, the change log and the risk register alongside the issue log. The lessons learned register is the strongest distractor there, because something will certainly be learned. It is still wrong, because writing the lesson down does not get the supplier's remaining work done.
| Artefact | What belongs in it |
|---|---|
| Risk register | Uncertain future events, with a probability, an impact and a planned response |
| Issue log | Conditions already affecting the project, with an owner and a resolution date |
| Change log | Requested changes and what was decided about each |
| Lessons learned register | What the project learned, recorded when the insight is available |
The sequence a bank ordering question teaches runs: log it with an owner and a date raised, assess impact and urgency, agree the resolution and a due date, resolve it or escalate if it exceeds the project's authority, then verify the fix, close it and record the lesson. Escalation sits inside the resolution step, not before it. That placement is the whole point.
Worth noting on vocabulary: PMBOK 8 keeps risk as a performance domain of its own (§2.7, with Monitor Risks among its six processes), while issues and impediments are handled through governance rather than through a process named after them. The 2026 Exam Content Outline files removing impediments and managing issues in Business Environment, alongside change and risk, which is where candidates studying from older material tend to lose track of it.
When should a project manager escalate an impediment? Only when clearing it needs authority, money or a decision the project does not hold. Escalation is an option in 93 bank questions and keyed correct in nine.
What is the difference between an issue and a risk? A risk is uncertain and in the future; an issue has already happened. When a risk materializes it moves from the risk register to the issue log, with an owner and a date.
Is logging an issue enough? No. An issue with no named owner and no due date stays open. Where logging is keyed, it is almost always paired with a next action.
Should impediments be solved during the daily stand-up? No. The stand-up surfaces them. Solving happens separately, with the people who can actually contribute to the fix.
The 64 impediment and issue questions in PMP Practice sit inside a bank of 2,141 re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and every 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: Project governance: where your authority ends · Business Environment tripled in weight · Business environment study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
When should a project manager escalate an impediment?
Only when clearing it needs authority, money or a decision the project does not hold. In this bank, escalation appears as an option in 93 questions and is keyed correct in nine. The two cases in the impediments slice are a compliance breach past the organization's own tolerance threshold with a contractual penalty attached, and management pulling specialists off a strategically important project. Both sit above the project manager's authority by the stem's own wording.
What is the difference between an issue and a risk?
A risk is an uncertain future event. An issue has already happened and is affecting the project now. The moment a risk materializes it stops being a risk register entry and becomes an issue log entry, with an owner and a resolution date. Recording something that has already occurred in the risk register is a wrong answer in four questions in this slice alone.
Is logging an issue enough?
No, and several questions are built on that gap. An issue logged without a named owner and a due date is one everyone assumes somebody else has. Where logging is the keyed answer, the keyed option almost always pairs it with something: assign an owner, bring in an expert, or check whether a substitute component exists.
Should impediments be solved during the daily stand-up?
No. The stand-up surfaces impediments; it does not resolve them. One bank scenario keys taking the problem offline with the people who can actually contribute, and marks both working it through in the stand-up and calling an immediate follow-up meeting as wrong.