September 6, 2026 · 9 min read
TL;DR: Governance questions test authority, not committees. Inside the authority your charter delegates, decide and move on. Outside it, take the gap to the body that owns it. The reflex wrong answer is escalating again, reporting again, or pushing harder, all of which record a problem without changing who gets to solve it.
A sponsor is unreachable for ten days, several decisions are needed this week, and every option in front of you sounds responsible. Wait for the sponsor. Escalate to their line manager. Put it to the team. Most candidates pick one of those three, and all three are wrong for the same reason: the charter already said who decides.
Governance is the framework naming who may decide what, within which limits, and to whom the project answers. Scenarios test it by removing a decision-maker, splitting authority across two bodies, or handing you a problem you have no standing to fix.
The pattern is consistent enough to be worth memorising. Across the 63 governance-tagged questions in this bank, 28 mention authority and 24 mention a decision, while only one mentions a steering committee and three mention stage gates. It is not a vocabulary topic about governance structures; it is a reasoning topic about who owns a call.
| Situation in the stem | What the exam wants | What it does not want |
|---|---|---|
| Decision falls inside your charter authority | Take it | Wait, escalate, or poll the team |
| Decision falls outside anyone's authority | Get the owning body to establish who decides | Decide it yourself, or escalate repeatedly |
| Two bodies have decided differently | Ask them jointly to agree one route | Follow the larger funder, or build both |
| A role that owns decisions is vacant | Get it filled | Absorb the role quietly |
Common trap: treating escalation as a safe default. In this bank, escalation is keyed correct only when it takes a structural gap to the body that can close it, and keyed wrong when the decision was already yours or when the same escalation has already failed. One scenario has a project manager pressing supervisors harder for their views; the keyed answer gives those supervisors a seat on the board instead. The reflex to report a problem upward appears as a distractor in nine of these records, and the explanations describe it the same way each time: it records the harm without touching its cause.
Take the decisions that fall within the delegated authority limits. The charter granted that authority in writing, and a sponsor being on a plane does not revoke it.
The scenario is a rail signalling upgrade needing several decisions this week, with the sponsor unreachable for ten days, and the stem states plainly that the decisions fall inside the authority the project manager was granted in the charter. Holding the work concedes schedule for no reason. Escalating to the sponsor's line manager asks a third party for permission you already hold, and undermines the sponsor besides. A team vote does not transfer accountability, which stays with the project manager either way.
Delegated authority is written down precisely so routine absence does not stall delivery. The exam rewards candidates who read the charter clause in the stem and act on it rather than seeking reassurance they do not need.
Get the authority established before trying to make progress inside a structure that cannot produce a decision. That is the fix; anything else treats a symptom.
Five district councils share a waste-collection scheduling system. Their joint board decides by unanimous agreement so no council can be bound by the others, and in nine months it has agreed two of eleven decisions while a release ready since March sits deployed nowhere. The keyed answer is to ask the councils to agree how the board will decide when they do not all agree.
Unanimity hands every member a veto, so the board's output is set by whoever is most reluctant rather than by the merits of anything put to it. Deploying only to the willing councils splits a shared system on the project manager's own initiative. Re-presenting the same decisions with clearer recommendations assumes the problem is persuasion when the problem is the decision rule. Escalating to five chief executives asks five people to do what their own board was created to do.
A joint venture between a port operator and a rail freight firm makes the same point from the other direction: two parent steering groups have each approved conflicting handover rules, and the keyed answer is to ask them to establish a single route by which venture decisions get settled. Following the larger funder substitutes contribution for authority. Raising a change request routes the dispute back to the two bodies that created it. Building both models pays twice for a decision that still has no owner.
There is no universally ideal model, and a question asking you to rank them is usually testing whether you know that. The keyed answer blends characteristics and tailors the result to context.
Worth knowing if you are studying from older material: PMBOK 8 names the directive, supportive, and agile PMO as illustrative examples rather than as competing options to rank, and does not use the term controlling PMO. The traditional taxonomy still turns up in identification questions, where supportive means a consultative role supplying templates, controlling means enforcing compliance, and directive means managing the projects itself with project managers reporting into it. Know both framings: the taxonomy for questions that ask what a described PMO is, and the tailoring answer for questions that ask which one is best.
What does project governance actually mean on the exam? The framework saying who may decide what, within which limits, and to whom the project answers. It is tested through charter authority, the sponsor's role, and decisions with no clear owner.
When should a project manager escalate a decision? When it genuinely sits outside your delegated authority and belongs to a body that can settle it. Escalating something already inside your charter authority is a keyed wrong answer.
What if the sponsor is unavailable and a decision is needed? Take the decisions inside your delegated authority. That authority exists so a sponsor's absence does not stall the project.
Which PMO type is best? None inherently. PMBOK 8 treats the PMO types as examples rather than a ranking, so the keyed answer is to tailor to context.
The 63 governance 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: Business Environment tripled in weight · Change requests: who approves what · Business environment study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
What does project governance actually mean on the exam?
The framework that says who may decide what, within which limits, and to whom the project answers. In practice the exam tests it through the project charter's delegated authority, the sponsor's role, and what happens when a decision has no clear owner. Of the 63 governance-tagged questions in this bank, 28 mention authority and 24 mention a decision.
When should a project manager escalate a decision?
When the decision genuinely sits outside their delegated authority and belongs to a body that can actually settle it. Escalating something already inside your charter authority is a keyed wrong answer, and so is escalating the same problem repeatedly without changing who holds the decision.
What if the sponsor is unavailable and a decision is needed?
Take the decisions that fall within the authority the charter granted you. Delegated authority exists precisely so a sponsor's routine absence does not stall the project, and a decision mattering does not withdraw it from your remit. Waiting gives up schedule for nothing.
Which PMO type is best?
None of them, and a question asking you to rank them is usually testing that. PMBOK 8 treats the directive, supportive, and agile PMO as illustrative examples rather than competing options, so the keyed answer is to blend characteristics and tailor to the organization's context. The traditional supportive, controlling, and directive taxonomy still appears in identification questions.