PK0-005 CompTIA Project+ Certification (2026) Exam Topics and Questions

Project Management Concepts is the largest single slice of the exam, and it earns that weight by covering almost every decision a project manager makes from kick-off to close. The domain is broad by design. You are expected to know not just what each process is, but when to apply it, who owns it, and what goes wrong when it is skipped or mis-sequenced. Gaps here cost more points than anywhere else on the exam.

– Methodology selection and change control

The exam does not reward you for knowing what agile and waterfall are in the abstract. It rewards you for knowing which one fits a given situation. The deciding factors are requirement stability, team composition, stakeholder involvement, and delivery cadence. A project with locked-down regulatory requirements and a single delivery date calls for a different approach than one where the client refines scope every two weeks. Know how communication patterns shift between the two: agile teams rely on daily stand-ups and sprint reviews, waterfall teams on formal status reports and milestone gates.

Change control is tested as a process, not a concept. You need to know the sequence: a change request is raised, assessed for impact, approved or rejected through a defined authority, and then tracked. The exam distinguishes between a project that applies change control and one that simply accepts changes informally. Scope creep is the predictable consequence of the latter, and items in this area often hinge on recognising that distinction.

– Risk, issues, and quality

Risk management and issue management sit close together but the exam treats them as separate tracks. Risk is forward-looking: you identify threats and opportunities, assign probability and impact, select a response strategy (avoid, transfer, mitigate, accept for threats; exploit, share, enhance, accept for opportunities), and assign an owner. Issue management is present-tense: something has already gone wrong, it is logged, assigned, resolved, and closed out. Confusing the two in an item is one of the most common ways candidates drop marks in this domain.

