Describe the stages of a CI/CD pipeline for a containerized app

What's really being asked

This question assesses your hands-on experience with modern DevOps practices. The interviewer is looking beyond textbook definitions to see if you understand the flow of code from a developer's machine to a live customer, specifically for containerized services. They are testing your understanding of automation, quality control (gates), and risk mitigation in a production environment.

The full answer

A senior-level answer walks through four distinct phases. First, the Continuous Integration (CI) phase, triggered by a pull request, which runs static analysis (SAST, linting) and unit tests. Second, the Build phase, where a Docker image is created, tagged with a commit hash, scanned for vulnerabilities (e.g., using Trivy or Snyk), and pushed to a container registry like ECR or GCR. Third, the Staging/Testing phase, where the new image is deployed to a production-like environment to run integration tests, API contract tests, and load tests. This is a critical quality gate. Fourth, the Production Deployment phase, which uses a safe strategy like blue-green or canary deployment. This phase must include post-deployment monitoring and automated rollback procedures.

The mistakes people make

A common red flag is describing a generic pipeline that omits container-specific steps like building the image, scanning it for vulnerabilities, or pushing it to a registry. Another mistake is being vague about quality gates, simply saying "we run tests" instead of specifying what tests run at which stage (e.g., unit tests pre-build, integration tests post-deployment to staging). Confusing Continuous Delivery (requires manual approval for production) with Continuous Deployment (fully automated to production) is also a frequent error. An answer that ends at deployment without mentioning monitoring and rollback is incomplete.

What usually comes next

"How would you implement a zero-downtime deployment for this service?" (Tests knowledge of blue-green, canary). "What specific metrics would you monitor after deployment to decide if a rollback is necessary?" (Tests production monitoring sense: error rates, latency, CPU/memory). "How would you handle database schema migrations within this pipeline?" (Tests understanding of stateful vs. stateless components).

A concrete example

For our payments service, a PR kicks off a GitHub Action. It first runs a SonarQube scan and requires unit test coverage to remain above 90%. On merge to main, it builds a Docker image, scans it with Trivy for critical vulnerabilities, and pushes it to ECR. That image is then automatically deployed to our staging Kubernetes cluster. We run a full Postman test suite against it. If all tests pass and p99 latency is under 150ms, a manual approval is required in Slack via a ChatOps bot to trigger the production canary deployment, which gradually shifts 10% of traffic over 30 minutes before a full rollout.