I85PREP
⌘ K
CDOS study materials
CDOS study resources

CDOS practice questions

One question at a time. Build your CDOS 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 1DevOps Foundations and Culture

In DevOps culture, what does the term 'blameless postmortem' primarily mean?

  1. A meeting where each engineer is asked to accept written responsibility for the outage
  2. A template that lists every employee who touched the affected service
  3. A review that focuses on system and process causes rather than punishing the individuals involved Correct answer.
  4. A report that is kept confidential and never shared outside the incident team

Explanation

A blameless postmortem assumes people act with good intent given the information and tools available, so the analysis targets systemic and process factors. Removing fear of punishment encourages honest disclosure, which yields more accurate root causes and better preventive actions.

Question 2DevOps Foundations and Culture

Which statement best describes the 'Three Ways' framing of DevOps from Gene Kim's work?

  1. Plan, build, and run as three sequential hand-off phases owned by separate teams
  2. Automate, containerize, and orchestrate every workload in the delivery pipeline
  3. Monitor, alert, and escalate as the three tiers of production support
  4. Systems thinking, amplified feedback loops, and a culture of continual experimentation and learning Correct answer.

Explanation

The Three Ways describe flow and systems thinking from dev to ops, fast and amplified feedback from right to left, and a culture of continual experimentation and learning. They are principles about how the whole value stream behaves, not a tool list or a phased hand-off model.

Question 3DevOps Foundations and Culture

A team has automated builds and tests but still waits two weeks for a separate operations group to schedule every production deployment. Which constraint most directly limits their delivery flow?

  1. The lack of unit test coverage in the build pipeline
  2. The absence of a shared definition of done across the team
  3. The manual hand-off and queue between development and operations Correct answer.
  4. The choice of branching strategy in version control

Explanation

Flow is constrained by the largest queue and hand-off in the value stream, and here that is the manual deployment gate owned by another group. Reducing that wait, for example through shared ownership or automated release, shortens lead time far more than tuning earlier stages that already run quickly.

Question 4DevOps Foundations and Culture

What is the main cultural purpose of holding regular, cross-functional incident retrospectives that include developers and operators?

  1. To satisfy an audit requirement that meetings took place
  2. To rank engineers by the number of incidents they caused
  3. To convert shared operational experience into agreed improvements to systems and process Correct answer.
  4. To determine which team should absorb the cost of the outage

Explanation

Cross-functional retrospectives bring the people who build and the people who run the service into one conversation, so operational insight feeds back into design and tooling. The output should be owned action items that change systems and process, not cost allocation or individual ranking.

Question 5DevOps Foundations and Culture

Which practice most directly shortens feedback time between writing code and learning whether it works in a production-like environment?

  1. Annual penetration testing by an external vendor
  2. Manual code review held once per sprint
  3. Quarterly release trains with a change freeze before each one
  4. Continuous integration that runs automated tests on every commit Correct answer.

Explanation

Continuous integration runs automated verification on each commit, so defects and integration problems surface in minutes rather than weeks. Shorter feedback loops let developers fix issues while context is fresh, which is a core DevOps goal.

Question 6DevOps Foundations and Culture

An organization wants engineers to be able to deploy on their own without a separate operations ticket. Which cultural and structural change best supports this?

  1. Moving all operators into a separate security group
  2. Requiring all production changes to be approved by a central change board
  3. Embedding operations responsibilities into product teams with self-service platforms Correct answer.
  4. Increasing the number of manual sign-off steps before release

Explanation

DevOps shifts operational responsibility to the teams that build the service and supports them with self-service platforms and guardrails. This removes the ticket queue while keeping safety through automation rather than manual gates.

Question 7DevOps Foundations and Culture

Which metric set is most associated with the DORA research on software delivery performance?

  1. CPU utilization, memory pressure, disk IOPS, and network latency
  2. Deployment frequency, lead time for changes, change failure rate, and time to restore service Correct answer.
  3. Headcount, budget spent, tickets closed, and hours billed
  4. Lines of code, number of commits, test count, and open pull requests

Explanation

DORA's delivery performance measures are throughput (deployment frequency and lead time for changes) and stability (change failure rate and time to restore service). Together they prevent optimizing speed while ignoring reliability or vice versa.

Question 8DevOps Foundations and Culture

A team's deployment frequency rises sharply while change failure rate also rises sharply. What does this pattern most likely indicate?

  1. The DORA metrics are being measured incorrectly and should be discarded
  2. Throughput improved without matching investment in testing and reliability safeguards Correct answer.
  3. The team has achieved elite delivery performance on all dimensions
  4. Deployment frequency is unrelated to stability and can be ignored

