CI/CD quiz — 75 questions with answers and explanations

Answer: C

Merging code into the main branch frequently (at least daily), with every merge running an automated build and test. The essence is short-lived branches and fast feedback, not installing a tool.

Answer: A

PATCH (the last number): 1.4.2 → 1.4.3. Rule: MAJOR when you break compatibility, MINOR when you add backwards-compatible features, PATCH when you fix a bug without changing public behavior.

Answer: D

So that what was verified is what actually runs. Rebuilding per environment can produce different results (changed dependencies, drifted build config), which makes staging verification worthless.

Answer: D

Fail fast: order jobs fastest first — lint and type checking (seconds) → unit tests (minutes) → build → integration → e2e. The cheapest failures get caught first.

Answer: B

pnpm install --frozen-lockfile (or npm ci): installs exactly what the lockfile says, and fails if the lockfile doesn't match package.json instead of silently updating it.

Answer: A

A few days to a few weeks is enough for test reports and logs — they only matter while you are investigating. Released artifacts (images, packages) should be kept longer since they are needed for rollback and traceability.

Answer: B

Combines all commits on the branch into a single commit on the main branch. History stays clean and each commit is a complete change — the tradeoff is losing the small intermediate commits from the work process.

Answer: C

Use the same checks (lint, test, build) so results on the PR match results on the main branch, and gate the deploy part — run it only when the branch is main (or on a release tag).

Answer: D

Trunk-based keeps very short-lived branches (hours to a day) and merges into the main branch continuously, using feature flags to hide unfinished work. GitFlow maintains multiple long-lived parallel branches, so integration is pushed to the end and conflicts are larger.

Answer: B

Fail fast principle: put lint, type checks, and unit tests first so obvious errors are reported within a minute or two. A short feedback loop is the single most important factor in whether developers actually use CI.

Answer: B

A canary sends the new version to a small percentage of real traffic (say 5%), monitors error rate and latency, then ramps up if metrics look good or rolls back if they don't. The blast radius of a failure is therefore much smaller than a full cutover.

Answer: D

Common requirements: pull requests are mandatory (no direct pushes), required CI jobs must be green, at least one approval, and usually force-push and branch-deletion blocks as well.

Answer: B

A matrix generates one job per declared configuration combination — for example, three Node versions times two operating systems gives six jobs running in parallel. It is used to verify that an application or library works on every supported version.

Answer: B

Results from the old commit are no longer valuable once a new commit exists, so letting it continue only occupies runners and lengthens the queue for the whole team. Configuring concurrency groups per branch and enabling cancellation of in-progress runs is the standard approach.

Answer: D

Scheduled builds catch breakages not caused by source code: updated transitive dependencies, new base image versions, expired certificates, external services changing behavior. The same commit being green yesterday and red today is exactly this signal.

Answer: B

Place it in both: a pre-commit hook blocks secrets on the developer's machine before they enter Git history; a CI job catches cases where the hook is bypassed. Also enable scanning on the code hosting platform side if available.

Answer: C

Standardized prefixes (feat, fix, chore, with breaking change markers) let tools automatically determine version numbers per semantic versioning and generate grouped changelogs. This removes manual steps from releases.

Answer: A

Files with a content hash in the name are cached for a long time and marked immutable. The entry HTML file is not cached or cached very briefly, because it references the new set of files. This way a new release takes effect immediately without needing to purge the cache.

Answer: D

It blocks gradual degradation: each pull request adds a little and nobody objects, but after a few months load time increases significantly. The gate makes the added size visible right at the pull request that caused it.

Answer: B

Check environment differences first: runtime and dependency versions, environment variables, timezone and locale, test execution order, and leftover state on the local machine. CI starts clean, so it exposes hidden dependencies that the local machine hides.

Answer: B

Use the CI's secret store (GitHub Actions secrets, the deploy platform's environment variables), referenced via an environment variable in the job. Never commit a secret, even to a private repo.

Answer: C

Layer cache is lost: Docker recomputes from the first changed layer onward, so a one-line code change makes npm install run again from scratch. Correct order: copy package.json + lockfile → install → then copy the rest of the source.

Answer: A

latest is a moving name: it points wherever the last push went. When something breaks you don't know exactly which code is running and can't roll back to the correct previous version. Tag by commit SHA or version number.

Answer: A

Cache by lockfile hash: key the cache as deps-${hash(pnpm-lock.yaml)}. If the lockfile is unchanged, cache restores in seconds; if it changes, it's a cache miss and a full install — exactly when needed.

Answer: C

Roll back to the previous version, then investigate. To make that fast you need: immutable image tags, migrations that are backwards compatible, and a rollback command that has been rehearsed.

Answer: D

