A Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it. Those two sentences carry the whole rule, and nearly every question on the topic turns on one or the other.
Obsolete is a high bar
A Sprint Goal is obsolete when achieving it would no longer make sense. The regulator has banned the feature, the competitor has shipped it and taken the market, the customer the work was for has gone, or the company has changed direction so completely that the objective now belongs to a product it no longer sells.
What does not qualify is far more common in exam scenarios. Work turning out harder than expected, a key person falling ill, a dependency arriving late, a stakeholder wanting something else more urgently, or the Developers realising they cannot finish everything they selected. All of those are handled inside the Sprint by renegotiating scope with the Product Owner, because the goal is still worth reaching even if less will be delivered alongside it.
Only the Product Owner decides
The Scrum Master can see that the goal is dead, the Developers can say so first, and a stakeholder can be the one who brings the news that killed it. None of them can cancel the Sprint.
The authority sits with the Product Owner because cancellation is a decision about value rather than about delivery. Continuing a Sprint whose goal is obsolete spends the team's time producing something worth nothing, and the one accountable for maximising the value of the product is the one who should carry that call. This is also why the reverse holds. Management cannot cancel a Sprint either, however senior the person asking.
Why it is rare
Cancellation is expensive. Everyone regroups in another Sprint Planning, the plan is rebuilt from nothing, and the team spends a chunk of the recovered time on the recovery itself.
It is also rare for a structural reason. Sprints are a month or less, so the window in which a goal can go obsolete and there is still meaningful time left to save is narrow. In a two week Sprint that has run for eight days, finishing usually costs less than stopping. A Product Owner who cancels often is normally telling you that the Sprint Goals were never sharp enough to become obsolete, or that the Sprint length is longer than the rate of change in the market allows.
What happens to the work
Completed and Done items are reviewed. If the Product Owner accepts them they are potentially releasable, and work that met the Definition of Done does not stop being valuable because the Sprint around it ended early.
Everything incomplete goes back on the Product Backlog. It is not held aside in a partial Sprint Backlog and it carries no privileged position, so it is sized again and reordered against everything else. A new Sprint then starts with its own Sprint Planning and its own Sprint Goal.
What cancellation is not
It is not a punishment, and it is not a tool for correcting a team that is behind. Using it that way makes the Sprint feel unsafe and pushes the Developers towards padded forecasts, which costs far more than the Sprint being rescued.
Nor is it a way to change direction quickly. A Product Owner who wants different work next can usually wait days rather than weeks, and reordering the Product Backlog before the next Sprint Planning achieves the same thing without throwing away the plan in progress.