Describe the pipeline stages and quality gates you would set up for a microservice

A quality gate is an automated decision point: the pipeline cannot move past it unless an objective condition holds. The design principle is to order stages by cost and speed, so cheap checks fail fast, and to make every gate measurable rather than a judgement call.

Stages for a typical service

commit/PR
  1. Build + static checks   -> compile, lint, type-check, static analysis
  2. Unit + component tests  -> service with dependencies mocked or containerised
  3. Contract tests          -> consumer pacts published / provider verification
  4. Package + scan          -> build image, SCA, container scan, secrets scan
merge to main
  5. Deploy to test env      -> ephemeral or shared environment
  6. API / integration tests -> real database, real neighbours where possible
  7. Non-functional checks   -> smoke performance budget, DAST baseline
release
  8. Staging deploy + smoke  -> same artefact, promoted
  9. Production canary       -> metrics-based promotion or automatic rollback

The same immutable artefact (image digest) moves through every environment. Rebuilding per environment means you tested something different from what you ship.

Example gates

Gate	Pass rule (example)
Static analysis	No new blocker/critical issues; coverage on new code above the team’s agreed threshold
Unit/component	100% pass, no skipped tests without a linked ticket
Contract	Provider verifies all consumer pacts for deployed consumer versions
Security	No critical/high vulnerabilities without an approved exception; no secrets detected
API/integration	All tests pass; quarantined tests reported but not blocking
Performance smoke	p95 latency of key endpoints within budget versus baseline
Canary	Error rate and latency of canary within tolerance of the stable version

The numbers are a team decision. What matters is that they are written down, enforced by the pipeline and reviewed when they cause pain, rather than silently bypassed.

Design considerations

• Coverage on new code works better than an overall coverage target, which is easy to game and punishes legacy code.
• Gates need an exception process: a security finding with no fix available should be accepted with an expiry date, not ignored by disabling the scan.
• Flaky tests undermine gates. A gate that fails randomly gets overridden. Quarantine flaky tests with an owner and keep the blocking set trustworthy.
• Microservice-specific risk sits at the boundaries, which is why contract tests appear early: they catch breaking API changes without deploying the whole system.
• Post-deploy verification: smoke tests plus monitoring (error rates, latency, saturation) are the last gate, and rollback should be automated.

Common mistakes

• Running end-to-end tests of the entire system as the main gate for one microservice.
• Gates that only warn, so nobody acts on them.
• Different artefacts per environment.

What interviewers look for

• Logical ordering from fast/cheap to slow/expensive.
• Concrete, measurable gate criteria, not “tests pass”.
• Contract testing, security scanning and post-deployment checks as part of the design.