I85PREP
⌘ K
LPI DevOps Tools Engineer study materials
LPI DevOps Tools Engineer study resources

LPI DevOps Tools Engineer practice questions

One question at a time. Build your LPI DevOps Tools Engineer 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 1Software Engineering

A team wants every commit pushed to the shared repository to be built and tested automatically before merging. Which Git hosting capability most directly enforces this gate?

  1. A post-receive hook that emails the committer after the push
  2. Git hooks installed only in each developer's local clone
  3. Protected branch rules requiring status checks to pass before merge Correct answer.
  4. Signed commits using GPG keys on the main branch

Explanation

Branch protection on the shared remote blocks merges until required CI status checks report success, so the gate applies to everyone regardless of local setup. Local hooks and notification hooks do not prevent a merge. Commit signing proves authorship but does not run builds or tests.

Question 2Software Engineering

A pipeline needs a secret API token at build time. Which practice fits a twelve-factor, pipeline-friendly workflow?

  1. Bake the token into the Docker image so all stages reuse it
  2. Commit the token to the repository inside an encrypted-looking string
  3. Store the token in the README so all contributors can find it
  4. Inject the token as a masked CI variable at job runtime Correct answer.

Explanation

Twelve-factor apps keep config in the environment, and CI systems offer masked variables injected only into the running job. This keeps the secret out of version control and out of image layers. Committing or documenting the token exposes it to anyone with repository read access.

Question 3Software Engineering

Which statement describes the role of a Dockerfile multi-stage build in a CI pipeline?

  1. It guarantees reproducible builds by pinning the host kernel version
  2. It runs unit tests inside the production container at startup
  3. It replaces the need for a container registry by storing layers in Git
  4. It lets build tooling live in an early stage while the final image ships only runtime artifacts Correct answer.

Explanation

Multi-stage builds separate a builder stage, which may include compilers and SDKs, from a slim final stage that copies only the produced artifacts. This shrinks the attack surface and image size. The final image still needs a registry, and the host kernel is not controlled by the Dockerfile.

Question 4Software Engineering

In a CI job you see the command `docker run --rm -v "$PWD:/src" -w /src node:20 npm test`. What is the effect of the `-w /src` flag?

  1. It names the container src for later reuse
  2. It sets the working directory inside the container to /src Correct answer.
  3. It mounts the host directory /src as read-only
  4. It limits the container to one CPU named src

Explanation

The `-w` (or `--workdir`) flag sets the container's working directory, so npm runs with the bind-mounted source as its current directory. Read-only mounts use `:ro` on the volume, naming uses `--name`, and CPU limits use `--cpus`.

Question 5Software Engineering

A developer wants to run the same lint command locally that CI runs, without installing the linter on the host. Which approach best matches the exam's container-centric workflow?

  1. Run the project's linter image or a container built from the project Dockerfile Correct answer.
  2. Copy the linter binary from the CI server into the repository
  3. Add the lint step to a pre-receive hook on the Git server
  4. Ask each developer to install a different linter version

Explanation

Running the same container image locally and in CI gives environment parity, so lint results match. Copying binaries or letting versions drift breaks reproducibility, and a server-side hook cannot help a developer before pushing.

Question 6Software Engineering

What does a `docker-compose.yml` (Compose file) primarily describe?

  1. A multi-container application with services, networks, and volumes Correct answer.
  2. The CPU architecture of the build host
  3. The Git branching strategy used by the team
  4. The kernel capabilities granted to the Docker daemon

Explanation

A Compose file declares services, their images or builds, ports, volumes, and networks so a multi-container stack can be started with one command. It does not configure the daemon's kernel capabilities, branching strategy, or host architecture.

Question 7Software Engineering

Which artifact should a CI pipeline publish so a downstream deployment stage can deploy exactly the bits that were tested?

  1. The CI runner's shell history
  2. The developer's local .git directory
  3. A screenshot of the passing test output
  4. A versioned container image tagged with the commit SHA Correct answer.

Explanation

Publishing an immutable, versioned artifact such as an image tagged with the commit SHA lets later stages deploy precisely what passed the tests. Shell history, local repositories, and screenshots are not deployable artifacts and cannot be promoted.

Question 8Software Engineering

An infrastructure-as-code repository keeps Terraform state on a developer laptop. What is the main problem this creates for a team?

  1. Providers cannot authenticate without local state
  2. Terraform refuses to run without a local state file
  3. State files become larger than the provider allows
  4. Concurrent runs and lost laptops can corrupt or lose the single source of truth Correct answer.

