I85PREP
⌘ K
Continuous Delivery Architecture study materials
Continuous Delivery Architecture study resources

Continuous Delivery Architecture practice questions

One question at a time. Build your Continuous Delivery Architecture understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Continuous Delivery Foundations and Value Streams

Which metric best indicates that a delivery pipeline is helping rather than hindering flow through the value stream?

  1. Total lines of code reviewed per week
  2. Number of branches merged per sprint
  3. Lead time for changes from commit to production Correct answer.
  4. Count of deployment scripts maintained by the team

Explanation

Lead time for changes measures how long work takes to travel from commit to running in production, which is the core flow metric of the value stream. Branch merges, code volume, and script counts are activity measures that do not reveal how quickly value reaches users.

Question 2Continuous Delivery Foundations and Value Streams

In value stream mapping for software delivery, which activity is typically classified as value-adding time?

  1. Automated tests running in the pipeline Correct answer.
  2. A change sitting in a staging environment awaiting approval
  3. A ticket blocked on a dependency team
  4. Work waiting in a review queue

Explanation

Value-adding time is spent transforming work into something the customer ultimately values, and automated verification that moves a change toward release qualifies. Waiting states such as queues, approval holds, and blocked tickets are pure waste in the value stream.

Question 3Continuous Delivery Foundations and Value Streams

A team deploys to production once per quarter and batches many features into each release. Which outcome should the architect most expect from this approach?

  1. Shorter lead time because of fewer deployments
  2. Lower deployment risk because each release is thoroughly rehearsed
  3. Improved mean time to restore because releases are rare
  4. Higher change failure rate due to large, untested batches Correct answer.

Explanation

Large batch releases concentrate risk: many changes interact, and defects are harder to isolate, which raises the change failure rate. Rare deployments also make each one unusual, so recovery tends to be slower rather than faster.

Question 4Continuous Delivery Foundations and Value Streams

What distinguishes continuous delivery from continuous deployment?

  1. Continuous delivery requires manual testing; continuous deployment requires automated testing
  2. Continuous delivery applies only to libraries; continuous deployment applies only to services
  3. Continuous delivery keeps every change releasable; continuous deployment automatically releases every change Correct answer.
  4. Continuous delivery uses feature flags; continuous deployment forbids them

Explanation

Continuous delivery guarantees that the mainline is always in a deployable state, with the release decision left to a human or business trigger. Continuous deployment goes further and pushes every change that passes the pipeline into production automatically.

Question 5Continuous Delivery Foundations and Value Streams

Which is the strongest signal that a team has adopted a trunk-based development model?

  1. A release branch cut for every sprint
  2. Short-lived branches merged to main at least daily Correct answer.
  3. Separate branches per environment
  4. Long-running feature branches merged at release time

Explanation

Trunk-based development means developers integrate small changes into a shared mainline frequently, typically at least daily, using short-lived branches. Long-lived feature branches, per-sprint release branches, and environment branches all indicate the opposite pattern.

Question 6Continuous Delivery Foundations and Value Streams

An organization wants to measure whether its delivery process is improving. Which pairing of metrics gives the most balanced view?

  1. Story points completed with team velocity
  2. Test count with code coverage percentage
  3. Number of environments with number of approvals
  4. Deployment frequency with change failure rate Correct answer.

Explanation

Deployment frequency captures throughput while change failure rate captures stability, so the pair balances speed against quality. Velocity, test counts, coverage, and environment counts are local or output measures that can improve while delivery performance stagnates.

Question 7Continuous Delivery Foundations and Value Streams

Which practice most directly reduces the batch size of changes flowing through a delivery pipeline?

  1. Scheduling releases on a fixed monthly calendar
  2. Adding a final manual sign-off before production
  3. Increasing the length of the regression test cycle
  4. Splitting a large feature into independently deployable increments Correct answer.

Explanation

Batch size shrinks when work is decomposed into increments that can each be deployed on their own. Manual sign-off, longer test cycles, and fixed release calendars all encourage accumulation rather than reducing batch size.

Question 8Continuous Delivery Foundations and Value Streams

