A Release policy needs to be documented and agreed. What must be included in the Release policy?

Question

Options

• Aan analysis of the success or failure of
• BReleases Requests For Change (RFCs)
• Cthe frequency and type of Releases
• Dthe Release dates

• A
  15% (10)
• B
  3% (2)
• C
  75% (51)
• D
  7% (5)

Explanation

Option C is correct because a Release policy must define how releases are managed - specifically the frequency (how often releases occur, e.g., monthly) and type (e.g., major, minor, emergency). This gives the organization a consistent, agreed-upon framework for planning and executing releases.

• A is wrong - Post-release analysis (success/failure review) belongs in a Post-Implementation Review (PIR), not the policy itself.
• B is wrong - RFCs (Requests for Change) are inputs to the Change Management process, not a required element of a Release policy.
• D is wrong - Specific release dates are scheduling details that vary per release; they belong in a Release Plan, not the overarching policy.

Memory tip: Think of a policy as the rules of the game, not the scoreboard (A), the application forms (B), or the match schedule (D). The rules define what kind of game is played and how often - that's frequency and type.

No community discussion yet for this question.