Explanation

State records the mapping between configuration and real resources, so a single local copy risks corruption and lost updates when several people apply changes. Teams use a remote backend with locking to serialize access and share state safely.

Question 9Software Engineering

A CI pipeline fails with `permission denied` when a script in the repository is executed on the runner. Which fix addresses the root cause?

  1. Prefix the command with sudo in the pipeline
  2. Rewrite the script in a compiled language
  3. Set the executable bit on the script in Git and commit the mode change Correct answer.
  4. Disable the pipeline's container isolation

Explanation

Git records the executable bit, and a checkout on the runner reproduces it; if the bit was never set, the script is not executable. Committing the mode change fixes it for every runner. Using sudo or removing isolation changes privileges rather than the file's mode.

Question 10Software Engineering

A container image build is slow because dependencies are reinstalled on every code change. Which Dockerfile change best exploits layer caching?

  1. Copy only the dependency manifest and install dependencies before copying the rest of the source Correct answer.
  2. Combine every instruction into a single RUN layer
  3. Disable the build cache with --no-cache
  4. Copy the entire source tree first, then run the package install

Explanation

Docker invalidates a layer when its inputs change, so copying the manifest and installing dependencies first means that layer is reused until the manifest changes. Copying all source first busts the cache on every edit, and --no-cache guarantees a full rebuild.

Question 11Software Engineering

A pipeline should run integration tests only when a merge request targets the main branch. Which configuration element expresses this?

  1. A retry count on the job
  2. A rules or only/except clause scoped to the target branch and event type Correct answer.
  3. A longer job timeout
  4. A cache key based on the commit SHA

Explanation

Conditional execution is expressed with pipeline rules that match the branch and event, such as merge request pipelines targeting main. Timeouts, retries, and cache keys control duration and reuse, not whether the job runs.

Question 12Software Engineering

During review you find `curl -k https://internal.example/install.sh | bash` in a CI job. What is the primary risk?

  1. Unverified remote code executes with the runner's credentials and network access Correct answer.
  2. curl cannot follow HTTPS redirects
  3. bash is unavailable in most CI images
  4. The download may exceed the job's disk quota

Explanation

Piping a remote script into a shell runs whatever the server returns, with the job's privileges and secrets, and `-k` disables certificate verification so tampering goes undetected. The concern is supply-chain integrity, not disk usage or redirect handling.

Question 13Software Engineering

A team adopts trunk-based development. Which practice keeps the main branch releasable?

  1. Manual release branches cut per developer
  2. Long-lived feature branches merged quarterly
  3. Small, frequent merges backed by automated tests on every commit Correct answer.
  4. Freezing main for the duration of each feature

Explanation

Trunk-based development relies on short-lived branches and frequent integration, with automated tests guarding every change so main stays deployable. Long-lived branches, per-developer branches, and freezes increase integration risk and delay feedback.

Question 14Software Engineering

A pipeline pushes an image tagged `latest` to the registry. Why is this tag problematic for reproducible deployments?

  1. The tag can be reassigned, so the same reference may resolve to different content over time Correct answer.
  2. latest always points to the oldest image in the repository
  3. It prevents the image from being pulled by Kubernetes
  4. Registries reject the latest tag for security reasons

Explanation

A tag is a mutable pointer, so `latest` can be overwritten and the same name may yield different images across deploys. Immutable references such as a digest or commit SHA make deployments reproducible. Registries and orchestrators do accept `latest`.

Question 15Software Engineering

A GitOps controller reconciles a Kubernetes cluster against a Git repository. What is the key property of this model?

  1. Developers must hold cluster-admin credentials to deploy
  2. Rollbacks require rebuilding images from source
  3. The Git repository is the declared source of truth and drift is corrected automatically Correct answer.
  4. The cluster state is pushed only by manual kubectl commands

Explanation

In GitOps the desired state lives in Git and an agent continuously reconciles the cluster toward it, correcting drift and making the commit history the audit trail. Manual pushes, broad credentials, and image rebuilds are not required.

Question 16Software Engineering

A test suite passes locally but fails in CI with missing timezone data. Which action best addresses the discrepancy?

  1. Add retries until the test passes
  2. Skip the failing tests in CI
  3. Pin the CI base image and set the timezone explicitly in the pipeline environment Correct answer.
  4. Increase the runner's memory allocation

Explanation

The failure reflects an environment difference, so aligning the base image and setting the timezone in the pipeline restores parity with local runs. Retrying, skipping, or adding memory hides the discrepancy without fixing it.

