5 Risk Management Questions That Trip Up Experienced PMs (2026 Edition)

Answer: B. Generate the risk report.

The risk register and the risk report are two distinct PMI artifacts that serve different audiences and purposes.

The risk register is a living list of individual risks. Each row is a specific risk with its probability, impact, score, response, and owner. This is a working document for the project team.

The risk report is a summary of overall project risk. Includes total risk exposure, distribution by category, trends, reserves status, and top risks. This is the executive-facing artifact.

The sponsor asked for project-level risk posture, not a list of risks. That's a risk report request.

Why experienced PMs get this wrong: In real-world projects, "the risk register" is often the only risk document that exists. Many PMs have never produced a formal risk report — they just hand executives a filtered version of the register. So when PMI asks the question, the muscle memory says "give them the register" because that's what we actually do at work. PMI tests the artifact distinction PMBOK actually defines, not the shortcut most teams take.

The PMI principle: Risks (individual) live in the risk register. Risk (overall, aggregate) lives in the risk report. Audience determines artifact.

Answer: B. You can use the contingency reserve but the management reserve requires the sponsor's authorization.

Two different budget pools with two different authority levels.

The contingency reserve funds known risks — the ones identified in your risk register with assigned response strategies. The PM controls it. It's part of the cost baseline.

The management reserve funds unknown unknowns — risks that weren't identified during planning. The PM does NOT control it. It sits outside the cost baseline and requires sponsor or management approval to access.

The $180K is yours to deploy. The $90K isn't. You'd have access to $180K of the $250K needed, and you'd need to formally request the additional $70K from the sponsor or PMO.

Why experienced PMs get this wrong: In real-world projects, especially at smaller companies, the PM often controls the entire project budget — including any "buffer" the sponsor approved up front. The distinction between "your reserve" and "their reserve" gets lost because culturally it's all just "the cushion." Senior PMs answer A out of habit because at their last job they DID control both pools. PMI is testing the PMBOK definition, not your company's accounting practices.

The PMI principle: Contingency equals known risks, PM authority, inside baseline. Management equals unknown risks, sponsor authority, outside baseline.

Answer: A. Vendor capacity is secondary. Integration is residual.

These terms aren't interchangeable. PMI defines them precisely.

A secondary risk is a risk that arises directly from implementing a risk response. You wouldn't have this risk if you hadn't taken the action. The vendor capacity risk only exists because you transferred work to the vendor — it's a consequence of the response itself.

A residual risk is a risk that remains after the response has been applied. Even with the original risk addressed, some exposure is still present. The integration risk was always there in some form — it just wasn't fully eliminated by transferring the work.

The test: ask "did the response cause this risk?" If yes, it's secondary. If the response merely failed to fully eliminate it, it's residual.

Why experienced PMs get this wrong: Both risks happen "after" the response, and the words "secondary" and "residual" both sound like "leftover." So senior PMs grab whichever term sounds right and move on. Answers C and D are designed to catch the candidate who thinks the distinction is about timing rather than causation. In practice, most PMs use these terms interchangeably at work because nobody's grading them on definitions. PMI is.

The PMI principle: Secondary equals caused by the response. Residual equals remains despite the response. The test is causation, not timing.

Answer: B. Perform quantitative risk analysis.

The two analysis processes sit in sequence and serve different purposes.

Qualitative risk analysis is subjective. It rates risks by probability and impact using categories (high/medium/low, or 1-5 scales). Fast, cheap, gets you a prioritized list. Required on every project.

Quantitative risk analysis is numerical. It assigns actual dollar values and probability distributions, then runs techniques like EMV, decision trees, or Monte Carlo simulation to produce ranges and confidence levels. Slower, more expensive, optional but valuable when stakeholders need probabilistic forecasts.

The CFO is asking for numbers with confidence intervals. That's the exact output of quantitative analysis. You've already done the qualitative pass (the risk register exists, risks are prioritized) — now you move to the next process for the risks that warrant deeper analysis.

Why experienced PMs get this wrong: Most candidates have done qualitative analysis dozens of times — every risk matrix workshop is qualitative analysis. But very few have actually run Monte Carlo or built a quantitative model, so when PMI asks the question, the muscle memory says "make the qualitative analysis better" (answer A). Answer C is the "I'll fake it" trap — adding cost estimates to a register isn't the same as performing quantitative analysis, which uses specific techniques and produces probability distributions. Answer D is the "I don't have the data" cop-out PMI explicitly tests against — the answer they want is "do the process," not "tell stakeholders no."

The PMI principle: Qualitative comes first and is always done. Quantitative comes second and is done when stakeholders need numerical forecasts. The trigger is stakeholder demand for probabilistic data, not project size.

Answer: D. Escalate.

This is one of PMI's most distinctive 2026-era additions to risk response strategies. Escalation isn't a cop-out — it's the correct response when a risk meets specific criteria.

The risk is outside the project's scope or authority. The response requires decisions you don't have the authority to make. The risk's impact extends beyond the project's boundaries.

All three apply here. The law isn't a project risk you can mitigate, accept, or avoid — it's an organizational risk that the project happens to be exposed to. The right move is to formally hand it to the people who can actually own it.

After escalation, the risk leaves your risk register and moves to the organizational risk register (or equivalent). You don't continue tracking it as a project risk because it's no longer yours to manage.

Why experienced PMs get this wrong: Senior PMs have been trained their whole careers to "solve the problem." Escalating feels like failure — like you couldn't handle it. So they reach for A (mitigate by adding flexibility) because that feels like the responsible, capable answer. But mitigating a risk you don't have the authority to make decisions about is how projects end up with scope creep, hidden compliance gaps, and PMs taking blame for decisions they were never empowered to make. PMI added escalate as an explicit response strategy in PMBOK 7 specifically because the profession was bad at this. The 2026 exam tests whether you've absorbed the shift.

The PMI principle: Escalate when the risk is outside your authority, scope, or impact boundary. Escalation moves the risk off your register — you don't keep tracking what you can't control.