Explanation

DORA treats throughput and stability as a balanced pair, so faster deploys with more failures suggest safeguards such as automated testing, canaries, or rollback have not kept pace. The response is to strengthen verification and recovery, not to abandon measurement or assume elite status.

Question 9DevOps Foundations and Culture

What does 'shifting left' mean in the context of quality and security in a DevOps pipeline?

  1. Transferring all quality work to a downstream QA gate
  2. Performing testing, security review, and compliance checks earlier in the delivery lifecycle Correct answer.
  3. Delaying release decisions until the end of the quarter
  4. Moving production workloads to a secondary region

Explanation

Shifting left means addressing quality and security concerns as early as possible, ideally in code review and automated pipeline checks on every change. Finding problems earlier is cheaper and faster to fix than discovering them after release.

Question 10DevOps Foundations and Culture

Which behavior best demonstrates psychological safety within a DevOps team during an incident?

  1. Only the on-call lead is permitted to speak in the incident call
  2. Engineers openly report a mistake they made because they expect help rather than punishment Correct answer.
  3. Team members avoid mentioning risky changes to prevent blame
  4. Managers require a written apology before the incident channel is closed

Explanation

Psychological safety means people believe they can raise problems, admit errors, and ask for help without humiliation or retaliation. That openness surfaces information quickly during incidents and feeds accurate learning afterward.

Question 11DevOps Foundations and Culture

A platform team builds an internal self-service deployment tool so product teams can release without filing tickets. Which DevOps principle does this most directly embody?

  1. Treating the platform as a product that enables team autonomy Correct answer.
  2. Reducing deployment frequency to lower risk
  3. Centralizing all release decisions in one approval group
  4. Removing the need for any automated testing

Explanation

A self-service platform treats internal teams as customers and removes bottlenecks while preserving guardrails. This supports autonomy and fast flow instead of central approval queues.

Question 12DevOps Foundations and Culture

Which statement best captures the DevOps view of the relationship between culture and tooling?

  1. Tooling alone reliably produces collaboration regardless of organizational culture
  2. Culture is irrelevant once a CI/CD pipeline is in place
  3. Tooling should be avoided until culture is perfect
  4. Culture and tooling reinforce each other, and tools adopted without supportive culture often fail to change behavior Correct answer.

Explanation

Tools can enable or constrain behavior, but adoption succeeds when norms, incentives, and ownership support collaboration. Buying a pipeline without changing hand-offs or blame dynamics usually reproduces the old silos in new software.

Question 13DevOps Foundations and Culture

What is the primary purpose of a service-level objective (SLO) in an SRE-aligned DevOps organization?

  1. To guarantee that no incident will ever affect users
  2. To define a target level of reliability that guides engineering trade-offs and error budget policy Correct answer.
  3. To document the on-call rotation schedule
  4. To replace monitoring with manual inspection

Explanation

An SLO expresses a target reliability level for a service, and the error budget derived from it informs decisions about release velocity and reliability investment. It aligns teams on an acceptable target rather than an impossible goal of zero incidents.

Question 14DevOps Foundations and Culture

A team repeatedly exceeds its error budget for a service. According to common error budget policy, what should happen next?

  1. The team should remove the SLO so the budget no longer applies
  2. The team should ignore the budget because it is only advisory
  3. The team should immediately double deployment frequency to gather more data
  4. The team should pause or slow risky feature releases and prioritize reliability work until the budget recovers Correct answer.

Explanation

An error budget policy pre-agrees that when budget is exhausted, reliability work takes priority over new feature risk. This converts a vague argument about speed versus stability into a documented, predictable rule.

Question 15DevOps Foundations and Culture

Which practice best supports a culture of continuous learning in a DevOps organization?

  1. Restricting incident details to senior management only
  2. Publishing internal postmortems and running regular game days and blameless reviews Correct answer.
  3. Discouraging engineers from attending conferences or training
  4. Rewarding teams solely for the number of features shipped

Explanation

Shared postmortems, game days, and blameless reviews turn operational experience into organizational knowledge. Making learning visible and routine builds the generative culture associated with high delivery performance.

Question 16DevOps Foundations and Culture

A company reorganizes so that each product team owns its service from code through production operations, supported by a platform group. Which organizational pattern does this describe?

  1. A traditional centralized operations department
  2. A pure outsourcing arrangement
  3. A matrixed QA-only organization
  4. A cross-functional product team model with a platform enabling team Correct answer.

