Free CAPM Exam Questions That Helps Candidates Pass

In precedence diagramming, Start-to-Finish (SF) indicates a successor cannot finish until the predecessor starts. It’s the least-used relationship but accurately models handover scenarios such as shift changes or cutover support where the outgoing activity (successor) must remain active until the incoming activity (predecessor) has begun. In this case, the night-shift operator’s duty (successor) ends only after the day-shift operator starts (predecessor). By contrast, Finish-to-Start (FS) requires the successor to start after the predecessor finishes—typical for sequential tasks like “build then test,” but the situation here hinges on the start of the next shift, not the finish of the first. Start-to-Start (SS) aligns starts of two activities (useful for concurrent ramp-up) and wouldn’t prevent the night shift from ending before day shift begins. Finish-to-Finish (FF) ties finishes together and is more appropriate when two activities must complete at roughly the same time, such as testing and documentation. Correctly selecting SF preserves operational safety and service continuity by ensuring overlap at the transition point. CAPM scheduling emphasizes choosing the smallest, clearest relationship that reflects real constraints, documenting any leads/lags, and analyzing risk due to overlaps, especially for human-intensive handoffs.

The Sprint Goal is a concise statement that gives the team a unifying objective for the sprint. It provides focus and flexibility: while the set of Product Backlog Items selected is expected to deliver the goal, the team may negotiate changes with the Product Owner during the sprint if doing so still meets the goal. Thus, the Sprint Goal is not a scope lock (Option A). Velocity and forecasting (Option C) are outcomes of empirical measurement, not the purpose of the goal. Acceptance criteria (Option D) are item-specific and complement, but do not equal, the Sprint Goal. CAPM’s agile content emphasizes empiricism and adaptation; the Sprint Goal enables coherent decision-making under uncertainty by anchoring trade-offs to a shared outcome. It also improves stakeholder communication, since progress can be discussed in terms of achieving the goal rather than ticking off isolated tasks. Teams use the Daily Scrum to inspect progress toward the goal and adjust the plan accordingly.

Option B is specific, measurable, and testable. It defines traceability (who changed what, when), retention period, tamper-evidence, and access control aligned to role-based policies. Such clarity guides architecture (audit logging, WORM storage, key management), verification (log integrity checks, access tests), and operations (retention jobs, monitoring). “Use secure coding” (A) and “encrypt everything” (C) are vague and can’t be verified without concrete thresholds and scope. “Periodic reviews” (D) is a process requirement, not a product quality attribute. CAPM’s business analysis content stresses expressing NFRs as objective criteria tied to compliance (e.g., GDPR, HIPAA), with traceability to tests and controls. Early articulation reduces costly rework and supports vendor/tool evaluation. Include measurement methods and environments, and ensure the NFRs are reflected in the Definition of Done so that security is built-in rather than bolted on late in the cycle.

The assumption log captures assumptions (uncertainties taken as true for planning) and constraints (imposed limitations such as budget caps, regulatory deadlines, or fixed technologies). Documenting them provides transparency, enables validation, and feeds risk identification—if an assumption proves false, it becomes a risk or an issue. The risk register (Option B) contains identified risks with probabilities, impacts, owners, and responses; many originate from challenging assumptions, but they are tracked separately. The issue log (Option C) records current problems requiring action now (e.g., a vendor missed a milestone). The change log (Option D) tracks submitted change requests and their dispositions. CAPM fundamentals stress that well-managed assumptions and constraints improve estimate quality and stakeholder alignment. Good practice includes periodically reviewing the assumption log, testing critical assumptions (e.g., pilots, proofs-of-concept), and updating related plans when assumptions are invalidated. This discipline reduces surprises and supports robust decision-making throughout the project life cycle.

The scope baseline is the approved version of scope components used to guide execution and control. It consists of the project scope statement, the Work Breakdown Structure (WBS), and the WBS dictionary. The scope statement articulates what is in and out of scope and the acceptance criteria at a high level. The WBS provides hierarchical decomposition of total project work into manageable work packages. The WBS dictionary supplies detailed descriptions, assumptions, constraints, and acceptance information for each WBS element. Together, these establish a common understanding of the deliverables and the work required, becoming the reference for change control and performance measurement. Option A includes the project charter, which authorizes the project but is not part of the baseline. Option C confuses a subsidiary plan (scope management plan) and operational documents with the baseline. Option D mixes a verification tool (RTM) and a different baseline (schedule baseline). In CAPM-aligned practice, accurate baselining reduces scope creep, enhances estimating, and provides a solid foundation for integrated change control when deviations are proposed.