Practice CompTIA Project+ PK0-005 with free sample questions, timed mock exams, topic drills, and detailed answer explanations in IT Mastery.
CompTIA Project+ (PK0-005) is a broad project-management certification built around practical delivery, governance, communication, change, risk, and documentation in real work environments. If you are searching for PK0-005 sample questions, a practice test, mock exam, or simulator, this is the main PM Mastery page to start on web and continue on iOS or Android with the same account.
Start a practice session for CompTIA Project+ (PK0-005) below, or open the full app in a new tab. For the best experience, open the full app in a new tab and navigate with swipes/gestures or the mouse wheel—just like on your phone or tablet.
Open Full App in a New TabA small set of questions is available for free preview. Subscribers can unlock full access by signing in with the same account they use on web and mobile.
Use on iPhone or Android too: PM Mastery on the App Store or PM Mastery on Google Play using the same account you use on web. The same subscription works across web and mobile.
PK0-005 questions usually reward the answer that clarifies goals, uses the correct governance path, documents decisions properly, and balances delivery speed with risk control.
These sample questions include the same mix of single-answer and multiple-response items you should practice for PK0-005. Use them to check your readiness here, then move into the full PM Mastery question bank for broader timed coverage.
Topic: Domain 4: Basics of IT and Governance
A project team supporting a SaaS rollout needs to enable SSO for a pilot group. To stay on schedule, the technical lead asks to push the identity-provider configuration directly to production today, skipping the normal change request, impact assessment, CAB approval, and post-implementation review. The project manager agrees.
What is the most likely near-term impact of this decision?
Best answer: B
Explanation: Bypassing the standard change-management workflow removes key controls that catch conflicts, validate risk, and confirm a rollback plan. For a production SSO change, the near-term consequence is increased operational risk and a higher chance of an outage or access issues shortly after implementation. The workflow exists to reduce immediate business impact, not just to create documentation.
Standard change management follows a request, assess, approve, implement, and review flow to prevent production changes from introducing avoidable incidents. Skipping the request/assessment/approval steps means the team may miss dependency impacts (e.g., token settings, certificate chains, user provisioning, firewall rules) and may not have a tested back-out plan or the right stakeholders informed. As a result, the most immediate effect is increased risk of service disruption or user lockouts right after the change.
A key takeaway is that going faster by bypassing governance typically trades schedule for immediate operational risk, even if no direct cost or scope change is intended.
Topic: Domain 1: Project Management Concepts
Your team is implementing a new IT service desk platform using a fixed-price SOW. During configuration, the vendor states that a “security hardening package” (extra role-based controls and audit log retention) is required to meet your organization’s policy and submits a request for +$22,000 and +10 business days.
Constraints:
Which action best optimizes the outcome while meeting the constraints?
Best answer: A
Explanation: Vendor change requests and scope disputes should be handled through the contract’s change-order and dispute processes, not informal approvals or unilateral direction. Getting the request in writing, confirming whether it is truly out of scope, and routing the decision through the CCB preserves governance and baselines. This also enables negotiation of alternatives that meet the immovable go-live constraint.
When a vendor requests additional cost/time and there is disagreement about whether the work is in scope, the project manager should use formal change control and the contract’s change-order mechanism. First, require a written proposal that clearly states the change, rationale, assumptions, and impacts (cost, schedule, risk). Next, compare the request to the SOW/requirements to determine whether it is a true scope change or a contractual obligation. Then, submit the impact analysis to the CCB for a decision and, if approved, execute a signed change order (or, if in scope, document the determination and direct performance per contract). This approach protects the go-live constraint by enabling schedule-neutral alternatives (re-sequencing, added resources at vendor cost, or reduced noncritical scope) while maintaining enforceable documentation.
The key takeaway is to avoid informal approvals or adversarial escalation until the contractual process has been followed and documented.
Topic: Domain 2: Project Life Cycle Phases
You are executing an identity-and-access project to roll out MFA to 600 users. A regulatory audit requires MFA enabled for all finance users by the end of this month (fixed date). The vendor reports the SSO connector needed for the full rollout will arrive 2 weeks late. The security manager asks you to “just deploy MFA anyway” using a manual workaround, but the workaround would increase help-desk load and is not in the approved plan. Production changes must go through the CAB.
What is the BEST next action?
Best answer: B
Explanation: With a fixed compliance deadline and a critical dependency delay, the project must adapt the delivery approach without bypassing governance. The right next step is to analyze schedule/operational impacts and present feasible rollout options for an approved decision. This keeps stakeholders aligned and preserves control of scope, risk, and production changes.
During execution, you should follow the approved plan but adapt when constraints change (like a vendor delay) by using formal change control and proactive stakeholder communication. Here, the SSO connector delay threatens a non-negotiable compliance date, and a workaround introduces new operational risk and support effort that was not approved. The best next action is to quickly assess impacts and propose alternatives (for example, a phased rollout starting with finance users, additional support coverage, or adjusted scope), then route the recommended plan through the CAB and key stakeholders for a documented decision. This maintains alignment, updates baselines appropriately, and avoids unauthorized production changes.
Key takeaway: adapting delivery is expected, but it must be done transparently and with the required approvals.
Topic: Domain 2: Project Life Cycle Phases
You are executing a SaaS CRM rollout. The latest status report shows the project is trending off plan:
Which TWO actions are the best corrective actions to bring the project back in line? (Select TWO.)
Best answers: B, F
Explanation: Corrective actions should directly address the variance drivers while honoring constraints. With a fixed regulatory go-live, schedule recovery must come from execution changes such as schedule compression and/or scope trade-offs. Deferring optional scope through change control and crashing critical-path work are practical ways to recover time and reduce ongoing cost pressure from rework.
In project execution, when indicators show the work is trending off plan, corrective actions are changes to how work will be performed to realign with the approved plan (or to meet a fixed constraint). Here, the date is fixed, and the delay is on the critical path, so schedule recovery must come from execution tactics such as adding resources (crashing) to critical-path tasks. Because costs are already high due to rework, another strong corrective lever is to reduce work by deferring optional deliverables, but it must be done through formal change control so expectations, acceptance criteria, and baselines stay governed. The key takeaway is to act on the drivers (critical path and scope) rather than only reporting the variance.
Topic: Domain 2: Project Life Cycle Phases
You are initiating a project to implement a new SaaS CRM. During kickoff planning, Sales Operations and IT Operations both claim they can approve scope changes, and the team is unsure where to escalate decisions that impact the go-live date.
Which artifact best validates that the sponsor is identified and that decision-making authority and escalation paths are established?
Best answer: A
Explanation: The best validation is a formally approved document that explicitly identifies the project sponsor and defines who has authority to make decisions and how unresolved items are escalated. In project initiation, the project charter (or project brief) is the primary artifact used to establish and confirm this governance.
In initiation, the project needs clear governance so decisions can be made quickly and consistently. The project sponsor should be explicitly identified, and the project must define decision-making authority (who can approve scope, budget, and schedule impacts) along with escalation paths for conflicts or time-sensitive decisions. The strongest evidence is an approved project charter (or equivalent project brief) because it is formally authorized and typically includes sponsor identification and governance details such as approval authority and escalation routes. Other artifacts may support understanding, but they do not validate that authority is established unless they are formally approved as part of governance.
Topic: Domain 2: Project Life Cycle Phases
You are reviewing a proposed project during initiation and must confirm it aligns to organizational strategy and expected value.
Exhibit: Strategy and concept (excerpt)
Strategic priorities (FY26): Cloud-first; reduce data center footprint 30%;
improve customer response time
Proposed project: Refresh on-prem CRM servers and storage; extend life 5 years
Stated benefits: Reduce unplanned downtime; use remaining capex budget
Requested outcome metrics: TBD
Based on the exhibit, what is the BEST next action?
Best answer: B
Explanation: Initiation requires confirming the project’s business case supports organizational strategy and delivers measurable benefits. The exhibit shows a cloud-first, data-center-reduction strategy, but the concept extends on-prem infrastructure life and leaves outcome metrics undefined. The right move is to revalidate with the sponsor (and adjust scope or stop) before authorizing further planning or work.
In project initiation, you should confirm the proposed work supports stated organizational strategy and that expected benefits/value are clear and measurable. The exhibit shows strategic priorities focused on moving to cloud and reducing the data center footprint, while the proposed project refreshes on-prem CRM infrastructure and extends its life for five years. That may directly conflict with the strategy, and the outcome metrics are still “TBD,” so expected value is not yet verifiable.
The best next action is to meet with the sponsor (and, if applicable, portfolio/steering stakeholders) to:
Moving into procurement, scheduling, or kickoff assumes authorization and a validated business case.
Topic: Domain 1: Project Management Concepts
You are coordinating a SaaS CRM migration. During UAT, users report intermittent SSO login failures that prevent testing the critical sales workflow. The PMO will review the issue log as evidence that blockers are being managed.
Which issue statement best validates that this issue is documented with impact, owner, and next action?
Best answer: A
Explanation: The best validation artifact here is an issue log entry that is immediately actionable and auditable. A clear issue statement names the problem, describes the specific project impact, assigns a single accountable owner, and defines the next action (often with a due date). This shows the team can track and manage the blocker to resolution.
In issue management, the issue log is used as evidence that the team is controlling active problems that are already occurring (not hypothetical risks). To be usable for tracking and for governance reviews, an issue statement should be specific and complete: what is happening, what it affects (impact), who is accountable (owner), and what will be done next (next action, ideally with a target date). In this scenario, the PMO is validating readiness to proceed with UAT and eventual cutover, so the entry must show that the SSO blocker is understood, owned, and has a concrete next step toward resolution. Vague wording, shared ownership, or progress/throughput metrics do not validate that the blocker itself is being managed.
Topic: Domain 2: Project Life Cycle Phases
A project is in execution for a contact-center VoIP migration. A vendor has confirmed a remote cutover support window next Tuesday (only availability this month). Your only network engineer is assigned to the cutover tasks and also to an internal firewall upgrade the same day. The cutover tasks are on the critical path.
Which action best resolves the resource conflict while maintaining delivery flow?
Best answer: A
Explanation: Because the vendor’s cutover support window is fixed and the cutover is on the critical path, the plan must be adjusted around that dependency. The best approach is to re-sequence non-critical work and ensure the constrained resource is available for the vendor-dependent activity to keep the project moving.
In execution, resolving resource conflicts is about protecting the activities that drive the delivery date while making practical adjustments to keep work flowing. Here, the single most important discriminator is the fixed vendor dependency: the cutover support window is only available next Tuesday and the cutover tasks are on the critical path. That means the network engineer’s time for that window is effectively non-movable.
A sound approach is to:
Delaying the vendor cutover should be a last resort because it risks slipping the entire project due to vendor availability constraints.
Topic: Domain 1: Project Management Concepts
A team is delivering a custom integration between an HR SaaS platform and on-premises Active Directory. Requirements are expected to change as HR discovers edge cases, so the project is being run with 2-week sprints.
During Sprint 0, the project coordinator finds that the team cannot create a realistic sprint plan because requested work is scattered across emails and meeting notes, and there is no agreed priority. What is the BEST next step?
Best answer: A
Explanation: Because the project is using an agile approach with changing requirements, the team needs agile planning artifacts to proceed. A prioritized product backlog consolidates work items and establishes order, enabling effective sprint planning and near-term commitments. Once the backlog is in place, the team can create an iteration plan for the next sprint.
In agile projects, detailed up-front decomposition and fixed baselines are usually not appropriate when requirements are expected to evolve. The immediate problem is that work is not captured in a single, prioritized list, so the team cannot select and size work for a sprint.
The next step is to:
A WBS and scope baseline are predictive planning artifacts and tend to be premature in this scenario where scope is intentionally allowed to change.
Topic: Domain 2: Project Life Cycle Phases
You are building the project work plan for migrating an on-prem customer support system to a SaaS platform. The new system will store customer names, emails, and support chat transcripts, and data will be hosted by the vendor.
Before you can schedule security, privacy, and compliance activities, what should you verify or obtain FIRST?
Best answer: D
Explanation: To plan security, privacy, and compliance work, you first need to know what obligations apply to the solution and the data being processed. Confirming regulatory and internal requirements drives the required activities (assessments, reviews, controls, approvals) and when they must occur in the plan. Without that baseline, scheduling is guesswork and risks missed compliance gates.
Security, privacy, and compliance tasks in a work plan must be derived from the governing requirements for the data and the solution (laws/regulations, contractual obligations, and internal policies/standards). In a SaaS migration that includes customer information and vendor hosting, the first clarifying step is to confirm what compliance framework applies and who must approve (e.g., security, privacy/legal, risk/GRC). That input determines what activities must be planned (such as vendor security due diligence, data classification handling, privacy impact assessment, and control validation) and where they fit in the project schedule as entry/exit criteria.
Once requirements are known, you can sequence the specific security/privacy/compliance deliverables and align them to milestones (design review, procurement, testing, go-live).
Topic: Domain 3: Project Tools and Documentation
A hybrid project is implementing a SaaS HR system with a custom SSO integration. UAT defects keep being reopened because stakeholders disagree on who must approve configuration changes and when the identity team can deploy updates to the test environment.
You have one 60-minute working session with DevOps, Security, and HR to produce a single artifact that will be reused for onboarding and to reduce rework risk. Which action best meets this objective?
Best answer: C
Explanation: A swimlane flowchart is designed to clarify a cross-functional process by showing steps by role, including handoffs and approval gates. That directly addresses the root problem: disagreement about ownership and sequencing for configuration changes and deployments. It also fits the constraint of producing one reusable artifact quickly in a single working session.
When a project is experiencing rework because teams disagree on “who does what, when,” the best productivity tool is a diagram that makes roles, responsibilities, and handoffs unambiguous. A swimlane flowchart maps each step of the change-and-deploy process into lanes (DevOps, Security, HR, etc.), showing approval points, inputs/outputs, and where work transitions between groups.
In the stated scenario, this directly reduces reopened defects by aligning stakeholders on:
A network diagram is better for dependency/critical-path planning, not clarifying cross-team approvals and responsibilities.
Topic: Domain 3: Project Tools and Documentation
You are coordinating a network refresh project. Today is June 10, 2026. The go-live milestone is fixed for June 28, 2026.
Exhibit: Gantt excerpt (dates and dependencies)
ID Task Start Finish Pred
1 Finalize requirements Jun 3 Jun 5 -
2 Order firewall appliances Jun 6 Jun 7 1
3 Vendor ships/delivers Jun 8 Jun 14 2
4 Rack and cable new firewalls Jun 17 Jun 18 3
5 Configure & harden Jun 19 Jun 21 4
6 UAT / cutover rehearsal Jun 24 Jun 26 5
7 Go-live Jun 28 Jun 28 6
8 Update runbooks Jun 17 Jun 24 1
9 Admin training Jun 20 Jun 26 5
Based on the Gantt chart, which activity represents the greatest schedule risk to the June 28 go-live due to dependencies?
Best answer: D
Explanation: The highest schedule risk is the task that gates the dependent chain leading to the fixed go-live date. The delivery task is an external dependency and is the immediate predecessor to the installation, configuration, and testing activities that must all complete before go-live. A delay there propagates through all successor tasks and threatens the milestone.
To interpret schedule risk from a Gantt chart, trace the predecessor links that lead directly to a fixed milestone and identify which activities have successors with no alternative start until the predecessor finishes. In the exhibit, go-live depends on UAT, which depends on configuration, which depends on racking/cabling, which depends on the vendor delivery.
Because the delivery task is both (1) a hard predecessor to the critical sequence and (2) controlled by an outside party, it is the most likely single point of delay that will cascade into the June 28 milestone. In contrast, work like runbooks may be important but does not gate the go-live chain shown by the dependencies.
Topic: Domain 1: Project Management Concepts
Midway through an IAM rollout, the schedule baseline shows 4 weeks remaining. The remaining work is estimated at 160 hours. The sponsor approves a change to add an audit-reporting feature estimated at 40 additional hours. The team is fixed at two engineers, each available 20 hours/week (no overtime or additional staff approved).
What is the most likely near-term impact of accepting this change without replanning?
Best answer: D
Explanation: With a fixed team and no overtime, the only lever is time. Adding 40 hours to 160 hours increases the remaining effort to 200 hours. At 40 hours/week of capacity, the simple forecast is 5 weeks remaining, so the schedule slips by roughly 1 week if scope is not reduced.
A simple schedule forecast compares remaining effort to available capacity. Here, the change increases remaining effort while capacity stays fixed, so the most direct near-term consequence is a longer duration.
\[ \begin{aligned} \text{Capacity} &= 2 \times 20 = 40\ \text{hours/week} \\ \text{New remaining effort} &= 160 + 40 = 200\ \text{hours} \\ \text{Forecast weeks remaining} &= 200/40 = 5\ \text{weeks} \end{aligned} \]Since the baseline assumed 4 weeks remaining, accepting the change without replanning creates an immediate schedule variance of about 1 week.
Topic: Domain 4: Basics of IT and Governance
A SaaS identity platform used by your company has an actively exploited vulnerability. The vendor released a patch that requires applying a configuration update in production. Security requires mitigation within 4 hours.
The change control policy defines:
To minimize security risk while still following governance, which handling path should the project team use?
Best answer: C
Explanation: Because the vulnerability is actively exploited and must be mitigated within 4 hours, it meets the policy definition of an emergency change. The best path is to use the expedited emergency workflow that still includes required approvals, a documented backout plan, and after-the-fact CAB review to remain compliant. This optimizes risk reduction without bypassing governance.
Change classification should follow the provided definitions and the constraints in the scenario. A standard change is only appropriate when the activity is preapproved, low risk, and repeatable; the scenario does not state it is preapproved and the risk is high due to active exploitation. A normal change cannot meet the 4-hour mitigation requirement because it requires full analysis and CAB approval with a multi-day lead time.
An emergency change is explicitly intended for immediate security exposure and provides a compliant fast path:
Key takeaway: when time-critical security risk is the primary constraint, use the emergency path rather than skipping controls or forcing a normal/standard classification.
Topic: Domain 1: Project Management Concepts
Halfway through an IT portal modernization project, the scope/schedule/cost baselines are approved. A business stakeholder requests adding multi-factor authentication (MFA). The technical lead estimates the change would add 120 hours of effort, increase cost by $18,000 (USD), and delay the go-live milestone by 2 weeks.
Which TWO actions should the project manager take to evaluate and control this change? (Select TWO)
Best answers: C, E
Explanation: Change control starts by evaluating the requested change against the approved scope, schedule, and cost baselines to understand impact. The request should then follow the established approval path so the project only updates baselines and plans when an authorized decision is made. This preserves governance and prevents uncontrolled scope, date, and cost changes.
Baselines are the approved references used to measure and control performance: scope (scope statement/WBS), schedule (planned dates), and cost (cost baseline). When a new request arises during execution, the project manager should first assess how the request would change those baselines (added deliverables, time, and funding) and capture that analysis in a change request. The change must then be reviewed and approved/rejected by the defined change control authority (such as a CCB/CAB) before work begins or baselines are altered. Only after approval should the PM update the affected baselines and plans and communicate the decision, ensuring the project remains measurable and auditable.
Key takeaway: evaluate against baselines first, then control the change through formal approval before rebaselining.
Topic: Domain 4: Basics of IT and Governance
Your project is implementing a third-party SaaS ticketing system that will store customer PII. During contract review, you notice the vendor’s draft MSA/SOW describes uptime and support but does not specify data handling requirements (encryption, data retention/destruction, subcontractor controls) or breach notification responsibilities/timeframes. The vendor is ready to sign this week.
What is the best next step?
Best answer: C
Explanation: The project has identified a procurement deliverable defect: the vendor agreement lacks required privacy/compliance clauses for handling PII and for breach notification. The proper next step is to close that gap by requiring a DPA/contract addendum (or revised MSA/SOW) and routing it through legal/compliance review before execution.
When a vendor will process or store regulated/sensitive data, the contract package should explicitly assign privacy and security obligations (how data is collected/used, encryption expectations, retention and destruction, restrictions on subcontractors, audit/right-to-assess where applicable) and define breach notification responsibilities (who notifies whom, within what timeframe, and required content). In the scenario, those terms are missing, so signing would create unmanaged compliance risk and limit enforcement options.
The best sequence is to request a revised contract or a Data Processing Addendum (DPA) that includes the required data handling and breach notification clauses, then route it through the organization’s legal/compliance approval workflow before signature. The key takeaway is to fix contractual compliance gaps before committing the organization to the vendor relationship or starting dependent work.
Topic: Domain 4: Basics of IT and Governance
During UAT for a new SaaS single sign-on (SSO) integration, testers report “login fails sometimes.” The project coordinator asks the developers to start investigating immediately, but the ticket does not include steps to reproduce, timestamps, affected users, environment details (browser/IdP tenant), or any error messages/logs.
What is the most likely near-term impact of proceeding with triage using this limited information?
Best answer: A
Explanation: Effective triage depends on collecting enough context to reproduce and classify the problem (who is affected, when it happens, where it occurs, what changed, and what evidence exists). With only a vague symptom, the team will spend time chasing details instead of validating hypotheses. The near-term consequence is delayed diagnosis and schedule risk from rework and repeated testing cycles.
In project work, technical issue triage starts by gathering actionable facts so the right people can reproduce the problem and narrow likely causes. In this scenario, the ticket lacks the minimum information needed to confirm whether the issue is user-specific, environment-specific, time-bound, or related to a recent configuration change.
At a minimum, triage data typically includes:
Without these, developers must loop back to testers to collect evidence, leading to slow progress and repeated cycles of “try again,” which most directly threatens short-term schedule and resolution time.
Topic: Domain 1: Project Management Concepts
You are managing a software upgrade project. The release gate requires an automated regression pass rate of 95% before promoting to production.
Exhibit: Quality dashboard (today)
Planned for release gate: 200 tests executed, 95% pass
Actual today: 200 tests executed, 176 pass
Go-live window: 2 weeks
Based on the variance from the required pass rate, what is the best NEXT step?
Best answer: D
Explanation: The project is not meeting the defined quality threshold. With 176 of 200 tests passing, the pass rate is 88%, which is 7 percentage points below the 95% gate. The appropriate next step is to use quality management practices (triage and root-cause analysis) to define corrective actions and assess impact before requesting major changes or escalating.
This situation is a quality/performance variance against a defined acceptance threshold (the release gate). First calculate the actual pass rate and compare it to the required pass rate:
\[ \begin{aligned} \text{Actual pass rate} &= \frac{176}{200} = 0.88 = 88\% \\ \text{Variance} &= 88\% - 95\% = -7\%\text{ points} \end{aligned} \]A negative variance means the project is not meeting the quality criterion to proceed. The best next step is to perform defect triage and root-cause analysis with the team to identify what is driving failures, prioritize fixes, and define a corrective action plan (including re-test approach and schedule/cost impacts). Escalation or a schedule change request is appropriate only after the team has quantified recovery options and impacts.
Topic: Domain 4: Basics of IT and Governance
A project team just implemented new security controls for an internal web app: SSO with MFA, least-privilege roles, and SIEM alerting for failed logins. An internal audit requires evidence within 5 business days that the controls are working. The project has no budget for new tools or third-party testing, and production access is limited to a 2-hour change window.
Which action best validates the security controls while meeting these constraints?
Best answer: B
Explanation: The best evidence for validating controls is a combination of documented test results, approvals, and monitoring output. Executing repeatable test cases for MFA and role access, capturing the results, obtaining stakeholder sign-off, and exporting SIEM alert/log data creates an audit-ready package. This approach fits the 5-day deadline, avoids new cost, and can be done within the limited production window.
Validating security controls means showing objective evidence that the control is implemented and operating as intended. In this scenario, the audit specifically needs evidence quickly, with limited production time and no budget for external services.
A strong evidence set typically includes:
Running scripted tests (e.g., verify MFA challenges, confirm least-privilege role restrictions, attempt unauthorized actions) and exporting relevant SIEM events during/after the test window provides verifiable, repeatable proof. The key takeaway is to prefer direct operational evidence over statements or vendor-only assurances when validating project-implemented controls.
Topic: Domain 2: Project Life Cycle Phases
You are planning a 12-week SaaS identity management implementation with internal infrastructure, a security team, and an external integrator. The client requires an audit trail showing who approved changes to requirements, design documents, and test plans. Teams are distributed and have already started editing draft artifacts in email threads. The sponsor wants the project schedule baselined by next week.
What is the BEST next action?
Best answer: C
Explanation: The project needs planned change control and configuration/document management before baselining and broad collaboration continue. Setting up a controlled repository with versioning and an approval workflow creates a reliable audit trail and prevents conflicting edits. It also enables a defensible baseline for schedule and key planning artifacts.
In project planning, you should proactively define how project artifacts are created, reviewed, approved, versioned, stored, and changed. With an audit requirement and distributed teams already editing via email, the immediate need is to establish configuration/document management (single source of truth, naming/versioning, access controls) and change control (what constitutes a change, how requests are submitted, who approves, and how baselines are updated). This prevents uncontrolled scope and document drift, supports traceability for audits, and makes the upcoming schedule baseline meaningful because it ties to controlled, approved requirements and plans. The key takeaway is to put governance around artifacts and changes before you lock baselines and accelerate execution.
Topic: Domain 1: Project Management Concepts
A project team is two weeks from launching a new payment microservice. During final security testing, the team discovers a critical vulnerability in a third-party open-source library the service depends on. There is no patch available, and the organization’s policy states that systems handling cardholder data cannot go live with critical vulnerabilities.
The project manager needs to document the risk response and take the next action. What is the BEST next step?
Best answer: B
Explanation: This situation requires a response that aligns with the non-negotiable constraint that critical vulnerabilities cannot reach production. The best fit is risk avoidance: changing the plan to remove the vulnerable dependency (or redesigning the component) so the risk no longer exists. Any approach that leaves the vulnerability in place conflicts with the stated policy and is not an appropriate next step.
Risk response selection should match both the threat and the project’s constraints. Here, the key constraint is a policy prohibition on deploying cardholder-data systems with critical vulnerabilities, so the team cannot simply live with the risk while hoping controls reduce impact. The appropriate response is to avoid the risk by eliminating the cause-replacing the library, redesigning the module, or delaying launch until the vulnerability is removed-and then updating the plan (schedule/baseline) accordingly.
Mitigation (adding compensating controls) can reduce likelihood or impact, but it does not remove the underlying critical vulnerability. Transfer shifts financial responsibility (for example, insurance or contractual terms) but does not make the system compliant for go-live. Acceptance is only appropriate when the risk is within tolerance and allowed by policy.
Topic: Domain 1: Project Management Concepts
You are the project coordinator for a customer identity (SSO) rollout. During integration testing, the SaaS vendor announces a mandatory API change that will delay the go-live date by two weeks unless the team removes a low-priority feature from the first release. The sponsor has already communicated the original go-live date to business leaders.
Which communication approach SHOULD AVOID when sharing this bad news?
Best answer: C
Explanation: When delays or scope changes occur, expectation management depends on timely, transparent communication that includes impact, options, and next steps. Waiting to inform stakeholders until a “perfect plan” exists and minimizing the impact increases surprise and reduces time for informed trade-offs. The best practice is to communicate early with facts and a path forward.
Managing expectations during bad news means communicating early, factually, and with enough context for stakeholders to make trade-offs. In this scenario, the vendor’s mandatory change creates a known two-week impact unless scope is reduced, so stakeholders need prompt visibility to decide between schedule and scope. Effective messages typically include the cause (at a high level), quantified impact, options (with pros/cons), the immediate next actions, and how often updates will be provided. Avoid “hope-based” messaging (minimizing impact or promising to catch up without evidence), because it damages credibility and delays decisions that could reduce overall impact. The key takeaway is to reduce surprise and enable timely decisions, even if all details are not finalized.
Topic: Domain 1: Project Management Concepts
You are coordinating an enterprise SaaS email migration. An issue in the issue log (ISS-23) states that 18 pilot users cannot authenticate via SSO.
Constraints:
What is the BEST next action?
Best answer: D
Explanation: An issue should not be closed just because someone reports it is fixed. The project coordinator should validate the resolution against the documented acceptance criteria and capture the required evidence and stakeholder confirmation. This ensures the dependency for go-live is truly satisfied and the issue log accurately reflects closure.
Issue management includes tracking an issue through resolution and then verifying closure using the issue’s acceptance criteria. In this scenario, the fix is only in staging and the acceptance criteria explicitly require (1) successful SSO for all pilot users and (2) security review of authentication logs. The best next step is to coordinate and document that verification.
This keeps governance and the go-live dependency aligned with what “done” means for the issue.
Topic: Domain 1: Project Management Concepts
You are managing an IT project to deploy MFA for remote VPN access. A draft milestone schedule will be published tomorrow. The operations manager points out that any production change must be approved by the CAB before deployment.
Exhibit: Draft milestone schedule (excerpt)
ID Milestone Planned date Predecessor(s)
M1 Requirements signed off Apr 5 -
M2 Pilot build complete Apr 12 M1
M3 Pilot testing complete Apr 19 M2
M4 CAB approval for production change Apr 26 -
M5 Production deployment Apr 23 M3
M6 Post-deployment validation complete Apr 30 M5
What should you do NEXT?
Best answer: B
Explanation: The schedule shows production deployment occurring before CAB approval, which violates a required governance dependency. The next step is to fix the schedule logic by adding the missing predecessor relationship and re-sequencing the affected milestones. This produces a realistic, compliant milestone plan before publishing it to stakeholders.
Milestone schedules must reflect real sequencing and dependencies, including governance gates like CAB approval. In the exhibit, the production deployment is planned for Apr 23 while CAB approval is planned for Apr 26, and CAB approval has no listed predecessors. The immediate next step is to correct the schedule network logic so the deployment cannot occur until CAB approval is complete, then let the schedule recalculate and review the resulting dates.
A practical sequence is:
Escalation or risk logging may follow, but only after the schedule reflects valid dependencies.