"Sovereign cloud" is the most-used phrase in the region that two people in a meeting almost never define the same way.
Everyone wants it. Ask three buyers what they mean and you'll get three answers, and that's before the vendors arrive with a fourth.
For one, sovereignty means the data physically stays in-country. For another, it means no foreign government can compel access, wherever the bytes sit. For a third, it's operational control: that local staff, vetted locally, run the thing, and a parent company on another continent can't reach in. These aren't the same requirement. A design that satisfies one can fail another completely.
The word does a lot of marketing work precisely because it's elastic. A provider can truthfully say "sovereign" while meaning only the easiest of those definitions, and the buyer hears the hardest one. Everyone leaves the room agreeing, and agreeing about different things.
The useful work is unglamorous. Before the architecture, before the shortlist, pin down which sovereignty you actually need: data location, legal reach, operational control, or some specific combination. Then test every "sovereign" claim against that, not against the brochure.
Sovereign isn't a product category. It's a question you have to answer for yourself before anyone can sell you the answer.