SRE Release Engineering & CI/CD 3 — Questions and Answers
Question 1: What is the purpose of a 'deployment pipeline' in the context of SRE?
- To automatically provision cloud infrastructure
- To automate the path from code commit to production delivery with quality gates (Correct answer)
- To monitor application performance after deployment
- To manage on-call schedules for release teams
Correct answer: To automate the path from code commit to production delivery with quality gates
A deployment pipeline automates build, test, and release steps, enforcing quality gates before production.
Question 2: Which Git workflow practice helps avoid long-lived branches and supports frequent integration?
- Gitflow with release branches
- Trunk-based development (Correct answer)
- Fork-and-merge strategy
- Monorepo with per-team branches
Correct answer: Trunk-based development
Trunk-based development requires developers to commit to the main branch frequently, reducing merge conflicts and integration risk.
Question 3: What is a 'rollback' in release engineering?
- Deploying a hotfix on top of the current version
- Reverting production to a previously known-good version (Correct answer)
- Running a load test before a new release
- Deleting failed deployment artifacts
Correct answer: Reverting production to a previously known-good version
A rollback restores the system to a previous stable version when a new release causes problems.
Question 4: In CI/CD, what is the role of an 'artifact' produced by a build stage?
- A log file capturing build errors
- An immutable, versioned package ready to be deployed to any environment (Correct answer)
- A temporary file deleted after testing
- A configuration file for the CI server
Correct answer: An immutable, versioned package ready to be deployed to any environment
Build artifacts are immutable outputs (binaries, Docker images, jars) that are promoted through environments without rebuilding.
Question 5: Which metric best measures the efficiency of a CI/CD pipeline from an SRE perspective?
- Number of engineers on the team
- Lead time for changes (time from commit to production) (Correct answer)
- Total lines of code deployed per release
- Number of CI servers in the cluster
Correct answer: Lead time for changes (time from commit to production)
Lead time for changes is a DORA metric that captures how quickly code moves from commit to production.
Question 6: What is a 'build matrix' in a CI system?
- A dashboard showing build health across all repositories
- Running the same build steps across multiple combinations of environments or versions (Correct answer)
- A dependency graph of all build jobs
- A permissions model for who can trigger builds
Correct answer: Running the same build steps across multiple combinations of environments or versions
A build matrix runs the same pipeline across multiple combinations (e.g., OS versions, language runtimes) in parallel.
Question 7: Why should secrets like API keys never be stored in a CI/CD pipeline's version-controlled configuration files?
- CI systems cannot read environment variables
- Version control history is typically accessible to many people and external systems, exposing the secrets (Correct answer)
- Secrets are automatically rotated by CI systems
- Pipeline files do not support variable substitution
Correct answer: Version control history is typically accessible to many people and external systems, exposing the secrets
Storing secrets in version control exposes them to anyone with repo access and permanently in git history.
SRE Release Engineering & CI/CD 3
What is the purpose of a 'deployment pipeline' in the context of SRE?