A cross-functional Scrum Team holds all the skills necessary to create value each Sprint. The test is practical. Can the team take an item from the Product Backlog and reach the Definition of Done without waiting on anyone outside it?
The wording repays a slow reading. The Guide does not say the team has every skill anyone might ask of it, it says the skills necessary to create value each Sprint. The size of the skill set is fixed by whatever it takes to get an item all the way to Done inside one Sprint.
Collective, not individual
Cross-functionality is a property of the team rather than of each person. Individuals keep their specialisms, and a team of five people who each know a little about everything and nothing deeply is usually worse at building a product than a team with real depth in it. What matters is that no skill required to finish a Sprint's work sits outside the team.
A database specialist is not a problem. A specialist who is the only possible route to any change in the schema is one, because the rest of the team stops whenever that person is away. Depth is worth keeping, and a single point of failure is not.
Why an outside dependency breaks the Sprint
Work that needs a team outside the Scrum Team cannot be finished on the Scrum Team's own decision. It finishes when the other group gets to it, and that group is ordering its own queue against its own priorities. A Sprint is a fixed length container for producing at least one usable Increment, and work that leaves the container to wait in somebody else's queue reliably comes back after the Sprint has closed.
The damage is larger than a late item. Scrum runs on inspecting a real Increment and adapting from what is learned, so a dependency that defers completion defers the feedback by the same amount, and the team is left holding work that cannot be inspected.
Why it connects to the Definition of Done
If the Definition of Done includes, say, security review or performance testing, then the team needs those skills or that criterion cannot be met within a Sprint. A Definition of Done a team cannot satisfy on its own is a signal that either the team composition or the Definition needs to change.
Which of the two changes is a real decision rather than a formality. Loosening the Definition to match the skills a team happens to have produces an Increment that is not usable, which is the worse of the two failures. Where the organisation sets a standard, a Scrum Team may apply stricter criteria and never looser ones, so the honest route is to bring the missing skill inside the team.
Broadening skills beats hiring
Where a gap exists, the instinct is to ask for another person. Hiring is slow, it is often refused, and it adds one more individual whose absence stops the work. The route that tends to hold is to broaden the skills already present and to remove the handoffs that made the gap visible in the first place.
In practice that means the people who hold a skill teaching it rather than performing it on request, pairing on work only one person can currently do, and treating an approval step outside the team as an impediment to be argued with rather than a fact of life. Some of those steps turn out to be a policy nobody has reviewed in years. The Scrum Master coaches the team in cross-functionality and causes the removal of what keeps a gap in place, which is often work to be done outside the team rather than inside it.
What the Guide does not prescribe
Scrum states the outcome and leaves the composition open. It names no roles inside the Developers, asks for no skills matrix and sets no ratio of specialists to generalists, because the answer depends on the product and on what its Definition of Done demands. What it fixes is that those skills sit inside the team.