Try 10 focused PMI-RMP questions on Risk Identification, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PMI-RMP |
| Topic area | Risk Identification |
| Blueprint weight | 23% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Risk Identification for PMI-RMP. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 23% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Risk Identification
A team records this risk in the register: “A new import regulation may delay delivery of specialized equipment from an overseas supplier.” Which risk-origin classification best fits this entry?
Best answer: D
What this tests: Risk Identification
Explanation: Risk origin classifies where the uncertainty comes from. Because the possible delay is caused by an import regulation outside the project, this risk has an external origin.
Risk origin is a risk-register attribute used to show whether the source of uncertainty is inside or outside the project. In this case, the possible problem comes from a new import regulation affecting a supplier shipment, which is outside the project’s direct control, so it is an external origin. This kind of classification helps the team group risks correctly and understand whether causes come from project work itself or from the surrounding environment. Internal origins typically come from estimates, resources, design decisions, interfaces, or execution practices within the project. External origins typically come from regulation, market conditions, weather, or supplier environment. The closest distractor is internal origin, but that applies only when the cause is within the project boundary.
A regulatory change comes from outside the project’s direct control, so the risk source is external.
Topic: Risk Identification
During risk identification for a data-center migration, the team records a threat that telecom permit approval may be delayed, pushing cutover. They agree on an early warning trigger of no permit decision by July 15 and a threshold of more than 5 days of projected schedule impact, but these details are still only in workshop notes. What should the risk manager do next to support later monitoring?
Best answer: A
What this tests: Risk Identification
Explanation: The best next step is to record the trigger and threshold in the risk register. That turns workshop discussion into documented monitoring criteria so the team knows exactly what to watch and when exposure becomes unacceptable.
Triggers are early warning signs, and thresholds define the point at which risk exposure requires action or escalation. In this scenario, the team has already identified the threat and agreed on both the monitoring signal (no permit decision by July 15) and the tolerance limit (more than 5 days of projected schedule impact). The next step is to capture that information in the risk register so later monitoring is based on specific, agreed criteria rather than memory or informal notes. This supports consistent tracking, timely escalation, and better response timing. Acting immediately would be premature because the trigger has not occurred, and treating the threat as an issue would be incorrect because the delay is still uncertain.
Documenting the trigger and threshold in the risk register gives the team objective criteria for future monitoring and escalation.
Topic: Risk Identification
During a hybrid billing-platform rollout, the team is converting workshop notes into entries for the risk register before qualitative probability-impact assessment. Which statement is already written as a recordable risk event rather than a raw observation?
Best answer: D
What this tests: Risk Identification
Explanation: A recordable risk event describes a future uncertainty and its possible effect on a project objective. The statement about a possible vendor API delay and missed go-live is the only option framed that way, so it is ready for the risk register and later probability-impact analysis.
In risk identification, workshop notes often start as observations, facts, issues, or constraints. Before the team can analyze a risk qualitatively, the item should be written as an uncertain event or condition with a potential effect on project objectives. The possible vendor API delay is uncertain, and the effect on testing and go-live makes the impact explicit, so it can be recorded and managed as a risk.
Mixed user feedback is only a signal that may require more probing. A missed review date is something that already happened, so it is an issue, not a future risk event. Limited schedule contingency is a constraint or exposure factor, not a risk statement by itself. Qualitative analysis should be applied after vague observations have been converted into clear risk statements.
It states an uncertain future event and a potential project impact, making it suitable for risk-register entry and qualitative assessment.
Topic: Risk Identification
A hybrid ERP project is 2 months from go-live. The sponsor has low appetite for schedule risk: any threat likely to delay go-live by more than 5 days must be highlighted at the weekly review. During backlog refinement, the team learns the middleware vendor has not started its required security retest; the audit result is due in 10 days, and the procurement lead manages this vendor. The draft risk register entry only says, “Vendor retest may delay integration,” and it has no probability, impact, urgency, trigger, or owner. What is the best action?
Best answer: A
What this tests: Risk Identification
Explanation: The best action is to complete the risk register entry before escalating or acting on it. The threat is still an uncertainty, and the project cannot judge its priority or monitor it properly without probability, impact, urgency, trigger, and owner information.
In risk register development, a vague statement is not enough. The entry should capture the risk cause, the uncertain event, the impact on project objectives, the trigger to watch, the qualitative assessment such as probability and impact, urgency, and a named owner. In this case, the vendor’s unstarted retest is the cause/context, the possible integration delay is the event and impact, the upcoming audit date or missed retest milestone can serve as the trigger, and the procurement lead is the logical owner because that role manages the vendor. Once those attributes are recorded, the team can decide whether the threat exceeds the 5-day threshold and whether escalation or a response is warranted. Escalating, treating it as an issue, or implementing a contingency now all skip needed identification quality.
A complete risk register entry needs the missing attributes so the team can prioritize, monitor, and escalate the threat appropriately.
Topic: Risk Identification
At kickoff for a hybrid software project, the sponsor states that external vendor spend is capped at $900,000 by the signed funding agreement. The risk management plan already says any forecast cost variance above 5% must be escalated, and separate triggers will be defined for major risks. During constraint analysis, how should the risk manager classify the $900,000 cap?
Best answer: C
What this tests: Risk Identification
Explanation: The $900,000 cap is a hard project limit imposed by the funding agreement, so it is a constraint. A risk threshold is a tolerance or escalation boundary, and a trigger is a specific sign that a risk may occur; the stem already provides a separate 5% threshold.
A constraint is a restriction that limits the project’s options, such as a fixed budget cap, mandatory date, or resource limit. In this scenario, the signed funding agreement sets a nonnegotiable ceiling on vendor spend, so the $900,000 amount is a project constraint. A risk threshold is different: it is the level of exposure or variance that prompts action, review, or escalation. The stem explicitly gives that threshold as a forecast cost variance above 5%. A risk trigger is also different: it is a specific warning condition tied to an individual risk, such as a vendor quote rising above a planned amount or a procurement milestone slipping. Keeping these distinct improves risk identification and monitoring because project limits should not be confused with warning signs or action criteria.
A signed spending cap is a project constraint, while triggers and thresholds are separate risk-monitoring elements.
Topic: Risk Identification
During assumption analysis, the team records: “The city will issue the road-closure permit within 30 days, allowing excavation to start as planned.” Which category best fits this statement?
Best answer: D
What this tests: Risk Identification
Explanation: This is an assumption because the team is treating a future event as true for planning. It is external because a city authority controls the permit, and it primarily affects schedule because excavation depends on the approval date.
Assumption analysis checks statements the project is accepting as true and examines where uncertainty could create risk. Here, the permit is controlled by an outside party, so the source is external to the project team. The stated consequence is that excavation can start “as planned,” which makes schedule the affected objective. If the assumption proves false, the project faces a schedule threat from delayed start of field work. This is not an internal assumption because the team does not control the city, and it is not a constraint because the stem presents a planning belief, not a fixed imposed limit. The key takeaway is to classify assumptions by both who controls them and which project objective they could disrupt.
The permit approval is outside the project’s control and mainly threatens planned work timing.
Topic: Risk Identification
A hybrid process-improvement project is rolling out a new intake workflow across six clinics. The risk manager wants to identify adoption risks by hearing from several front-desk staff who perform similar work and by letting participants react to one another’s concerns. Which risk identification approach is the best fit?
Best answer: A
What this tests: Risk Identification
Explanation: This need is about eliciting risks from a group of similar users and benefiting from participant interaction. A focus group is designed for exactly that type of risk identification exercise.
In risk identification, the method should match the source and nature of the uncertainty. Here, the goal is to uncover workflow adoption risks from multiple people who do similar work, and the stem explicitly says their reactions to each other matter. That points to a focus group, which is useful when shared discussion helps reveal concerns, patterns, and overlooked impacts.
Interviews are stronger when you need private, detailed input from individuals. A routine meeting is usually for coordination, not structured elicitation. An SME review is best for specialized technical uncertainty, not broad user adoption concerns from representative participants.
The key distinction is group interaction among similar stakeholders, which is why the focus group is the best match.
A focus group is best when similar participants can surface risks through shared discussion and reaction to each other’s concerns.
Topic: Risk Identification
A project manager is performing assumption analysis for a hybrid CRM rollout. The team has documented:
Which statement should be treated as an assumption rather than a confirmed project fact?
Best answer: B
What this tests: Risk Identification
Explanation: An assumption is something the team is currently treating as true for planning but has not yet verified. The statement about key-user availability in July depends on a future commitment, while the approval, signed contract term, and completed test result are already supported by evidence.
In assumption analysis, the team separates verified information from statements that are still uncertain. A confirmed fact is backed by current evidence, such as an approval already given, a contract already signed, or a test result already recorded. An assumption is different: it is a planning basis that may be true, but it still depends on future conditions or validation.
Here, the statement about key users being available in July is forward-looking and could change because of operational priorities, staffing limits, or schedule conflicts. That makes it an assumption and a potential source of risk if it proves false. The other statements describe events or evidence that already exist, so they should be treated as facts, not assumptions.
A useful check is simple: if the team can prove it now, it is a fact; if it still depends on something happening later, it is an assumption.
Key-user availability in July is a future condition not yet verified, so it should be logged as an assumption and monitored for related risk.
Topic: Risk Identification
In a risk identification workshop for a hybrid project, the facilitator asks stakeholders to question statements the team has been treating as true, such as the vendor API will remain stable, and to identify threats or opportunities if those statements prove false. Which risk identification method is this?
Best answer: B
What this tests: Risk Identification
Explanation: This is assumption analysis because the team is deliberately challenging what has been accepted as true and looking for uncertainty if those beliefs are wrong. Involving stakeholders this way helps expose hidden threats and opportunities during risk identification.
Assumption analysis is a risk identification method used to test whether stated or implicit assumptions are valid. In the scenario, stakeholders are being encouraged to challenge beliefs the project has been relying on, then consider what could happen if those beliefs fail. That is the core purpose of assumption analysis.
This is especially useful because different stakeholders often hold different assumptions about vendors, technology, timelines, or approvals. By surfacing and questioning those assumptions early, the team can identify both threats and opportunities before they affect project objectives. The resulting risks should then be documented in the risk register with relevant causes, impacts, and owners. The key distinction is that the discussion starts with uncertain assumptions, not with restrictions, known causes, or a predefined risk list.
It tests stated or implicit assumptions to uncover risks when those assumptions may be invalid.
Topic: Risk Identification
A hybrid medical-device software project has a fixed external validation test in 5 weeks. The sponsor has very low appetite for schedule risk after that date, and any delay over 3 days breaches the project’s threshold. A newly identified threat is that the API supplier may change its sandbox environment before the final integration sprint; if it does, validation would likely slip by 4 days. Historical data on supplier changes is limited. What is the BEST action?
Best answer: B
What this tests: Risk Identification
Explanation: The risk is tied to a specific near-term window and would breach the stated schedule threshold if it occurs, so its timing must be documented now. Limited historical data does not remove the need to prioritize and monitor a time-sensitive threat more closely.
This item tests identifying and documenting risk timing when it affects priority and monitoring. Here, the threat only matters if it occurs before the final integration sprint, and its impact would exceed the project’s 3-day threshold before a fixed validation date. That makes timing a decisive identification detail, not an optional note.
The best action is to capture the timing window, trigger, and consequence in the risk register and increase monitoring during that exposure period. Treating it as an issue is premature because the supplier change has not happened. Waiting for better probability data or reviewing it only monthly ignores the fact that the risk is time-bound and near a critical milestone.
Key point: when timing changes urgency, document it explicitly so prioritization and monitoring reflect the real exposure.
This best captures the risk’s time-sensitive exposure so it can be prioritized and monitored appropriately despite limited probability data.
Use the PMI-RMP Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PMI-RMP guide on PMExams.com, then return to PM Mastery for timed practice.