Block the merge: lint, type check, unit + integration tests — fast and deterministic. Run after merge or on a schedule: full e2e, performance tests, deep security scans, and builds for multiple platforms.

Answer: C

Reviewers see the thing actually running instead of imagining it from a diff — most important for UI changes, and it lets non-engineers (design, product) give feedback directly on the running version.

Answer: C

Retry a limited number of times (1–2) but record which tests need retries and how many. Without that data flakiness silently accumulates, and eventually everyone assumes a red CI is flaky — even when it's a real bug.

Answer: B

Machines not cleaned between runs: cache, temp files, environment variables, and credentials left over from a previous job. One job can read another job's data, and a build "works" only because that machine happened to have something preinstalled.

Answer: D

They separate deploy (shipping the code) from release (enabling it for users). That way you merge code early without exposing the feature, roll it out gradually to a subset of users, and turn it off instantly on problems without a rollback.

Answer: B

Code written by outsiders runs on your runner: if secrets are present they can print them, and they can abuse CI resources. That's why CI platforms don't give secrets to workflows from forks by default.

Answer: C

Multi-stage build: the first stage installs dependencies and builds, the final stage FROM a slim base and only COPY --from the artifacts needed to run. Build tooling doesn't make it into the final image.

Answer: D

Three conditions: tests trustworthy enough that merging means it's deployable, fast rollback that's been rehearsed, and monitoring that alerts as soon as errors rise. Miss any one and auto-deploy just ships bugs to production faster.

Answer: A

The most practical is no regression: the PR's coverage must not be lower than the main branch. It blocks adding untested code without pressuring people to write token tests to hit an absolute number.

Answer: C

Two things that are fast and clear-cut: dependency scanning (known vulnerabilities in libraries) and secret scanning (committed keys). Both run in seconds, have few false positives, and catch the kinds of incidents that actually happen.

Answer: C

CI runners are fresh machines each time, so there's no local cache. Configure an off-machine cache: point --cache-from/--cache-to at a registry, or use the CI platform's cache with buildx.

Answer: B

Environment variables read at runtime, declared on the deployment platform per environment. That way a single artifact runs anywhere, and secrets never live in the repo.

Answer: D

Automatically assigning reviewers by file path in a pull request and, with branch protection, requiring approval from the owner of that area. Useful in a large repo where nobody knows every part.

Answer: C

A commit message convention (Conventional Commits): feat:, fix:, refactor:, plus ! or BREAKING CHANGE for breaking changes. A tool groups the entries and infers the version bump.

Answer: B

A readiness probe: an endpoint checking essential dependencies (DB connection, config loaded) that returns OK only once ready. The load balancer sends traffic only to instances that pass the probe.

Answer: B

Send targeted notifications: the PR author is notified when their own PR is red, and a red main branch alerts a channel with an owner. Paging everyone for every red build is the fastest way to get nobody to read it.

Answer: A

Declare a Postgres service container in the job (same version as production), wait for it to be ready, then run migrations and tests. Every run gets a clean DB isolated from other jobs.

Answer: A

Format automatically in the editor (format on save) and in a pre-commit hook, and let CI only re-check to catch cases where the hook was skipped. When a tool decides the formatting, reviews are left to discuss logic only.

Answer: C

The four DORA metrics: deployment frequency, time from commit to production, change failure rate, and time to restore. The first two measure speed, the last two measure stability — look at them together.

Answer: C

Three things go together: rolling deploy (replace instances gradually, always keeping one serving), graceful shutdown (finish in-flight requests before exiting), and additive migrations (old and new versions both work against the same schema).

Answer: B

Pin them to the full commit SHA (uses: actions/checkout@<sha>). Tags are movable pointers: if the author's account is compromised, an attacker can point @v4 at injected code and your pipeline runs it with your secrets.

Answer: A

The most serious risk is losing or leaking real data: a trial migration, a test that deletes data, or a staging mail job touching real user data. Each environment must have its own database.

Answer: C

Deploy smaller and more often. It sounds counterintuitive but it's right: a one-month batch has hundreds of changes so when something breaks you don't know which one caused it; with a one-day batch the cause is almost obvious.

Answer: C

The semantic conflict problem: pull requests A and B both pass on the old main, but main breaks once both land — for example A renames a function while B adds a call to the old name. A merge queue runs CI on the actual combined result before merging.

Answer: B

GitOps flips the direction: instead of the pipeline pushing changes into the cluster, an agent running in the cluster pulls the desired state from Git and continuously reconciles. Git is the source of truth, and any drift from it is detected.

Answer: A

Sharding tests across multiple machines in parallel gives the biggest win without changing the tests themselves. Alongside that: cache dependencies, run only what the change affects, and move slow e2e tests to a post-merge tier.

Answer: C

