Yes, I agree Dirk it can be a tricky concept to grasp for most of our customers at first.
Think of it this way... you have a file that is uploaded and sitting in a container in blob storage. That container is the "security boundary" for what we call the "Asset" in Media Services. Essentially, you can think of it like a file sitting in a folder on your local disk, but the boundary of security for us is the Folder itself.
This is true for both uploaded content, or for live streaming, where you have a Live Output that "records" content into one of our "Asset" containers.
Now when you want people to see the content in that container, you have to publish it. The process of publishing it involves creating a "Streaming Locator" - essentially a fancy word for a URL to the manifest file for HLS or DASH streaming manifests. The Streaming Locator has some "policy" settings that can be applied to it to control things like the encryption (DRM or AES-128) and authentication required (Tokens, etc.) when publishing it.
The most basic Streaming Locator is just "in the clear" with no encryption or token policy applied. That will return you back a URL that ends with /manifest - which is the simplest form of the URL and gives you the Smooth Streaming version XML manifest back.
To modify that, and get back HLS for Apple devices, you add /manifest(format=m3u8-aapl) to the end of the URL. And there are more formats like MPEG-DASH, and different versions and settings that can be applied after that.
Streaming Locators can expire, and also be deleted if you like without impacting the Asset stored in the cloud.
In addition, you can have n-number of different Streaming Locators, that could have different DRM, encryption, and token claims settings, as you see fit for your business scenarios.
One more tricky thing is that you can also have n-number of Streaming Endpoints (origins) which provide different "hostname" paths for the Streaming Locators. This allows you to distribute traffic between two or more different CDN's if desired, but routing through multiple Streaming Endpoints. Or you may have a lot of traffic that you need to split out and route differently as needed.
Hope that helps a bit! I'll work with docs team to help explain this better based on your feedback.