Question 17Software Engineering

Which statement about immutable infrastructure is accurate?

  1. Servers are patched in place and never replaced
  2. Instances are replaced with new builds rather than modified after deployment Correct answer.
  3. Images are rebuilt on every boot from the running system
  4. Configuration drift is corrected by logging into each host

Explanation

Immutable infrastructure treats servers as disposable: changes ship as new images or instances, and old ones are replaced. In-place patching, manual logins, and boot-time rebuilds from a live system are the mutable patterns it avoids.

Question 18Software Engineering

A pipeline needs to run a database migration once per deployment, before the new application version starts. Which design is most robust?

  1. Let the first user request trigger the migration
  2. Run the migration as a separate job that the deploy stage depends on Correct answer.
  3. Run the migration manually after the deployment
  4. Run the migration in each application replica's startup script

Explanation

A dedicated migration job that the deploy stage depends on runs exactly once, in a controlled order, and can fail the pipeline before new code starts. Running it per replica races, manual steps are unreliable, and request-triggered migrations are unpredictable.

Question 19Software Engineering

A team wants to detect that a deployed environment has drifted from its declared configuration. Which approach provides that signal?

  1. Periodically comparing live state to the IaC plan and alerting on differences Correct answer.
  2. Increasing the deployment frequency
  3. Relying on code review of pull requests alone
  4. Disabling the state file to avoid conflicts

Explanation

Drift detection compares the real environment with the declared configuration, such as a Terraform plan showing unexpected changes, and alerts when they differ. Code review covers intended changes only, frequency does not reveal drift, and removing state eliminates the reference point.

Question 20Software Engineering

A CI job must build a Go binary and then run it in a minimal runtime image. Which sequence reflects a sound multi-stage Dockerfile?

  1. Run the compiler inside the final stage at container start
  2. Mount the host Go toolchain into the runtime container
  3. Build in a golang stage, then COPY the binary into a scratch or distroless final stage Correct answer.
  4. Use golang as the final base and delete the source after building

Explanation

Compiling in a builder stage and copying only the resulting binary into a minimal final stage keeps the runtime image small and free of toolchains. Keeping golang as the final base, compiling at startup, or mounting host toolchains all bloat or break the runtime image.

Question 21Software Engineering

A repository uses semantic versioning and publishes library releases. A change removes a public function without a deprecation period. Which version bump is required?

  1. No release, because removals are internal
  2. A minor release, because new behavior is added
  3. A patch release, because the code compiles
  4. A major release, because backward compatibility is broken Correct answer.

Explanation

Semantic versioning reserves the major number for incompatible API changes, and removing a public function breaks consumers. Patch and minor releases must remain backward compatible, so neither fits.

Question 22Software Engineering

Two pipeline stages both need a compiled artifact. Stage B runs on a different runner than stage A. What must happen for B to receive the artifact?

  1. Stage A uploads the artifact to shared storage and B downloads it Correct answer.
  2. The runners share a local filesystem by default
  3. Stage B reads the artifact from the previous runner's memory
  4. Stage B re-clones the repository and rebuilds from source

Explanation

Runners are isolated, so artifacts must pass through shared storage such as the CI system's artifact store or a registry. Rebuilding wastes time and may diverge, default shared filesystems do not exist across runners, and process memory is not shared.

Question 23Software Engineering

A team wants a failing security scan to block merges but still let developers see results on every push. Which configuration achieves both goals?

  1. Run the scan nightly only on the main branch
  2. Run the scan only after a release tag is created
  3. Let developers run the scan manually before pushing
  4. Make the scan a required status check that runs on every push to the branch Correct answer.

Explanation

A required status check runs on each push so results are visible immediately, and branch protection blocks the merge while it fails. Nightly, release-only, or manual scans provide no gate at merge time and may miss the change entirely.

Question 24Software Engineering

A deployment uses a canary release. Which observation would justify automatically rolling back?

  1. Error rate and latency on the canary exceed the baseline beyond a defined threshold Correct answer.
  2. The canary image digest matches the stable image digest
  3. The canary pods are scheduled on different nodes than stable pods
  4. The canary receives a small share of traffic as configured

Explanation

Canary analysis compares the new version's health metrics against the baseline and rolls back when error rate or latency breaches thresholds. Receiving a small traffic share, matching digests, and node placement are expected conditions, not failure signals.

Question 25Software Engineering