Explanation

This is the common DevOps topology in which stream-aligned product teams own build and run, while a platform team provides self-service capabilities. Ownership end to end shortens feedback and accountability loops.

Question 17DevOps Foundations and Culture

Why does DevOps culture emphasize small, frequent changes over large, infrequent releases?

  1. Small changes remove the need for code review
  2. Frequent changes eliminate the need for monitoring
  3. Large releases are always technically impossible to test
  4. Smaller changes reduce the risk per change and make failures easier to isolate and roll back Correct answer.

Explanation

Smaller batches limit the blast radius of any single change and make it easier to identify the cause of a failure and revert quickly. Frequent small releases also keep the pipeline exercised, so problems surface early.

Question 18DevOps Foundations and Culture

An engineer argues that because the team has a fast CI/CD pipeline, they no longer need to discuss incidents or run retrospectives. Which response best reflects DevOps culture?

  1. Disagree, because fast delivery increases the value of learning from failures to keep improving reliability Correct answer.
  2. Agree, because automation makes learning from incidents unnecessary
  3. Agree, because retrospectives only matter for teams with manual deployments
  4. Disagree, because retrospectives are required only by external auditors

Explanation

Automation speeds delivery but does not remove the need to learn from failures; frequent change makes fast, accurate feedback about incidents more valuable. Retrospectives convert those lessons into systemic improvements that keep reliability aligned with delivery speed.

Question 19DevOps Foundations and Culture

What does the term 'you build it, you run it' imply for a development team?

  1. The team that builds a service also carries operational responsibility for it Correct answer.
  2. Running the service is outsourced to a third party
  3. Developers hand the service to operations and take no further part
  4. Operations staff write all the application code

Explanation

The phrase captures end-to-end ownership: the team that writes the code also operates it and responds to its incidents. This tightens feedback between design decisions and real-world operational outcomes.

Question 20DevOps Foundations and Culture

Which combination best reflects a generative DevOps culture when a production incident occurs?

  1. Information is shared openly, messengers are not punished, and responsibility is accepted jointly Correct answer.
  2. Information is restricted, the reporter is questioned, and responsibility is assigned to one person
  3. Incidents are hidden until the next audit cycle
  4. Only contractors are held accountable for outages

Explanation

Generative culture is characterized by high cooperation, open information flow, and shared responsibility, so incidents become learning opportunities. Punishing messengers or hiding information suppresses the data needed to improve.

Question 21Source Code Management and Version Control

In Git, which command creates a new local branch named release-2.4 and immediately switches the working tree to it?

  1. git branch release-2.4
  2. git merge release-2.4
  3. git switch release-2.4
  4. git checkout -b release-2.4 Correct answer.

Explanation

The -b flag on git checkout creates the branch at the current HEAD and then checks it out in one step, updating the working tree. Plain git branch only creates the reference without switching, and git switch without -c expects an existing branch.

Question 22Source Code Management and Version Control

A developer wants to record which commit introduced a specific line in a source file. Which Git command shows the commit, author, and date for each line?

  1. git diff
  2. git blame Correct answer.
  3. git log --stat
  4. git show

Explanation

git blame annotates every line of a file with the commit hash, author, and timestamp of the last change to that line. It is the standard tool for tracing line-level provenance during defect investigation.

Question 23Source Code Management and Version Control

Which file in a Git repository defines path patterns that Git should ignore when reporting untracked files?

  1. .gitmodules
  2. .gitconfig
  3. .gitignore Correct answer.
  4. .gitattributes

Explanation

.gitignore holds glob patterns for files and directories that should remain untracked, such as build output or local secrets. It affects only untracked paths; already tracked files continue to be versioned.

Question 24Source Code Management and Version Control

What does a Git commit object primarily store?

  1. Only the textual diff against the previous commit
  2. A full copy of every file in the working directory
  3. A snapshot reference to a tree object plus parent commits, author, and message Correct answer.
  4. A list of remote tracking branches and their URLs

Explanation

A commit object points to a tree that captures the repository snapshot, references zero or more parent commits, and records author, committer, and message metadata. The content itself lives in tree and blob objects, which are shared and deduplicated.

Question 25Source Code Management and Version Control

In Subversion, what does a working copy revision number indicate?

  1. The number of local edits made since the last update
  2. The revision of the most recent commit made by the current user
  3. The number of branches created in the repository
  4. The highest repository revision from which any file in the working copy was updated Correct answer.

