USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. How would you design a CI/CD pipeline for a microservices app?
Short answer: Build → test → scan → containerize → deploy per service, with gates and rollbacks.
Strong answer: Each service gets its own pipeline: build, unit/integration tests, security and image scanning, container build, then progressive deploy (canary/blue-green) with automated rollback on failed health checks. Use trunk-based development, artifact versioning, and environment promotion. Keep pipelines fast so they stay trusted.
Likely follow-up: How do you keep 50 service pipelines maintainable?
What the interviewer is checking: End-to-end delivery design, not just "we use Jenkins".
Common mistake: One giant pipeline for all services with no isolation.
Q2. What is Infrastructure as Code and why does it matter?
Short answer: Declaring infra in version-controlled code for repeatable, reviewable provisioning.
Strong answer: IaC (Terraform, etc.) defines infrastructure declaratively so it is versioned, peer-reviewed, and reproducible across environments. It eliminates snowflake servers, enables drift detection, and makes disaster recovery a re-apply. State management and modules keep it maintainable.
Likely follow-up: How do you handle Terraform state safely in a team?
What the interviewer is checking: IaC discipline and collaboration.
Common mistake: Manual console changes that drift from code.
Q3. Explain blue-green vs canary deployments.
Short answer: Blue-green swaps whole environments; canary shifts a small % of traffic first.
Strong answer: Blue-green keeps two identical environments and switches traffic all at once (fast rollback by switching back). Canary routes a small slice of traffic to the new version, watches metrics, then ramps up. Canary limits blast radius; blue-green gives instant full cutover. Choose by risk tolerance and infra cost.
Likely follow-up: How do you decide when a canary is healthy enough to promote?
What the interviewer is checking: Release-safety understanding.
Common mistake: Big-bang deploys with no rollback plan.
Q4. How do you monitor and observe a production system?
Short answer: Metrics, logs, and traces, with SLOs and actionable alerts.
Strong answer: The three pillars — metrics (Prometheus), logs (centralized), traces (OpenTelemetry) — plus dashboards (Grafana) and alerts tied to SLOs, not noise. Alert on symptoms users feel, keep runbooks, and reduce alert fatigue. Good observability turns "it is slow" into a root cause fast.
Likely follow-up: What makes an alert good vs noisy?
What the interviewer is checking: Operational maturity.
Common mistake: Alerting on every metric and drowning on-call.
Q5. How do you handle secrets in a pipeline and at runtime?
Short answer: Never in code; use a secrets manager and inject at deploy/runtime.
Strong answer: Store secrets in a manager (Vault, cloud secret stores), inject via environment or mounted volumes at runtime, rotate regularly, and scope least-privilege access. Keep them out of git, logs, and images. Scan for accidental commits in CI.
Likely follow-up: What do you do if a secret leaks into git history?
What the interviewer is checking: Security hygiene.
Common mistake: Hardcoding secrets in env files committed to the repo.
Q6. What is the difference between horizontal and vertical scaling?
Short answer: Horizontal adds instances; vertical adds resources to one instance.
Strong answer: Vertical scaling gives a node more CPU/RAM — simple but capped and a single point of failure. Horizontal scaling adds more nodes behind a load balancer — resilient and elastic but needs statelessness and coordination. Cloud-native systems favor horizontal with autoscaling.
Likely follow-up: What must be true of an app to scale horizontally?
What the interviewer is checking: Scalability fundamentals.
Common mistake: Assuming you can just add nodes to a stateful app.
Q7. How would you reduce a slow Docker image build and large image size?
Short answer: Layer caching, multi-stage builds, small base images, and .dockerignore.
Strong answer: Order Dockerfile steps so rarely-changing layers cache; use multi-stage builds to ship only artifacts; pick slim/distroless bases; and add .dockerignore to shrink context. This cuts build time and attack surface. Pin versions for reproducibility.
Likely follow-up: Why does step order matter for caching?
What the interviewer is checking: Container efficiency.
Common mistake: Copying the whole context early and busting the cache.
Q8. Describe how you would respond to a production incident.
Short answer: Detect, mitigate, communicate, resolve, then blameless postmortem.
Strong answer: Acknowledge the alert, assess blast radius, mitigate first (rollback, scale, feature flag) before root-causing, communicate status to stakeholders, then fix and verify. Afterward run a blameless postmortem with action items so it does not recur. Calm process beats heroics.
Likely follow-up: Why mitigate before finding the root cause?
What the interviewer is checking: Incident-response discipline.
Common mistake: Debugging root cause while users stay down.