A CI pipeline caches `~/.m2` using a key of the branch name. Builds on the main branch intermittently pick up stale dependencies after a dependency update. What is the most likely cause?

  1. The cache is restored across commits because the key does not include the dependency manifest Correct answer.
  2. Maven cannot read caches on CI runners
  3. The runner has insufficient disk space
  4. The pipeline lacks a retry policy

Explanation

A cache key tied only to the branch is reused across commits, so a lockfile or manifest change does not invalidate it and stale dependencies persist. Including a hash of the manifest in the key restores correctness. Disk space, Maven compatibility, and retries do not explain stale content.

Question 26Software Engineering

A team wants every merge to the main branch to be traceable back to the exact commit that produced a deployed build. Which artifact identifier should the pipeline embed in the image label and deployment record?

  1. The timestamp of the build start
  2. The full Git commit SHA of the built revision Correct answer.
  3. The human-readable branch name
  4. The pipeline job number

Explanation

A commit SHA uniquely and immutably identifies the source revision, so it survives rebases of labels and can be cross-referenced in Git history. Branch names move, job numbers are pipeline-local, and timestamps do not identify source content.

Question 27Software Engineering

A developer wants to run the same lint and unit-test steps locally that the CI pipeline runs. Which practice makes this possible without duplicating logic?

  1. Document the commands in the README and trust developers to retype them
  2. Define the steps once in a script committed to the repository and call it from both CI and local workflows Correct answer.
  3. Rely on the CI provider's hosted runner image for local execution
  4. Copy the CI configuration into a personal shell alias

Explanation

A shared script in version control is a single source of truth, so local and CI execution stay consistent and changes are reviewed like code. Aliases, README instructions, and provider-specific images all drift or fail outside the CI environment.

Question 28Software Engineering

A team stores secrets as plain environment variables in the pipeline configuration file committed to Git. Which change most directly removes the exposure?

  1. Base64-encode the values in the configuration file
  2. Add the configuration file to .gitignore after the first commit
  3. Restrict repository read access to the core team
  4. Move the values into the CI system's masked secret store and reference them by name Correct answer.

Explanation

A dedicated secret store keeps values out of version control and masks them in logs, which removes the plaintext exposure entirely. Encoding, ignoring after commit, and narrowing access do not remove the secret from history.

Question 29Software Engineering

A repository's default branch must stay deployable. Which branching convention supports this with the least merge overhead?

  1. Long-running release branches per environment
  2. A permanent develop branch that merges to main quarterly
  3. Direct commits to main without review
  4. Short-lived feature branches merged frequently after passing automated checks Correct answer.

Explanation

Short-lived branches integrated frequently keep divergence small and let automated gates verify each merge, which is the core of trunk-based flow. Long-lived environment branches and infrequent integration accumulate risk.

Question 30Software Engineering

A build produces a tarball that a later stage must deploy. The stages run on separate runners with no shared disk. Which mechanism should carry the artifact between stages?

  1. Upload the tarball to the pipeline's artifact storage and download it in the later stage Correct answer.
  2. Rely on the runner's local workspace persisting between stages
  3. Print the tarball as base64 in the job log and copy it manually
  4. Commit the tarball to the repository from the build stage

Explanation

Artifact storage is the designed transport between isolated runners and guarantees the later stage receives the exact bytes produced. Local workspaces are not shared, and committing build output pollutes history.

Question 31Software Engineering

Which file in a repository typically declares the exact dependency versions a build will use, so that installs are repeatable?

  1. The CI provider's default configuration
  2. The project's README
  3. The .editorconfig file
  4. The lockfile generated by the package manager Correct answer.

Explanation

A lockfile pins resolved versions and checksums so every install resolves identically across machines and time. README files, provider defaults, and editor settings do not pin dependencies.

Question 32Software Engineering

A team wants automated checks to run on every pull request before review. Which trigger configuration achieves this?

  1. Run the pipeline only on a nightly schedule
  2. Run the pipeline only after a tag is pushed
  3. Run the pipeline only on manual dispatch by a maintainer
  4. Run the pipeline on pull request events targeting the protected branches Correct answer.

Explanation

Pull request events fire when changes are proposed, so checks gate review and merge. Scheduled, tag, and manual triggers either run too late or depend on human action.

Question 33Software Engineering

A pipeline script needs a value that differs per environment. Which approach keeps the pipeline definition environment-agnostic?

  1. Read the value from the developer's shell profile
  2. Inject the value as a parameter supplied by the environment's configuration Correct answer.
  3. Hardcode the value and edit the pipeline before each deployment
  4. Duplicate the entire pipeline file once per environment

