PMI Certified Associate in Project Management (CAPM)® Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the PMI Certified Associate in Project Management (CAPM)®. We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for PMI Certified Associate in Project Management (CAPM)®. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
PMI Certified Associate in Project Management (CAPM)®
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for PMI Certified Associate in Project Management (CAPM)®. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Project Management Fundamentals and Core Concepts
36%Project Life Cycles — Predictive vs Adaptive
Phase structure of a project; pick predictive, adaptive, or hybrid based on uncertainty and delivery needs.
Key Insight
Match life cycle to uncertainty: predictive for stable scope, adaptive for evolving requirements; hybrids mix both.
Often Confused With
Common Mistakes
- Assuming one life cycle is always superior — choice is context-driven.
- Treating process groups as project phases — they’re sets of activities used across phases.
- Believing predictive means requirements cannot change — controlled changes still occur.
WBS & Work Packages — Deliverable‑Oriented Breakdown
Hierarchical, deliverable-focused decomposition into work packages used for scope, estimating, and control.
Key Insight
WBS defines what will be delivered (scope), not when — work packages feed estimates and the schedule.
Often Confused With
Common Mistakes
- Confusing WBS with the schedule/Gantt — WBS is scope/deliverables, not sequencing.
- Thinking the WBS is fixed — it can be revised (especially in adaptive approaches) with control.
- Creating activity‑oriented WBS items — PMI expects deliverable‑oriented decomposition.
OPAs — Reuse, Tailor & Update
Organization-level templates, lessons, policies you select, tailor, and update per project.
Key Insight
OPAs are org-owned reusable assets you must validate and tailor — they aren't fixed project plans.
Often Confused With
Common Mistakes
- Assuming OPAs always exist and are complete
- Treating OPAs as immutable — don't update or tailor them
- Thinking reusing a past plan removes need for stakeholder review
EEFs — Constraints, Tools & Cultural Forces
Internal/external conditions (tools, culture, market, regs) that influence or enable project choices.
Key Insight
EEFs can constrain or enable; tool outputs still need expert judgment and depend on configuration/skill.
Often Confused With
Common Mistakes
- Treating EEFs as only constraints, ignoring enabling influences
- Confusing EEFs with OPAs (environment vs. organizational assets)
- Assuming tools automatically produce accurate estimates without judgment
Sponsor, Project Manager, Team — Role Boundaries
Sponsor owns funding/strategy and major decisions; Project Manager runs delivery; team performs the work and provides専門/
Key Insight
Authority vs responsibility: PM controls execution and day-to-day decisions; sponsor controls business decisions, scope/budget approvals, and escalati
Often Confused With
Common Mistakes
- Assuming the PM can unilaterally change scope or approve budget increases.
- Expecting the sponsor to manage day-to-day tasks and team assignments.
- Believing the PM has authority to redesign or operate organizational systems without escalation.
Stakeholders — Internal vs External, Roles & Limits
Classify stakeholders by internal/external status; contractors/partners require contracts, defined authority, and formal
Key Insight
Internal vs external differ in authority, contractual limits, onboarding, and influence — external parties still impact requiremen
Often Confused With
Common Mistakes
- Treating channel partners or contractors as internal employees with identical reporting.
- Skipping formal role definitions and relying on ad hoc task assignment.
- Assuming contractors need no separate onboarding, governance, or contractual controls.
Project Charter — Sponsor Authorization
Sponsor-issued document that authorizes the project, names the PM, and records high-level scope, objectives, assumptions
Key Insight
Grants formal authorization and limited PM authority to use org resources — it's high-level only, not a detailed plan.
Often Confused With
Common Mistakes
- Treating the charter as the detailed plan, schedule, or full budget
- Assuming the charter gives the PM unlimited authority to reassign resources or change scope
- Thinking the PM alone creates and approves the charter (the sponsor issues/authorizes it)
Initiating Process Group — Authorize & Identify
Formal processes (Develop Project Charter, Identify Stakeholders) to define a project/phase and obtain authorization to
Key Insight
Initiating authorizes work and identifies stakeholders — it starts the project but does NOT produce detailed baselines (planning does).
Often Confused With
Common Mistakes
- Equating Initiating with an informal kickoff meeting
- Expecting detailed scope, schedule, or cost baselines from Initiating
- Assuming PM authority exists before the charter is issued
Facilitation & Problem-Solving: Standups, Brainstorms, Workshops
Structured group methods to surface blockers, generate options, and drive fast decisions — pick the technique by purpose
Key Insight
Pick by objective: standups = quick sync/blockers; brainstorming = quantity of ideas, no critique; focus groups = qualitative stakeholder views;worksh
Often Confused With
Common Mistakes
- Turning daily standups into manager status reports
- Critiquing ideas during brainstorming's idea‑generation phase
- Expecting focus groups to produce statistically generalizable data
Root Cause Analysis (RCA): 5 Whys & Fishbone
Structured method to identify underlying causes so you fix systems, not just symptoms
Key Insight
RCA usually shows multiple contributing causes; separate identifying causes from implementing fixes; 5 Whys needs careful probing to avoid stopping at
Often Confused With
Common Mistakes
- Assuming RCA will reveal a single 'root' cause
- Relying on 5 Whys without probing deeper, ending at symptoms
- Using RCA to assign blame instead of designing system/process fixes
Project Life Cycles — Predictive vs Adaptive
Phase structure of a project; pick predictive, adaptive, or hybrid based on uncertainty and delivery needs.
Key Insight
Match life cycle to uncertainty: predictive for stable scope, adaptive for evolving requirements; hybrids mix both.
Often Confused With
Common Mistakes
- Assuming one life cycle is always superior — choice is context-driven.
- Treating process groups as project phases — they’re sets of activities used across phases.
- Believing predictive means requirements cannot change — controlled changes still occur.
WBS & Work Packages — Deliverable‑Oriented Breakdown
Hierarchical, deliverable-focused decomposition into work packages used for scope, estimating, and control.
Key Insight
WBS defines what will be delivered (scope), not when — work packages feed estimates and the schedule.
Often Confused With
Common Mistakes
- Confusing WBS with the schedule/Gantt — WBS is scope/deliverables, not sequencing.
- Thinking the WBS is fixed — it can be revised (especially in adaptive approaches) with control.
- Creating activity‑oriented WBS items — PMI expects deliverable‑oriented decomposition.
OPAs — Reuse, Tailor & Update
Organization-level templates, lessons, policies you select, tailor, and update per project.
Key Insight
OPAs are org-owned reusable assets you must validate and tailor — they aren't fixed project plans.
Often Confused With
Common Mistakes
- Assuming OPAs always exist and are complete
- Treating OPAs as immutable — don't update or tailor them
- Thinking reusing a past plan removes need for stakeholder review
EEFs — Constraints, Tools & Cultural Forces
Internal/external conditions (tools, culture, market, regs) that influence or enable project choices.
Key Insight
EEFs can constrain or enable; tool outputs still need expert judgment and depend on configuration/skill.
Often Confused With
Common Mistakes
- Treating EEFs as only constraints, ignoring enabling influences
- Confusing EEFs with OPAs (environment vs. organizational assets)
- Assuming tools automatically produce accurate estimates without judgment
Sponsor, Project Manager, Team — Role Boundaries
Sponsor owns funding/strategy and major decisions; Project Manager runs delivery; team performs the work and provides専門/
Key Insight
Authority vs responsibility: PM controls execution and day-to-day decisions; sponsor controls business decisions, scope/budget approvals, and escalati
Often Confused With
Common Mistakes
- Assuming the PM can unilaterally change scope or approve budget increases.
- Expecting the sponsor to manage day-to-day tasks and team assignments.
- Believing the PM has authority to redesign or operate organizational systems without escalation.
Stakeholders — Internal vs External, Roles & Limits
Classify stakeholders by internal/external status; contractors/partners require contracts, defined authority, and formal
Key Insight
Internal vs external differ in authority, contractual limits, onboarding, and influence — external parties still impact requiremen
Often Confused With
Common Mistakes
- Treating channel partners or contractors as internal employees with identical reporting.
- Skipping formal role definitions and relying on ad hoc task assignment.
- Assuming contractors need no separate onboarding, governance, or contractual controls.
Project Charter — Sponsor Authorization
Sponsor-issued document that authorizes the project, names the PM, and records high-level scope, objectives, assumptions
Key Insight
Grants formal authorization and limited PM authority to use org resources — it's high-level only, not a detailed plan.
Often Confused With
Common Mistakes
- Treating the charter as the detailed plan, schedule, or full budget
- Assuming the charter gives the PM unlimited authority to reassign resources or change scope
- Thinking the PM alone creates and approves the charter (the sponsor issues/authorizes it)
Initiating Process Group — Authorize & Identify
Formal processes (Develop Project Charter, Identify Stakeholders) to define a project/phase and obtain authorization to
Key Insight
Initiating authorizes work and identifies stakeholders — it starts the project but does NOT produce detailed baselines (planning does).
Often Confused With
Common Mistakes
- Equating Initiating with an informal kickoff meeting
- Expecting detailed scope, schedule, or cost baselines from Initiating
- Assuming PM authority exists before the charter is issued
Facilitation & Problem-Solving: Standups, Brainstorms, Workshops
Structured group methods to surface blockers, generate options, and drive fast decisions — pick the technique by purpose
Key Insight
Pick by objective: standups = quick sync/blockers; brainstorming = quantity of ideas, no critique; focus groups = qualitative stakeholder views;worksh
Often Confused With
Common Mistakes
- Turning daily standups into manager status reports
- Critiquing ideas during brainstorming's idea‑generation phase
- Expecting focus groups to produce statistically generalizable data
Root Cause Analysis (RCA): 5 Whys & Fishbone
Structured method to identify underlying causes so you fix systems, not just symptoms
Key Insight
RCA usually shows multiple contributing causes; separate identifying causes from implementing fixes; 5 Whys needs careful probing to avoid stopping at
Often Confused With
Common Mistakes
- Assuming RCA will reveal a single 'root' cause
- Relying on 5 Whys without probing deeper, ending at symptoms
- Using RCA to assign blame instead of designing system/process fixes
Predictive, Plan-Based Methodologies
17%Weak Matrix — Functional-Led Projects
Functional managers control resources and budgets; the PM coordinates part-time project work with limited authority.
Key Insight
PM is a coordinator (low resource authority); functional managers assign staff and control budgets.
Often Confused With
Common Mistakes
- Assuming the project manager has full authority over staff or budgets.
- Mixing up weak and balanced matrices — authority is NOT shared equally.
- Believing functional orgs can't run projects or have no silo/coordination issues.
Project-Oriented (Projectized) Org
Organization structured around projects: PMs have primary authority and staff are often dedicated to projects.
Key Insight
PM holds legitimate/reward power for the project (assigns work, controls resources) but still follows corporate policies.
Often Confused With
Common Mistakes
- Assuming the PM has unlimited, organization‑wide authority (HR/promotions).
- Thinking functional managers retain equal authority over dedicated project staff.
- Believing projectized structure alone guarantees better project outcomes.
Plan‑Based (Predictive) Control
Upfront scope, schedule and cost baselines; use CPM, float, compression and variance to control execution.
Key Insight
Baseline = control point — WBS defines scope, the schedule shows timing; changes require formal change control.
Often Confused With
Common Mistakes
- Mistake: Treat the WBS as the schedule — WBS is scope decomposition only.
- Mistake: Assume the plan cannot change — baselines can be revised via change control.
- Mistake: Ignore float because 'it doesn't matter' — float affects sequencing and risk decisions.
Critical Path Method (CPM)
Deterministic sequencing of activities to find the longest path, calculate floats, and set minimum project duration.
Key Insight
Activities with zero total float are schedule drivers; resource changes or uncertainty can create additional critical paths.
Often Confused With
Common Mistakes
- Mistake: Treat CPM finish date as guaranteed — CPM uses fixed estimates and ignores uncertainty.
- Mistake: Expect only one critical path — multiple or shifting critical paths are common.
- Mistake: Assume CPM handles resource limits — resource constraints need separate leveling or analysis.
EVM Formulas — PV/EV/AC → CV, SV, CPI, SPI, EAC
Quantifies cost and schedule performance: use PV, EV, AC to calculate CV/SV, CPI/SPI and choose the right EAC.
Key Insight
CPI = EV/AC (cost efficiency) and SPI = EV/PV (planned-value progress); pick EAC formula based on expected future performance.
Often Confused With
Common Mistakes
- Treating PV as money actually spent — PV is planned spending, not AC.
- Assuming CPI > 1 guarantees finishing under budget regardless of future performance.
- Interpreting SPI > 1 as literal time-ahead — SPI uses currency; use Earned Schedule for time conclusions.
Cost Baseline — Time‑phased Approved Budget (BAC)
The approved, time‑phased budget for WBS work packages (excludes management reserve); its total is the BAC used in EVM.
Key Insight
Cost baseline is a frozen, approved budget (sums to BAC) and changes only via formal change control; it is not raw estimates or funding limits.
Often Confused With
Common Mistakes
- Confusing baseline with initial activity estimates — estimates feed the baseline but aren’t the approved budget.
- Equating cost baseline with total project funding — it excludes management reserves and may differ from authorized funding.
- Expecting BAC to auto-update with actuals — BAC changes only through formal change control, not as AC accrues.
Agile Frameworks/Methodologies
20%Change Requests — Control the Baseline
Formal process to propose, analyze, authorize, and record changes to scope, schedule, cost, or deliverables.
Key Insight
All change types — increases, decreases, corrective, preventive — require documented requests and governance approval, not verbal consent.
Often Confused With
Common Mistakes
- Treating verbal or informal acceptance as an approved change.
- Only submitting requests for scope/cost increases; ignoring decreases or corrective actions.
- Thinking change control prevents all change instead of authorizing and recording allowed changes.
Agile Frameworks — Scrum, Kanban, XP, SAFe
Iterative approaches from single-team to enterprise scale; pick by team size, cadence, governance and architecture needs
Key Insight
Frameworks differ in prescribed roles, cadences, scaling mechanics and governance — Agile is a mindset, not a single recipe.
Often Confused With
Common Mistakes
- Assuming every agile method mandates the same roles (e.g., Product Owner/Scrum Master).
- Treating scaling as just more Scrum teams — ignoring architecture, governance and portfolio changes.
- Believing 'agile' means no planning or documentation.
Adaptive Task Management
Select, sequence, perform, and track iteration tasks inside a fixed timebox; adjust scope to deliver a usable increment.
Key Insight
Time is fixed each iteration — shrink scope or task detail to guarantee a releasable increment, not extend the timebox.
Often Confused With
Common Mistakes
- Treating the iteration as fixed-scope instead of fixed-timebox.
- Banning scope changes once an iteration starts (small, negotiated adjustments are allowed).
- Skipping basic documentation/traceability because 'it's informal'.
Backlog Refinement (Readying Work)
Ongoing team activity that adds detail, acceptance criteria, relative estimates and priority so items are ready for the次
Key Insight
Refinement is continuous and collaborative — 'Ready' = sized, testable, and prioritized for likely selection.
Often Confused With
Common Mistakes
- Treating refinement as a one-off meeting instead of continuous grooming.
- Assuming refined items are automatically committed to the next iteration.
- Expecting precise fixed estimates rather than relative/provisional sizing.
Adaptive Artifacts — Backlog, Burn Charts & Increments
Iterative artifacts that record prioritized scope, track remaining work, and show potentially releasable product slices.
Key Insight
Burn-down = remaining work; backlog is refined and can change; increment must be potentially releasable, not necessarily shipped.
Often Confused With
Common Mistakes
- Reading a burn-down as 'work done'—it plots remaining work; burn-up shows completed work.
- Treating the product backlog as fixed—it's continuously refined; sprint backlog is the short-term commitment.
- Assuming an increment must be immediately released—it only needs to meet 'Definition of Done' and be potentially releasable.
Kanban Board — Visual Flow & WIP Limits
A continuous-flow visual board (cards, columns, swimlanes) using WIP limits and policies to expose and manage bottleneks
Key Insight
WIP limits + explicit policies control flow; columns show stages not fixed iterations—measure throughput, not just task counts.
Often Confused With
Common Mistakes
- Calling Kanban a Scrum/sprint board—Kanban is continuous flow and does not require fixed-length sprints.
- Believing more columns always improve flow—extra states can hide bottlenecks, not solve them.
- Treating WIP limits as optional—they're the core mechanism to reveal constraints and improve throughput.
Scrum — Timeboxed Agile with 3 Accountabilities
Iterative Agile framework using timeboxed Sprints, three accountabilities, and inspect-and-adapt to deliver usable work.
Key Insight
Sprints are timeboxes that create a usable increment; Daily Scrum is for Developers to inspect progress toward the Sprint Goal.
Often Confused With
Common Mistakes
- Believing 'Scrum' is an acronym or a prescriptive checklist
- Assuming Sprints must always be two weeks long
- Using the Daily Scrum as a status report to the Scrum Master or manager
Kanban — Pull-based Flow with WIP Limits
Flow-focused method that visualizes workflow, enforces explicit policies and WIP limits to optimize cycle and lead time.
Key Insight
Kanban optimizes continuous flow via explicit workflow policies and strict WIP limits; it does not mandate timeboxed iterations.
Often Confused With
Common Mistakes
- Thinking Kanban means no planning or no defined process
- Expecting Kanban to require fixed-length sprints like Scrum
- Treating WIP limits as optional rather than the mechanism that reveals bottlenecks
Adaptive Task Prioritization — WSJF / MoSCoW / Kano
Order backlog items by value, time‑criticality, risk reduction, size and dependencies to maximize iterative delivery.
Key Insight
Prioritize for value and time‑sensitivity, not stakeholder noise; re-evaluate every iteration and balance size vs dependencies.
Often Confused With
Common Mistakes
- Treat stakeholder noise/urgency as highest priority
- Set priorities once and never re-evaluate each iteration
- Always pick smallest/fastest tasks first regardless of value or deps
WIP Limits (Kanban): Finish-First Flow Control
Caps on items in a workflow state to reduce multitasking, expose bottlenecks and improve predictability.
Key Insight
WIP limits force finishing and reveal constraints — properly set they increase flow and predictability, not always lower throughput.
Often Confused With
Common Mistakes
- Assume WIP limits always reduce overall throughput
- Treat WIP as per-person only instead of per column/lane or swimlane
- Raise limits ad hoc to hide issues instead of fixing bottlenecks
Business Analysis Frameworks
27%Stakeholder Engagement — Two‑Way Influence
Ongoing two‑way process of building relationships, aligning expectations, and collaborating to inform decisions and cut/
Key Insight
Engagement = dialogue + relationship; frequency alone doesn't equal effectiveness — tailor interactions by influence/interest.
Often Confused With
Common Mistakes
- Thinking engagement is just sending status updates
- Assuming only external parties (not team/sponsor) are stakeholders
- Believing more contact always means better engagement
Identify Stakeholders — Who Matters & Why
Iterative process to list people/groups affected by or affecting the project and capture their interests, influence and‑
Key Insight
Identification is iterative; the stakeholder register stores assessments (influence, interest, impact), not just names.
Often Confused With
Common Mistakes
- Doing stakeholder ID only during project initiation
- Recording only names/contacts in the stakeholder register
- Treating identification as the same as engagement planning
Communications Management (Plan → Validate → Measure)
Specify who needs what, when and how; build two‑way feedback, validation checks, acceptance criteria, and success métric
Key Insight
Make communications two‑way and measurable: define feedback method and acceptance criteria before distribution.
Often Confused With
Common Mistakes
- Leaving validation until project end; feedback must be continuous.
- Assuming documentation alone equals engagement or understanding.
- Using only opens/attendance as success metrics; ignore comprehension and acceptance.
Influence & Org Politics
Map power/interest, build coalitions, and tailor messaging to align stakeholders and reduce resistance.
Key Insight
Influence is not just top‑down — use coalitions, tailored messages and small wins; politics can be navigated ethically.
Often Confused With
Common Mistakes
- Relying only on the sponsor; ignoring grassroots influence and coalition-building.
- Avoiding politics entirely; failing to address real stakeholder interests.
- Using one generic message for everyone; not tailoring to motives or power level.
Elicitation Toolbox — User Stories, Use Cases & Methods
Techniques and artifacts to discover stakeholder needs; choose method by stakeholder, scope, and desired detail.
Key Insight
Match goal to method: user stories = lightweight value slices; use cases = detailed workflows; interviews = depth; surveys = breadth; workshops = real
Often Confused With
Common Mistakes
- Treating user stories and use cases as interchangeable.
- Relying on one technique (e.g., interviews) to capture all requirements.
- Assuming surveys only produce quantitative answers and miss nuance.
Product Backlog — Emergent, Prioritized Work List
Emergent, ordered list of product work — features, defects, technical & nonfunctional items — owned and prioritized by��
Key Insight
Backlog is emergent and value-prioritized by the Product Owner; it changes. Sprint backlog = the sprint's chosen subset and plan.
Often Confused With
Common Mistakes
- Treating the product backlog as a fixed scope document.
- Assuming the Scrum Master or dev team owns/prioritizes the backlog.
- Believing the backlog contains only user stories (excludes defects, tech work, NFRs).
BA Frameworks & Release Planning
Techniques BAs use to elicit, trace, validate requirements and map features into roadmaps and releases.
Key Insight
Frameworks connect requirements to outcomes — traceability and release planning apply in both predictive and adaptive projects.
Often Confused With
Common Mistakes
- Thinking roadmaps or release plans must lock exact delivery dates early
- Believing requirements traceability matrices are only for waterfall
- Assuming the business analyst and product owner roles are always the same
Product Roadmap — Vision to Releases
A high-level, living plan that sequences vision, goals, themes, time horizons and learning milestones for releases.
Key Insight
Roadmaps are strategic, flexible timelines (ranges/horizons) for alignment and learning — not task-level schedules.
Often Confused With
Common Mistakes
- Treating the roadmap as a detailed task-level schedule
- Using exact calendar dates for every feature instead of ranges
- Thinking an agile roadmap removes the need for planning or stakeholder alignment
Product Owner — Single‑Voice Value Owner
The single person accountable for maximizing product value by ordering the backlog, making scope decisions, and engaging
Key Insight
Only the named PO has final authority to order the backlog and decide value; proxies can act but not override that authority.
Often Confused With
Common Mistakes
- Treating the PO like a Project Manager who assigns daily tasks to the team.
- Allowing a committee or multiple people to act collectively as the PO.
- Assuming a BA acting as a proxy PO has the same decision authority as the named PO.
BA Role: Predictive vs Adaptive
Predictive: BA delivers upfront requirements, traceability, and sign-offs; Adaptive: BA facilitates continuous discovery
Key Insight
Predictive = document-first, trace and baseline requirements; Adaptive = continuous stakeholder facilitation, evolving artifacts, and quick feedback.
Often Confused With
Common Mistakes
- Assuming BA duties are identical in predictive and adaptive projects.
- Believing agile projects don't need a BA because the Product Owner handles all analysis.
- Thinking BAs only write requirements once in predictive projects and then disengage.
Requirements Validation (Inspect & Accept)
Confirm requirements are met and obtain stakeholder sign‑off using inspections, walkthroughs, and peer reviews.
Key Insight
Run lightweight reviews early to catch defects and create documented evidence — formal acceptance requires meeting criteria and sign‑off.
Often Confused With
Common Mistakes
- Only formal inspections count — walkthroughs/peer reviews are valid early evidence too.
- Assuming a milestone equals acceptance; acceptance needs criteria met and formal sign‑off.
- Believing reviews replace testing; reviews find defects, testing verifies behavior.
Acceptance Criteria (Testable Exit Conditions)
Explicit, measurable conditions a deliverable must meet for stakeholder acceptance and to drive verification tests.
Key Insight
Make every criterion testable and cover stated and implied needs — partial fulfilment does not equal acceptance.
Often Confused With
Common Mistakes
- Writing vague or high‑level criteria — each criterion must be measurable and verifiable.
- Leaving stakeholders or testers out — they must help define and approve criteria.
- Assuming some criteria met is enough — acceptance requires all agreed criteria satisfied.
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- PMI Professional in Business Analysis (PMI-PBA)® Cheat Sheet
- PMI Agile Certified Practitioner (PMI-ACP)® Cheat Sheet
- Google Cloud Certified Generative AI Leader Cheat Sheet
- PMI Construction Professional (PMI-CP)™ Cheat Sheet
- Project Management Institute Portfolio Management Professional (PfMP)® Examination Cheat Sheet
- IAPP Certified Information Privacy Manager (CIPM) Cheat Sheet