Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
CI/CD Pipelines · Question Set
Fundamentals of CI/CD interview questions for placements and exams.
Questions
15
Included in this set
Subject
CI/CD Pipelines
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for CI/CD Pipelines.
Treat pull requests like a secure door. Only green checks and an approval let code in. This prevents broken changes from landing on the main branch.
For complete preparation, combine this set with full subject-wise practice for CI/CD Pipelines. You can also explore other subjects and sets from the links below.
Lead time tells you how quickly code flows from commit to release. It is a key delivery speed signal used widely in DevOps reporting.
The pipeline watches the repo for changes, so version control becomes the single source of truth. It gives history, reviews, and easy rollback, and it triggers automation the moment code changes.
Never hard code secrets in scripts or in the repo. Store them in a secret manager or the CI vault and inject at runtime only. Scope access with least privilege and rotate keys regularly to reduce blast radius.
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}Keep deployments versioned and immutable. If health checks fail or error rate spikes, promote the last good artifact back to production. For blue green or canary, flip traffic to the stable version while you investigate and fix forward in a new release.
In simple words, CI/CD is a delivery conveyor. Code goes in, checks run, and a deployable build comes out. The aim is speed with safety. Automation removes manual errors and gives quick feedback to developers.
CI is about integrating code often and proving it works with fast checks. CD makes sure every successful change can be deployed at any time with a push of a button.
First create the artifact in the build step. Then validate it with tests. If all green, deploy to an environment. This flow reduces risk by catching issues before they reach users.
If lint, unit tests, or security checks fail, the pipeline should halt. Fast failure gives quick signal and avoids wasting compute on later stages.
The moment code is pushed or a pull request opens, the V C S calls the CI server. This gives fast feedback so developers fix issues while the context is fresh.
Start with triggers on push and pull requests. Add a build step to install dependencies and create the artifact. Run unit tests and linters. On main branch, publish the artifact and deploy to a staging env with health checks. Keep jobs short and independent. Cache dependencies and fail fast on basic checks before heavier steps.
name: ci on: [push, pull_request] jobs: build_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci - run: npm run lint - run: npm test -- --ci deploy_staging: needs: build_test if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - run: echo Deploying artifact to staging
Caching prevents repeated downloads or rebuilds for the same inputs. It shortens the feedback loop while keeping checks intact.
cache: paths: - ~/.m2/repository - node_modules
An artifact is the deliverable from the build step, like a jar, a zip, or a container image. Later stages pull the same artifact to ensure consistency across testing and deployment.
Quarantine known flaky tests so they do not gate merges, but still report them loudly. Add limited retries and gather evidence. Fix root causes like timing, shared state, or network calls, then return the test to the blocking lane once stable.
You run blue and green side by side. Deploy to the idle one, test, then flip traffic. Rollback is simple because the old version is still available.