A regulated bank must retain a human approval before production releases but wants continuous delivery. How should the architect reconcile these requirements?

  1. Move approval into the change advisory board's monthly meeting
  2. Keep the mainline releasable and automate all verification, placing the approval as an explicit release decision Correct answer.
  3. Deploy only at quarter end so auditors can review a single release
  4. Require manual approval at every stage gate in the pipeline

Explanation

Continuous delivery separates the technical ability to release from the business decision to release, so an approval can sit at the release trigger without breaking the always-releasable property. Adding gates throughout the pipeline, batching quarterly, or routing to a monthly board reintroduces waiting and large batches.

Question 9Continuous Delivery Foundations and Value Streams

A value stream map shows 30 minutes of automated build and test time against 4 days of queue time before code review. What is the most accurate interpretation?

  1. The pipeline is the bottleneck and should be optimized first
  2. Flow efficiency is very low because waiting dominates the value stream Correct answer.
  3. Lead time is acceptable because the build itself is fast
  4. The team should add more approval steps to control the queue

Explanation

Flow efficiency is value-adding time divided by total lead time, and here waiting swamps the active work, so efficiency is low. Optimizing the already-fast pipeline or adding gates would not address the dominant queue before review.

Question 10Continuous Delivery Foundations and Value Streams

A team using continuous deployment wants to release a risky feature without exposing it to all users at once. Which technique fits best?

  1. Add a manual approval step before every deployment
  2. Deploy it only during the next scheduled maintenance window
  3. Ship behind a feature flag that is enabled progressively Correct answer.
  4. Hold the change on a long-lived branch until it is safe

Explanation

Feature flags decouple deployment from release, letting code reach production while exposure is controlled incrementally. Long-lived branches, maintenance windows, and per-deployment approvals all delay integration or deployment instead of managing exposure.

Question 11Continuous Delivery Foundations and Value Streams

Which change most reliably shortens the feedback loop for a developer who just pushed a commit?

  1. Running a fast unit test suite on every commit before slower stages Correct answer.
  2. Consolidating all tests into a single nightly job
  3. Requiring two reviewers before any automated checks run
  4. Running the full end-to-end suite only at release time

Explanation

Fast checks on every commit give developers feedback within minutes and fail early before expensive stages run. Deferring tests to release or nightly jobs, or gating checks behind reviews, lengthens the time before a defect is discovered.

Question 12Continuous Delivery Foundations and Value Streams

An architect is mapping a value stream and finds a step where a change waits for a shared test environment. Which lean concept does this waiting most directly represent?

  1. Value-adding verification time
  2. Rework caused by a defect
  3. Processing time required by the test suite
  4. Queue time that inflates lead time without adding value Correct answer.

Explanation

Waiting for a constrained shared resource is queue time, which counts toward lead time but produces no value for the customer. It is distinct from the actual test execution time and from rework caused by defects.

Question 13Continuous Delivery Foundations and Value Streams

Which organizational structure most supports a single delivery pipeline owned end to end by one team?

  1. A cross-functional team accountable for build, deploy, and run Correct answer.
  2. Separate build, test, and operations teams handing off artifacts
  3. A centralized release management group approving each deployment
  4. An outsourced operations vendor owning production changes

Explanation

End-to-end accountability for the pipeline requires the same team to own building, deploying, and operating the service, which shortens handoffs. Splitting those responsibilities across teams or vendors reintroduces the handoffs and queues that continuous delivery seeks to remove.

Question 14Continuous Delivery Foundations and Value Streams

What is the primary purpose of keeping the mainline in a always-releasable state in continuous delivery?

  1. It allows any passing build to be released on demand without extra stabilization work Correct answer.
  2. It guarantees that no defects ever reach production
  3. It eliminates the need for monitoring in production
  4. It removes the need for automated testing in the pipeline

Explanation

An always-releasable mainline means the release decision can be made at any time without a hardening phase, because every commit has passed the full pipeline. It does not guarantee zero defects, nor does it replace automated testing or production monitoring.

Question 15Continuous Delivery Foundations and Value Streams

