A city endpoint team rolls Windows feature updates through rings: pilot IT first, then broader staff, then remaining devices. What Windows-as-a-Service practice does that describe?
Select an answer to reveal the explanation.
Short Explanation
Rings are the ‘try it on the help desk before city hall’ ladder. Feature updates crawl outward so one bad build doesn’t hit every desktop at once. Licenses and labels are different toolkits.
Full Explanation
A city endpoint team rolling Windows feature updates through rings—pilot IT first, then broader staff, then remaining devices—is using deployment rings to stage Windows-as-a-Service releases and limit blast radius during rollout. Rings turn “everyone upgrades Friday” into sequenced validation so problems surface in lower-risk cohorts first. Help desk absorbs early pain; wider city staff expand only after confidence grows. That staged servicing practice is core WaaS risk management at MS-900 fundamentals depth.
Assigning Microsoft 365 Copilot seats fails because Copilot licensing controls AI assistance seats rather than Windows feature-update staging. Enabling Microsoft Teams Phone only fails because adding calling features does not stage OS feature updates across cohorts. Creating Purview sensitivity labels fails because labels classify documents instead of sequencing Windows feature updates.
Exam caveat: deployment rings are about staged Windows servicing and blast-radius control—not Copilot, Phone, or Purview labels. Do not import unrelated Microsoft 365 brands into a rings question.
Operational check: define pilot, early majority, and late rings explicitly; place help desk early and critical offices later; watch Endpoint Analytics during pilots; pause expansion on negative signals; document promotion criteria; and keep unrelated product families out of the ring design document.