CAPM Certified Associate in Project Management Exam Topics and Questions

This topic carries more weight than any other on the exam, and it shows. You face questions on life cycles, scope, roles, ethics, planning, and closure. The breadth is the problem: you need working knowledge across twenty-seven sub-topics, and a gap in any one of them costs marks.

– Life cycles, approaches, and the shape of projects

You need to distinguish project from programme from portfolio, and project from operations. The exam tests these boundaries by presenting scenarios where the line is unclear. Predictive and adaptive approaches appear throughout the syllabus, but the foundational contrast lives here: when each is appropriate, what each demands, and how they differ in planning and control. Life cycles and processes form the scaffolding. You also distinguish issues from risks from assumptions from constraints, a set of definitions that recur in every domain but are examined most directly in this topic. Scope review appears here too, and the ability to critique it rather than simply accept it.

– Planning, deliverables, and the mechanics of control

Project management planning sits at the centre of this group. You explain its purpose, describe why cost, quality, risk, and schedule matter, and distinguish the deliverables of a project management plan from those of a product management plan. Milestones and task durations are not the same thing, and the exam will test that distinction in context. You determine resource numbers and types, use a risk register, and use a stakeholder register. Each of these is a practical skill: given a situation, you apply the right artifact and interpret what it tells you. Closure and transitions close the loop, covering how a project ends and what happens to its outputs.

– Roles, responsibilities, and the human side of delivery

The project manager's role is multifaceted: initiator, negotiator, listener, coach, working member, facilitator. You compare it to the sponsor's role, and compare the project team's responsibilities to the sponsor's. Leadership and management are not interchangeable, and the exam expects you to explain the difference. Emotional intelligence appears here, with its impact on how a project is run and how people respond. These are not soft skills treated lightly. The exam tests them with scenarios where a manager's choice of approach changes the outcome.

– Strategy, frameworks, and solving problems

Following and executing planned strategies or frameworks is one skill; knowing when and how to respond to them is another. Communication plans, risk frameworks, and other structured approaches appear throughout a project, and you demonstrate understanding of both adherence and adaptation. Problem-solving tools and techniques are tested through application, not definition. You evaluate whether a meeting was effective, explain the purpose of focus groups, standup meetings, and brainstorming, and show that you know when each is the right choice. Project initiation and benefit planning open the project properly, and the exam expects you to understand why they matter before any work begins.

How Project Management Fundamentals and Core Concepts is tested

Thirty-six percent of the exam comes from this topic, so expect it in every section. Items present a scenario and ask you to choose the correct response based on roles, definitions, or the application of a tool. The most common trap is choosing the answer that sounds right in principle but ignores the context. A risk register is not always the right response, and a project manager is not always the person who decides. Another frequent mistake is confusing similar terms: milestone and duration, issue and risk, leadership and management. The exam writes stems that make both plausible, and only one is correct. You lose marks when you default to a memorised definition instead of reading the scenario. The weight of this topic means that weak coverage here limits your overall score, even if you perform well elsewhere. Every sub-topic is in scope, and the exam samples across all of them.

Where fundamentals span all approaches, this topic narrows to the predictive, plan-based world. You explain when it suits the work, when it suits the organisation, and how to execute it. Seventeen percent of the exam tests your ability to apply the mechanics: critical path, variance calculations, work breakdown structures, and the artifacts that control a traditional project.

– Suitability, structure, and when to choose predictive delivery

You explain when a predictive approach is appropriate, and that explanation depends on the nature of the work and the clarity of requirements. Organisational structure matters: virtual, colocated, matrix, hierarchical environments each create different conditions, and the exam expects you to identify which structures support plan-based delivery and which do not. This is not about preference. The question is whether the approach fits the constraints, the culture, and the reporting lines. You also determine the activities within each process and give examples of typical activities. The emphasis is on distinguishing between project components so that you can describe what happens in each phase and why the sequence matters.

– Schedules, critical path, and the work breakdown

A project management plan schedule is more than a list of dates. You demonstrate understanding of how it is built, what it controls, and how it changes. Critical path methods are tested through application: given a network of tasks, you identify the path that determines the project's duration. Schedule variance is a calculation, and the exam gives you the data. Work breakdown structures and work packages form the foundation of scope control. You explain what a WBS is, how it decomposes deliverables, and what a work package contains. These are not definitions to recite but tools to apply when a scenario presents unclear scope or contested deliverables.