A team's deployment frequency is high but its mean time to restore is poor. Which investment most directly addresses the weakness?

  1. Shortening the code review checklist
  2. Adding more unit tests to the pipeline
  3. Increasing the number of deployments per day
  4. Improving observability and automated rollback in production Correct answer.

Explanation

Restoration time depends on how quickly a failure is detected and reversed, so better observability and automated rollback target that metric directly. More deployments, extra unit tests, or a shorter checklist may help elsewhere but do not speed recovery from a live incident.

Question 16Continuous Delivery Foundations and Value Streams

Which describes the correct relationship between continuous integration and continuous delivery?

  1. The two terms are interchangeable descriptions of the same pipeline
  2. Continuous integration applies only to open-source projects
  3. Continuous integration is a prerequisite practice that continuous delivery builds upon Correct answer.
  4. Continuous delivery replaces the need for continuous integration

Explanation

Continuous integration ensures changes are merged and verified frequently on a shared mainline, and continuous delivery extends that discipline to keeping every verified change deployable. Delivery does not replace integration, and the terms are not synonyms.

Question 17Continuous Delivery Foundations and Value Streams

A value stream contains a step where a change waits three days for a security scan that runs for ten minutes. Which action best improves the value stream?

  1. Extend the scan to run nightly to reduce load
  2. Move the scan to after the production deployment
  3. Trigger the scan automatically on every commit so the wait disappears Correct answer.
  4. Add a second manual security review to compensate

Explanation

The waste is the three-day wait, not the ten-minute scan, so automating the trigger removes the queue while preserving the control. Adding reviews, running nightly, or scanning after deployment either lengthens the wait or weakens the control.

Question 18Continuous Delivery Foundations and Value Streams

Which statement about deployment pipelines as code is most accurate?

  1. Storing pipeline definitions in a wiki keeps them consistent with the build
  2. Pipelines must be configured through a vendor UI to be auditable
  3. Defining the pipeline in version control makes it reviewable and reproducible across services Correct answer.
  4. Each service should maintain a hand-edited pipeline to preserve flexibility

Explanation

Treating pipeline definitions as versioned code makes them reviewable, testable, and reproducible, and allows shared templates across services. UI-only configuration, wiki documentation, and hand-edited per-service pipelines drift and resist review.

Question 19Continuous Delivery Foundations and Value Streams

A team claims continuous delivery but cannot release without a two-week stabilization phase. Which conclusion is best supported?

  1. The mainline is not truly always-releasable, so the practice is incomplete Correct answer.
  2. The team has achieved continuous deployment instead
  3. The stabilization phase is a required part of continuous delivery
  4. The pipeline is working as designed because releases are rare

Explanation

Continuous delivery requires that any passing build can be released without a hardening period, so a two-week stabilization phase contradicts the claim. Continuous deployment would mean automatic release, and a stabilization phase is a symptom of missing pipeline coverage rather than a required step.

Question 20Continuous Delivery Foundations and Value Streams

Which combination best characterizes a well-designed deployment pipeline stage?

  1. Require manual approval before any automated check runs
  2. Run the slowest end-to-end tests first to catch major defects
  3. Fail fast on cheap checks, then run progressively more expensive verification Correct answer.
  4. Run all tests in parallel regardless of cost or feedback value

Explanation

Ordering cheap, fast checks first lets the pipeline fail quickly on common defects and reserves expensive verification for changes that already passed basic gates. Running slow tests first, ignoring cost, or gating checks behind approval all delay feedback.

Question 21Continuous Delivery Foundations and Value Streams

An organization measures lead time from commit to production but excludes time spent waiting for a release approval. What is the effect on the metric?

  1. It overstates lead time by counting idle periods
  2. It makes the metric equivalent to deployment frequency
  3. It understates true lead time and hides a major source of delay Correct answer.
  4. It has no effect because approvals are not part of the value stream

Explanation

Lead time for changes must span the entire path from commit to running in production, so excluding approval waits removes real delay and flatters the result. Approval waits are part of the value stream, and the metric remains distinct from deployment frequency.

Question 22Continuous Delivery Foundations and Value Streams

