An operations team uses the terms release and deployment interchangeably. The service manager wants to separate the two responsibilities in line with ITIL practices. Which distinction is correct?
Select an answer to reveal the explanation.
Short Explanation
Think of a restaurant: deployment is getting the new dish into the kitchen, and release is putting it on the menu for diners. You can deploy something and keep it hidden behind a feature flag until release day. The trap is swapping the two, or confusing either with change approval.
Full Explanation
ITIL separates two practices that are often blurred. Release management aims to make new and changed services and features available for use, deciding what is offered to users and when. Deployment management aims to move new or changed hardware, software, documentation, processes or other components to live environments, and may also deploy components to other environments for testing or staging. The two can be decoupled: code may be deployed to production but not released, for example behind a feature flag, until the business is ready. Reversing the definitions assigns the technical movement of components to release and the user-facing availability decision to deployment, which is the opposite of the ITIL purposes. Change approval belongs to change enablement, and recording configuration items belongs to service configuration management, so neither describes release or deployment. Restricting release management to emergency fixes misunderstands it entirely; releases include planned features and versions, while emergency changes are a category within change enablement. Exam caveat: the 2026 outline lists deployment and release management separately among operational controls, so expect questions that test the boundary. Operational check: confirm that the deployment pipeline records which build reached each environment, and that release records show who approved making the change available to users and when it was communicated.