What is a CI/CD quality gate? Give a simple example.

WHAT THIS TESTS: This question checks if you understand the difference between running checks and enforcing policy. A quality gate is not a test suite; it is a set of conditions on metrics that produces a binary pass or fail result. The interviewer wants to see that you know it blocks pipeline progression and merge requests when failed, and that you can design a pragmatic starting policy rather than an overwhelming one.

A GOOD ANSWER COVERS: Four things in order. First, define the purpose: a quality gate answers whether code is ready for release by measuring new or overall code against metric thresholds during analysis. Second, explain CI integration: the gate status is reported back to the pipeline and can fail the build or block a pull request merge via decoration. Third, describe a simple new-project gate focused on new code, not overall code, because legacy debt should not block new progress. Good starting conditions are zero new critical or blocker issues, zero new security vulnerabilities, and at least 70 percent coverage on new code. Fourth, justify the choice: starting minimal avoids alert fatigue, keeps the team honest about new changes, and can be tightened over time as the codebase matures.

COMMON WRONG ANSWERS: Three red flags stand out. One, conflating quality gates with running unit tests or linting; those generate data, but a gate is a policy layer that acts on the data. Two, proposing an overly aggressive gate for a new project, such as 90 percent overall coverage or strict cognitive complexity limits on all code, which creates noise and teaches teams to ignore the gate. Three, forgetting to mention that the gate must actually block the pipeline or merge; if it only warns, it is not a gate.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a legacy project with massive existing debt, how to prevent developers from gaming coverage with meaningless tests, or when to use overall versus new-code conditions. They might also ask how to integrate the gate with GitHub, GitLab, or Jenkins, or how to manage different gates for different teams or risk profiles.

ONE CONCRETE EXAMPLE: For a new Java microservice using SonarQube, I would assign the default Sonar way gate initially, then create a custom lightweight gate named Team Alpha New Code. The conditions would be: no new blocker or critical issues, no new vulnerabilities, at least 70 percent line coverage on new code, and less than 3 percent duplication on new code. I would configure the CI pipeline to fail the build if the gate fails, and enable pull request decoration so the merge button is disabled until the issues are resolved or the coverage threshold is met. After three sprints of stability, I would raise the coverage threshold to 80 percent and add a condition on security hotspots.