A platform team offers a shared pipeline template to many product teams. Which design choice best preserves both consistency and team autonomy?

  1. Every team copies the template once and edits it freely thereafter
  2. Templates are documented in a wiki but not enforced by tooling
  3. The platform team runs all deployments on behalf of product teams
  4. Central templates enforce required stages while teams extend with their own optional stages Correct answer.

Explanation

Enforced shared stages guarantee compliance and consistency, while an extension mechanism lets teams add verification specific to their service. Copied templates drift, central deployment reintroduces handoffs, and unenforced documentation cannot guarantee anything.

Question 23Continuous Delivery Foundations and Value Streams

A value stream map reveals that 80 percent of lead time is spent after code complete but before deployment. Which intervention addresses the largest contributor?

  1. Increasing the frequency of status meetings
  2. Adding more developers to write code faster
  3. Automating environment provisioning and test data setup to remove environment waits Correct answer.
  4. Extending the code freeze period before release

Explanation

If most delay sits between code complete and deployment, the constraint is in the path to production, typically environment provisioning and test data. Adding coding capacity, more meetings, or longer code freezes does not remove those post-completion waits.

Question 24Continuous Delivery Foundations and Value Streams

Which scenario most clearly violates the principle that deployment and release should be decoupled?

  1. Deploying dark code that is activated later by a configuration change
  2. Deploying code to production only at the moment all users are meant to see the feature Correct answer.
  3. Deploying continuously while marketing controls the announcement date
  4. Releasing a feature to a small cohort before general availability

Explanation

Decoupling means code can reach production before it is exposed to users, so tying deployment to the exposure moment re-couples them and forces batching. Dark launches, cohort releases, and marketing-controlled announcements all keep deployment and release separate.

Question 25Build and Dependency Management

Which statement best describes the purpose of a build artifact repository in a continuous delivery pipeline?

  1. It caches source control history so developers can rebase feature branches faster.
  2. It stores versioned build outputs so downstream stages deploy the exact same binary that was tested. Correct answer.
  3. It hosts container orchestration control planes during production rollout.
  4. It compiles source code into binaries on every commit before tests run.

Explanation

An artifact repository is the system of record for versioned binaries produced by the build stage. Because every downstream environment pulls from that same immutable version, promotion does not require rebuilding, which removes a major source of drift between tested and deployed code.

Question 26Build and Dependency Management

A team wants reproducible builds from a Maven project. Which practice most directly supports that goal?

  1. Building only on developer laptops where the environment is already known.
  2. Allowing Maven to resolve the latest release of each dependency at build time.
  3. Deleting the local repository before each build to force fresh downloads.
  4. Pinning plugin and dependency versions and committing the resolved dependency lock information. Correct answer.

Explanation

Reproducibility requires that the same inputs produce the same outputs, so every dependency and plugin version must be fixed rather than resolved dynamically. Committing lock or resolved dependency information ensures the build resolves identical versions across agents and over time.

Question 27Build and Dependency Management

What is the primary benefit of running builds in a clean, ephemeral workspace for each pipeline run?

  1. It removes the need for any dependency repository or proxy.
  2. It reduces the number of test cases that must be executed per commit.
  3. It prevents leftover files or cached state from one run silently influencing the next. Correct answer.
  4. It guarantees that build times will be shorter than on persistent agents.

Explanation

Ephemeral workspaces eliminate contamination from prior runs, which is a common cause of builds that pass locally or intermittently but fail after a clean checkout. They do not reduce test scope or remove the need for dependency resolution.

Question 28Build and Dependency Management

Which dependency management technique reduces the risk of a transitive library upgrade breaking a production build without warning?

  1. Disabling the dependency cache so versions are re-resolved on every run.
  2. Relying on open version ranges such as 1.x for all direct dependencies.
  3. Vendoring only the direct dependencies and ignoring transitive ones.
  4. Using a dependency lock file that records exact resolved versions. Correct answer.

Explanation

A lock file records the exact versions of every resolved dependency, including transitive ones, so the same graph is reconstructed on each build. Open ranges allow an upstream release to silently change the graph and break the build.

Question 29Build and Dependency Management

