CAPM — PMI Certified Associate in Project Management Quick Review
Quick Review for PMI Certified Associate in Project Management (CAPM) candidates: high-yield concepts, traps, formulas, and practice focus.
Quick Review purpose
This Quick Review is for candidates preparing for the real PMI Certified Associate in Project Management (CAPM) exam from PMI, exam code CAPM. Use it to refresh high-yield concepts before working through topic drills, mock exams, and detailed explanations.
The CAPM rewards candidates who can do more than recognize terms. You need to connect project management vocabulary to realistic scenarios: which artifact is used, what the project manager should do next, which lifecycle fits the situation, and how to avoid common “sounds right but not best” answers.
This page is PM Mastery review support and companion practice guidance. It is not affiliated with PMI.
Exam identity
| Item | Details |
|---|---|
| Provider | PMI |
| Official exam title | PMI Certified Associate in Project Management (CAPM) |
| Exam code | CAPM |
| Best use of this page | Final concept refresh before original practice questions, topic drills, and mock exam review |
High-yield review map
| Area | Know cold | Common exam angle |
|---|---|---|
| Project fundamentals | Project vs operations, programs, portfolios, constraints, stakeholders, value | Identify what type of work is being described and who should act |
| Predictive project management | Charter, plan, baselines, WBS, schedule, budget, quality, risks, change control | Choose the next process, artifact, or control action |
| Agile and adaptive approaches | Scrum, Kanban, servant leadership, backlog, increments, velocity, WIP | Match adaptive practices to uncertain or changing work |
| Hybrid delivery | Combining predictive governance with adaptive execution | Decide which parts should be planned up front and which should evolve |
| Business analysis | Needs, requirements, elicitation, traceability, acceptance criteria | Separate business need, solution requirement, and acceptance validation |
| Formulas and metrics | EVM, PERT, communication channels, EMV, float | Interpret whether the project is ahead/behind or over/under budget |
| Scenario judgment | “First,” “best,” “next,” “most likely” | Avoid jumping to escalation, blame, or undocumented action |
Project management fundamentals
Project, program, portfolio, and operations
| Concept | Meaning | Exam trap |
|---|---|---|
| Project | Temporary effort that creates a unique product, service, or result | “Temporary” means the project ends, not necessarily that the result is short-lived |
| Operations | Ongoing, repetitive work that sustains the business | Operations can use project outputs, but they are not projects |
| Program | Related projects managed together for benefits not available separately | Do not treat a program as merely a large project |
| Portfolio | Projects, programs, and operations grouped to meet strategic objectives | Portfolio decisions are about strategic alignment and investment choices |
Core project constraints
CAPM questions often hide the real issue inside one constraint while distracting you with another.
| Constraint | Typical question signal | Review point |
|---|---|---|
| Scope | New features, unclear deliverables, acceptance disputes | Use requirements, scope statement, WBS, acceptance criteria, and change control |
| Schedule | Missed dates, dependencies, critical path, compression | Review sequencing, duration estimates, float, crashing, and fast tracking |
| Cost | Budget variance, reserves, cost estimates | Know cost baseline, contingency reserve, management reserve, and earned value basics |
| Quality | Defects, rework, inspection, prevention | Quality is meeting requirements, not automatically “premium grade” |
| Risk | Uncertain future event, probability, impact | Risk is proactive; issues are already happening |
| Resources | Skills, availability, conflict, team performance | Match staffing, development, conflict resolution, and recognition |
| Stakeholders | Resistance, expectations, communication needs | Analyze interest, influence, engagement, and communication preferences |
Organizational structures
| Structure | Project manager authority | Resource control | Typical clue |
|---|---|---|---|
| Functional | Low | Functional manager | Team members report mainly to department managers |
| Weak matrix | Low to moderate | Functional manager | Project coordinator or expediter language may appear |
| Balanced matrix | Shared | Shared | PM and functional manager both influence decisions |
| Strong matrix | Moderate to high | Project manager | PM has meaningful authority over work and priorities |
| Projectized | High | Project manager | Team is organized around projects |
Project manager behavior that is usually favored
In scenario questions, the best project manager usually:
- Uses documented processes before acting informally.
- Communicates early and appropriately.
- Engages stakeholders instead of avoiding conflict.
- Uses data, baselines, and agreed criteria.
- Facilitates team problem solving.
- Protects value and quality.
- Tailors the approach to the project context.
- Escalates only after reasonable project-level action is insufficient.
Delivery approach decision rules
Choosing the lifecycle is a frequent decision point. Focus on uncertainty, change frequency, stakeholder involvement, and ability to define requirements early.
flowchart TD
A[Start with product and project uncertainty] --> B{Requirements stable and well understood?}
B -- Yes --> C{Technology and work approach familiar?}
C -- Yes --> D[Predictive approach likely fits]
C -- No --> E[Hybrid may fit: plan governance, adapt technical work]
B -- No --> F{Frequent stakeholder feedback possible?}
F -- Yes --> G[Adaptive or agile approach likely fits]
F -- No --> H[Hybrid with discovery, prototypes, and staged decisions]
| Approach | Best fit | Weak fit | Key artifacts or practices |
|---|---|---|---|
| Predictive | Stable requirements, regulated sequence, clear scope | High uncertainty and frequent change | Charter, baselines, WBS, detailed plan, formal change control |
| Iterative | Need repeated refinement of solution | Work that must be fully defined once and delivered once | Prototypes, feedback cycles, evolving solution |
| Incremental | Need usable pieces delivered over time | Product cannot provide value until everything is complete | Increments, release planning, staged delivery |
| Adaptive/agile | Requirements change, discovery needed, high stakeholder involvement | Low collaboration or fixed detailed scope with no flexibility | Backlog, sprint/iteration, daily coordination, review, retrospective |
| Hybrid | Some elements stable, others uncertain | Organization cannot support mixed governance | Predictive milestones plus adaptive delivery cycles |
Predictive project management essentials
Initiating
High-yield idea: initiating authorizes the project and identifies key stakeholders. It does not create every detailed plan.
| Artifact | Purpose | Trap |
|---|---|---|
| Business case | Explains business need and justification | Usually created before or around project selection, not as a substitute for the project plan |
| Benefits management information | Describes expected benefits and how they may be measured | Benefits may continue after project closure |
| Project charter | Formally authorizes the project and names the project manager | A project manager should not spend heavily or direct major work before authorization |
| Stakeholder register | Identifies stakeholders and relevant information | It is updated as new stakeholders are discovered |
Planning
Planning defines how the project will be executed, monitored, controlled, and closed.
| Planning item | What to remember |
|---|---|
| Project management plan | Integrated plan made of subsidiary plans and baselines |
| Scope baseline | Approved scope statement, WBS, and WBS dictionary |
| Schedule baseline | Approved schedule used to measure schedule performance |
| Cost baseline | Approved time-phased budget, excluding certain management-level reserves |
| Requirements documentation | Captures stakeholder and solution requirements |
| Requirements traceability matrix | Links requirements to business needs, deliverables, tests, and acceptance |
| Risk register | Contains identified risks, analysis, owners, and responses |
| Communications plan | Defines who needs what information, when, how, and from whom |
| Stakeholder engagement plan | Plans how to move stakeholders toward desired engagement |
Executing
Executing is where the team performs the work and the project manager facilitates delivery.
Common executing activities:
- Direct and manage project work.
- Manage quality.
- Acquire, develop, and manage the team.
- Manage communications.
- Implement risk responses.
- Conduct procurements.
- Manage stakeholder engagement.
Exam trap: executing is not uncontrolled doing. Work should follow the approved plan, and problems should feed monitoring, controlling, or change control when needed.
Monitoring and controlling
Monitoring and controlling compares actual performance against the plan and recommends corrective action.
| If the question says… | Think… |
|---|---|
| Performance differs from baseline | Analyze variance and determine corrective or preventive action |
| Deliverable needs formal acceptance | Validate scope |
| Work results need inspection | Control quality |
| A requested change affects baseline | Submit and evaluate through change control |
| Risk trigger occurs | Implement risk response or handle as issue |
| Stakeholder engagement differs from plan | Adjust engagement and communication actions |
Closing
Closing confirms completion, acceptance, transition, records, lessons learned, and release of resources.
Common trap: closing is not only administrative. It includes formal acceptance, final reporting, procurement closure where applicable, archiving records, and capturing lessons learned.
Scope, requirements, and change control
Product scope vs project scope
| Concept | Meaning | Example |
|---|---|---|
| Product scope | Features and functions of the product, service, or result | What the software does |
| Project scope | Work required to deliver the product, service, or result | The project activities needed to build and release the software |
WBS essentials
The work breakdown structure is a hierarchical decomposition of the total project scope.
Remember:
- The WBS organizes deliverables and work packages.
- The WBS dictionary gives detail about WBS components.
- The scope baseline includes the approved scope statement, WBS, and WBS dictionary.
- The WBS is not the same as the schedule; activities are developed from work packages.
Integrated change control
When a requested change could affect scope, schedule, cost, quality, risk, or baselines, do not simply “do the work.”
Typical sequence:
- Document the change request.
- Assess impact on scope, schedule, cost, quality, resources, risk, and stakeholders.
- Submit to the appropriate change control authority.
- Communicate the decision.
- Update plans, baselines, and documents if approved.
- Implement and verify the approved change.
Common trap: “The customer is important, so implement immediately” is usually wrong if the change affects approved baselines.
Schedule review
Dependencies
| Dependency type | Meaning | Example clue |
|---|---|---|
| Mandatory | Inherent or legally/contractually required | Foundation before walls |
| Discretionary | Preferred or best-practice sequence | Team chooses one design review before another |
| External | Dependency outside project control | Vendor or regulator action |
| Internal | Dependency within project control | Team A must finish before Team B starts |
Leads and lags
| Term | Meaning | Trap |
|---|---|---|
| Lead | Successor can start before predecessor fully finishes | Lead accelerates overlap |
| Lag | Waiting time between activities | Lag adds delay |
Critical path and float
The critical path is the longest path through the network and usually determines the shortest project duration. Activities on the critical path generally have zero total float, but always rely on the data in the question.
| Metric | Plain-language formula |
|---|---|
| Total float | LS - ES, or LF - EF |
| Free float | Time an activity can slip without delaying the early start of its successor |
| Critical path | Longest path through the project network |
Schedule compression
| Technique | Meaning | Main risk |
|---|---|---|
| Crashing | Add resources to shorten duration | Higher cost; may not work for all activities |
| Fast tracking | Perform activities in parallel that were planned sequentially | Increased rework and risk |
Cost and earned value review
Key cost terms
| Term | Meaning |
|---|---|
| Rough order estimate | Early estimate with limited detail |
| Definitive estimate | More detailed estimate when information is better known |
| Contingency reserve | Budget for identified risks, often controlled within the project |
| Management reserve | Budget for unknown unknowns, usually outside the cost baseline |
| Cost baseline | Approved budget used to measure cost performance |
Earned value basics
Know the meaning before memorizing formulas.
| Metric | Meaning | Interpretation |
|---|---|---|
| PV | Planned Value: budgeted value of work planned | What should have been earned by now |
| EV | Earned Value: budgeted value of work actually completed | Value of completed work |
| AC | Actual Cost: actual cost incurred | What has been spent |
| CV | Cost Variance = EV - AC | Positive is under budget; negative is over budget |
| SV | Schedule Variance = EV - PV | Positive is ahead of schedule; negative is behind schedule |
| CPI | Cost Performance Index = EV / AC | Greater than 1 is favorable |
| SPI | Schedule Performance Index = EV / PV | Greater than 1 is favorable |
| EAC | Estimate at Completion | Forecasted total cost |
| VAC | Variance at Completion = BAC - EAC | Positive is favorable |
High-yield formulas:
\[ \text{CV} = \text{EV} - \text{AC} \]\[ \text{SV} = \text{EV} - \text{PV} \]\[ \text{CPI} = \frac{\text{EV}}{\text{AC}} \]\[ \text{SPI} = \frac{\text{EV}}{\text{PV}} \]Fast interpretation rule:
- Variance: positive is generally good.
- Index: greater than 1 is generally good.
- If EV is lower than PV, the project has earned less value than planned.
- If AC is higher than EV, the project spent more than the value earned.
Quality review
Quality vs grade
| Concept | Meaning | Example |
|---|---|---|
| Quality | Degree to which requirements are met | A basic product that meets all requirements can be high quality |
| Grade | Category or rank of features | A luxury version may be higher grade |
Do not assume higher grade means higher quality.
Prevention, inspection, and cost of quality
| Concept | Meaning | Exam point |
|---|---|---|
| Prevention | Avoid defects before they happen | Usually preferred over inspection |
| Inspection | Find defects after work is done | Necessary but not as efficient as building quality in |
| Cost of conformance | Money spent to prevent defects | Training, process improvement, testing |
| Cost of nonconformance | Money lost due to defects | Rework, warranty, reputation damage |
Quality assurance vs quality control
| Term | Focus |
|---|---|
| Manage quality / quality assurance | Process effectiveness and quality practices |
| Control quality | Inspecting and verifying deliverables meet requirements |
Resource and team review
Team development
A common model describes team progression as forming, storming, norming, performing, and adjourning.
| Stage | Clue | Project manager focus |
|---|---|---|
| Forming | Team is polite, uncertain, looking for direction | Clarify goals, roles, working agreements |
| Storming | Conflict, disagreement, competition | Facilitate conflict resolution |
| Norming | Team establishes norms and trust | Reinforce collaboration |
| Performing | Team works effectively and independently | Remove impediments, support performance |
| Adjourning | Work ends, team disbands | Recognition, lessons learned, transition |
Conflict resolution
| Technique | Meaning | When it is attractive |
|---|---|---|
| Collaborate / problem solve | Work together for a win-win solution | Usually best for important issues |
| Compromise | Each side gives something up | Useful when time is limited and both can accept tradeoff |
| Smooth / accommodate | Emphasize agreement, downplay disagreement | Temporary or low-priority issues |
| Force / direct | One side wins | Emergency or when authority must decide |
| Withdraw / avoid | Postpone or retreat | Rarely best for important unresolved issues |
Exam trap: “Avoid the conflict” is seldom best when the conflict affects project objectives or team performance.
Responsibility assignment
A RACI chart clarifies roles:
| Letter | Meaning |
|---|---|
| R | Responsible: does the work |
| A | Accountable: owns the outcome or decision |
| C | Consulted: provides input |
| I | Informed: kept updated |
Communications review
Communication questions often test the method, not just the message.
| Method | Best use | Example |
|---|---|---|
| Interactive | Real-time multidirectional communication | Meeting, call, workshop |
| Push | Sent to recipients | Email, memo, report |
| Pull | Recipients access when needed | Portal, knowledge base, dashboard |
Communication channel formula:
\[ \text{Number of communication channels} = \frac{n(n-1)}{2} \]Where \(n\) is the number of people.
Common trap: adding one stakeholder increases channels by more than one because that person can communicate with every existing person.
Risk review
Risk vs issue
| Concept | Meaning | Response |
|---|---|---|
| Risk | Uncertain future event | Analyze and plan response |
| Issue | Current problem or event that has occurred | Manage and resolve now |
Threat responses
| Response | Meaning |
|---|---|
| Avoid | Change plan to eliminate the threat |
| Mitigate | Reduce probability or impact |
| Transfer | Shift impact to a third party, often through contract or insurance |
| Accept | Take no proactive action beyond monitoring or reserve |
| Escalate | Move outside project authority when appropriate |
Opportunity responses
| Response | Meaning |
|---|---|
| Exploit | Ensure the opportunity happens |
| Enhance | Increase probability or positive impact |
| Share | Allocate ownership to a party best able to capture it |
| Accept | Take advantage if it occurs |
| Escalate | Move outside project authority when appropriate |
Expected monetary value:
\[ \text{EMV} = \text{Probability} \times \text{Impact} \]For decision trees, multiply each outcome by its probability and sum the results for each option.
Procurement review
Contract types
| Contract type | Buyer risk | Seller risk | Best fit |
|---|---|---|---|
| Fixed price | Lower if scope is clear | Higher if seller underestimates | Well-defined scope |
| Cost reimbursable | Higher | Lower | Uncertain or evolving work |
| Time and materials | Moderate; can grow without control | Moderate | Staff augmentation or unclear duration |
Common traps:
- Fixed price is not automatically best; unclear scope can cause disputes and change requests.
- Cost reimbursable does not mean uncontrolled spending; it still needs oversight.
- Procurement documents should match the type of work and the desired risk allocation.
Stakeholder review
Identify, analyze, engage
| Activity | Purpose |
|---|---|
| Identify stakeholders | Determine who can affect or be affected by the project |
| Analyze stakeholders | Understand interest, influence, power, expectations, and impact |
| Plan engagement | Decide how to move stakeholders toward desired engagement |
| Manage engagement | Communicate, address concerns, and involve stakeholders |
| Monitor engagement | Compare actual engagement to desired engagement |
Stakeholder engagement levels
| Level | Meaning |
|---|---|
| Unaware | Does not know about the project or impact |
| Resistant | Aware but opposed |
| Neutral | Aware but neither supportive nor resistant |
| Supportive | Aware and supportive |
| Leading | Actively helps the project succeed |
Exam trap: the best answer is often to engage, understand concerns, and communicate value—not ignore resistance or escalate immediately.
Agile and adaptive essentials
Agile mindset
Agile questions usually favor:
- Frequent delivery of usable value.
- Close customer or stakeholder collaboration.
- Welcoming change when it improves value.
- Self-organizing, empowered teams.
- Transparency through visual work and regular feedback.
- Continuous improvement through retrospectives.
Agile does not mean no planning. It means planning is continuous and adaptive.
Scrum review
| Element | Purpose |
|---|---|
| Product owner | Maximizes product value and orders the product backlog |
| Scrum master | Facilitates Scrum, removes impediments, supports the team |
| Developers / team | Build the increment |
| Product backlog | Ordered list of product work |
| Sprint backlog | Work selected for the sprint plus delivery plan |
| Increment | Usable completed work that meets the Definition of Done |
| Sprint planning | Decide what can be delivered and how |
| Daily Scrum | Short daily inspection and adaptation by the team |
| Sprint review | Inspect increment and adapt backlog with stakeholders |
| Sprint retrospective | Improve process and teamwork |
Common trap: the daily Scrum is not a status meeting for the project manager. It is for the team to coordinate.
Kanban review
| Concept | Meaning |
|---|---|
| Visual board | Makes work visible |
| WIP limit | Limits work in progress to improve flow |
| Pull system | Work is pulled when capacity exists |
| Cycle time | Time from starting work to finishing it |
| Lead time | Time from request to delivery |
| Bottleneck | Constraint slowing flow |
Common trap: adding more work to a clogged system usually worsens flow. Reduce WIP and address bottlenecks.
Agile estimation and tracking
| Metric or practice | Meaning | Trap |
|---|---|---|
| Story points | Relative estimate of effort, complexity, and uncertainty | Do not compare points directly across unrelated teams |
| Velocity | Amount of work completed in an iteration | Useful for forecasting, not as a performance weapon |
| Burndown chart | Shows work remaining over time | A flat line signals little completed work |
| Burnup chart | Shows work completed and may show scope changes | Helps reveal expanding scope |
| Definition of Done | Shared quality/completion standard | “Almost done” is not done |
| Acceptance criteria | Conditions a story or requirement must meet | Used to confirm the right outcome |
User stories
A common user story pattern is:
“As a [user], I want [capability], so that [benefit].”
Good user stories are small enough to complete, testable, valuable, and understood by the team. Acceptance criteria clarify when the story satisfies the need.
Hybrid project management
Hybrid questions test tailoring. A project can use predictive planning for governance, funding, compliance, or major milestones while using agile delivery for uncertain product features.
| Situation | Likely approach |
|---|---|
| Fixed regulatory deadline, uncertain product design | Hybrid |
| Stable construction sequence with defined plans | Predictive |
| New digital product with evolving customer feedback | Adaptive |
| Hardware component fixed, software features evolving | Hybrid |
| Research or discovery work with unknown solution | Iterative or adaptive |
Common trap: do not force every project into agile. The best approach depends on uncertainty, risk, stakeholder availability, and organizational needs.
Business analysis essentials
Need, requirement, and solution
| Term | Meaning |
|---|---|
| Business need | Problem or opportunity that justifies action |
| Requirement | Condition or capability needed by a stakeholder or solution |
| Solution | Product, service, or result that satisfies the need |
| Acceptance criteria | Conditions used to determine whether a requirement is satisfied |
Requirement types
| Requirement type | Focus |
|---|---|
| Business requirements | High-level organizational needs |
| Stakeholder requirements | Needs of a stakeholder group |
| Solution requirements | Functional and nonfunctional capabilities |
| Functional requirements | What the solution must do |
| Nonfunctional requirements | Quality attributes such as performance, security, usability |
| Transition requirements | Temporary capabilities needed to move from current to future state |
Elicitation techniques
| Technique | Best use |
|---|---|
| Interviews | Deep individual insight |
| Workshops | Shared understanding and alignment |
| Observation | Discover actual work practices |
| Surveys | Broad input from many people |
| Document analysis | Understand existing rules, processes, and systems |
| Prototypes | Clarify uncertain or visual requirements |
Verification vs validation
| Concept | Question to ask |
|---|---|
| Verification | Is the requirement or deliverable built correctly according to specification? |
| Validation | Does it meet the business need and stakeholder expectations? |
Common trap: a requirement can be documented clearly and still fail to solve the real business problem.
Formula quick sheet
PERT expected duration
\[ \text{Expected duration} = \frac{O + 4M + P}{6} \]Where:
- \(O\) = optimistic estimate
- \(M\) = most likely estimate
- \(P\) = pessimistic estimate
Communication channels
\[ \text{Channels} = \frac{n(n-1)}{2} \]Earned value interpretation
| If… | Meaning |
|---|---|
| CV is positive | Under budget |
| CV is negative | Over budget |
| SV is positive | Ahead of schedule |
| SV is negative | Behind schedule |
| CPI greater than 1 | Cost efficiency is favorable |
| CPI less than 1 | Cost efficiency is unfavorable |
| SPI greater than 1 | Schedule efficiency is favorable |
| SPI less than 1 | Schedule efficiency is unfavorable |
Common CAPM candidate traps
Trap 1: Memorizing terms without context
Many wrong answers use correct vocabulary in the wrong situation. Practice identifying the project phase, lifecycle, artifact, and decision point before choosing.
Trap 2: Skipping change control
If an approved baseline may change, use formal change control. Do not implement just because the sponsor, customer, or senior stakeholder requested it.
Trap 3: Confusing risks and issues
A risk may happen. An issue has happened. Risk responses are planned proactively; issue management is immediate and corrective.
Trap 4: Treating agile as unplanned work
Agile uses planning, prioritization, quality standards, reviews, and retrospectives. It is adaptive, not chaotic.
Trap 5: Choosing escalation too quickly
Escalation can be correct, but only when the matter exceeds the project manager’s authority or reasonable project-level action has failed.
Trap 6: Ignoring stakeholders
Stakeholder resistance usually calls for analysis, engagement, communication, and understanding—not avoidance.
Trap 7: Misreading “best,” “first,” and “next”
- First often means identify, document, assess, or understand before acting.
- Next means the immediate logical step in the process.
- Best means the most professional, proactive, and process-aligned answer.
- Most likely asks for diagnosis, not necessarily the ideal action.
Scenario-answering checklist
Use this quick mental sequence on practice questions:
- Identify the lifecycle. Predictive, agile, or hybrid?
- Find the moment. Initiating, planning, executing, monitoring/controlling, or closing?
- Name the issue. Scope, schedule, cost, quality, risk, resources, communications, procurement, stakeholder, or business analysis?
- Look for the artifact. Charter, plan, baseline, backlog, risk register, stakeholder register, requirements traceability matrix, etc.
- Apply the rule. Change control, stakeholder engagement, risk response, team facilitation, or value delivery?
- Eliminate weak answers. Ignore, blame, act without approval, gold-plate, over-escalate, or skip analysis.
- Choose the most professional next step.
Practice focus before exam day
Use this Quick Review as a checklist, then move into PM Mastery practice:
| Practice activity | Goal |
|---|---|
| Topic drills | Isolate weak areas such as EVM, agile roles, risk responses, or requirements |
| Original practice questions | Build recognition of realistic scenario patterns |
| Mock exams | Practice timing, stamina, and mixed-topic decision-making |
| Detailed explanations | Learn why the best answer is best and why distractors are wrong |
| Error log | Track repeated mistakes by concept and question wording |
A strong final review cycle is: read this Quick Review, complete focused topic drills, review detailed explanations, then sit for a mixed mock exam and update your error log.
Practical next step
Start with a short set of CAPM topic drills in your weakest area, then review every explanation carefully—especially for questions where two answers seemed plausible.
Continue in PM Mastery
Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official PMI questions, copied live-exam content, or exam dumps.