Explanation

Parameterizing environment-specific values lets one reviewed pipeline serve every environment while configuration supplies the differences. Hardcoding, duplicating files, and shell profiles create drift and manual steps.

Question 34Software Engineering

A pipeline builds a container image and tags it with both a version and a mutable alias. Which tagging approach supports safe rollback to a known good build?

  1. Deploy by immutable digest or version tag and keep prior tags available in the registry Correct answer.
  2. Overwrite the version tag on every build so the registry stays small
  3. Tag every build with the current date only
  4. Deploy the mutable alias and rely on the registry to keep only the newest image

Explanation

Immutable tags or digests let a deployment reference an exact image that still exists, which is what rollback requires. Overwriting tags destroys the ability to return to a previous build.

Question 35Software Engineering

A pipeline runs unit tests, then a container build, then a deployment. The deployment step fails after the image was pushed. Which design limits the blast radius of that failure?

  1. Deploy to a staging environment first and require promotion after verification Correct answer.
  2. Retry the failed deployment step indefinitely
  3. Skip the unit tests to shorten the pipeline
  4. Push the image only after the deployment succeeds

Explanation

A staging gate verifies the image before production exposure, so a bad deployment fails where impact is contained. Infinite retries, skipped tests, and ordering image push after deploy all increase risk.

Question 36Software Engineering

A team wants to know whether a code change slowed the build. Which measurement supports that conclusion?

  1. Count the number of lines changed in the pull request
  2. Measure the developer's local build time
  3. Compare stage durations for the change against a baseline from recent successful builds Correct answer.
  4. Count the number of commits in the repository

Explanation

Stage duration compared against a recent baseline isolates the effect of the change on pipeline performance. Line counts, commit counts, and local timing do not reflect CI execution.

Question 37Software Engineering

A repository contains a Dockerfile that installs build tools and also runs the application. Which change reduces the runtime image attack surface?

  1. Disable the health check to reduce processes
  2. Use a multi-stage build so the runtime stage copies only the built artifact Correct answer.
  3. Add more build tools to the runtime stage for debugging
  4. Run the application as root to avoid permission errors

Explanation

Multi-stage builds separate compilation from runtime, so the shipped image contains only what execution needs. Extra tools, root execution, and removed health checks all increase risk.

Question 38Software Engineering

A pipeline must fail when a dependency introduces a known critical vulnerability. Which control enforces this?

  1. A comment in the pull request describing the dependency
  2. A dependency scan whose policy blocks the build on critical findings Correct answer.
  3. A manual review checklist item
  4. A weekly email report of scan results

Explanation

Only an automated policy that fails the build prevents the vulnerable dependency from being merged and deployed. Reports, checklists, and comments rely on human follow-through.

Question 39Software Engineering

A team wants the pipeline to publish a test report that reviewers can inspect even when the test stage fails. Which configuration is required?

  1. Mark the report step to always run and upload results regardless of test outcome Correct answer.
  2. Suppress test failures so the stage always succeeds
  3. Place the report step before the tests
  4. Store reports only on the runner's local disk

Explanation

Report upload must be unconditional so results survive a failing test stage and reach reviewers. Ordering, suppression, and local-only storage all defeat that purpose.

Question 40Software Engineering

Two services are deployed from the same repository. A change to one service triggers a full rebuild of both. Which improvement targets this inefficiency?

  1. Merge the services into a single deployable unit
  2. Increase the runner size for all jobs
  3. Detect which paths changed and run only the affected service's build and tests Correct answer.
  4. Run the full pipeline on a nightly schedule only

Explanation

Path-based change detection scopes work to the components actually modified, which cuts redundant builds while preserving coverage. Larger runners, merging services, and nightly-only runs do not address the redundant work.

Question 41Software Engineering

A pipeline needs to run a step only when a previous step failed, for example to collect diagnostics. Which construct expresses this?

  1. A pre-step hook that runs before any job
  2. A parallel job that always starts at pipeline creation
  3. A scheduled trigger on the pipeline
  4. A conditional execution clause that checks the prior step's failure status Correct answer.

Explanation

Conditional execution keyed to the previous step's outcome runs cleanup or diagnostics exactly on failure. Parallel jobs, pre-hooks, and schedules are not tied to prior step status.

Question 42Software Engineering