A pipeline builds a Docker image tagged only with latest for every commit. What is the main problem for continuous delivery?

  1. The tag does not uniquely identify the artifact, so promotion and rollback cannot target a specific build. Correct answer.
  2. Using latest disables layer caching and forces full rebuilds.
  3. Docker refuses to push images that use the latest tag to private registries.
  4. The latest tag prevents the image from being built from a Dockerfile.

Explanation

A mutable tag like latest points to different content over time, so a deployment that references it is not traceable to a specific commit or tested binary. Continuous delivery depends on immutable, uniquely identifiable artifact versions for promotion and rollback.

Question 30Build and Dependency Management

Which pattern best describes a build that fetches dependencies through an internal proxy repository that mirrors an upstream public registry?

  1. A static analysis service that scans source code for defects.
  2. A container scheduler that places build pods on available nodes.
  3. A distributed version control mirror that replicates source repositories.
  4. A caching proxy that insulates builds from upstream outages and enforces approved versions. Correct answer.

Explanation

An internal proxy repository caches artifacts from upstream registries and serves them to builds, which improves availability and lets organizations control which versions are allowed. It is a dependency distribution mechanism, not source replication or scheduling.

Question 31Build and Dependency Management

A build produces different checksums on two consecutive runs from the same commit. Which cause is most likely?

  1. The build agent has more CPU cores than the previous agent.
  2. The build embeds a timestamp or other non-deterministic value into the output. Correct answer.
  3. The artifact repository is configured with a retention policy.
  4. The source repository contains too many branches.

Explanation

Non-reproducible checksums usually come from embedded build metadata such as timestamps, hostnames, or randomized ordering. Removing or normalizing those values is the standard remedy for deterministic output.

Question 32Build and Dependency Management

What is the recommended way to handle secrets such as repository credentials during a CI build?

  1. Hard-code them in the pipeline definition file in version control.
  2. Commit them encrypted in the build script so every agent can read them.
  3. Store them in the Dockerfile as environment variables for convenience.
  4. Inject them at runtime from a secrets manager scoped to the pipeline job. Correct answer.

Explanation

Secrets should be supplied at runtime from a managed store with least-privilege access for the specific job, so they are never persisted in source or images. Encoding or hard-coding them in repository files exposes them to anyone with read access.

Question 33Build and Dependency Management

Which build stage ordering best supports fast feedback in a continuous delivery pipeline?

  1. Run packaging and deployment before unit tests to validate the artifact early.
  2. Run all stages in parallel so total pipeline duration is minimized.
  3. Run fast unit tests and static checks before slower integration and packaging stages. Correct answer.
  4. Run full end-to-end environment tests before any compilation occurs.

Explanation

Placing cheap, high-signal checks first means most failures are caught within seconds or minutes, before expensive stages consume resources. Slow integration and packaging run only after the fast gates pass.

Question 34Build and Dependency Management

A monorepo build runs the entire test suite on every change. Which change most improves pipeline efficiency without sacrificing correctness?

  1. Disable tests for projects that have not changed in the last thirty days.
  2. Reduce the number of parallel agents to lower contention.
  3. Run the full suite only on the main branch and skip it on pull requests.
  4. Use dependency-graph analysis to build and test only affected projects and their dependents. Correct answer.

Explanation

Affected-project selection uses the dependency graph to identify which modules could be impacted by a change and their downstream dependents. This preserves correctness for changed code while avoiding work on unrelated projects.

Question 35Build and Dependency Management

Which statement correctly distinguishes a build cache from an artifact repository?

  1. A cache is mandatory for deployment, while an artifact repository is optional.
  2. A cache stores only source code, while an artifact repository stores only test reports.
  3. A cache speeds up rebuilds and may be evicted, while an artifact repository retains authoritative versioned outputs. Correct answer.
  4. A cache and an artifact repository are the same system configured differently.

Explanation

Caches are performance optimizations whose contents can be discarded and regenerated, whereas the artifact repository holds the authoritative, versioned binaries that deployments consume. Conflating them risks losing the artifact a release depends on.

Question 36Build and Dependency Management

