CI/CD automates building, testing and delivering code on every change, which makes releases repeatable and reduces manual steps. Questions cover the difference between CI and CD, fail-fast pipeline design, workflow files on hosted CI platforms, blue-green and canary deployments, secrets handling, build artifacts and versioning, quality gates, and logging and alerting.
All 75 CI/CD quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 19 subtopics, so you can revise one part at a time. Choose Try CI/CD quiz above to take a scored run and review the questions you got wrong.
A.Running the whole test suite nightly on a schedule
B.Deploying to production automatically after every commit
C.Merging into the main branch frequently, with automated checks on each merge
D.Using a CI tool such as GitHub Actions across the project
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.
Under semantic versioning, a bug fix with no API change bumps which number?
A.The patch number, the last one
B.The minor number, the middle one
C.The major number, the first one
D.No number at all; just create a new tag for it
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.
Why build once and use the same artifact across environments?
A.To save storage space in the registry
B.Because CI tools do not allow building twice in one pipeline
C.So the pipeline runs faster by skipping the build step
D.So what was verified in staging is exactly what runs for real
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.
Where should a pipeline fail before spending time on the build?
A.The security scan first because it is the highest priority
B.The build first, to be sure the code compiles
C.Integration tests first because they catch the most bugs
D.Linting and type checking first because they are the fastest
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.
C.pnpm update to always get the newest patched versions
D.Install from the previous build's cache for speed
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.
How long should pipeline artifacts (test reports, build output) be kept?
A.Long enough to investigate, typically days to weeks
B.Keep only the artifacts of successful builds
C.Delete them as soon as the pipeline finishes, to save space
D.Forever, so the full history of every build is available
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.
A.It merges the code without creating any new commit
B.It combines every commit of the branch into one commit on the main branch
C.It compresses the git history so the repository shrinks
D.It deletes the source branch after merging
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.
Should the same pipeline run for both PRs and the main branch?
A.PRs run only the linter while the main branch runs everything
B.One identical pipeline for both
C.Share the checking part, with deployment running only on the main branch
D.Two entirely separate pipelines for the two cases
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).
What fundamentally distinguishes trunk-based development from GitFlow?
A.Each developer works in their own repository
B.Pull requests are not used for code review
C.There are no release branches for older versions
D.Branches live very briefly and merge continuously into main
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.
Why should a pipeline run fast jobs before slow ones?
A.Because the slow jobs need the fast jobs' results
B.To report failures early so nobody waits for nothing
C.So the slow jobs always run on more powerful machines
D.To reduce the CI provider's compute cost
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.
B.Releasing the new version to a small share of users
C.Running two complete environments side by side then switching everything
D.Releasing internally before going outside the company
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.
What does a branch protection rule on the main branch typically require?
A.Blocking all merges outside working hours
B.Requiring every commit message to follow a template
C.Limiting the number of commits per pull request
D.Requiring a pull request, a green CI run and a reviewer
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.
A.Splitting the test suite across machines to run faster
B.Running one job across several configuration combinations
C.Ordering the jobs by priority
D.Combining several small pipelines into one large pipeline
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.
Why cancel an in-progress CI run when a new commit lands on the same pull request?
A.The CI platform does not allow two simultaneous runs
B.The old run's result is worthless and only consumes resources
C.Two parallel runs would cause data conflicts
D.The old result would overwrite the new one in the interface
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.
What problems do nightly builds catch that per-commit builds do not?
A.Merge conflicts between the open branches
B.Syntax errors in the files just edited
C.Violations of the source formatting rules
D.Breakage from external dependencies rather than from the source
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.
Where in the workflow is secret scanning most effective?
A.Only at pre-commit, so the pipeline is not slowed
B.At pre-commit and in CI, as two complementary layers
C.Only in CI, since pre-commit is easy to skip
D.At the deploy step, right before production
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.
What does the conventional commits convention give a pipeline?
A.Preventing commits directly to the main branch
B.Squashing small commits automatically on merge
C.Deriving the version number and generating the changelog automatically
D.Requiring every commit to come with at least one test
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.
How should cache headers be set when deploying a static frontend?
A.Cache hashed files long; HTML no-cache or very short
B.Cache everything forever and purge manually on each release
C.Cache nothing so the latest version is always served
D.Cache every file for one hour as a compromise
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.
What does enforcing a frontend bundle size budget in CI achieve?
A.It guarantees the application runs on low-end devices
B.It automatically removes unused code from the bundle
C.It compresses the files better to reduce transfer size
D.It stops the size creeping up unnoticed
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.
Tests pass locally but fail in CI. What is the first thing to check?
A.Increase the timeout on the failing tests
B.Environment differences: versions, variables, execution order
C.Skip those tests and open a task to fix them
D.Rerun the pipeline a few times to see whether it goes green
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.
A pipeline needs an API key to deploy. How should it be stored?
A.Encrypted and committed to the repo, decrypted at pipeline run time
B.In the CI's secret store, read through an environment variable
C.In the pipeline configuration file, since the repo is private
D.Passed in by hand on every deployment run
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.
A Dockerfile copies all source before npm install. Problem?
A.Dependencies may be installed at the wrong versions
B.The image is larger than necessary because it contains the source
C.Changing one line of code reinstalls every dependency
D.The build fails because the lockfile is missing
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.
Deploying with the latest image tag. What is the risk?
A.You cannot tell exactly which build is running, so rollbacks are hard
B.A latest image is always re-pulled so deployment is slower
C.latest cannot be used in a multi-node environment
D.The registry deletes the latest tag after a while
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.
The pipeline reinstalls dependencies from scratch every run. How do you improve it?
A.Cache the store directory keyed by the lockfile's hash
B.Skip the install step when the previous build succeeded
C.Commit node_modules to the repository to skip installing
D.Preinstall the dependencies into the runner's image and reuse it
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.
A serious bug appears right after deploying, and there is no feature flag or configuration to switch off just the faulty feature. Fastest response?
A.Fix the bug and deploy a new build immediately
B.Turn the broken feature off through configuration
C.Roll back to the previous build and fix the bug once things are stable
D.Wait and see whether the bug affects many users
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.
Which jobs should block a merge, and which run after merging?
A.The reviewer decides per pull request
B.Only the linter should block, with the tests running afterwards
C.Every job should block merging to guarantee quality
D.Fast and deterministic jobs block the merge; slow or flaky ones run afterwards
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.
What is the benefit of a preview deployment per pull request?
A.It replaces the need to write automated tests for that change
B.It guarantees the code behaves exactly as in production
C.Reviewers can see the change actually running rather than only reading code
D.It makes the pipeline faster because one build serves several places
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.
CI often fails on one flaky e2e test. What retry policy is right?
A.Delete the test because it is no longer trustworthy
B.No retries; leave CI red until someone fixes the test
C.A bounded retry, but record how often it was flaky
D.Retry indefinitely until the test passes
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.
What is the risk of self-hosted CI runners versus provider-hosted ones?
A.Self-hosted runners cannot run jobs in parallel
B.The machine is not clean between runs so one job affects another
C.Repository secrets cannot be used on a private runner
D.Community actions cannot be used on a private runner
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.
A.They shrink the bundle because disabled code is not downloaded
B.They allow skipping the tests before deploying
C.They remove the need for a staging environment
D.They separate deploying the code from switching the feature on
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.
What is the risk of running CI on pull requests from forks?
A.The pipeline runs more slowly because an extra repo must be cloned
B.Someone else's code runs in the runner and could take the secrets
C.Test results from a fork are untrustworthy so they must be rerun
D.A fork could write directly to the source repository's main branch
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.
A 1.2GB production image includes build tooling. How do you shrink it?
A.Compress the image before pushing it to the registry
B.Just switch to a smaller base image such as Alpine
C.A multi-stage build: copy only the output into a slim base image
D.Delete the cache and temporary files on the Dockerfile's last line
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.
What conditions make auto-deploy on merge to main safe?
A.Every pull request being reviewed by at least two people
B.Having a staging environment identical to production
C.Deploying during off-peak hours to reduce the impact
D.Trustworthy tests, fast rollback, and monitoring that catches problems early
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.
A.Do not let coverage fall below the main branch's level
B.An 80% threshold because it is the industry standard
C.No gate at all, since coverage does not measure quality
D.Require 100% coverage for every change
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.
Which security scan belongs in the pipeline first?
A.Container image scanning after deploying to production
B.Dynamic application scanning by simulating attacks
C.Dependency scanning and secret scanning, since they are fast with few false positives
D.Comprehensive static analysis for every class of vulnerability
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.
Docker builds on CI always take 8 minutes with no cache. Fix?
A.Reduce the number of instructions in the Dockerfile for fewer layers
B.Build the image locally and push it to the registry
C.Enable the registry cache or the CI platform's cache
D.Switch to a self-hosted runner to keep a local cache
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.
Where should configuration differing between staging and production live?
A.Baked in at build time, with a separate artifact per environment
B.Per-environment environment variables read at runtime
C.In each environment's database
D.Several configuration files in the repo, chosen by environment name
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.
A.Recording who wrote each line of code in the project
B.Dividing repository access by team
C.Restricting who may edit certain files
D.Automatically assigning reviewers by the path of the changed files
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.
Generating a changelog automatically from commits requires what?
A.Tagging every commit on the main branch
B.Writing the changelog by hand with the tool only formatting it
C.Commit messages following a convention with a type prefix
D.Every pull request having exactly one commit
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.
After deploying, how do you know the new version is healthy before it takes traffic?
A.Wait a fixed period after startup
B.A readiness probe checking the dependencies, taking traffic once it passes
C.Read the startup logs and enable traffic by hand
D.Send one test request to the new instance
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.
The pipeline is red and nobody notices. What should you do?
A.Put up a dashboard for whoever wants to check it
B.Send a targeted notification to the people involved rather than to everyone
C.Notify the entire team every time the pipeline goes red
D.Ask everyone to check CI at the start of the working day
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.
Integration tests need Postgres. Tidiest way to run them in CI?
A.Run Postgres as a service container within the job
B.Point at one shared Postgres used by every CI run in the team
C.Mock the DB layer so no database is needed
D.Replace Postgres with SQLite for speed and simplicity
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.
Where should lint and formatting run so they do not derail reviews?
A.Automatically in the editor and at pre-commit, with CI re-checking
B.Let the reviewer point out convention violations
C.Run it once a week and commit all the changes at once
D.Only in CI so committing stays fast
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.
Which metrics tell whether a team delivery process is healthy?
A.How many pull requests are merged per sprint
B.How the project's coverage percentage changes over time
C.4 DORA metrics: deployment frequency, lead time, fail rate, MTTR
D.How many lines of code each member writes per week
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.
Deploying several times a day without affecting users — minimum requirements?
A.Several instances running in parallel across regions
B.Deploying at night when few users are active
C.A rolling deploy, graceful shutdown, and additive migrations
D.A load balancer distributing traffic across the instances
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).
A CI workflow uses community actions. How should they be pinned?
A.By a major version tag such as @v4 for easy updates
B.By full commit SHA, because a tag can be repointed
C.By the main branch to always have the newest version
D.No pinning is needed because actions run in an isolated environment
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.
Staging and production share one database. Problem?
A.A test on staging may modify or delete data
B.Staging will be slower because it shares resources with production
C.Different migrations cannot be run in the two environments
D.The two environments' logs cannot be told apart
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.
A team deploys monthly and every release is stressful. What changes first?
A.Let only the most experienced person do the deploy
B.Extend the testing period before each deploy
C.Deploy smaller and more often to reduce the risk of each release
D.Add another testing environment before production
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.
What problem does a merge queue solve that ordinary branch protection cannot?
A.Pull requests are too large to review carefully
B.CI is too slow so developers wait a long time
C.Two changes that are green individually but break when combined
D.Reviewers do not respond in time
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.
How does GitOps differ from pipeline-push deployment?
A.The deployment configuration is stored in a dedicated database
B.An in-cluster agent pulls and reconciles against Git
C.The pipeline runs the deploy command with cluster admin rights
D.Each deployment creates a completely new cluster
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.
A test suite takes 40 minutes in CI. What shortens it most effectively?
A.Split the suite across several machines in parallel
B.Reduce the number of tests to lighten the suite
C.Move all the tests to run after the merge
D.Raise each test's timeout to avoid random failures
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.
How should automated dependency updates be configured to avoid noise?
A.Turn off automatic updates and review once a quarter
B.Only update when a security vulnerability is announced
C.Group the small patches and separate the major upgrades
D.Auto-merge every update pull request when CI is green
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.
On finding a bug after deployment, roll back or fix forward?
A.Roll back first to stop the damage
B.Wait until the next scheduled deployment
C.It depends on the severity; there is no general principle
D.Always fix and deploy forward so the new features are not lost
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.
B.A token with no expiry so the pipeline is never interrupted
C.Store the token in a repository-level environment variable
D.One administrative token shared across the whole pipeline
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.
How should a monorepo handle versioning and releases?
A.Do not version at all; always use the latest from main
B.Always release every package at the same version
C.Always give each package a fully independent version
D.It depends on how the packages relate: independent or synchronized
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.
How should a pipeline promote the same artifact through environments?
A.Build in production and copy backwards to staging
B.Give each environment its own branch and build from it
C.Rebuild from source in each environment to guarantee freshness
D.Build once and promote that artifact through the environments
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.
Adding static analysis to a legacy codebase with thousands of warnings — what is the sensible approach?
A.Only run the tool on a schedule and send the team a report
B.Disable the rules that produce the most warnings
C.Set a baseline and only block new warnings
D.Block merges until every warning is fixed
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.
Many repositories share a nearly identical CI process. How should it be organized?
A.Extract a reusable workflow and parameterize the differences
B.Write one shared script that each repository calls
C.Copy the workflow file into each repository and edit as needed
D.Merge every repository into a monorepo to share one pipeline
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.
You need an image running on both x86 and ARM. How is it built?
A.Choosing a base image compatible with both architectures is enough
B.Build for x86 and rely on an emulation layer on ARM machines
C.Build two separate images with two different tags
D.Build a multi-architecture image under one tag
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.
What does a remote build cache add over a local one?
A.It lets builds run in parallel across several machines
B.It guarantees every build is reproducible
C.Build results can be reused by the whole team and by CI
D.It reduces the disk space needed on developer machines
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.
A.Quarantine it from the merge gate, record it and assign the fix
B.Delete the test because it is unreliable
C.Configure automatic reruns until it goes green
D.Ignore it, since every large suite has flaky tests
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.
What operational concern matters most for per-pull-request ephemeral environments?
A.Automatic teardown when the pull request closes, so they do not pile up
B.It must share the staging database
C.The configuration must match production exactly
D.Create them only for approved pull requests
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.
How should a pipeline for infrastructure as code be structured?
A.Show a preview on the pull request and apply on merge
B.Run it manually from the infrastructure owner's machine
C.Apply on every commit so the infrastructure is always current
D.Run it only on a weekly schedule to reduce risk
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.
Which two parameters matter most in a Kubernetes rolling update?
A.The retry count and the wait between retries
B.The CPU and memory requested per pod
C.How many extra pods may be created and how many may be missing
D.The minimum and maximum replicas when autoscaling
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.
CI runner costs are rising fast. What reduces them most effectively?
A.Move to self-managed runners for a lower rate
B.Run only the affected parts and cache the dependencies
C.Reduce the number of runs by only running CI when needed
D.Use lower-specification machines for every job
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.
What is required to run only the tests affected by a change?
A.Every test must live in the same directory
B.Every test must be a pure unit test
C.Knowing the relationship between source files and test files
D.The suite must run in under five minutes
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.
How can breaking API changes be caught in the pull request itself?
A.Wait for the consumers to report errors after the release
B.Compare the new API specification against the one on main
C.Ask reviewers to read the API changes carefully
D.Bump the major version on every API change
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.
How should a dependency vulnerability gate be configured without blocking work?
A.Only warn and never block a merge
B.Block every vulnerability at any severity
C.Block by severity, with time-bounded exceptions
D.Only scan before each major release
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.
Application base images need regular updates. How is this automated?
A.Rebuild on a schedule and run the tests before releasing
B.Update manually when a vulnerability is announced
C.Install the updates when the container starts
D.Use the latest tag for the base image so it is always current
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.
What must be handled when doing visual regression testing with screenshots?
A.Only capture screenshots at one single resolution
B.The rendering environment must be consistent to avoid false alarms
C.The comparison must match every pixel exactly
D.The reference images must be updated after every run
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.
What is the downside of deployment freezes during peak periods?
A.Changes pile up so the unfreeze deployment is high risk
B.The merged changes are lost when the freeze lifts
C.The team cannot fix urgent bugs during that period
D.Monitoring stops working during the freeze
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.
What mechanism should switch traffic in a blue/green deployment?
A.Change the configuration in the client application and re-release it
B.Shut down the old environment so traffic moves to the new one
C.Change the DNS record to point at the new environment
D.Change the target at the load balancer, effective immediately
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.
After a frontend release, what must be done with the CDN cache?
A.Invalidate only the HTML, not the hashed assets
B.Change the distribution domain for every release
C.Invalidate the whole cache to make sure everything is fresh
D.Do nothing, since the CDN detects new files itself
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.
What release strategy reduces risk for a mobile app distributed through app stores?
A.Ask users to update manually instead of automatically
B.Only release at the weekend when fewer people update
C.Release to everyone and pull the bad build from the store if needed
D.A staged rollout with a gradually increasing share
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.
A bad configuration broke production after deploy. What pipeline safeguard prevents this?
A.Back up the old configuration before each deployment
B.Validate the configuration against a schema before deploying
C.Deploy the configuration separately from the code
D.Only let experienced people edit configuration files
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.
