Ideally, the Quality Gate always passes. But there are some things even SonarLint can’t catch for you in the IDE. So sometimes the Quality Gate fails.
When it’s failing for something you can’t - or won’t - fix immediately, what do you do? Do you override the Quality Gate and merge or release anyway? Or do you always, always make the Quality Gate pass first? And if you override, what does that look like? Manual approvals? Something else?
Always make the QG pass.
If you had to add code coverage exclusions to bring the coverage up, add a user story in the next sprint to make up that tech debt.
If you had some other rule violation, and you plan on fixing it later, add a user story in the next sprint and close the violation with a comment or link to the user story. If you dont plan on fixing it later then no story needed, just close the violation with a comment.
If its a security hotspot violation, mark it as false positive and close it. I have used SonarCloud at two different firms in the last 3 years and every security hotspot I can remember was a false positive. Always complaining about an http:// value in a string not being https:// which would have been correct except that was not being used as a URI in any way. (SonarSource dont feel too bad about this, my last org ran Coverity Synopsis specifically to flag security issues and it was > 80% FP for me, and Sonar is so much more useful and less clunky.)