What does it mean for a build to be hermetic?

  1. It produces a single monolithic binary with no external libraries.
  2. It runs inside a container image that is rebuilt on every commit.
  3. It relies only on declared inputs and does not reach the network or host state during compilation. Correct answer.
  4. It always completes within a fixed time budget enforced by the pipeline.

Explanation

Hermetic builds declare all inputs and avoid undeclared network or host dependencies, which is what makes them reproducible and cacheable. Containerization and time limits are separate properties that do not by themselves guarantee hermeticity.

Question 37Build and Dependency Management

A team must guarantee that the artifact deployed to production is byte-identical to the one that passed acceptance tests. Which practice achieves this?

  1. Promote the same immutable artifact by digest through each environment without rebuilding. Correct answer.
  2. Rebuild from the same commit in each environment and compare test results.
  3. Store the artifact in a shared directory that all environments mount read-write.
  4. Tag the artifact with the environment name at each deployment stage.

Explanation

Promotion by immutable digest ensures every environment consumes the exact bytes that were verified, eliminating rebuild-induced differences. Rebuilding, even from the same commit, can introduce different dependency resolution or toolchain output.

Question 38Build and Dependency Management

Which signal in a build pipeline most reliably indicates dependency drift?

  1. A build duration that increases by ten percent between runs.
  2. A rising count of commits merged to the main branch.
  3. A decrease in the number of pipeline agents available.
  4. A resolved dependency graph that differs from the previously recorded lock file. Correct answer.

Explanation

Dependency drift is defined by a change in the resolved versions of dependencies, which appears as a diff against the recorded lock file. Timing, commit volume, and agent capacity are operational metrics that do not reveal version changes.

Question 39Build and Dependency Management

Why should build metadata such as commit hash and build number be injected at build time rather than committed to source?

  1. It prevents the build from requiring a version control system checkout.
  2. It keeps the source tree clean while allowing the artifact to be traced back to its exact origin. Correct answer.
  3. It guarantees that the build will be reproducible across agents.
  4. It removes the need to tag artifacts in the repository.

Explanation

Injecting metadata at build time avoids churn in source files while stamping each artifact with traceable provenance. Reproducibility still depends on deterministic inputs, not on how metadata is supplied.

Question 40Build and Dependency Management

A pipeline fails intermittently when fetching a popular open-source library from a public registry. Which remediation best addresses availability without weakening version control?

  1. Remove the dependency and reimplement the functionality in-house.
  2. Switch to resolving the newest snapshot on each build to avoid stale caches.
  3. Retry the download indefinitely until the public registry responds.
  4. Route dependency resolution through an internal proxy that caches approved versions. Correct answer.

Explanation

An internal caching proxy keeps approved artifacts available even when the upstream registry is unreachable or rate-limited, while preserving pinned versions. Snapshot resolution and unbounded retries introduce nondeterminism or delay rather than solving availability.

Question 41Build and Dependency Management

Which approach best supports incremental compilation across many parallel build agents?

  1. A local disk cache that exists only on each individual agent.
  2. Sharing a single writable build directory among all agents.
  3. A shared remote build cache keyed by declared inputs and toolchain version. Correct answer.
  4. Disabling caching so every agent always compiles from scratch.

Explanation

A remote cache keyed by precise inputs and toolchain version lets any agent reuse outputs produced by another, which is essential for incremental builds at scale. Local-only caches provide no cross-agent reuse, and shared writable directories create race conditions.

Question 42Build and Dependency Management

What is the role of a bill of materials (BOM) in dependency management?

  1. It lists the human approvers required to release an artifact.
  2. It defines a consistent set of dependency versions that consuming projects can import. Correct answer.
  3. It records the hardware inventory used by build agents.
  4. It stores the checksums of deployed container images.

Explanation

A BOM centralizes version alignment so that projects importing it receive a coherent, tested set of dependency versions. This reduces version conflicts across modules without each project specifying every version.

Question 43Build and Dependency Management

An organization wants to block builds that pull dependencies with known critical vulnerabilities. Where should this gate be enforced?

  1. In the production deployment approval meeting held after release.
  2. In the artifact repository's storage quota configuration.
  3. In the dependency resolution step, failing the build when a scanned artifact violates policy. Correct answer.
  4. In the source code review checklist completed by developers.