Quality and performance management covers both the agile and waterfall sides. On the agile side you need to distinguish what happens in a retrospective (the team's own process) from what happens in a sprint review (the deliverable shown to stakeholders). On the waterfall side, SLAs define the service standard, KPIs measure performance against it, and audits verify that the standard is being met. Testing cycles confirm the deliverable itself. Each of these has a different owner and a different trigger, and the exam exploits any blurring between them.

– Communication, meetings, and team management

Communication management covers the full lifecycle of a communication plan: identifying what information each stakeholder needs, choosing the right channel, setting the frequency, and confirming receipt. The exam tests the difference between push communication (you send it, the recipient may or may not engage) and pull communication (the information is available when the recipient wants it). Getting that distinction wrong in a scenario item is a reliable mark loss.

Meeting management is more procedural than it looks. An agenda sets scope, a timeboxing discipline keeps the meeting on track, roles (facilitator, note-taker, timekeeper) are assigned in advance, and action items are documented with owners and due dates. Items in this area reward candidates who know that a meeting without documented outcomes has not produced a decision.

Team and resource management asks you to identify when a skill gap exists, how to address it (training, hiring, reassigning), and how performance issues are handled. Procurement and vendor selection adds contract types and evaluation criteria. Know the difference between a fixed-price and a time-and-materials contract: the risk sits with a different party in each case.

– Schedule management

Schedule management runs through the entire project and the exam tests it at each stage. Milestones mark the completion of a phase or a deliverable, not a task. Activity sequencing requires you to understand dependency types: finish-to-start is the default, but finish-to-finish, start-to-start, and start-to-finish each appear in scenarios. Resource estimation feeds directly into the schedule, and candidates who treat it as a separate exercise tend to miss items that combine both.

The critical path is the longest sequence of dependent activities. Any delay on it delays the project end date. Float (or slack) is the amount of time an activity can slip before it affects the critical path. The exam tests your ability to apply these ideas in a scenario, not just define them. Know also that schedule compression techniques (crashing and fast-tracking) each carry a different type of risk: crashing adds cost, fast-tracking adds rework risk.

How Project Management Concepts is tested

At 33% of the exam, this domain produces more items than any other. Most of them are scenario-based: you are placed inside a project situation and asked what the project manager should do next, or what went wrong, or which document applies. The weight of the domain means you cannot afford to treat any of its sub-topics as optional reading.

Items in this domain reward candidates who can sequence a process correctly under pressure. The most common trap is selecting an action that is correct in isolation but wrong for the stage of the project described. A change request that would be valid in planning may be out of scope during execution, for example. Another frequent trap is conflating similar-sounding roles or documents: a risk register and an issue log are not interchangeable, and items are written to catch candidates who treat them as if they were.

The agile vs. waterfall sub-topic generates items where the scenario contains subtle cues about project type. Candidates who default to one methodology regardless of context lose marks consistently. Read the scenario for the cues before selecting.

Where the previous domain tests process knowledge in isolation, Project Life Cycle Phases tests whether you can place those processes in the right phase of the project. The distinction matters because the exam regularly puts a real activity in the wrong phase and asks you to identify the problem. At 30% of the exam, this domain is nearly as heavy as the first, and candidates who know their processes but cannot anchor them to a phase consistently drop marks here.

– Discovery and initiation

Discovery is the phase before the project is formally authorised. The business case is the key artifact: it justifies the project in terms of cost, benefit, and strategic fit. Prequalified vendor lists and high-level financial concepts (NPV, ROI, payback period) also appear here. The exam tests whether you know that these are inputs to the decision to start, not outputs of the planning phase.

Initiation begins when the project is approved. The project charter is the document that formally authorises the project and names the project manager. Without a charter, the project manager has no authority to commit resources. Stakeholder identification happens here too, because the later you identify a stakeholder, the more disruptive their requirements become. The responsibility assignment matrix (RAM), often expressed as a RACI chart, maps roles to deliverables. The kickoff meeting closes out initiation and opens planning. Items in this area test whether you know which document is produced first and which roles are defined at which point.

– Planning

Planning is the phase the exam tests most heavily within the life cycle, because it is where the most documents are produced and the most decisions are made. Resource assignment connects the WBS to named individuals or roles. The communication plan defines who gets what information, in what format, and how often. Scope definition produces the scope statement and the WBS; together they establish the authorised boundary of the project.

Schedule creation takes the WBS work packages, sequences them, estimates durations and resources, and produces the baseline schedule. Risk assessment during planning is different from risk management during execution: in planning you are building the risk register and defining response strategies, not yet responding to active risks. The exam distinguishes between these two activities and rewards candidates who apply the right one to the phase described in the scenario. A candidate who jumps to a risk response in a planning-phase scenario, or who treats a planning activity as an execution task, will find most items in this group going against them.

– Execution and closing

Execution is where the plan meets reality. Task management, vendor management, budget tracking, and conflict resolution all happen here. Phase gate reviews (also called stage gates or toll gates) are checkpoints within execution where the project is assessed before moving to the next phase. The exam tests whether you know that a phase gate is a go/no-go decision point, not a status update meeting.

Conflict during execution is tested in terms of resolution techniques. The exam distinguishes between confronting (problem-solving), compromising, smoothing, forcing, and avoiding, and items reward the technique that produces a lasting resolution rather than a temporary one.

Closing is the phase candidates underestimate most. Deliverable validation confirms that outputs meet the agreed acceptance criteria. Contracts must be formally closed, not just allowed to lapse. Resources are released in a documented way. Project documentation is archived so future projects can reference it. The closure meeting produces lessons learned. Items in this area reward candidates who treat closing as a structured phase, not an afterthought.

How Project Life Cycle Phases is tested

Items in this domain are almost always scenario-based and almost always contain a phase cue. The scenario will tell you, directly or indirectly, where the project is in its life cycle. Your job is to identify the correct action for that phase, not the correct action in general.

The most productive trap the exam sets here is the out-of-phase action. An activity that is entirely correct in planning looks wrong when the scenario places it in execution, and items are written to exploit that. Candidates who read quickly and select the action that sounds right in isolation, without checking the phase context, lose marks on items they could have answered correctly.

A second trap is document confusion. The business case, the project charter, the scope statement, and the project management plan are each produced at a specific phase. Items reward knowing which document authorises the project (the charter), which one justifies it (the business case), and which one governs how it will be managed (the project management plan). Closing phase items reward candidates who know that releasing resources and archiving documentation are formal activities, not informal wrap-up tasks.

After two domains that test decision-making and process knowledge, Tools and Documentation shifts the demand toward interpretation. You are given a chart, a log, or a diagram and asked what it tells you, or you are given a project situation and asked which tool fits it. The 19% weight means roughly one in five items will come from here. Candidates who have read about these tools but never worked with their outputs are the ones this domain catches.

– Project tracking tools

Gantt charts show tasks plotted against time, with dependencies indicated by the sequence of bars. The exam tests your ability to read one: which task is on the critical path, which has float, and what a delay in one activity does to the project end date. Burndown charts are the agile equivalent for tracking work remaining in a sprint or a release. A burndown that flattens or rises tells you work is being added or not completed at the expected rate.

PERT charts (program evaluation review technique) use three-point estimates (optimistic, most likely, pessimistic) to calculate expected duration. The formula is tested. Know it: (O + 4M + P) / 6. The issue log and the change log are running records of problems raised and changes requested respectively. A risk register captures identified risks, their probability and impact ratings, assigned owners, and chosen response strategies. Dashboards aggregate multiple metrics into a single view. Time-tracking tools record actual hours against planned hours. Items in this area test which tool answers which management question, not just what each tool is called.

– Productivity and quality tools

Productivity tools cover the platforms a project team uses to communicate, collaborate, document, schedule, and track work. The exam tests selection criteria: a synchronous meeting tool is the right choice when real-time discussion is needed; an asynchronous documentation platform is right when the team spans time zones and decisions need a written record. Ticketing tools are used to track tasks, defects, or requests through a defined workflow. The exam rewards knowing which tool type fits the communication or coordination need in the scenario.

Quality and performance charts each answer a different question. A histogram shows frequency distribution of a variable. A Pareto chart ranks causes by frequency or impact, applying the 80/20 principle to focus corrective effort. A scatter diagram shows the correlation between two variables. A fishbone (Ishikawa) diagram maps causes back to a root effect. Burnup charts track cumulative work completed against total scope, which makes scope changes visible in a way a burndown chart does not. Decision trees map choices and their probable outcomes. The exam tests your ability to match the analytical question to the chart that answers it.

How Tools and Documentation is tested

Items in this domain fall into two types. The first gives you a scenario and asks which tool or chart the project manager should use. The second gives you a chart or log entry and asks what it means for the project. Both types reward pattern recognition over memorisation.

For tool-selection items, the trap is selecting a tool that is adjacent to the right one. A Gantt chart and a PERT chart both involve scheduling, but they answer different questions. A burndown and a burnup chart both track sprint progress, but they surface different information. Items are written to distinguish candidates who know the difference from those who know only the category.

For interpretation items, the trap is over-reading. A scatter diagram that shows a weak correlation does not prove causation, and items reward candidates who resist the stronger claim. A Pareto chart that shows one cause at 60% does not mean the other causes are irrelevant, but it does tell you where to focus first.

The PERT formula is tested directly. Know it, apply it, and check your arithmetic before selecting.

The final domain shifts context. After three domains focused on project management process, Basics of IT and Governance asks whether you can manage a project that runs inside an IT environment and an organisational governance structure. At 18%, it is the smallest domain by weight, but candidates with a non-technical background find it the least familiar. The exam does not expect deep technical knowledge, but it does expect you to understand how IT constraints shape project decisions.

– Governance, ESG, and compliance

Environmental, social, and governance (ESG) considerations appear in project management when a project's outputs affect the environment, carry regulatory obligations, or touch the organisation's stated values or public reputation. The exam tests whether you can identify when an ESG factor is relevant to a project decision, not whether you can build an ESG framework from scratch.

Compliance and privacy cover the project manager's obligation to handle information lawfully. Confidentiality requirements define who can see project data. Privacy regulations (GDPR is the most cited example in IT project contexts) constrain how personal data is collected, stored, and disposed of. Legal impact means understanding that a compliance failure is not just a process problem: it carries liability. Items in this area reward candidates who treat compliance as a constraint on scope and schedule, not as a separate workstream managed by someone else. The exam does not require legal expertise, but it does require you to recognise when a legal or regulatory constraint changes a project decision.

– IT concepts and IT change control

IT concepts tested here are deliberately high-level. Infrastructure basics (on-premises vs. cloud, network components, server roles) appear in scenarios where the project manager needs enough vocabulary to communicate with technical team members and to understand project constraints. Cloud models (IaaS, PaaS, SaaS) appear because the choice of model affects procurement, vendor management, and security obligations. Software basics cover the distinction between custom development and commercial off-the-shelf solutions.

IT change control is distinct from project change control, and the exam tests that distinction directly. IT infrastructure change control governs changes to the production environment and typically requires a change advisory board (CAB) review. Software change control manages version control and code promotion. CI/CD (continuous integration/continuous deployment) is the practice of automating build, test, and deployment pipelines. The production vs. staging environment distinction matters because changes validated in staging still require a formal approval before promotion to production. Items reward candidates who apply IT change control as a constraint on the project schedule, not as a technical detail someone else handles.

How Basics of IT and Governance is tested

This domain generates items where the scenario contains an IT or governance detail that changes the project manager's decision. The technical detail is never the point in itself: the point is always what the project manager should do given that detail.

The most reliable trap in this domain is treating IT change control and project change control as the same process. They are not. A change that has been approved through the project's change control process may still require a separate CAB approval before it touches the production environment. Items reward candidates who know that both approvals may be required and that the IT change control step is not the project manager's to bypass.

ESG and compliance items reward candidates who recognise a regulatory constraint early and factor it into scope, schedule, or risk planning. The trap is treating the constraint as someone else's problem. Privacy and confidentiality items reward the candidate who identifies the correct handling obligation for the data type described in the scenario. Cloud and infrastructure items test vocabulary, not architecture: know what each cloud model implies for who manages what, and apply that to the scenario.