Sample questions
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 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.
Ci Cd PipelinesDifficulty 2
A team uses trunk-based development: everyone commits small changes directly to a short-lived branch merged into main multiple times a day, and the pipeline runs on every merge. A new hire proposes instead keeping long-lived feature branches open for weeks and only running the pipeline right before the final merge. What is the main pipeline-related downside of the new hire's proposal?
- aIntegration problems and test failures pile up and surface late, once they are harder to isolate and fix.✓
- bThe pipeline would need to be rewritten in a different tool, since long-lived branches are unsupported.
- cBuild artifacts could no longer be versioned, because a branch name literally cannot be included in a version tag.
- dTest stages would have to be removed entirely, since they only work correctly on short-lived branches.
Explanation:Branching strategy and pipeline design are linked: the value of continuous integration comes from testing changes frequently, in small batches. Long-lived branches delay that feedback, so incompatibilities and failing tests accumulate and become harder to trace to a single change once finally merged. Option b, c, and d are all false technical constraints — pipelines, versioning, and test stages work fine regardless of branch lifetime; the real cost is delayed feedback, not tooling breakage.
Ci Cd PipelinesDifficulty 2
A pipeline job needs an API key to deploy to a cloud provider. Which approach best follows common practice for handling this kind of secret in a CI/CD pipeline?
- aHardcode the API key directly in the pipeline YAML file so every teammate can see and reuse it.
- bPaste the API key into a comment on the pull request so reviewers can confirm it is correct.
- cPrint the API key to the pipeline logs at the start of the job, so failures are easier to debug.
- dStore the API key in the pipeline's built-in secret store and reference it as a masked environment variable.✓
Explanation:CI/CD tools provide a dedicated secret store precisely so sensitive values are encrypted at rest, injected only at runtime, and masked in logs — avoiding exposure in version control or plain text. Option a puts a credential in version-controlled, widely readable source. Option b exposes it in a PR comment, which is even less controlled than the repo itself. Option c defeats masking by deliberately printing it, risking exposure to anyone with log access.
Ci Cd PipelinesDifficulty 2
A pipeline job config lists its stages as:
pipeline:
stop-on-failure: true
steps:
- lint
- unit-test
- integration-test
- deploy
With
stop-on-failure: true, what happens if the
unit-test step fails?
- aThe pipeline retries
unit-test automatically up to three times before moving on to integration-test. - bThe pipeline ignores the failure and continues running
integration-test and deploy as scheduled. - cThe pipeline stops immediately, skipping
integration-test and deploy, instead of running the remaining steps.✓ - dThe pipeline pauses and waits for a human to manually approve whether
integration-test should run.
Explanation:A stop-on-failure (fail-fast) policy means the pipeline stops as soon as a step fails rather than continuing to run subsequent steps that likely depend on it, saving time and avoiding deploying a broken build. Option a invents automatic retries, which is a separate, unrelated feature some tools offer but is not what this setting does. Option b describes the opposite behavior. Option d invents a manual-approval gate that isn't implied by this setting.
Ci Cd PipelinesDifficulty 2
A junior engineer suggests removing the automated test stage from the pipeline so that deployments to production happen faster after every merge. What is the strongest reason to push back on this suggestion?
- aAutomated tests are only useful during initial development and provide no value once an app reaches production.
- bWithout the test stage, the pipeline can no longer catch regressions before they reach a live environment.✓
- cRemoving a stage from the pipeline configuration file usually causes the pipeline tool itself to stop working entirely.
- dTest stages are required by every CI/CD tool and cannot technically be removed from a pipeline definition.
Explanation:The test stage is the pipeline's automated gate for catching regressions before a bad change reaches users — removing it trades a faster pipeline for a real increase in the risk of shipping broken behavior. Option a is a false generalization; tests remain valuable across a project's lifetime. Option c invents a fabricated tooling failure. Option d is also false — most tools let you freely remove stages, though doing so is a bad practice, not a technical impossibility.