Most PMP marks are lost on pairs of answers that are both reasonable in real projects but distinguished sharply on the exam: risk versus issue, escalate versus resolve, contingency versus management reserve, quality assurance versus quality control. Learn the fork, not the definitions — the exam tests which side of it the scenario puts you on.
Nobody fails the PMP because they cannot define a change request. They fail because a scenario describes something that is arguably a risk and arguably an issue, offers a defensible action for each, and expects one of them.
That is the exam's actual difficulty, and it is why definition-first study stops working around the halfway mark. Definitions tell you what a thing is. They do not tell you which of two things a paragraph is describing.
What follows is twelve of those forks — the ones that recur most and cost most — each stated as a decision rather than a definition. If you can put a scenario on the correct side of these twelve, a large share of the exam stops being ambiguous.
Risk or issue. A risk has not happened; an issue has. That sounds trivial and it decides dozens of questions, because the correct action diverges completely: a risk goes to the risk register and gets a response planned, an issue goes to the issue log and gets resolved. Read the tense of the scenario before you read the options.
Escalate or resolve. The exam's default is that you handle what is within your authority and escalate what is not — and it is unusually strict about the boundary. A change to scope, budget or schedule baseline is not yours to approve. A team disagreement about how to sequence work is not the sponsor's to settle. When both are offered, ask whose decision it actually is, not who could make it fastest.
Contingency reserve or management reserve. Contingency covers identified risks, sits inside the cost baseline, and the project manager controls it. Management reserve covers unknown-unknowns, sits outside the cost baseline, and is released by management. If the scenario describes a risk you had identified, you are spending contingency; if something arrived that nobody anticipated, you are asking for management reserve.
Quality assurance or quality control. Assurance is about the process — are we working in a way that will produce a good result. Control is about the deliverable — is this specific thing acceptable. A question about auditing how the team works is assurance; a question about inspecting what the team produced is control.
Responsible or accountable. In a RACI, several people can be responsible for doing work; exactly one is accountable for the outcome. Questions that hinge on who answers for a failure are asking about accountability, and the answer is singular.
Sponsor or product owner. The sponsor funds and champions the project and owns the business case. The product owner owns the backlog and decides what gets built next. A scenario about whether the project should continue goes to the sponsor; a scenario about what the team builds this iteration goes to the product owner. Both appear in hybrid scenarios, which is exactly when candidates conflate them.
Remove an impediment or direct the team. A servant leader clears obstacles and protects the team's ability to decide; they do not decide for the team. When one option has you resolving a technical disagreement by choosing, and another has you facilitating the team to choose, the exam wants the second — unless the scenario makes clear that the decision is genuinely yours.
Stakeholder engagement or communications management. Communications is about information moving — who gets what, when, how. Engagement is about attitude and involvement — bringing a resistant stakeholder round. If the scenario describes someone who is informed but unhappy, more reporting is not the answer; engagement is.
Fast-tracking or crashing. Fast-tracking runs activities in parallel that were planned in sequence — it costs risk. Crashing adds resource to shorten duration — it costs money. When a scenario tells you the budget is fixed, it has told you which one; when it tells you the risk appetite is low, it has told you the other.
Mitigate, transfer, avoid or accept. Mitigate reduces probability or impact. Transfer moves the financial consequence to someone else and does not reduce the risk. Avoid removes the exposure entirely, usually by changing the plan. Accept does nothing beyond acknowledging it. Insurance and contracts are transfer, not mitigation — a distinction the exam tests specifically because it is so often blurred in practice.
Change request or corrective action. In the exam's grammar, corrective action is itself performed through the change control process; the fork candidates actually face is whether the scenario calls for raising a change request at all, or whether the situation is inside the existing baseline. If the baseline moves, it is a change request. If you are bringing performance back to a baseline that has not moved, you are correcting.
Lessons learned, retrospective, or final report. Lessons learned are captured continuously, throughout. A retrospective is an iteration-level event with a cadence. The final report closes the project. A question about what to do now, mid-project, after something went wrong, is almost never asking you to wait until closure.
The distinction, not the definitions. Read the column that matches the scenario.
| The fork | One side | The other side | What decides it |
|---|---|---|---|
| Risk / issue | Has not happened — risk register, plan a response | Has happened — issue log, resolve it | The tense of the scenario |
| Escalate / resolve | Outside your authority — escalate | Within your authority — act | Whose decision it actually is |
| Contingency / management reserve | Identified risk, inside the cost baseline, PM controls | Unknown-unknown, outside the baseline, management releases | Was the risk identified? |
| Assurance / control | About the process — audit how we work | About the deliverable — inspect what we made | Process or product |
| Responsible / accountable | Does the work — can be several people | Answers for the outcome — exactly one | Doing or answering |
| Sponsor / product owner | Funds it, owns the business case, decides if it continues | Owns the backlog, decides what is built next | Continue the project, or build the feature |
| Remove impediment / direct | Clear the obstacle, let the team decide | Decide for the team | Default to the first unless the decision is genuinely yours |
| Engagement / communications | Attitude and involvement — win them round | Information flow — who gets what, when | Uninvolved, or uninformed |
| Fast-track / crash | Parallel work — costs risk | More resource — costs money | Which constraint the scenario fixed |
| Mitigate / transfer | Reduce probability or impact | Move the financial consequence — risk remains | Insurance and contracts are transfer |
| Change request / corrective action | The baseline moves | Bring performance back to an unchanged baseline | Does the baseline change? |
| Lessons / retrospective / final report | Captured continuously; iteration event | Closes the project | What to do now, versus what to do at the end |
When two options both look defensible and none of the twelve forks settles it, the exam has a strong preference, and it is worth internalising: understand before you act, and involve the person before you decide about them.
In practice that means options which gather information, analyse the cause, or talk to the affected stakeholder usually beat options which take immediate corrective action — unless the scenario has already established the cause, in which case gathering more information is stalling and the exam penalises it.
The exception is safety, legal or ethical exposure. Where the scenario describes a breach, a hazard or a compliance failure, the exam does not want you to investigate first.
That is the shape of the judgment being tested, and it is the reason a decision map beats a definition list in the final weeks. Our visual guide draws these forks as maps for exactly that reason — fifty of them across People, Process and Business Environment — because the thing you need under time pressure is not the definition of contingency reserve but the fork that tells you which reserve this scenario is about.
No — it is an issue, and it moves from the risk register to the issue log. The exam distinguishes these sharply because the correct action differs completely: a risk gets a planned response, an issue gets resolved.
When the decision is genuinely outside your authority — typically anything that moves the scope, schedule or cost baseline, or that belongs to the sponsor or the governance body. Team-level decisions and problems within the baseline are yours to handle.
No, it is transfer. Mitigation reduces the probability or impact of the risk itself. Insurance and contractual arrangements move the financial consequence to another party while leaving the risk in place.
Contingency covers identified risks, sits inside the cost baseline and is controlled by the project manager. Management reserve covers unforeseen work, sits outside the cost baseline, and is released by management.
Usually the one that understands before acting, or that involves the affected person before deciding about them — unless the scenario has already established the cause, or unless it involves safety, legal or ethical exposure, where acting immediately is correct.
Rules change. Where a figure or a procedure can move, the issuing agency’s current published instructions win over anything here.
