How do you add a basic post-deployment health check in CI/CD?

WHAT THIS TESTS: This question probes whether you treat deployment as a process that ends with verified service health, not just with a configuration change pushed to a cluster. Interviewers want to see that you distinguish between infrastructure mutation and application readiness, and that you can build automated gates that protect users from broken releases.

A GOOD ANSWER COVERS: A strong answer walks through the following layers in order. First, the pipeline stage itself: you add a post-deployment job that runs after the deploy stage and is marked as a hard gate, so a failure blocks production traffic or triggers rollback. Second, the probe mechanism: you call a dedicated health endpoint such as /health or /ready with HTTP retries, exponential backoff, and a timeout budget, for example 30 seconds with three retries. Third, the validation criteria: you check that the endpoint returns a 200-level status code, responds within an SLA such as 500 milliseconds, and returns an expected payload or version identifier. Fourth, dependency validation: you confirm that the application can reach its database, cache, or message broker, either through the health endpoint depth or through a separate smoke test. Fifth, the failure action: on repeated probe failure, the pipeline should either run an automatic rollback, drain traffic from the new version, or page the on-call engineer.

COMMON WRONG ANSWERS: The biggest red flag is saying that a successful Terraform apply, kubectl rollout status, or Ansible play exit code is sufficient proof. Another weak pattern is proposing a manual check in a browser or a single curl with no retry logic. Some candidates only mention container readiness probes inside Kubernetes but forget that the pipeline itself needs a validation stage before it marks the build green. Also, checking only that the process is running without validating traffic-serving ability misses the point.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle health checks during a canary or blue-green rollout, how you avoid false positives from cached health endpoints, or how you secure the health endpoint so it does not leak sensitive data while still being reachable from the CI runner. They might also ask for a concrete timeout and retry policy, or how you would validate a non-HTTP service such as a gRPC or queue worker.

ONE CONCRETE EXAMPLE: Imagine a GitLab CI pipeline deploying a Node.js API to Kubernetes. After the Helm upgrade stage, a post-deploy job runs a script that loops up to ten times with a five-second sleep. Each iteration calls https://api-staging.example.com/health and expects HTTP 200 with a JSON body containing status: up and a version field matching the CI_COMMIT_SHA. If the call succeeds within the loop, the job passes. If not, the job fails and triggers a helm rollback to the previous revision, then notifies Slack.