# Risk Management — Quiz

## Question 1

A risk is best defined as:

A) Something that has already gone wrong
B) An uncertain event that, if it occurs, affects project objectives
C) A guarantee of project failure
D) A problem that needs immediate fixing

<!-- ANSWER: B -->
<!-- EXPLANATION: A risk is characterized by uncertainty—it might or might not occur. If it occurs, it has an effect (positive or negative) on project objectives. Problems are current; risks are potential future events. -->

## Question 2

In a risk matrix, a "high probability, high impact" risk should typically be:

A) Accepted
B) Monitored only
C) Avoided, transferred, or aggressively mitigated
D) Documented for later

<!-- ANSWER: C -->
<!-- EXPLANATION: High-probability, high-impact risks pose the greatest threat. The priority is to avoid (change approach), transfer (insurance, contract), or mitigate (reduce prob/impact). Accept is for lower-priority risks. -->

## Question 3

The "Transfer" risk response strategy means:

A) Moving the risk to another project
B) Shifting the impact to another party (e.g., insurance, contract)
C) Delegating the risk to a junior team member
D) Ignoring the risk

<!-- ANSWER: B -->
<!-- EXPLANATION: Transfer shifts the impact to another party. Examples: insurance, warranties, penalty clauses in contracts, SLAs. The risk may still occur, but the financial or operational impact is borne by someone else. -->

## Question 4

A pre-mortem is useful because:

A) It predicts the future
B) It helps people imagine failure and surface risks they might not otherwise consider
C) It eliminates all risks
D) It replaces the need for a risk register

<!-- ANSWER: B -->
<!-- EXPLANATION: In a pre-mortem, you imagine the project has already failed and ask "what went wrong?" This counterfactual framing helps people think more honestly about threats. It surfaces assumptions and blind spots. -->

## Question 5

When communicating risks to stakeholders, you should:

A) Only share risks when they become problems
B) Lead with context, pair risks with responses, and avoid alarmism
C) Use dramatic language to get attention
D) Hide technical risks from non-technical stakeholders

<!-- ANSWER: B -->
<!-- EXPLANATION: Effective risk communication builds trust. Lead with context ("here's what we're tracking"), pair each risk with your response plan, and maintain a calm tone. Avoid surprises; surface early. Frame as "we're on it." -->

## Question 6

Dependency mapping helps identify risks because:

A) It shows the project timeline
B) Each dependency is a potential failure point
C) It replaces the risk register
D) It guarantees no integration issues

<!-- ANSWER: B -->
<!-- EXPLANATION: Dependencies—external APIs, vendors, other teams, legacy systems—are points of reliance. If a dependency fails, your project is affected. Mapping dependencies surfaces "what if X fails?" risks systematically. -->