PMP · Question #1183
A project manager is managing a project for a government owned company using an iterative approach. The first useful release to production consisted of three iterations. Each iteration was successfull
The correct answer is B. Reviewed the compliance requirements with stakeholders. To prevent deployment rejection due to compliance issues, the project manager should have reviewed all compliance requirements, including security, with relevant stakeholders early in the project.
Question
Options
- AImplemented the authorization in the first iteration
- BReviewed the compliance requirements with stakeholders
- CDeployed to production after the first iteration
- DPlanned smaller iterations to review the results more often
How the community answered
(68 responses)- A3% (2)
- B81% (55)
- C6% (4)
- D10% (7)
Why each option
To prevent deployment rejection due to compliance issues, the project manager should have reviewed all compliance requirements, including security, with relevant stakeholders early in the project.
While implementing authorization early is good practice, simply implementing it doesn't guarantee it meets all security team requirements if those requirements were never reviewed.
For a government-owned company, compliance requirements, including security, are paramount and non-negotiable for production deployment. The project manager should have thoroughly reviewed and understood all such compliance requirements with *all* relevant stakeholders, including the security team, early in the project to ensure they were integrated into the development and testing process.
Deploying to production after the first iteration would likely have resulted in the same rejection, just earlier, as the underlying issue of unaddressed security compliance would still exist.
Planning smaller iterations focuses on delivering features more frequently, but it does not inherently address or prevent compliance issues if those requirements are not actively managed and reviewed.
Concept tested: Compliance management and stakeholder engagement
Source: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/project-quality-management
Topics
Community Discussion
5B is correct. The security team rejecting the deployment at the last second is a classic compliance failure, which means the PM missed a stakeholder. Reviewing compliance requirements with stakeholders early ensures security is involved from the start and not surprised at deployment time. A trips people up because it sounds agile, but authorization is a technical detail, not the root cause. The real issue is that the PM never checked what the security team required before building anything. Government owned company in the stem is your hint that compliance and security requirements will be strict and need early stakeholder alignment.
Agreed on B, and the government owned company detail is also your hint to flag compliance as a project risk early, not just a requirement to review.
Got B on my exam last month, security reviews are compliance reviews every time.
I first leaned toward A, since authorization feels like the kind of concrete security detail you'd want baked in early. But the real issue here isn't a missing feature, it's a missing conversation. Think of it like building a house and the city inspector red-tags you at move-in because nobody ever pulled the permits or checked the building code with the planning office first. The security team's decline is a compliance gate, and B is the move that catches that before you ever ship, reviewing compliance requirements with stakeholders surfaces those rules up front so test-environment sign-off doesn't lull you into a
Agree on B, and the test-environment sign-off trap is real, but I would add that the security team declining late in the game also signals nobody mapped the compliance gates into the project timeline at all, which is why B has to happen before architecture decisions get locked in, not just before shipping.