Try 10 focused PMI-PBA questions on Traceability and Monitoring, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PMI-PBA |
| Topic area | Traceability and Monitoring |
| Blueprint weight | 15% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Traceability and Monitoring for PMI-PBA. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 15% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Traceability and Monitoring
A business analyst must provide a weekly requirements update to the project manager, sponsor, compliance lead, and operations manager. Several requirements have changed, two stakeholder conflicts remain unresolved, and one pending change could affect the release date. The audience wants a clear, concise status view, but detailed backup must be available if needed. Which communication approach is the best fit?
Best answer: D
What this tests: Traceability and Monitoring
Explanation: The best choice is the concise status dashboard because the need is to communicate requirements issues, changes, risks, and overall status clearly to a mixed stakeholder group. It gives leaders a fast view of what matters while preserving access to detailed artifacts when questions arise.
This situation is about tailoring requirements communication to the audience and purpose. The stakeholders need an efficient status view, not a deep working artifact. A one-page dashboard can summarize current requirement status, approved and pending changes, unresolved conflicts, key risks, and decisions needed, which directly supports clear and succinct communication.
It works well because it:
A full traceability matrix or complete requirements package is useful for analysis, auditability, or approval rigor, but those are too detailed for routine status communication. Workshop minutes capture discussion history, not an executive-ready requirements status message.
A concise dashboard fits a mixed audience by highlighting requirement status and impacts while allowing supporting detail to be referenced separately.
Topic: Traceability and Monitoring
A business analyst is reviewing the traceability tool before the next design handoff. Based on the exhibit, what is the best action?
Exhibit: Traceability record excerpt
Req ID: BR-24
Requirement: Capture customer consent before data sharing
Lifecycle status: Under review
Owner(s): Compliance manager / Sales operations lead
Last status change: 19 days ago
Dependent artifact: Interface design D-08 (blocked)
Target baseline date: 6 days ago
Recent notes:
- Day 5: Compliance: "Consent required for all channels."
- Day 8: Sales Ops: "Phone orders should be exempt."
- Day 12: BA requested joint clarification and approval.
- Day 16: Reminder sent; no joint response.
Best answer: D
What this tests: Traceability and Monitoring
Explanation: The record shows more than a routine review delay. Conflicting stakeholder direction, no movement for 19 days, a missed baseline date, and a blocked downstream artifact indicate the requirement is stalled and needs escalation with an updated lifecycle status.
In traceability and monitoring, a requirement is stalled when it is not progressing through lifecycle states because a needed decision or clarification is unresolved. Here, the signs are clear: the status has not changed for 19 days, the target baseline date was missed, key stakeholders disagree on the business rule, and a dependent design artifact is already blocked.
The BA should follow the requirements management or escalation path, obtain clarification from the proper decision authority, and update the traceability record to reflect the actual condition, such as blocked or at risk, along with impacted dependencies. That keeps status reporting accurate and supports timely intervention. Continuing as if the requirement were approved would hide uncertainty, while restructuring the requirement before the policy is clarified would be premature.
The key takeaway is that unresolved conflict plus downstream impact means the requirement needs escalation, not passive waiting.
Conflicting interpretations, a missed baseline date, no status movement, and a blocked dependency show the requirement is stalled and needs formal clarification through escalation.
Topic: Traceability and Monitoring
On a hybrid project, a BA sees that a regulatory reporting requirement is linked to completed development and passed QA tests in the traceability tool. The product owner asks the BA to update the requirement from Validated to Accepted before the weekly status report, but the BA is unsure whether the compliance manager, business owner, or product owner must confirm that transition. What should the BA verify FIRST before recording the status update?
Best answer: C
What this tests: Traceability and Monitoring
Explanation: This is a governance question about requirement status changes. Before updating a lifecycle state in the traceability tool, the BA must first confirm who is authorized to approve that transition and who must be informed, using the requirements management approach or similar guidance.
The core concept is lifecycle status control in requirements traceability. When the evidence suggests a requirement may be ready for the next state but the responsible stakeholder is unclear, the BA should first check the defined approval and notification assignments for that specific transition. In this scenario, passed QA testing supports progress, but it does not identify who has authority to confirm Accepted for a regulatory requirement.
A good first check is the project’s requirements management plan, RACI, or traceability governance rules to confirm:
Only then should the BA communicate with the right stakeholder and record the update. Test results and readiness inputs matter, but they do not replace decision rights.
If the required confirmer is unclear, the BA should first verify the plan-defined authority and notification rules for that status change.
Topic: Traceability and Monitoring
A BA is about to change requirement R-27 from Validated to Approved in the traceability tool for a loan-origination project. The requirements management plan states that the business owner confirms business value and acceptance criteria before Approved, the solution architect reviews feasibility, and the compliance manager is notified after status changes. Developers say the requirement is implementable.
Before the BA records the new status, whose confirmation is required?
Best answer: D
What this tests: Traceability and Monitoring
Explanation: Requirement status updates should reflect the stakeholder authorization defined in the requirements management approach. Here, moving to Approved requires confirmation from the business owner, not from feasibility reviewers, implementers, or stakeholders who are only informed after the change.
The key concept is that a requirement’s lifecycle status should only be updated when the appropriate stakeholder has provided the confirmation tied to that specific state. In this scenario, the plan explicitly says the business owner confirms business value and acceptance criteria before the requirement can move to Approved.
That makes the business owner the required confirmer. The solution architect’s role is to assess feasibility, which supports analysis but does not authorize business approval. The development lead’s input shows readiness to implement, but implementation readiness is not the same as business approval. The compliance manager is part of the communication path after the update, not the approval path before it.
When recording status in a traceability tool, the BA should match the update to the authorized stakeholder for that lifecycle transition.
The business owner is the designated approver for moving the requirement into an approval status because that role confirms value and acceptance criteria.
Topic: Traceability and Monitoring
During a steering review, stakeholders receive a status report showing that 9 of 25 high-priority requirements are marked implemented but have no passed validation evidence, and go-live is in two weeks. Stakeholders now question whether the solution is truly ready. What should the business analyst provide next to best support an informed decision?
Best answer: A
What this tests: Traceability and Monitoring
Explanation: When stakeholders are concerned about readiness, they need evidence that requirements have been fully traced through acceptance criteria and successful validation. A traceability matrix with test status and open changes directly shows whether high-priority requirements are ready for go-live.
The key concept is communicating requirements status with evidence that supports decision-making, not just reporting activity. Here, the concern is solution readiness: some high-priority requirements are implemented, but there is no passed validation evidence. The most useful follow-up is an end-to-end traceability view that connects each critical requirement to its acceptance criteria, test results, and any unresolved changes.
This lets stakeholders quickly determine:
Activity summaries, team progress measures, and document version history may be useful for management, but they do not prove that the delivered solution satisfies the required outcomes. In this situation, readiness must be validated with requirement-level traceability and test evidence.
This artifact best validates readiness because it shows whether critical requirements are fully covered, tested, and still affected by unresolved change.
Topic: Traceability and Monitoring
A business analyst reviews the weekly traceability report for a regulated claims-processing enhancement. The release baseline was approved 3 weeks ago, and any requirement change after baseline must follow formal change control. Which observation is the strongest evidence that requirements governance is functioning effectively?
Best answer: A
What this tests: Traceability and Monitoring
Explanation: Effective requirements governance is shown by complete, current traceability plus disciplined baseline control. The strongest evidence is a report showing lifecycle status, downstream links to supporting artifacts, and formal approval for the only post-baseline change.
To judge whether requirements governance is functioning, look for evidence that each requirement is being monitored through its lifecycle and that any post-baseline change is controlled. Current status values show the team is actively tracking progress. Trace links to supporting artifacts such as models and test cases show dependency coverage and help confirm the right artifacts were produced, reviewed, and kept aligned. An approved change record for a revised requirement shows impact analysis, versioning, and baseline control are working as intended.
By contrast, adding work before approval breaks change discipline, leaving links to superseded artifacts creates unreliable traceability, and stopping status updates removes visibility into lifecycle progress. Strong governance is not just having a baseline; it is maintaining accurate trace links and controlled changes after that baseline is set.
This shows active lifecycle monitoring, complete downstream traceability, and controlled handling of a post-baseline change.
Topic: Traceability and Monitoring
A retail bank’s BA reviews a failed UAT cycle for a funds-transfer requirement. Operations rejected the build as “not what we approved,” developers say they coded the latest wording, and QA tested older acceptance criteria. The traceability tool shows:
ID: FR-18
Version: 3.1
Status: Approved
Approved by: Operations director on April 4
Last content change: April 16
Change summary: Added exception handling and manual override
Linked tests: Based on version 2.0 criteria
Stakeholder notification of change: None recorded
What is the most important status error in this requirement record?
Best answer: B
What this tests: Traceability and Monitoring
Explanation: The key gap is that the requirement was materially changed after approval, but its lifecycle status still showed Approved. That prevented proper reapproval, stakeholder communication, and synchronized traceability updates across tests and delivery work.
The core concept is lifecycle status accuracy in the traceability record. Once an approved or baselined requirement is materially changed, it should no longer remain simply Approved; it should move to the organization’s change, review, or pending reapproval state so impacted stakeholders can reassess it. In this scenario, version 3.1 added exception handling and manual override after the April 4 approval, yet no change notification was recorded and QA stayed tied to version 2.0 criteria. That means the requirement’s recorded status did not reflect its true state, which led to approval churn, mismatched testing, and rework.
The outdated test links are an important symptom, but they stem from the incorrect status handling.
A substantive post-approval change should move the requirement out of Approved until impacted stakeholders review and reapprove it.
Topic: Traceability and Monitoring
After a review meeting, a compliance requirement is no longer considered ready for build. The product owner asks the business analyst to change its status in the traceability tool from Approved to Needs Review. Legal raised the concern verbally, but teams use the tool differently: some overwrite the status field, while others create a new version or change-log entry. What should the business analyst verify first before making the update?
Best answer: C
What this tests: Traceability and Monitoring
Explanation: The first priority is to preserve traceability integrity when updating lifecycle status. Before changing the requirement, the BA should confirm the approved method for recording the new status, prior status, and reason so history is not lost.
This tests lifecycle status management in the traceability artifact. When a requirement moves backward or changes state, the BA should first verify the defined recording method in the tool or requirements management approach so the update keeps an audit trail of the previous status and the rationale for the change. In this scenario, the status is changing based on a verbal concern, and the team uses inconsistent methods, so the immediate risk is overwriting evidence of what changed and why.
A sound first step is to confirm whether the tool requires a status transition entry, comment, version, or linked change record. Once that method is clear, the BA can record the update, communicate it, and assess downstream impacts. Checking priority, design progress, or rewritten wording may matter later, but those actions come after protecting status history and rationale in the traceability record.
The BA should first confirm the required audit trail method so the status change preserves prior state and its rationale.
Topic: Traceability and Monitoring
A baselined requirements package for a health insurance claims portal is in UAT. A compliance manager notices one requirement says “member ID,” but the enterprise glossary, data model, interface spec, test cases, and acceptance criteria all use “subscriber ID” for the same existing field. The team confirms the field, format, business rules, interfaces, and reports do not change. Under the change control plan, a formal change request would pause UAT for governance review. Which action best maintains baseline integrity?
Best answer: D
What this tests: Traceability and Monitoring
Explanation: The issue is terminology alignment, not a new or altered requirement. Since the existing field, rules, interfaces, and acceptance criteria stay the same, the BA should manage it as a controlled clarification and keep traceability artifacts consistent without triggering unnecessary rebaselining.
The core concept is comparing the requested update to the requirements baseline to determine whether anything substantive changes. Here, the request does not add functionality, alter business rules, change acceptance criteria, or affect downstream solution behavior. It only resolves inconsistent terminology for the same already-approved data element.
A good BA response is to:
A formal change request is appropriate when the baseline itself is being changed in meaning, scope, risk, or acceptance. The closest distractor is leaving the text as-is and relying on verbal guidance, which avoids governance delay but weakens artifact integrity and increases confusion later.
This is a clarification because the term alignment does not change behavior, scope, or acceptance criteria, so controlled versioning preserves the baseline.
Topic: Traceability and Monitoring
A bank is preparing for an internal audit after several late changes to loan-origination requirements. The sponsor asks the business analyst for an artifact that shows each approved requirement’s origin, current status, dependencies, linked design/build/test items, and change history so auditors can verify what was delivered and why. Which traceability structure best supports this oversight and auditability need?
Best answer: D
What this tests: Traceability and Monitoring
Explanation: The best choice is the bidirectional traceability matrix because it connects each requirement to its source, status, dependencies, downstream work products, and validation evidence. That gives auditors and project leaders a clear line of sight into whether approved requirements were delivered as stated and changed in a controlled way.
For project oversight and auditability, the key need is evidence that a requirement can be traced across its lifecycle. In this scenario, the team must show where each requirement came from, whether it changed, what it affected, and how delivery was verified. A bidirectional traceability structure does that by linking upstream items such as source and rationale with downstream items such as design components, test cases, and release status.
This makes it possible to:
A sign-off record or backlog can support governance, but neither gives the same end-to-end, testable chain of evidence needed to prove requirements were delivered as approved.
This structure provides end-to-end evidence from requirement origin through implementation and validation, which is what oversight and auditability require.
Use the PMI-PBA Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PMI-PBA guide on PMExams.com, then return to PM Mastery for timed practice.