@steve-2 - While I certainly agree with you in that "How do I rollback a dacpac" is a completely LOADED question. What I strongly disagree with is the notion of table / data changes being dangerous and potentially prompting a restore. Planning a deployment *should* involve capturing all the necessary object level backups (ie. table exports, scripting of existing objects being updated in the deployment, etc.) needed to *revert* a deployment (which is, in fact, logically synonymous to a rollback and / or a restore) available prior code drop, and a full DB restore, IMO, should NEVER be required. This is exactly what they've built into SSDT when one deploys updates to populated tables. SSDT creates a backup of the existing table (select * into...), applies the updates to the live table, then copies the original data back into the updated table. It's all wrapped in a transaction, and if an error is thrown, a SQL rollback is performed.
My point is, there's no reason that same process can't be mimicked outside of SSDT , and I guess I was just surprised that this sort of information wasn't provided initially when the question was asked.
But, I will admit, my response here is in fact outside the scope of the initial question as I'm not providing instructions for "rolling back a dacpac applied", and more using it as a teaching moment to advise devs to do due diligence to prepare for deployments instead of just hitting that magic "update" button in SSDT and hope that everything works out :). So at the end of the day, you are correct, and none of my advice pertains to a situation in which the team is unprepared for deployment, applies a dacpac, and needs a magic "undo" button that doesn't come standard with SSDT :).