SonarQube — PYQ (Practice Questions)
Framing note: SonarSource's own certification programs (where they exist) are not the kind of widely-standardized, publicly-benchmarked exam this platform's other PYQ sections reference — there's no public leaked-question archive to draw from. What follows is built from this guide's own Overview/Fundamentals/Intermediate/Advanced material, framed as practice questions grounded in real, documented SonarQube behavior.
1. (Domain: Issue Classification) Why does SonarQube distinguish a Bug from a Vulnerability rather than treating all "incorrect code" findings the same way?
Answer: A Bug represents code likely to produce incorrect BEHAVIOR (a logic error), while a Vulnerability represents a security weakness with a known exploitation risk — genuinely different consequences and urgency. Treating them identically would either under-prioritize genuine security risk or over-treat every minor logic issue with security-level urgency; the separate classification lets teams and Quality Gates respond proportionally to each.
2. (Domain: Clean as You Code) Why does SonarQube's default Quality Gate scope conditions to the "New Code" period rather than the entire project's history?
Answer: Requiring a full historical codebase to meet gate conditions before any team could adopt SonarQube at all would make adoption on a real, imperfect legacy codebase impractical — a project with years of accumulated issues would fail immediately and indefinitely. Scoping to New Code makes the gate achievable for ongoing work while still surfacing (not hiding) the pre-existing backlog separately, letting teams add real value on everything going forward without requiring an unrealistic cleanup project first.
3. (Domain: Security Hotspots) A static analysis finding is classified as a Security Hotspot rather than a confirmed Vulnerability. What does this specifically indicate about the finding?
Answer: It indicates the pattern is security-sensitive but its actual exploitability depends on context static analysis can't fully determine on its own — whether user input feeding into the pattern is genuinely unsanitized in this specific case, for example. It requires human review to resolve, rather than being automatically confirmed as exploitable (Vulnerability) or automatically dismissed.
4. (Domain: Coverage Integration) A project shows 0% code coverage in SonarQube despite the team having substantial local test coverage. What's the most likely explanation?
Answer: SonarQube doesn't run tests or compute coverage itself — it imports a coverage report generated by the project's own test tooling. 0% almost always means the coverage report was never generated as part of the analysis run, or the report path/format configured in the scanner invocation doesn't match where the report actually was produced — not that coverage is genuinely absent.
5. (Domain: Quality Profiles vs. Gates) What's the functional difference between adjusting a Quality Profile and adjusting a Quality Gate?
Answer: Adjusting a Quality Profile changes WHICH rules are active and at what severity for the analysis itself — affecting what gets flagged as an issue at all. Adjusting a Quality Gate changes what COMBINATION of the resulting metrics constitutes an overall pass/fail — affecting whether a given set of findings blocks a merge, without changing what was actually detected. They're independent configuration axes addressing different questions.
6. (Domain: Pull Request Analysis) Why does PR-decorated analysis (inline comments, gate status directly on the pull request) tend to be more effective at driving fixes than a separate SonarQube dashboard report?
Answer: PR decoration surfaces findings exactly where and when a reviewer is already looking — during the actual review, on the specific changed lines — rather than requiring someone to separately remember to check a different dashboard after the fact. Feedback delivered at the point of natural attention is acted on far more reliably than feedback requiring an extra, easy-to-skip step to discover.
7. (Domain: Duplication Detection) Why does SonarQube's duplication detection use token-level similarity rather than requiring an exact textual match between code blocks?
Answer: Genuinely duplicated LOGIC often has minor superficial differences (different variable names, slightly different formatting) despite representing the same underlying, maintenance-risky duplication — an exact-text-match approach would miss this while the real risk (a bug fix applied to one copy being forgotten in the other) is identical regardless of superficial naming differences.
8. (Domain: Architecture) Why can a CI pipeline's Quality Gate check be delayed even after the SonarScanner itself finishes running quickly?
Answer: The scanner only uploads an analysis report — actual processing (computing metrics, evaluating gate conditions) happens server-side via the Compute Engine, which processes uploaded reports from a queue. A burst of simultaneous analyses across many projects/pipelines can create a real processing backlog, delaying when gate results become available even though the scanner's own work already completed.
9. (Domain: SonarLint vs. SonarQube) Why does using SonarLint alongside SonarQube provide more value than either alone?
Answer: SonarLint delivers feedback in the IDE as code is being written, before commit — the earliest, cheapest point to catch and fix an issue. SonarQube provides the shared, CI-integrated, historically-tracked, team-wide gate enforcement a single developer's local IDE session structurally can't provide on its own. Together, they cover both the earliest individual-feedback point and the authoritative, team-wide checkpoint — neither fully substitutes for the other.
10. (Domain: Legacy Adoption) Why is running an initial SonarQube analysis in "report-only" mode (no gate enforcement) often recommended before enabling a hard Quality Gate on a previously-unscanned codebase?
Answer: A brand-new hard gate against years of never-before-measured findings will almost always surface an overwhelming baseline immediately, since nothing was ever previously checked — this isn't a sign the tool or codebase is unusually bad, it's the expected result of measuring something for the first time. Report-only mode reveals the real scope before committing to enforcement, allowing genuine triage (fix what's fixable, document accepted exceptions) before a hard gate goes live against a now-realistic, deliberately-established baseline — avoiding the common failure mode of a team abandoning the tool entirely after an overwhelming, un-triaged first encounter.