CompTIA Project + PK0-005 (V5) Exam Practice Test 2

A phase gate review is a formal checkpoint where stakeholders evaluate progress, deliverables, and overall readiness before authorizing the project to proceed into its next major phase, providing a structured opportunity to catch problems before they compound further. A retrospective instead looks backward at what happened during a completed iteration or project to extract lessons learned, rather than serving as a forward-looking gate to authorize continued work. Coordinating phase gate reviews is explicitly called out as an activity performed during project execution, helping ensure the project remains on track before committing further resources to the next phase.

CI/CD, standing for Continuous Integration/Continuous Deployment, automates the process of building, testing, and deploying code changes triggered by each commit, reducing manual effort and the delay between when a change is made and when it reaches production. This automated approach is explicitly called out as a relevant concept for operational change control during an IT project, since it changes how release and validation activities are structured compared to a fully manual release process. Understanding CI/CD helps a project manager working on software-related IT projects better anticipate how frequently and automatically changes may reach production compared to a traditional, manually gated release cycle.

SaaS provides a fully managed, ready-to-use application, such as an email platform, where the vendor handles all underlying infrastructure, operating systems, and application maintenance, leaving the team responsible only for using the software itself. IaaS instead provides raw virtual servers or other fundamental computing resources, leaving the team responsible for installing and managing its own operating system and software on top of that infrastructure. Recognizing where a given cloud service sits along this spectrum, from IaaS through PaaS to SaaS, helps a project team understand exactly which responsibilities the vendor handles and which remain with the project's own IT resources.

Multifactor authentication requires more than one form of verification, such as a password combined with a one-time code, before granting access, which is explicitly called out as a digital security consideration under remote access restrictions. This differs from physical security, which instead addresses facility and device access controls, and from background screening, which is an operational security consideration related to personnel vetting rather than technical access controls. Projects involving remote access to sensitive systems increasingly require this kind of layered authentication as a baseline security expectation.

Awareness of applicable regulations and standards is explicitly one of the ESG factors a project should account for, ensuring the project's approach does not run afoul of industry or governmental requirements relevant to its sector. This differs from brand value awareness, which instead concerns how the project's execution and outcomes might reflect on the organization's public reputation. Considering regulatory awareness early, rather than discovering a compliance gap late in the project, helps avoid costly rework or legal exposure.

A scatter diagram plots two variables against each other to visually reveal a potential correlation, which is exactly the purpose of comparing testing hours against defects found. A run chart instead tracks a single variable's value over time in sequence, without directly comparing it against a second variable the way a scatter diagram does. A histogram shows the frequency distribution of a single variable's values, which is again a different analytical purpose from examining the relationship between two distinct variables.

Cloud-based solutions are accessed remotely over the internet, with the vendor responsible for hosting and maintaining the underlying infrastructure, offering accessibility from anywhere without the organization needing to manage servers itself. On-premises solutions instead are installed and maintained entirely on the organization's own servers, which can offer more direct control but also requires the organization to handle its own infrastructure maintenance and updates. Choosing between these two deployment models for project management scheduling tools often depends on an organization's specific security, control, and IT resourcing considerations.

A control chart tracks a specific metric over time against statistically defined upper and lower control limits, flagging out-of-limit data points as a signal that a process may be experiencing a problem requiring investigation. A scatter diagram instead plots two variables against each other to reveal a potential correlation, which is a different analytical purpose from tracking one metric's performance over time against control limits. A velocity chart, by contrast, tracks an Agile team's completed work per iteration, which is a related but distinct performance chart from a formal control chart.

A wiki knowledge base provides a collaborative, continuously editable repository where team members can contribute and update shared documentation over time, which directly matches the described need for evolving, collectively maintained process and decision documentation. Real-time surveys and calendaring tools instead serve gathering quick feedback and scheduling purposes respectively, neither of which supports this kind of ongoing collaborative documentation. Choosing a wiki over a static document repository specifically supports content that is expected to change and grow as the team's collective knowledge evolves.

A PERT chart is a network diagram that models task dependencies while incorporating weighted time estimates, typically optimistic, pessimistic, and most likely durations, to calculate an expected schedule that accounts for uncertainty in individual task estimates. A milestone chart instead simply highlights key dates without necessarily modeling dependencies or estimate uncertainty the way PERT does. A project organizational chart, by contrast, shows reporting relationships and team structure rather than schedule information at all.

Preexisting contracts, such as a client statement of work or client terms of reference already signed before the project formally begins, represent commitments the project must work within rather than negotiate from scratch. Reviewing these documents during the discovery or concept preparation phase ensures the project team understands any constraints or obligations already established before detailed planning gets underway. Failing to review preexisting contracts thoroughly risks a project plan that inadvertently conflicts with commitments the organization has already made.

Project sign-off is the formal acknowledgment from key stakeholders that all deliverables have been accepted and the project is officially considered complete, providing clear closure and a defined endpoint to the project's formal obligations. This differs from budget reconciliation, which specifically addresses financial closeout, and from archiving documentation, which preserves project records for future reference, even though all of these activities typically occur around the same closing phase. Without a clear sign-off, a project can linger in an ambiguous state where stakeholders disagree about whether it is actually finished.

