DOL CI/CD Pipeline 3 — Questions and Answers
Question 1: A deployment pipeline passes all automated tests but the production release still causes user-facing errors. Which practice would most likely have caught this gap?
- Adding more unit tests to the pipeline
- Implementing synthetic monitoring and real-user monitoring (RUM) post-deployment (Correct answer)
- Running the pipeline twice before deploying
- Requiring a longer manual QA freeze period
Correct answer: Implementing synthetic monitoring and real-user monitoring (RUM) post-deployment
Synthetic monitoring simulates user journeys in production while RUM captures real user experience, surfacing issues automated pre-deployment tests cannot replicate.
Question 2: What distinguishes a 'blue-green deployment' from a 'rolling deployment'?
- Blue-green switches all traffic instantly between two identical environments; rolling updates instances incrementally (Correct answer)
- Blue-green requires twice the infrastructure permanently; rolling uses none
- Blue-green is only suitable for containerized workloads; rolling works on VMs
- Blue-green always requires a database migration step; rolling does not
Correct answer: Blue-green switches all traffic instantly between two identical environments; rolling updates instances incrementally
Blue-green maintains two full environments and flips the load balancer, enabling instant cutover and rollback, while rolling gradually replaces instances.
Question 3: A team uses Docker images as pipeline artifacts. What is the best practice for ensuring image immutability across environments?
- Rebuild the Docker image fresh for each environment (dev, staging, prod)
- Tag images with 'latest' and pull on each deployment
- Build once, tag with the commit SHA, and promote the same image across all environments (Correct answer)
- Store Dockerfiles in each environment's configuration repository separately
Correct answer: Build once, tag with the commit SHA, and promote the same image across all environments
Building once and promoting the same immutable image tagged by commit SHA ensures what was tested is exactly what gets deployed to production.
Question 4: Which CI/CD pattern ensures that a deployment does not proceed if monitoring dashboards show elevated error rates after an initial traffic shift?
- Manual approval gates before every deployment
- Progressive delivery with automated rollback triggers based on observability signals (Correct answer)
- Scheduled maintenance windows for all deployments
- Feature branch deployments that bypass production monitoring
Correct answer: Progressive delivery with automated rollback triggers based on observability signals
Progressive delivery couples traffic shifting with automated health checks so pipelines can self-heal by rolling back when error thresholds are breached.
Question 5: When implementing database migrations in a CI/CD pipeline, what approach prevents downtime during schema changes?
- Drop and recreate the entire schema with each deployment
- Apply forward-only, backward-compatible migrations so old and new code run simultaneously (Correct answer)
- Pause the pipeline until the database team manually applies changes
- Use a separate database per pipeline stage with no shared schema
Correct answer: Apply forward-only, backward-compatible migrations so old and new code run simultaneously
Backward-compatible migrations allow the old application version to keep running while the new version is deployed, enabling zero-downtime releases.
Question 6: A DevOps leader wants to reduce the 'change failure rate' on her team. Which pipeline improvement directly targets this metric?
- Increasing deployment frequency by removing all approval gates
- Strengthening automated test coverage and adding contract testing between services (Correct answer)
- Moving from weekly to daily deployments immediately
- Consolidating all microservices into a monolith to simplify testing
Correct answer: Strengthening automated test coverage and adding contract testing between services
Change failure rate drops when defects are caught earlier; stronger automated and contract testing prevents broken changes from reaching production.
Question 7: In a Kubernetes-based CD pipeline, what is the purpose of a 'readiness probe'?
- To restart crashed containers automatically
- To signal that a pod is ready to receive traffic, preventing premature routing during rolling updates (Correct answer)
- To measure container resource consumption for autoscaling decisions
- To enforce network policies between namespaces
Correct answer: To signal that a pod is ready to receive traffic, preventing premature routing during rolling updates
Readiness probes tell the Kubernetes load balancer not to send traffic to a pod until it has completed initialization, ensuring zero-downtime rolling deployments.
DOL CI/CD Pipeline 3
A deployment pipeline passes all automated tests but the production release still causes user-facing errors.
Which practice would most likely have caught this gap?