– Plans, controls, and artifacts in predictive projects

Quality management plans and integration management plans are applied, not described. You show that you know what each one governs and how it shapes decisions during delivery. Documenting project controls is a skill tested in context: given a predictive project, you determine how progress is tracked, how changes are managed, and what gets recorded. Artifacts are the tangible outputs, and you identify which ones belong in a plan-based project. Cost and schedule variances are both tested through calculation. The exam provides earned value data or baseline comparisons, and you work out whether the project is over or under, ahead or behind. Errors come from misapplying the formula or misreading the scenario, not from the arithmetic.

How Predictive, Plan-Based Methodologies is tested

Seventeen percent means roughly one question in six. Items present a scenario and ask you to apply a technique, calculate a variance, or choose the correct artifact. The most common mistake is selecting an agile or adaptive response when the project is explicitly plan-based. The exam makes the context clear, but candidates default to the approach they know best. Another trap is miscalculating variance: the formula is straightforward, but the stem may present earned value, planned value, and actual cost in a way that requires careful reading. Critical path items often include a diagram or a table of tasks with durations and dependencies. You lose marks if you misidentify the longest path or confuse total float with free float. The weight is moderate, but the topic is technical, and errors are unforgiving. You need accuracy, not approximation.

Adaptive approaches take a fifth of the exam. You explain when to use them, how they differ from predictive delivery, and how to apply their mechanics. The topic tests iteration planning, tracking, prioritisation, and the ability to distinguish Scrum from XP from SAFe from Kanban when it matters.

– When adaptive works and when it does not

You explain when an adaptive approach is appropriate, and the answer depends on requirements volatility, stakeholder availability, and the organisation's capacity to support iterative delivery. Comparing the pros and cons of adaptive and predictive projects is not a theoretical exercise. The exam gives you a scenario and asks which approach fits. Organisational structure appears again: virtual, colocated, matrix, hierarchical. Some structures suit adaptive work, others resist it. You identify which is which and explain why. Organisational process assets and enterprise environmental factors either facilitate adaptive approaches or block them. The exam expects you to recognise the enablers and the obstacles, because choosing an approach without checking the environment is a common source of project failure.

– Iterations, scope, and translating structure into adaptive delivery

Planning project iterations means deciding what gets built, in what order, and in what increment. You distinguish the logical units of iterations, interpret their pros and cons, and translate a work breakdown structure into an adaptive iteration. That translation is a practical skill: given a WBS from a predictive plan, you determine how to break it into timeboxed increments. Inputs for scope come from the backlog, from stakeholder feedback, and from the iteration review. You determine what those inputs are and how they shape the next cycle. This is not about running a sprint. It is about understanding how scope is managed when it is not fixed at the start.

– Tracking, controls, and artifacts in adaptive projects

Adaptive project tracking differs from predictive tracking in cadence, in granularity, and in what gets measured. You explain why that difference matters and what it changes about control. Documenting project controls for an adaptive project means capturing velocity, burn-down, impediments, and retrospective actions, not variance against a baseline. Artifacts used in adaptive projects include backlogs, iteration plans, and task boards. You identify which artifact serves which purpose. The components of an adaptive plan are tested directly: what it contains, what it does not, and how it evolves. You also distinguish between Scrum, XP, SAFe, and Kanban. The exam does not ask for a history lesson, but it does expect you to know which framework uses which ceremonies, roles, and artifacts.

– Task management, success criteria, and prioritisation

Preparing and executing task management steps means breaking work into units that fit an iteration and ensuring each unit is ready to start. You interpret success criteria for an adaptive task: what done means, who decides, and how acceptance is confirmed. Prioritisation is tested more heavily here than anywhere else. Given a backlog and a set of constraints, you determine what gets built first. The exam presents competing priorities, stakeholder demands, technical dependencies, and risk, then asks you to sequence the work. Errors come from prioritising by preference rather than by value, or from ignoring a dependency that blocks downstream work.

