SonarQube Interview Questions
Q: What's the difference between a Bug, a Vulnerability, and a Code Smell in SonarQube?
A: A Bug is code likely to produce incorrect behavior (a logic error, a null-pointer risk). A Vulnerability is a security weakness with a known exploitation risk. A Code Smell is a maintainability concern — not strictly incorrect, but riskier or slower to safely change over time (excessive complexity, duplicated logic). The distinction drives prioritization: Bugs/Vulnerabilities generally warrant urgent, often gate-blocking attention; Code Smells are typically tracked but not necessarily blocking.
Q: What's a Security Hotspot, and why isn't it automatically classified as a Vulnerability?
A: A Security Hotspot flags a genuinely security-sensitive pattern (like a SQL query built from concatenated input) that COULD be a real vulnerability depending on context static analysis can't always fully determine — whether the input is actually sanitized elsewhere, whether it's genuinely untrusted in this specific case. It requires human review to resolve that ambiguity, rather than risking excessive false positives (auto-flagging as Vulnerability) or missed real risk (auto-dismissing).
Q: What's "Clean as You Code," and why does it matter for adopting SonarQube on a legacy codebase?
A: It's SonarQube's default philosophy of scoping Quality Gates to the New Code period (recently changed code) rather than a project's entire history. This makes adoption practical on an imperfect, real-world codebase — new/modified code must meet the gate's bar, while pre-existing issues remain visible and trackable without requiring an unrealistic full-history cleanup before the tool can add any value at all.
Q: What's the difference between a Quality Profile and a Quality Gate?
A: A Quality Profile determines WHICH rules are active and at what severity for a given language/project. A Quality Gate determines what COMBINATION of the resulting metrics (new bugs, coverage, duplication, etc.) constitutes an overall pass or fail. They're separate, complementary configuration axes — tuning one doesn't automatically tune the other.
Q: Does SonarQube run tests or compute code coverage itself?
A: No — SonarQube imports coverage reports generated by the project's own test tooling (JaCoCo, coverage.py, Istanbul, etc.) and displays/gates on that imported data. A project showing 0% coverage in SonarQube almost always means the coverage report wasn't generated or its path is misconfigured in the scanner invocation, not that coverage is genuinely zero.
Q: What's the difference between branch analysis and pull request analysis?
A: Branch analysis tracks ongoing quality for a specific branch over its own lifecycle — useful for long-lived feature branches. Pull request analysis is specifically oriented around decorating one PR (inline comments on changed lines, an overall gate status check) for review, tied to that PR's lifecycle and visible directly where a reviewer is already looking.
Q: What's the practical difference between SonarQube, SonarCloud, and SonarLint?
A: SonarLint gives real-time, local IDE feedback as code is written, before commit — the earliest possible feedback point. SonarQube (self-hosted) and SonarCloud (SonarSource's hosted SaaS) both provide the shared, CI-integrated, historically-tracked, gate-enforced analysis a single developer's local session can't provide — the choice between them is self-hosting control/data-residency versus no infrastructure to manage.
Q: Why might a Quality Gate that always fails, or one that never fails, both be signs of miscalibration?
A: A gate that always fails on real projects may be too strict for the team's actual situation, leading to gate fatigue or bypassing; a gate that never fails may be too lenient to add real value, effectively becoming a rubber stamp. Periodically reviewing the gate's pass/fail rate against the team's real experience is part of keeping a SonarQube setup genuinely useful over time, not a one-time setup decision.
Q: What's a genuine operational bottleneck at scale that's specific to SonarQube's architecture?
A: The Compute Engine's report-processing queue — server-side processing of uploaded scanner reports happens from a queue, and a burst of simultaneous analyses across many projects/CI pipelines can create a real backlog, delaying when Quality Gate results become available even after the scanner itself already finished. This matters directly for CI pipelines blocking on gate status.
Q: How would you introduce SonarQube into a large, previously-unscanned legacy codebase without disrupting the team?
A: Run an initial analysis in report-only/non-blocking mode first to see the real baseline (expected to be large — not a tool failure). Configure the Quality Gate using the default Clean as You Code New Code scope rather than gating on the full historical backlog. Integrate as a PR check so findings surface directly during review. Track the legacy backlog as a separate, visible item to work down deliberately, and revisit Quality Profile configuration over time as the team learns which rules genuinely add value for their codebase.