It all reduces to the key
Every CDN decision reduces to the cache key, the thing deciding whether two requests are the same object.
Take the default as roughly the host, the path and the query string. Both directions of getting it wrong hurt you.
Make your key too broad, by ignoring a parameter that changes the response, and you hand one person's variant to somebody else. That is how real incidents have leaked one customer's data to another.
Make it too narrow and you fragment the cache. Leave a marketing tag in the key and the same image is cached once per campaign link, and your hit rate quietly collapses.
Do the unglamorous work: normalise your keys, strip the irrelevant parameters, and be deliberate about which headers you vary on. That work decides whether the CDN helps you at all.
Expect invalidation to be harder here than in a single cache, because this one is thousands of servers on five continents.
Use whichever purge your provider offers, by address, by prefix, or by tags you attach to responses so purging one tag clears every page mentioning that product.
Propagation is eventual. One provider advertises purges in about 150 milliseconds and others take seconds to minutes, and during that window different cities serve different versions of your site.
Version the address instead
Avoid purging entirely instead, which is the professional habit, by versioning your addresses. Your build tool fingerprints each asset by its content and references the new name in your markup.
Notice what a deploy now does: it updates no cached object at all. It publishes new objects at new addresses and lets the old ones age out.
Give those assets a lifetime of a full year and mark them immutable, because their content can never change under that name. The only thing needing a short lifetime is the markup pointing at the versions.
Demote purges to your emergency tool, for takedowns and leaked data, not a step in every deploy.
Worked example
Amara's team at an online magazine deploys on Thursdays, and every deploy triggers a fire drill: purge the CDN, watch pages load with mismatched styling for a few minutes while some PoPs serve new HTML with old CSS, then field reader complaints. One Thursday the mismatch breaks the checkout page styling badly enough that subscriptions dip for an hour. The fix is switching their bundler to content-hashed filenames: styles.a91bd0.css instead of styles.css, with the HTML carrying a 60-second s-maxage and the hashed assets a one-year immutable lifetime. New HTML always references exactly the CSS it was built with, so old and new versions coexist harmlessly during rollout. Deploy-day purges disappear from the runbook, and their CDN hit rate rises three points because assets are never evicted by a purge again.