Sample questions
Ci Cd PipelinesDifficulty 1
A team says every push to their repository automatically triggers a build and runs the unit tests. That covers continuous integration. What would this team additionally need to also claim they practice continuous delivery?
- aNothing more — automatically building and testing on every push already is continuous delivery.
- bRewrite the test suite so it executes faster on every single commit pushed by developers.
- cAutomatically produce a validated release artifact that stays ready to deploy at any time.✓
- dHave developers manually merge feature branches into main once a week to keep history clean.
Explanation:Continuous integration means changes are automatically built and tested. Continuous delivery goes further: it keeps a release-ready, validated artifact available at all times, even if a human still decides when to deploy it. Option a confuses CI with CD. Option b is unrelated to delivery readiness. Option d describes infrequent manual merging, which works against the frequent-integration goal CI/CD is built on.
Ci Cd PipelinesDifficulty 1
A typical CI/CD pipeline is organized into ordered stages. Which sequence best reflects the usual purpose of the build, test, and deploy stages?
- aBuild compiles/packages the code, test verifies it behaves correctly, deploy releases it to an environment.✓
- bBuild releases the code to production, test checks user complaints, deploy compiles the source.
- cBuild and deploy are the same step, and test only runs once a month during a planned audit.
- dTest always runs before build, since running old test results first saves compute time overall.
Explanation:The conventional pipeline flow is build (compile/package), then test (verify correctness), then deploy (release to an environment) — each stage acting as a gate for the next. Option b reverses build and deploy's meaning. Option c wrongly merges build and deploy and detaches testing from every change. Option d reverses the natural order since you cannot meaningfully test code that has not been built yet.
Ci Cd PipelinesDifficulty 1
In pipeline terminology, what best describes a build "artifact"?
- aThe log output printed by the test runner after a pipeline stage finishes executing.
- bA configuration file that lists which branches are allowed to trigger a pipeline run.
- cThe commit message a developer writes when pushing changes to the repository.
- dA packaged, versioned output of the build stage, such as a binary, container image, or archive.✓
Explanation:An artifact is the tangible, versioned output produced by the build stage — a compiled binary, a packaged archive, or a container image — that later stages can deploy without rebuilding. Option a describes logs, not a shippable output. Option b describes trigger configuration. Option c describes a commit message, unrelated to build output.
Ci Cd PipelinesDifficulty 2
A pipeline config snippet includes this dependency install step:
- name: Install dependencies
run: npm ci
cache:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
What is the main practical benefit the
cache block is providing here?
- aIt guarantees the pipeline will always deploy the newest dependency versions on every run.
- bIt reuses previously downloaded packages when the lockfile is unchanged, speeding up later runs.✓
- cIt replaces the need to run
npm ci at all once a cache entry exists for the key. - dIt permanently stores the built application artifact so the deploy stage can skip building.
Explanation:Build/dependency caching keyed on the lockfile hash lets the pipeline restore previously downloaded packages instead of re-downloading them every run, cutting install time when dependencies haven't changed. Option a is the opposite of what caching does (caching favors reuse, not always fetching latest). Option c is wrong — npm ci still runs and validates against the lockfile even with a cache hit. Option d confuses dependency cache with a build artifact, which is a separate concept.
Ci Cd PipelinesDifficulty 1
"Pipeline as code" means the CI/CD pipeline definition (stages, triggers, jobs) is written as a versioned file, such as YAML, stored in the repository. What is the main practical reason teams prefer this over configuring the pipeline entirely through a web UI?
- aIt makes the pipeline run noticeably faster because YAML parses quicker than UI-stored settings.
- bIt allows the pipeline definition to be reviewed, versioned, and rolled back like any other code change.✓
- cIt removes the need for the pipeline to ever run automated tests before a deployment happens.
- dIt is required by every CI/CD tool, since none of them still offer a UI-based configuration option.
Explanation:Defining the pipeline as a file in the repository means changes to it go through the same review, diff, and version history as application code, and can be rolled back if a change breaks the pipeline. Option a is a fabricated performance claim, not the real reason. Option c is unrelated and false — pipeline-as-code doesn't remove testing. Option d overstates it; some tools still offer UI configuration, it's just discouraged for traceability reasons.
Ci Cd PipelinesDifficulty 2
A team wants their pipeline to run the full test suite on every pull request, run a lighter smoke test every night on a schedule, and rebuild a base dependency image only when someone pushes directly to the main branch. What pipeline concept lets them route different work to different events like this?
- aEnvironment promotion, which controls which environment receives a deployed artifact after tests pass successfully.
- bBuild caching, which restores previously downloaded dependencies between separate pipeline runs.
- cTriggers, which define which events — such as a pull request, a schedule, or a push — start a given job.✓
- dArtifact retention, which decides how long build outputs are kept in storage before deletion.
Explanation:Triggers are exactly the mechanism for binding pipeline jobs to specific events (PR opened, cron schedule, push to a branch), letting different jobs run for different circumstances. Option a is about where an artifact goes after being validated, not what starts a job. Option b is about speeding up dependency installs, unrelated to event routing. Option d is about artifact lifecycle/cleanup, not what causes a job to run.