The Sprint Backlog is the Developers' plan for a single Sprint, and it carries three things at once. The Sprint Goal is the why, the set of Product Backlog items selected for the Sprint is the what, and an actionable plan for delivering the Increment is the how. Remove any one of the three and what is left is a task list rather than a plan.
A plan by and for the Developers
Both halves of that phrase do work. The people who will carry out the work make the plan, because they are the only ones who know what the work actually involves. The plan then exists to serve their own decisions rather than to report progress to anybody outside the team.
Almost every exam question on this artefact tests the same boundary. A manager who assigns tasks, a Product Owner who inserts an item after Sprint Planning, or a Scrum Master who keeps the board tidy on the team's behalf is taking on something the framework places with the Developers.
Selected, not handed over
The items in the Sprint Backlog were chosen by the Developers during Sprint Planning. The Product Owner orders the Product Backlog and explains which items would most increase value, and the Developers decide how many of those they can turn into a Done Increment. That division is the reason a forecast means anything at all, since a quantity of work handed to a team is somebody else's guess about its capacity.
What may change and what may not
The Sprint Goal is the commitment of the Sprint Backlog, and it holds for the whole Sprint. Everything else in the plan is expected to move. Scope may be clarified and renegotiated with the Product Owner as more is learned, so an item can be dropped once it turns out to be unnecessary and work can be added when the Developers find that the goal needs it.
The word worth noticing is renegotiated, because it describes a conversation rather than a unilateral act by either side. The Product Owner cannot push work into the Sprint Backlog, and the Developers cannot quietly drop items the Sprint Goal depends on.
Why it is updated every day
A plan written on the first morning and left alone for two weeks is a record of what a team once believed. The Sprint Backlog is meant to be a highly visible, real time picture of the work the Developers plan to accomplish, which means it is revised as they learn. That currency is what makes it usable at the Daily Scrum, where the Developers inspect progress towards the Sprint Goal and adapt the plan for the coming day.
It follows that the plan needs enough detail to inspect progress against and no more. Detail beyond that point is effort spent specifying work that the next day's learning is about to change.
What the framework does not say
Scrum does not require a board, a burndown chart, tasks, estimates in hours or any tool. Those are practices teams have found useful, and none of them appears in the Guide. What is required is that the three parts exist, that the Developers own the plan, and that it stays current enough to support daily inspection.
So a scenario describing a team with no task board is not describing a team doing Scrum wrongly. One describing a Sprint Backlog that nobody has touched since Sprint Planning is.