Configure by risk level: group patches and minor upgrades into one weekly pull request, separate major upgrades, and prioritize immediate handling of security patches. Auto-merge should apply only to the lowest-risk group, and only once the test suite is trustworthy enough.

Answer: A

The default is to roll back first to return the system to a known-good state, then investigate and fix. Choose fix-forward only when rolling back isn't feasible — for example, an irreversible schema change has already shipped.

Answer: A

Grant least privilege per job: the build job only reads code, only the publish job can write to the registry, only the deploy job can touch the target environment. Prefer session-bound identities over static tokens stored in a secrets vault.

Answer: D

Two models depending on context: synchronized (every package shares one version number) works when they're always used together; independent works when packages have their own consumers and lifecycles. What's mandatory in both is releasing only the packages that actually changed.

Answer: D

The build once, release many times principle: create the artifact once from a commit, attach a fixed identity (digest or commit hash), then promote that same artifact through staging and production. Different configuration is loaded at runtime, not baked into the artifact.

Answer: C

Set a baseline by recording existing warnings, then block merges only on new warnings. Old debt is cleaned up gradually on a touch-it-fix-it basis, rather than halting development to clean everything at once.

Answer: A

Extract the common part into a reusable workflow with parameters for the differences (runtime version, test command, deployment environment). Each repository then only needs a few lines calling the shared workflow, and updates happen in one place.

Answer: D

Build a multi-architecture image: build for each platform then push a shared manifest under one tag. The server pulling the image automatically gets the version matching its architecture, so deployment configuration doesn't need to know what machine type it runs on.

Answer: C

A remote cache allows reusing build results across machines: something already built on a colleague's machine or in a previous CI run doesn't need to be rebuilt. The condition is that cache keys must be computed deterministically from input content.

Answer: A

Standard process: detect and record flaky tests; quarantine them from the merge gate but still run and monitor them; assign an owner and a deadline to fix them; and remove from quarantine once stable. Automatic retries are a temporary measure, not a solution.

Answer: A

The most important concern is automatic cleanup: delete the environment when the pull request is closed or merged, along with a process that scans for expired environments. Without this step, costs and resource quotas will gradually drain without anyone noticing.

Answer: A

Standard structure: the pull request runs a change preview and posts the result as a comment for review; after merge, an apply job runs automatically. Include a lock so two applies don't run concurrently.

Answer: C

maxSurge (pods created above the desired count) determines speed, and maxUnavailable (pods allowed to be missing) determines the minimum capacity still serving. Setting maxUnavailable to 0 keeps full capacity but requires spare room in the cluster to create new pods.

Answer: B

Most effective is cutting unnecessary work: only build and test the parts affected by the change, cache dependencies and build results, and cancel old runs when a new commit arrives. After that comes choosing the right machine type for each job.

Answer: C

You need a dependency map between source code and tests. In a monorepo, the graph between packages allows coarse inference. More precisely, use coverage data from previous runs to know which tests touch which files.

Answer: B

Generate the API spec on every build and compare it against the main branch version using a dedicated tool. The tool distinguishes compatible changes (adding an optional field) from breaking changes (removing a field, changing a type, adding a required field), and blocks merge on the latter.

Answer: C

Block at high severity and above for production dependencies, warn at lower levels, and have a mechanism to record exceptions with an expiry and an owner. Dependencies used only for development should have a separate policy.

Answer: A

Pin base images by digest so builds are reproducible, then have a scheduled pipeline update the digest, rebuild, run the test suite, and open a pull request. This gets patches into the system regularly while still passing tests.

Answer: B

The biggest problem is false positives from the render environment: different fonts, browser versions, and resolutions all produce pixel differences. Handling: run in a fixed container, set a diff threshold, and have a process to approve new baselines.

Answer: A

The downside is change pile-up: after a freeze, the first deployment carries dozens of changes at once, so if it breaks it is very hard to identify the cause and hard to roll back. A freeze moves risk into the future rather than eliminating it.

Answer: D

Switch at the load balancer layer (change the target group or weight): it takes effect almost instantly and rollback is also instant. Changing DNS depends on propagation time and client caching, so it is not used when fast reversal is needed.

Answer: A

Only invalidate the entry files (HTML and config files without a hash). Hashed resources have a different path in the new version, so they do not touch the old cache, and invalidating everything only costs money and pushes load back to the origin server.

Answer: D

Use staged rollout: the store lets you open gradually from a few percent of users, monitor crash rates and reviews, then increase or halt. This is the main safeguard because a build already installed on user devices cannot be recalled.

Answer: B

Validate config against a schema in the pipeline, and have the app re-validate at startup and exit immediately if it's wrong. A config error caught at startup is far better than one caught when a specific feature is first invoked.