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

Avoiding postpones or sidesteps a conflict rather than actively working to resolve it, which matches a project manager choosing not to address a disagreement directly and hoping it resolves on its own. Forcing instead imposes one party's preferred solution regardless of the other party's concerns, and collaboration works to find a solution that fully satisfies both parties' underlying concerns. Each conflict management style has situations where it is more or less appropriate, and consistently avoiding conflict can allow underlying tension to persist or worsen over time.

A rollback plan documents the specific steps needed to revert a system to its previous working state if a deployment causes unexpected problems, providing a safety net for IT infrastructure change control. Having this plan prepared and tested in advance, rather than improvising a recovery only after something has already gone wrong, significantly reduces the risk and potential downtime associated with a failed change. This is a standard component of change control alongside defined maintenance windows, customer notifications, and validation checks confirming the change worked as intended.

Personal health information specifically covers medical and health-related data, such as patient diagnosis records, reflecting its particular sensitivity in a healthcare context. Personally identifiable information more broadly covers data that could identify a specific individual, such as names and social security numbers, regardless of whether it is health-related. Recognizing that a single project can involve multiple distinct sensitive data classifications, each potentially carrying its own regulatory requirements, is an important compliance awareness for a project manager working in a regulated environment.

Physical security covers facility access controls and the physical protection of sensitive assets, which matches restricting who may enter a facility and requiring visitor escorts. This differs from digital security, which instead addresses resource access and permissions within systems, and from data security, which addresses classification and protection of information itself. Project managers working on sensitive initiatives need to be aware of all of these security categories, even though the technical implementation details are typically handled by dedicated security teams.

ESG considerations explicitly include a project's impact to the local and global environment, alongside awareness of applicable regulations, company values, and impact to brand value, which together capture exactly the kind of community and environmental evaluation described. This is a distinct category from digital security or change control, which address different aspects of responsible project execution. Increasingly, organizations expect project teams to consider ESG factors explicitly rather than treating them as an afterthought late in a project.

A risk register is a living document that lists every identified risk along with its assessed likelihood, potential impact, planned response strategy, and an assigned owner responsible for monitoring it. This differs from a risk report, which is typically a periodic summary communicating current risk status to stakeholders, whereas the register itself serves as the detailed, continuously updated source of truth. Keeping the risk register current throughout the project is essential, since a risk profile can change significantly as the project progresses.

A burndown chart tracks remaining work against time, typically within a sprint or project, showing whether the team is on pace to complete all planned work by the deadline as the remaining work trends toward zero. A burnup chart, by contrast, tracks completed work trending upward rather than remaining work trending downward, which is a related but visually inverted concept. Control charts and histograms instead serve statistical process control and frequency distribution purposes, which are different quality management applications from tracking sprint progress.

A Pareto chart ranks categories by frequency, typically highlighting how a small number of categories account for the majority of issues, which fits identifying which few defect categories matter most. A fishbone, or Ishikawa, diagram instead visually maps out the range of potential root causes contributing to one specific problem, organizing them into categories to support root cause analysis. A run chart tracks a single metric's value over time, which is a different visualization purpose from either ranking categories or mapping causes.

Real-time, multi-authoring editing software allows multiple people to edit the same document simultaneously, with changes appearing live for all collaborators, which directly matches the described need. A ticketing or case management system instead tracks discrete work items or support requests rather than supporting simultaneous document editing. Choosing the right collaboration tool category for a specific need, rather than defaulting to whatever tool is most familiar, helps a team work more efficiently together.

A Gantt chart displays each task as a horizontal bar positioned along a timeline, making start dates, end dates, and overlapping tasks easy to see at a glance, which is exactly the visualization described. A fishbone diagram instead maps out potential causes of a specific problem, and a control chart tracks a process metric over time against defined control limits, neither of which visualizes a task timeline the way a Gantt chart does. Gantt charts are one of the most widely used scheduling visualization tools across both Waterfall and hybrid project approaches.

A lessons learned, or retrospective, session captures what went well and what did not over the course of a project, documenting insights that future project teams can draw on to avoid repeating the same mistakes or to replicate successful practices. This reflective activity typically occurs both at project closing and, in Agile contexts, at the end of each sprint, providing more frequent opportunities to improve throughout the project rather than waiting until the very end. Failing to actually document and share these insights means the same lessons often have to be relearned by a future project team.

Closing contracts formally finalizes agreements with vendors or other external parties, confirming that all contractual obligations on both sides have been satisfied before the project is considered complete. This is a distinct closing activity from removing team members' system access or reconciling the final budget, even though all of these activities typically occur around the same time during project closeout. Leaving a contract improperly closed can create lingering legal or financial exposure even after the project's actual work has finished.