Enforcing vendor rules of engagement ensures the vendor operates within the agreed boundaries and expectations set at the start of the engagement, rather than assuming compliance will happen automatically. Approving deliverables formally confirms that what the vendor has provided actually meets the agreed requirements before the project accepts and relies on that work. Both of these are explicitly called out vendor management activities performed during project execution, alongside monitoring performance, which together ensure the vendor relationship delivers what was actually contracted for.

Scrum organizes work into fixed-length iterations called sprints, includes a daily stand-up for the team to synchronize, and holds a sprint review with stakeholders at the end of each iteration to inspect completed work. Waterfall instead organizes work into sequential phases without this kind of iterative, time-boxed cadence. PRINCE2 is a broader, stage-based project management framework rather than the specific iterative ceremonies Scrum defines.

A minimally viable product defines the smallest version of a product that still delivers meaningful value, allowing a team to release something usable to early users and gather real feedback before investing further in expanded capabilities. This concept is commonly established during project planning as part of defining baselines and milestones for what will actually be delivered first. A work breakdown structure instead decomposes the full scope of work into manageable pieces, which is a related but distinct planning activity from defining an intentionally minimal first release.

A communication plan establishes how and how often the team will communicate, including meeting cadence and specific channels or methodologies, which supports the coordination described in the first part of the scenario. A backlog instead holds a prioritized list of units of work, commonly used in Agile approaches to define what will be pulled into upcoming iterations, which is a different planning artifact from a communication plan entirely. Both artifacts are developed during project planning, but they address fundamentally different concerns: one governs how the team talks to each other and stakeholders, and the other governs what work is queued up next.

Identifying and assessing stakeholders during project initiation compiles everyone who could affect or be affected by the project and evaluates their relative influence and interest, which then informs how the project engages and communicates with each group going forward. This foundational activity typically precedes and directly informs the communication plan, since knowing who the stakeholders are and how much influence and interest they have shapes what kind of communication approach each group actually needs. Skipping or rushing stakeholder identification risks failing to properly engage someone whose support, or opposition, could significantly affect the project's success.

CapEx refers to a large upfront capital investment, such as purchasing servers outright, while OpEx refers to ongoing recurring operational costs, such as a monthly cloud subscription fee, and weighing these two financial concepts against each other is a common consideration during a project's discovery or concept preparation phase. This decision often involves tradeoffs beyond just total cost, including cash flow timing, flexibility, and how the expense is treated for accounting and tax purposes. Recognizing this distinction helps a project team present a well-rounded financial case to stakeholders evaluating the investment decision.

A matrix organizational structure creates dual reporting relationships, where team members report to both a functional manager for their discipline and a project manager for their project work, which can create both flexibility and potential conflict over competing priorities. This differs from a purely functional structure, where employees report solely through their functional department with no dedicated project manager authority, and from a projectized structure, where the project manager has full authority and team members report primarily through the project. Understanding which structure a project operates within helps a project manager anticipate how much direct authority they actually have over team members' time and priorities.

Unit testing verifies individual code components in isolation, typically performed by developers immediately after writing the code, catching defects early before they propagate further into the system. User acceptance testing instead involves actual business users testing the complete system against real-world scenarios, providing final validation that the system meets their actual needs before formal acceptance. These are distinct testing cycles serving different purposes at different points in the development and delivery process, both explicitly called out among the recognized test plan and testing cycle types.

Contingency reserves, or buffers, are extra time deliberately built into a schedule to absorb unexpected delays, particularly on high-risk tasks where uncertainty is greatest. Critical path analysis instead identifies the specific sequence of dependent tasks that determines the shortest possible overall project duration, since any delay on that specific path directly delays the entire project. Story points instead measure relative effort for Agile work items, which is an estimating technique distinct from either contingency buffers or critical path analysis.

Urgency specifically reflects how quickly an issue needs to be addressed, which is distinct from its overall impact or severity, and weighing urgency against a deadline is exactly what is being compared between these two issues. An issue with lower overall impact but a hard deadline may need to be prioritized ahead of a higher-impact issue with more available time, depending on how severely delay would affect the deadline-bound issue. Prioritization frameworks for issue management typically weigh multiple factors together, including severity, impact, scope, and urgency, rather than relying on any single dimension alone.

Quantitative risk analysis uses numerical techniques, such as simulation, to model probabilistic outcomes like a range of possible completion dates given uncertain task durations. Qualitative risk analysis instead typically assesses risks using relative categories, such as interconnectivity or detectability, without necessarily producing a numerical probability distribution. Choosing quantitative analysis for a complex scheduling uncertainty question, rather than a purely qualitative assessment, provides a more precise, data-driven basis for schedule risk decisions.

Scope creep describes exactly this pattern: small, unapproved additions to scope that accumulate outside the formal change control process, often without anyone deliberately deciding to expand the project's scope. A properly managed scope change, by contrast, goes through the documented change control process, including impact assessment and approval, before any work on the addition begins. Unchecked scope creep frequently strains a project's budget and schedule, even though each individual addition might have seemed small and reasonable in isolation.

A dedicated product owner who continuously prioritizes and clarifies requirements throughout development is a hallmark of Agile team composition, reflecting the ongoing collaboration Agile relies on rather than a single upfront requirements sign-off. Waterfall instead typically finalizes requirements early through formal sign-off before development begins, with less ongoing prioritization input built into the process itself. Recognizing how team composition and roles differ between methodologies helps a project manager set appropriate expectations for stakeholder involvement throughout the project.