Explanation

An SVN working copy is a mix of per-file base revisions, and the reported working copy revision is the highest revision among those bases. It is not a count of edits or a per-user value.

Question 26Source Code Management and Version Control

Which practice best supports reproducible builds from a version-controlled repository?

  1. Using the latest available dependency versions at build time
  2. Committing compiled binaries alongside source
  3. Keeping build scripts outside version control on the build server
  4. Pinning dependency versions in a manifest and committing the lock file Correct answer.

Explanation

Lock files record exact resolved dependency versions so every checkout resolves the same graph, which is the foundation of reproducible builds. Build scripts and configuration must also be versioned so the build definition travels with the source.

Question 27Source Code Management and Version Control

A hotfix commit was accidentally made on main and must be moved onto a release branch while main is restored to its prior state. Which sequence accomplishes this with Git?

  1. git branch release from the hotfix, then git reset --hard on main to the previous commit
  2. git cherry-pick the hotfix onto release, then git reset --hard HEAD~1 on main Correct answer.
  3. git stash the hotfix, then git pull on release
  4. git revert on main, then git merge main into release

Explanation

Cherry-pick replays the hotfix commit onto the release branch, and resetting main to its parent removes the misplaced commit from main's history. This preserves the change where it belongs without rewriting the release branch.

Question 28Source Code Management and Version Control

Two developers edit the same function and push conflicting changes. After pulling, the merge stops with conflict markers. What is the correct next step?

  1. Force-push the local branch to overwrite the remote history
  2. Delete the conflicted file and re-clone the repository
  3. Run git checkout --ours on the file and push immediately without committing
  4. Edit the file to resolve the conflict, then git add the file and complete the merge Correct answer.

Explanation

Conflict markers delimit the competing hunks; the developer must edit to the intended final content, stage the resolved file with git add, and then commit to conclude the merge. Staging signals resolution, and the merge commit records the combined history.

Question 29Source Code Management and Version Control

What is the main advantage of git rebase over git merge when integrating a feature branch with main?

  1. It preserves the original commit hashes of the feature branch
  2. It produces a linear history by replaying feature commits onto the updated main Correct answer.
  3. It pushes the feature branch to the remote in a single step
  4. It automatically resolves all conflicts without human input

Explanation

Rebase rewrites each feature commit on top of the new base, yielding a linear sequence without a merge commit. The trade-off is that commit hashes change, so rebasing published shared branches is discouraged.

Question 30Source Code Management and Version Control

A team wants an unreviewed change to be blocked from entering main. Which mechanism enforces this on a hosted Git platform?

  1. A tag named protected-main pushed after each release
  2. Protected branch rules requiring pull request approval before merge Correct answer.
  3. A local pre-commit hook installed by each developer
  4. A .gitignore entry for the main branch

Explanation

Protected branch settings are enforced server-side, so they block direct pushes and require approvals regardless of local configuration. Local hooks can be bypassed or skipped and therefore cannot guarantee policy.

Question 31Source Code Management and Version Control

What does the git tag -a v1.2 -m "Release 1.2" command create?

  1. An annotated tag object storing a tagger, date, and message Correct answer.
  2. A remote ref that is automatically pushed
  3. A lightweight tag pointing directly at a commit with no metadata
  4. A new branch named v1.2

Explanation

The -a flag creates an annotated tag object that records the tagger identity, timestamp, and message alongside the target commit. Annotated tags are preferred for releases because they carry auditable metadata.

Question 32Source Code Management and Version Control

Which command shows the commit history for a single file, including commits that renamed it?

  1. git log --follow -- path/to/file Correct answer.
  2. git diff --cached -- path/to/file
  3. git ls-files -- path/to/file
  4. git status -- path/to/file

Explanation

git log --follow detects renames and continues history traversal across them for the specified path. Without --follow, history stops at the rename boundary.

Question 33Source Code Management and Version Control

A developer needs to undo a commit that has already been pushed to a shared branch. Which approach preserves shared history?

  1. git revert of the commit, creating a new inverse commit Correct answer.
  2. Deleting the branch on the remote and re-pushing
  3. git reset --hard HEAD~1 followed by a force-push
  4. git commit --amend followed by a force-push

Explanation

git revert creates a new commit that inverses the earlier change, so collaborators can fast-forward without history rewriting. Rewriting published history forces everyone to reconcile divergent branches.

Question 34Source Code Management and Version Control