Providing initial training gives users the basic knowledge needed to use a new system, but reinforcing adoption over time, through ongoing support and communication, is what actually helps a change stick rather than fading once the novelty of training wears off. Organizational change management explicitly includes both ensuring initial adoption and reinforcing it afterward, alongside continued communication and updated documentation. Removing documentation or assuming adoption happens automatically both work against the sustained behavior change a successful rollout actually requires.

Kanban visualizes work on a board organized by stage and uses work-in-progress limits to prevent the team from starting more than it can handle at once, which directly matches the scenario described. Waterfall instead organizes work into sequential, non-overlapping phases rather than a continuous visual flow. PRINCE2 is a structured project management framework built around defined stages and management products, not a visual flow-limiting board.

A work breakdown structure decomposes the total project scope into progressively smaller, defined units of work, providing a foundation for estimating, assigning, and tracking everything the project must deliver. This differs from a backlog, which is more commonly used in Agile contexts to hold and prioritize a flexible, evolving list of work items rather than a fixed hierarchical decomposition. Building an accurate WBS early in planning supports more reliable scheduling and budgeting throughout the rest of the project.

Responsible identifies who actually performs the work required to complete a task or deliverable. Accountable identifies who holds final approval authority and ultimate ownership for that outcome, which is distinct from simply doing the work. Consulted instead refers to those whose input is sought before or during the work, and Informed refers to those who are simply kept up to date afterward, neither of which involves approval authority or hands-on execution.

The project charter is the foundational document developed during project initiation that establishes the project's objectives, a preliminary scope statement, and success criteria, formally authorizing the project to proceed. This document precedes detailed planning artifacts like a full schedule or risk register, which are developed once the project's fundamental purpose and boundaries are already established. Without a clear charter, a project risks lacking a shared understanding of what it is actually meant to achieve.

ROI analysis compares the expected financial return of a project against its cost, and comparing current state to future state helps quantify the value the project is expected to create. This kind of analysis typically occurs during the discovery or concept preparation phase, before a project is formally chartered, to help determine whether the investment is justified in the first place. A responsibility assignment matrix and communication plan instead address roles and information flow, which are different concerns from financial justification.

The scribe is responsible for recording the discussion, decisions, and action items during a meeting, producing an accurate written record that can be referenced afterward. This is a distinct role from the facilitator, who instead guides the discussion, keeps the meeting on track, and ensures the agenda is followed. Clearly assigning both roles before a meeting begins helps ensure important details are captured without also placing that burden on whoever is leading the discussion.

A negative schedule variance indicates the project has completed less work than planned at this point, meaning it is behind schedule. A negative cost variance indicates the project has spent more than the value of the work actually completed, meaning it is over budget. Tracking both variances together gives a fuller picture of project health than either figure alone, since a project could be on schedule but over budget, or vice versa.

A finish-to-start relationship means the successor task cannot begin until the predecessor task has completely finished, which is the most common and intuitive type of dependency in project scheduling. Start-to-start instead means two tasks can begin together or once the predecessor has started, without requiring it to finish first. Correctly identifying dependency types is essential for accurate schedule sequencing and for calculating the project's critical path.

Root cause analysis systematically traces a problem back to its true underlying source, rather than continuing to treat surface-level symptoms, which is exactly what is needed when a defect keeps recurring despite repeated quick fixes. Addressing only the symptom without identifying the root cause tends to produce exactly this pattern of repeated recurrence. Root cause analysis is part of the resolution planning process for issue management, distinct from risk response strategies, which address potential future events rather than issues that have already occurred.

Transferring a negative risk shifts the impact or responsibility for that risk to a third party, such as arranging a backup vendor who can absorb the consequence if the primary vendor fails. Mitigating the risk would instead involve actions that reduce the probability or impact of the primary vendor's own delay, such as adding schedule buffer with that same vendor. Accepting the risk would mean taking no proactive action and simply dealing with the consequence if it occurs, which is not what a backup contract represents.

When a change exceeds a project manager's own approval authority, the request is escalated to the change control board, the group with authority to approve or reject changes that fall outside standard limits. Once the CCB reaches a decision, that status must be documented in the change control log to maintain an accurate, auditable record of what was decided and when. Implementing a change before it is actually approved, or skipping communication of the decision, undermines the entire purpose of a formal change control process.

A high tolerance for change and flexibility in requirements is one of the criteria that favors Agile, since Agile methodologies are specifically designed to accommodate evolving requirements through iterative delivery and frequent feedback. Waterfall instead assumes requirements are well understood upfront and change is costly once a phase is complete, which fits a low tolerance for change. Recognizing which criteria point toward Agile versus Waterfall helps a team select the approach that matches the project's actual environment and constraints.