Explanation

Enforcing policy during dependency resolution stops vulnerable artifacts before they enter the build output, which is the earliest reliable point of control. Later manual or review-based checks are inconsistent and allow the artifact to propagate.

Question 44Build and Dependency Management

Which characteristic most clearly indicates that a pipeline has an undeclared dependency on its build environment?

  1. The build logs include the commit hash of the checked-out revision.
  2. The build produces a checksum that matches across all agents.
  3. The build succeeds on one agent image and fails on another with an identical checkout. Correct answer.
  4. The build completes faster when the remote cache is warm.

Explanation

Environment-dependent success or failure is the signature of an undeclared dependency, such as a preinstalled tool or ambient variable present on only one image. Matching checksums and cache speedups are expected behaviors of well-isolated builds.

Question 45Deployment Pipeline Design and Orchestration

In a deployment pipeline, what is the primary purpose of a gate that requires a manual approval before promotion to production?

  1. To compile the application artifacts from source on a clean agent
  2. To automatically roll back the previous release if health checks fail
  3. To insert a deliberate human decision point that automated verification cannot make Correct answer.
  4. To measure code coverage of the unit test suite

Explanation

A manual approval gate exists so that a person can exercise judgment the pipeline cannot encode automatically, such as business readiness or risk acceptance. It does not perform build, test measurement, or rollback duties, which belong to other pipeline stages.

Question 46Deployment Pipeline Design and Orchestration

A team wants every commit on the mainline to be validated by the same sequence of build, test, and package stages. Which pipeline design property does this describe?

  1. Per-developer pipelines that run only on feature branches
  2. Environment-specific branching per stage
  3. A single shared pipeline definition applied uniformly to all commits Correct answer.
  4. Manual stage triggering by the release manager

Explanation

A uniform pipeline definition ensures every change passes through the same automated validation, which is a core principle of pipeline design. Divergent or manually triggered paths undermine repeatability and comparability of results.

Question 47Deployment Pipeline Design and Orchestration

Which practice best supports the principle that a build artifact should be promoted through environments rather than rebuilt for each one?

  1. Rebuilding only when the target environment differs in operating system
  2. Storing the immutable artifact in a repository and deploying the same binary to each stage Correct answer.
  3. Recompiling from the tagged commit on every environment's agent
  4. Copying the source tree to each environment and building there

Explanation

Promoting one immutable artifact guarantees that what was tested is exactly what reaches production. Rebuilding per environment introduces the risk that the deployed binary differs from the validated one.

Question 48Deployment Pipeline Design and Orchestration

What distinguishes a deployment pipeline stage from an arbitrary script executed in a job?

  1. A stage has defined entry criteria, automated verification, and a promotion decision Correct answer.
  2. A stage is always triggered manually by a change advisory board
  3. A stage must always run on the same physical machine
  4. A stage can only contain a single command

Explanation

A pipeline stage is a bounded phase with clear inputs, automated checks, and a decision about whether to promote the artifact onward. A script is just an executable unit without those orchestration semantics.

Question 49Deployment Pipeline Design and Orchestration

A pipeline runs unit tests in parallel across four agents but must publish a single aggregated test report. Which orchestration pattern fits best?

  1. Fan-out parallel jobs followed by a fan-in aggregation step Correct answer.
  2. A manual gate between each parallel job
  3. A single job that runs all tests serially on one agent
  4. A sequential chain where each agent waits for the previous one

Explanation

Fan-out distributes work across parallel jobs, and fan-in collects their outputs into one aggregated result. This is the standard pattern for parallel test execution with unified reporting.

Question 50Deployment Pipeline Design and Orchestration

Which metric most directly indicates the health of a deployment pipeline's feedback loop?

  1. Lead time from commit to a deployable artifact Correct answer.
  2. Total lines of pipeline configuration
  3. Count of branches in the repository
  4. Number of environments provisioned

Explanation

Lead time from commit to deployable artifact measures how quickly the pipeline gives feedback and produces something releasable. The other options count infrastructure or code volume, which do not reflect feedback speed.