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.
What the Scrum Master does when a Sprint Goal looks obsolete
A Scrum Master often sees that a Sprint Goal has died and has no authority to act on it, and the service that follows is to make the evidence impossible to miss. The news that kills a Sprint Goal usually arrives somewhere other than the team, in a regulator's notice or a decision taken in a meeting the team was not in. Carrying it to the Product Owner quickly is the Scrum Master's work, along with asking plainly whether achieving this Sprint Goal would still be worth the days that remain.
The Scrum Master must not decide, and the pressure to decide is real, because management often asks the Scrum Master to stop the Sprint while the Developers often want somebody else to take the decision. The Guide gives the authority to the Product Owner alone, so the Scrum Master coaches that decision and never makes it. Once the Product Owner has decided, the service is ordinary again. The event that starts the next Sprint is Sprint Planning, and ensuring it happens and stays inside its timebox is the same accountability as on any other day.
Why cancellation 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 signalling one of two things, either 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.
Reasons that do not justify cancelling a Sprint
Cancellation is not a punishment, so 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.