In a trunk-based development model, what is the primary purpose of short-lived feature branches?

  1. To permanently separate teams' workstreams
  2. To replace continuous integration with scheduled nightly merges
  3. To store release binaries for long-term archival
  4. To isolate work briefly so it can be integrated into trunk within days Correct answer.

Explanation

Trunk-based development keeps branches short-lived so changes integrate into trunk frequently, reducing merge risk and enabling continuous integration. Long-lived divergent branches are explicitly avoided in this model.

Question 35Source Code Management and Version Control

What is the effect of storing large binary assets directly in a Git repository over many commits?

  1. Repository clone size grows because each version is stored as a distinct blob Correct answer.
  2. Git automatically deduplicates all binary versions into one blob
  3. History is truncated to keep only the latest binary version
  4. Binary files are converted to text and delta-compressed perfectly

Explanation

Git stores each distinct version of a binary as a separate blob, and binaries compress poorly, so history accumulates size. Teams often use Git LFS or external artifact stores to avoid bloating clones.

Question 36Source Code Management and Version Control

A CI pipeline must build the exact commit that triggered it. Which checkout configuration guarantees this?

  1. Fetching and checking out the specific commit SHA recorded in the pipeline event Correct answer.
  2. Using a shallow clone of any branch with depth one
  3. Checking out the latest tag in the repository
  4. Cloning the default branch tip at pipeline start

Explanation

Checking out the triggering commit SHA binds the build to the exact source state that produced the event. Relying on branch tips or tags can pick up later commits and produce non-reproducible artifacts.

Question 37Source Code Management and Version Control

A developer runs git stash, switches branches, and later wants to reapply the stashed changes while keeping them in the stash list. Which command should be used?

  1. git stash pop
  2. git stash branch
  3. git stash drop
  4. git stash apply Correct answer.

Explanation

git stash apply restores the stashed changes to the working tree while leaving the stash entry intact for later reuse. git stash pop restores and then removes the entry in one step.

Question 38Source Code Management and Version Control

A repository uses Git submodules. After cloning, the submodule directories are empty. Which command initializes and populates them?

  1. git fetch --all
  2. git checkout --recurse-submodules HEAD
  3. git remote update
  4. git submodule update --init --recursive Correct answer.

Explanation

git submodule update --init --recursive reads .gitmodules, clones missing submodules, and checks out the commits pinned by the superproject, recursing into nested submodules. A plain clone does not populate submodule working trees.

Question 39Source Code Management and Version Control

What does the git reflog record that git log does not?

  1. The contents of the index at each staging operation
  2. Only commits that were signed with a GPG key
  3. Local movements of HEAD and branch tips, including commits later removed from branch history Correct answer.
  4. Every commit reachable from all remote branches

Explanation

The reflog tracks local reference updates such as checkouts, resets, and rebases, so commits orphaned by a reset can often be recovered from it. git log follows reachable history only, so it will not show those orphaned commits.

Question 40Source Code Management and Version Control

A team adopts a branching model where main always reflects production and all changes reach it only through release branches created from a develop branch. Which consequence follows directly from this model?

  1. Hotfixes must be applied to main and back-merged into develop to avoid divergence Correct answer.
  2. Feature work is merged only after main is force-pushed
  3. Release branches are deleted before any testing occurs
  4. Developers commit directly to main for faster delivery

Explanation

When main is production-only and develop carries integration, a hotfix applied to main must be merged back into develop or the next release will reintroduce the defect. This back-merge discipline is the main ongoing cost of the model.

Question 41Continuous Integration and Continuous Delivery

In a CI pipeline, what is the primary purpose of a build artifact repository such as Nexus or Artifactory?

  1. To store immutable versioned build outputs so downstream stages consume the exact same binary Correct answer.
  2. To compile source code faster by caching compiler intermediate files across agents
  3. To run automated unit tests in parallel across build agents
  4. To host the Git remote that developers push feature branches into

Explanation

An artifact repository stores versioned, immutable binaries produced by the build so that test, staging, and production stages all promote the same bytes. This immutability is what makes a build once, deploy many times strategy trustworthy.

Question 42Continuous Integration and Continuous Delivery

A team wants every merge to the main branch to trigger an automated pipeline. Which mechanism implements this?

  1. A manual approval gate configured in the release stage
  2. A webhook from the Git server to the CI system on push events Correct answer.
  3. A polling interval set on the artifact repository
  4. A scheduled nightly cron job on the pipeline server

Explanation

