DOL CI/CD Pipeline 2 — Questions and Answers
Question 1: A team notices that every merged PR triggers a full regression suite taking 45 minutes. Which strategy best reduces this feedback cycle without sacrificing coverage?
- Run the full suite only on the main branch nightly
- Implement test parallelization and selective test execution based on changed files (Correct answer)
- Skip unit tests and rely solely on integration tests
- Reduce the number of test cases permanently
Correct answer: Implement test parallelization and selective test execution based on changed files
Parallelizing tests and running only tests relevant to changed code dramatically cuts feedback time while maintaining meaningful coverage.
Question 2: In a trunk-based development model, how are long-running features typically managed in the CI/CD pipeline?
- By creating long-lived feature branches merged quarterly
- By using feature flags to hide incomplete functionality in production (Correct answer)
- By freezing the main branch until the feature is complete
- By deploying features directly to production without testing
Correct answer: By using feature flags to hide incomplete functionality in production
Feature flags allow incomplete features to be merged into trunk and deployed without exposing them to users until ready.
Question 3: What is the primary purpose of a 'canary deployment' in a CD pipeline?
- To deploy only to a staging environment for final QA
- To gradually roll out a release to a small subset of users before full deployment (Correct answer)
- To automatically roll back a failed deployment within seconds
- To run smoke tests against the production environment post-deployment
Correct answer: To gradually roll out a release to a small subset of users before full deployment
Canary deployments limit blast radius by exposing a new version to a small traffic percentage first, allowing monitoring before a full rollout.
Question 4: A DevOps leader wants to enforce that no secrets are ever committed to the source repository. Which pipeline control is MOST effective?
- Educating developers in quarterly security training
- Adding a pre-commit hook and a CI stage that scans for secrets using tools like Gitleaks (Correct answer)
- Storing secrets in environment variable files committed alongside code
- Requiring manual code review approval for all changes
Correct answer: Adding a pre-commit hook and a CI stage that scans for secrets using tools like Gitleaks
Automated secret scanning at both the pre-commit and CI stages creates a layered defense that catches secrets before and after push.
Question 5: Which CI/CD metric directly measures the average time from a code commit to a successfully running production deployment?
- Change failure rate
- Mean time to recovery (MTTR)
- Lead time for changes (Correct answer)
- Deployment frequency
Correct answer: Lead time for changes
Lead time for changes measures the elapsed time from code commit through all pipeline stages to production, reflecting overall pipeline efficiency.
Question 6: A CI pipeline fails intermittently on the same test with no consistent reproduction steps. This is best described as:
- A regression caused by a recent commit
- A flaky test that introduces noise into the pipeline (Correct answer)
- A misconfigured build environment
- An infrastructure capacity issue
Correct answer: A flaky test that introduces noise into the pipeline
Flaky tests pass and fail non-deterministically, undermining pipeline reliability and eroding developer trust in the CI system.
Question 7: In a Jenkins pipeline, what is the role of a 'Jenkinsfile' stored in version control?
- It stores build artifacts for later retrieval
- It defines the pipeline as code, enabling versioning and peer review of the CI/CD process itself (Correct answer)
- It configures Jenkins server-level settings and plugins
- It acts as a secrets vault for pipeline credentials
Correct answer: It defines the pipeline as code, enabling versioning and peer review of the CI/CD process itself
A Jenkinsfile treats pipeline configuration as code, enabling the same review, branching, and auditing applied to application source code.
A team notices that every merged PR triggers a full regression suite taking 45 minutes.
Which strategy best reduces this feedback cycle without sacrificing coverage?