How Agile Frameworks/Methodologies is tested

Twenty percent means one question in five. Items ask you to choose the right adaptive technique, distinguish one framework from another, or prioritise a backlog. The most common trap is applying Scrum terminology to a Kanban scenario, or assuming all adaptive projects use sprints. The exam specifies the framework, and your answer must match it. Another frequent mistake is prioritising by effort or by stakeholder rank rather than by value or risk. The stem gives you enough information to decide, but candidates often default to intuition instead of analysis. Iteration planning items present a WBS or a set of requirements and ask how to structure the work. You lose marks if you create iterations that are too large, too small, or that ignore dependencies. Success criteria items test whether you know what done means in an adaptive context, and the wrong answer is usually the one that assumes completion equals deployment.

Business analysis takes just over a quarter of the exam, second only to fundamentals in weight. You demonstrate understanding of BA roles, stakeholder communication, requirements gathering, traceability, product roadmaps, and validation. The topic spans both adaptive and predictive contexts, and the exam expects you to know how methodology changes the BA's work.

– Roles, responsibilities, and why stakeholders matter

You demonstrate understanding of business analysis roles and responsibilities, then distinguish between stakeholder roles: process owner, process manager, product manager, product owner. The exam tests these distinctions with scenarios where the wrong person is consulted or the right person is ignored. You outline the need for roles and responsibilities, which means explaining why identifying stakeholders matters in the first place. The answer is not obvious to everyone, and the exam expects you to articulate it. Internal and external roles differ in authority, in access, and in what they need from the project. You differentiate between them and explain how that difference shapes your approach.

– Stakeholder communication and choosing the right channel

Conducting stakeholder communication is a skill tested in context. You determine how to do it, not just that it should be done. Recommending the most appropriate communication channel or tool means matching reporting, presentation, email, workshop, or other formats to the audience and the message. The exam gives you a scenario and asks which channel fits. Demonstrating why communication is important for a business analyst between various teams means showing what breaks when it fails. Features misalign with requirements, teams duplicate work, or delivery does not match expectations. The exam tests this with scenarios where poor communication is the root cause, and you identify it.

– Requirements gathering, traceability, and product roadmaps

You determine how to gather requirements, match tools to scenarios, and identify the right approach for a situation. User stories, use cases, interviews, surveys, workshops, and lessons learned each serve different needs. The exam presents a context and asks which one you choose. Requirements traceability matrices and product backlogs are both tools for tracking what was requested, what was built, and what remains. You explain each and demonstrate understanding of how they are used. Product roadmaps show what gets delivered when. You explain the application of a product roadmap and determine which components go to which releases. This is a planning skill, and the exam tests it by giving you a set of features and constraints, then asking you to allocate them.

– Methodology, validation, and readiness for delivery

Project methodologies influence business analysis processes, and you determine how. The role of a business analyst in adaptive approaches differs from the role in predictive ones: the timing of requirements, the granularity, the feedback loops, and the stakeholder engagement all change. You determine what that role is in each context. Validating requirements through product delivery means confirming that what was built matches what was requested and that it solves the problem. You define acceptance criteria, which is the action of defining them based on the situation, not reciting a template. Finally, you determine if a project or product is ready for delivery based on a requirements traceability matrix or product backlog. The exam gives you the artifact and asks whether all conditions are met. You lose marks if you approve delivery when acceptance criteria are incomplete or when a requirement is not traced.

How Business Analysis Frameworks is tested

Twenty-seven percent means more than one question in four. Items ask you to choose the right communication channel, select the appropriate requirements-gathering technique, or determine whether a product is ready to release. The most common trap is recommending a technique because it is thorough rather than because it fits the situation. Workshops are not always the answer, and interviews are not always feasible. Another frequent mistake is confusing the roles: treating a product owner as a process owner, or assuming the sponsor defines acceptance criteria. The exam writes stems where the distinction matters, and the wrong answer is the one that assigns the task to the wrong person. Traceability and roadmap items test your ability to read an artifact and make a decision. You lose marks if you miss an unmapped requirement or approve a release when the backlog shows incomplete work. Validation items ask whether requirements are met, and the wrong answer is usually the one that focuses on delivery rather than acceptance.