A team wants to prevent merging a pull request while any required check is still running. Which branch protection setting accomplishes this?

  1. Require status checks to pass before merging Correct answer.
  2. Enable automatic branch deletion after merge
  3. Require signed commits
  4. Restrict who can create tags

Explanation

Requiring status checks makes the merge button wait for the named checks to succeed. Signing, tag restrictions, and branch deletion govern other concerns and do not gate on check results.

Question 43Software Engineering

A pipeline caches build output between runs. After a dependency upgrade, builds intermittently use old compiled code. Which cache key strategy fixes this?

  1. Use a fixed key so the cache is always reused
  2. Key the cache on the runner's hostname
  3. Disable caching entirely for all jobs
  4. Include a hash of the dependency manifest and lockfile in the cache key Correct answer.

Explanation

Deriving the key from the dependency manifest and lockfile invalidates the cache whenever dependencies change, which prevents stale reuse. Fixed keys never invalidate, and disabling caching sacrifices legitimate speed.

Question 44Software Engineering

A deployment pipeline must stop automatically when error rates exceed a threshold shortly after release. Which mechanism implements this?

  1. Automated health checks that gate promotion and trigger rollback on breach Correct answer.
  2. A manual approval step before every release
  3. A dashboard that engineers check when they remember
  4. A post-incident review scheduled for the following week

Explanation

Automated health checks observe the deployed version and act on defined thresholds, which is what makes rollback timely. Reviews, dashboards, and approvals depend on human timing.

Question 45Software Engineering

A team wants infrastructure changes to be reviewed before they reach production. Which workflow achieves this?

  1. Run applies only during an on-call shift
  2. Open a pull request with the planned changes and require review plus a plan output Correct answer.
  3. Apply changes directly from an engineer's workstation
  4. Grant all engineers permanent production credentials

Explanation

Review of a proposed change together with the generated plan lets peers see the intended effect before it is applied. Direct applies and broad credentials bypass that control.

Question 46Software Engineering

A pipeline builds an image on an arm64 runner but production nodes are amd64. The deployment fails with an exec format error. What is the root cause?

  1. The image lacks a health check definition
  2. The deployment manifest omitted resource limits
  3. The image was built for a CPU architecture different from the target nodes Correct answer.
  4. The registry rejected the image tag format

Explanation

An exec format error indicates the binary's architecture does not match the host kernel's expectation. Building for the target platform or using a multi-architecture build resolves it; the other options cause different failures.

Question 47Software Engineering

A pipeline uses a shared cache across trusted and untrusted pull requests. Which risk does this create?

  1. The pipeline would lose the ability to run in parallel
  2. An untrusted change could poison the cache and influence later trusted builds Correct answer.
  3. The cache would grow too large to store
  4. Trusted builds would run slower than untrusted ones

Explanation

A shared cache is an input to later builds, so content written by an untrusted change can affect trusted executions. Isolating caches per trust level prevents this. Size, speed, and parallelism are not the security concern.

Question 48Software Engineering

A team wants to prove that a deployed artifact was produced by the pipeline from a specific commit, not rebuilt locally. Which practice provides that evidence?

  1. Store the artifact in a private bucket readable by the team
  2. Record the commit message in the deployment ticket
  3. Sign the artifact and its provenance attestation with a key the pipeline controls and verify at deploy time Correct answer.
  4. Compute a checksum and paste it into the wiki

Explanation

Signed provenance binds the artifact to the pipeline identity and source revision, and verification at deploy time rejects anything else. Private storage, tickets, and pasted checksums are not verifiable attestations.

Question 49Software Engineering

A pipeline runs a database migration job and an application rollout concurrently. The rollout starts before the migration finishes and errors occur. Which sequencing change resolves this?

  1. Remove the migration job and apply changes manually
  2. Make the rollout depend on successful completion of the migration job Correct answer.
  3. Run both steps in the same container to share state
  4. Run the migration after the rollout completes

Explanation

An explicit dependency forces the rollout to wait until the schema change succeeds, which is the required ordering. Running migrations later, sharing a container, or applying manually does not establish the dependency.

Question 50Software Engineering

A team wants to detect flaky tests rather than hide them. Which approach is most informative?

  1. Increase the global test timeout
  2. Re-run failed tests in isolation and record pass/fail history per test Correct answer.
  3. Run the suite only on the main branch
  4. Mark all failed tests as skipped

Explanation

Isolated re-runs distinguish nondeterministic failures from genuine ones, and per-test history quantifies flakiness. Skipping, extending timeouts, or narrowing where tests run conceals the signal.