Git servers emit webhooks on push or merge events, and the CI system reacts immediately by starting the pipeline. This event-driven trigger is the standard way to get fast feedback on every integration.

Question 43Continuous Integration and Continuous Delivery

What distinguishes continuous delivery from continuous deployment?

  1. Continuous delivery uses Git; continuous deployment uses configuration management
  2. Continuous delivery applies to containers; continuous deployment applies to virtual machines
  3. Continuous delivery requires manual approval before production release; continuous deployment releases automatically Correct answer.
  4. Continuous delivery only builds artifacts; continuous deployment also runs tests

Explanation

Both practices keep the main branch always releasable, but continuous delivery stops at a human approval before production while continuous deployment promotes automatically when all gates pass. The distinction is the final production gate, not the tooling.

Question 44Continuous Integration and Continuous Delivery

Which practice most directly reduces the integration pain described by the phrase integration hell?

  1. Freezing the main branch during the final weeks before a release
  2. Committing to a shared mainline at least daily with automated build and test on each change Correct answer.
  3. Running long-lived release branches that merge once per quarter
  4. Requiring each developer to maintain a private fork of the repository

Explanation

Frequent small integrations into a shared mainline with automated verification surface conflicts early when they are cheap to fix. Long gaps between merges recreate the large, risky integration events CI is designed to avoid.

Question 45Continuous Integration and Continuous Delivery

In a declarative pipeline, what is the role of a stage block?

  1. It declares the container image used by every agent in the pipeline
  2. It defines a logical phase of work that groups related steps and reports status Correct answer.
  3. It specifies the cron schedule that triggers the pipeline
  4. It stores credentials that steps can reference at runtime

Explanation

A stage is a named logical grouping of steps that gives structure and visible status to the pipeline. Grouping steps into stages makes failures easy to locate and enables stage-level policies such as approvals.

Question 46Continuous Integration and Continuous Delivery

Why should pipeline definitions be stored in the same repository as the application code?

  1. It guarantees the pipeline runs faster than an externally hosted definition
  2. It prevents developers from editing the pipeline file
  3. It lets pipeline changes be reviewed, versioned, and rolled back alongside code changes Correct answer.
  4. It removes the need for any credentials in the pipeline

Explanation

Keeping pipeline-as-code in the application repository subjects it to the same review, history, and rollback controls as the code it builds. This keeps build logic and application logic in sync at every commit.

Question 47Continuous Integration and Continuous Delivery

A deployment must be reversible within minutes if error rates spike. Which practice supports this requirement?

  1. Requiring a full regression cycle after every deployment
  2. Keeping the previous release artifact available for rollback Correct answer.
  3. Disabling health checks during the deployment window
  4. Deploying directly to all production servers at once

Explanation

Rollback depends on the prior known-good artifact still being available and deployable, which is why artifacts must be retained and versioned. Fast reversal is a property of the release process, not of post-deployment testing.

Question 48Continuous Integration and Continuous Delivery

What is the main benefit of running unit tests before integration tests in a pipeline?

  1. Integration tests cannot run in parallel with anything
  2. Unit tests exercise the database schema more thoroughly
  3. Unit tests require production credentials to run
  4. Fast failures give developers feedback in minutes instead of waiting for slow suites Correct answer.

Explanation

Ordering the fastest, cheapest checks first means broken changes fail quickly and do not consume resources on slower suites. This fail-fast ordering shortens feedback time and reduces wasted compute.

Question 49Continuous Integration and Continuous Delivery

A pipeline runs on a shared agent and leaves behind files from a previous job, causing intermittent failures. Which fix addresses the root cause?

  1. Run each job in a clean workspace or ephemeral container Correct answer.
  2. Move the failing tests to a nightly schedule
  3. Increase the pipeline timeout so retries have more time
  4. Add a manual approval before the test stage

Explanation

Intermittent failures caused by leftover state indicate workspace contamination, so each job needs an isolated, clean environment. Ephemeral agents or explicit workspace cleanup guarantee reproducible starting conditions.

Question 50Continuous Integration and Continuous Delivery

A team wants a failed integration test to block merging into main. Which configuration achieves this?

  1. Marking the test stage as optional in the pipeline
  2. Sending pipeline failure notifications to a chat channel
  3. Archiving test reports as build artifacts
  4. Making the pipeline status check a required check in branch protection Correct answer.

Explanation

Branch protection rules that require a passing status check prevent merges until the pipeline succeeds. Notifications and reports inform people but do not enforce a gate.