I85PREP
⌘ K
ca-fdops study materials
ca-fdops study resources

ca-fdops practice questions

One question at a time. Build your ca-fdops 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 Culture, Principles, and Practices

Which DevOps principle emphasizes breaking large work into small batches that flow quickly through the delivery pipeline?

  1. Centralization
  2. Immutability
  3. Flow Correct answer.
  4. Standardization

Explanation

The First Way of DevOps is flow, which focuses on optimizing the delivery of work from development through operations by reducing batch sizes and limiting work in progress. Small batches shorten feedback loops and expose problems earlier.

Question 2DevOps Culture, Principles, and Practices

A team wants fast, actionable feedback from production so defects are detected quickly. Which DevOps principle does this most directly reflect?

  1. The Second Way: amplify feedback loops Correct answer.
  2. The First Way: flow
  3. The Third Way: continuous experimentation
  4. Separation of duties

Explanation

The Second Way is about creating short, amplified feedback loops so that problems surface rapidly and can be corrected. It complements flow by ensuring information travels back from operations to development.

Question 3DevOps Culture, Principles, and Practices

Which practice best supports the Third Way principle of continuous experimentation and learning?

  1. Restricting engineers to a single specialty
  2. Running blameless post-incident reviews Correct answer.
  3. Freezing the production environment after launch
  4. Enforcing approval gates before each release

Explanation

The Third Way encourages a culture of experimentation and learning from failure, and blameless post-incident reviews turn outages into shared knowledge. Blame-free analysis increases the chance that people report and fix underlying causes.

Question 4DevOps Culture, Principles, and Practices

What is the primary purpose of a blameless postmortem?

  1. To identify systemic causes and prevent recurrence Correct answer.
  2. To satisfy an auditor's documentation requirement
  3. To rank teams by their reliability scores
  4. To determine which engineer should be disciplined

Explanation

A blameless postmortem assumes people act with good intent given the information available and focuses on systemic causes such as tooling, process, and design. The goal is learning and prevention rather than punishment.

Question 5DevOps Culture, Principles, and Practices

Which statement best describes the DevOps concept of a cross-functional team?

  1. A team that hands code to a separate operations group
  2. A team organized strictly by technical layer
  3. A team that owns a service from code through production operation Correct answer.
  4. A team that only performs testing before release

Explanation

Cross-functional teams combine the skills needed to build, deploy, and operate a service, which reduces handoffs and shortens feedback loops. Ownership extending into production is a defining trait of this model.

Question 6DevOps Culture, Principles, and Practices

What does the CALMS framework use the letter M to represent?

  1. Maintenance
  2. Measurement Correct answer.
  3. Migration
  4. Maturity

Explanation

CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. Measurement refers to using data such as lead time and error rates to guide improvement.

Question 7DevOps Culture, Principles, and Practices

A manager asks what value stream mapping contributes to a DevOps transformation. What is the most accurate answer?

  1. It defines the organization's salary structure
  2. It exposes wait times and handoffs that delay delivery Correct answer.
  3. It replaces the need for automated testing
  4. It guarantees that deployments will never fail

Explanation

Value stream mapping traces work from request to customer delivery and highlights where time is spent waiting rather than adding value. Those wait states and handoffs are the usual targets for improvement.

Question 8DevOps Culture, Principles, and Practices

Which metric measures the elapsed time from code commit to that code running in production?

  1. Mean time to restore
  2. Test coverage
  3. Deployment lead time Correct answer.
  4. Change failure rate

Explanation

Lead time for changes measures how long a committed change takes to reach production, making it a core delivery-performance indicator. It captures the whole path including review and pipeline duration.

Question 9DevOps Culture, Principles, and Practices

An organization deploys frequently but a high share of releases require hotfixes or rollback. Which DORA metric is most directly signaling the problem?

  1. Throughput
  2. Lead time for changes
  3. Deployment frequency
  4. Change failure rate Correct answer.

Explanation

Change failure rate is the percentage of deployments that cause degraded service and require remediation such as a hotfix or rollback. A high value indicates quality or testing gaps even when deployment frequency is strong.

Question 10DevOps Culture, Principles, and Practices

What distinguishes continuous delivery from continuous deployment?

  1. Continuous delivery uses feature flags; continuous deployment forbids them
  2. Continuous delivery keeps releases deployable on demand; continuous deployment releases automatically Correct answer.
  3. Continuous delivery requires manual testing; continuous deployment eliminates testing
  4. Continuous delivery applies only to mobile apps; continuous deployment applies to web apps

Explanation

Continuous delivery ensures every change is production-ready and can be released at any time, often with a business decision gating the release. Continuous deployment removes that manual gate and sends every passing change to production automatically.

Question 11DevOps Culture, Principles, and Practices

A team adopts trunk-based development. Which behavior is most consistent with that practice?

  1. Merging small changes to the mainline at least daily Correct answer.
  2. Maintaining a long-lived branch per feature for months
  3. Keeping integration until the end of a release cycle
  4. Requiring a release branch for every developer

Explanation

Trunk-based development keeps a single shared mainline and integrates small changes frequently, commonly at least daily. Short-lived branches reduce merge conflicts and keep the codebase continuously integrable.

Question 12DevOps Culture, Principles, and Practices

Why does DevOps culture favor small, frequent commits over large infrequent merges?

  1. They guarantee that no merge conflicts can occur
  2. They reduce integration risk and make defects easier to isolate Correct answer.
  3. They eliminate the need for version control
  4. They remove the requirement for code review

Explanation

Smaller changes are easier to review, test, and roll back, and when a defect appears the suspect set of changes is narrow. Frequent integration also surfaces conflicts early while they are cheap to resolve.

Question 13DevOps Culture, Principles, and Practices

Which outcome is the clearest evidence that a blameless culture is working?

  1. Managers personally approve every incident write-up
  2. Incident reports omit root causes to avoid blame
  3. Postmortems are skipped when the cause seems obvious
  4. Engineers report near-misses and defects without fear Correct answer.

Explanation

In a blameless culture people surface problems early because they expect analysis rather than punishment. Voluntary reporting of near-misses is a strong leading indicator of psychological safety.

Question 14DevOps Culture, Principles, and Practices

What is the main cultural risk of tying individual performance reviews directly to deployment counts?

  1. Stronger alignment with customer value
  2. Improved collaboration across teams
  3. Gaming the metric at the expense of real outcomes Correct answer.
  4. Faster detection of production defects

Explanation

When a single output metric becomes a personal target, people optimize for the number rather than for customer or reliability outcomes. This can produce trivial deployments, hidden failures, or reduced cooperation.

Question 15DevOps Culture, Principles, and Practices

An organization wants to reduce handoffs between development and operations. Which structural change aligns best with DevOps principles?

  1. Increasing the number of specialist approval roles
  2. Requiring written sign-off between each stage
  3. Forming service teams that build and run their own systems Correct answer.
  4. Adding a formal change advisory board for every release

Explanation

Teams that build and operate their own services internalize operational concerns and eliminate handoff delays. Ownership of the full lifecycle is a core structural expression of DevOps.

Question 16DevOps Culture, Principles, and Practices

Which practice most directly supports the DevOps goal of making infrastructure changes repeatable and auditable?

  1. Defining infrastructure as versioned code Correct answer.
  2. Granting standing administrator access
  3. Documenting changes in email threads
  4. Configuring servers manually by runbook

Explanation

Infrastructure as code stores environment definitions in version control, so changes are reviewable, repeatable, and reproducible. This replaces drift-prone manual configuration with an auditable record.

Question 17DevOps Culture, Principles, and Practices

A leader wants to introduce DevOps practices in a heavily siloed enterprise. Which first step is most consistent with DevOps transformation guidance?

  1. Purchase tooling before defining any outcomes
  2. Start with a small pilot team and share results Correct answer.
  3. Outsource all operations work immediately
  4. Mandate a full reorganization in one weekend

Explanation

Effective transformations usually begin with a bounded pilot that demonstrates measurable improvement, then spread through visible results and internal champions. This reduces risk and builds credibility before broad change.

Question 18DevOps Culture, Principles, and Practices

Which pair of practices best illustrates the DevOps value of amplifying feedback?

  1. Long-lived feature branches and infrequent releases
  2. Separate QA and operations departments
  3. Manual quarterly reviews and annual audits
  4. Automated tests in the pipeline and production monitoring alerts Correct answer.

Explanation

Automated tests give fast feedback before release while production monitoring closes the loop after deployment. Together they shorten the time between a mistake and its detection.

Question 19DevOps Culture, Principles, and Practices

A team claims to practice continuous integration but merges all feature branches only at release time. What is the best assessment?

  1. They are batching integration and not practicing continuous integration Correct answer.
  2. They have eliminated integration risk
  3. They are practicing continuous deployment instead
  4. They have achieved trunk-based development

Explanation

Continuous integration requires developers to integrate into a shared mainline frequently, with automated builds and tests verifying each integration. Deferring merges to release time is batch integration and defeats the practice's purpose.

Question 20DevOps Culture, Principles, and Practices

A team lowers its change failure rate by adding more manual approvals, but lead time rises sharply. How should a DevOps practitioner interpret this trade-off?

  1. Manual approvals should be expanded to every change
  2. The trade-off is optimal because reliability always requires slower delivery
  3. Lead time is irrelevant once failure rate improves
  4. Approvals treat a symptom while flow suffers; invest in automated verification instead Correct answer.

Explanation

DevOps seeks to improve speed and stability together, typically through automated testing, progressive delivery, and observability rather than gatekeeping. Adding approvals may mask quality problems while lengthening feedback and delivery time.

Question 21DevOps Culture, Principles, and Practices

Why can a metric like lines of code changed per developer be a poor indicator of DevOps performance?

  1. It always correlates perfectly with reliability
  2. It is impossible to collect with modern tooling
  3. It measures activity rather than delivered customer outcomes Correct answer.
  4. It directly measures mean time to restore

Explanation

Activity metrics reward volume rather than the outcomes DevOps cares about, such as faster flow and lower failure rates. They can also be gamed and may penalize valuable work like deletion or simplification.

Question 22DevOps Culture, Principles, and Practices

An incident occurs after a change that passed all automated tests. What does a mature DevOps learning culture most likely do next?

  1. Revert the change and close the incident without review
  2. Restrict future deployments to quarterly windows
  3. Examine why the tests missed the condition and add coverage Correct answer.
  4. Identify the author and require additional sign-off

Explanation

A learning culture treats the gap between test coverage and production behavior as a systemic improvement opportunity. Strengthening tests and observability reduces the chance of recurrence more reliably than restricting delivery or blaming individuals.

Question 23DevOps Culture, Principles, and Practices

A regulated firm must retain evidence of who approved each production change while still deploying daily. Which approach best reconciles compliance with DevOps flow?

  1. Automate approvals as policy checks recorded in the pipeline Correct answer.
  2. Disable audit logging to speed up deployments
  3. Move approvals to after deployment completes
  4. Require a weekly committee meeting for all changes

Explanation

Encoding approval policy as automated, logged checks preserves an auditable trail while avoiding human queue time. The evidence is generated continuously and attached to each change rather than collected in batch meetings.

Question 24DevOps Culture, Principles, and Practices

Which scenario best demonstrates the Third Way practice of shortening and amplifying feedback from operations back to development?

  1. Operations files defects only during annual planning
  2. Operations shares production error trends with developers each sprint for backlog prioritization Correct answer.
  3. Leadership reviews deployment counts once a year
  4. Developers write code and never review production dashboards

Explanation

The Third Way includes creating feedback from the right side of the delivery flow back to the left so that operational insight shapes future work. Regular sharing of error trends turns production data into prioritized improvements.

Question 25Version Control and Collaborative Workflows

In Git, which command creates a new branch and immediately switches to it in a single step?

  1. git checkout -b new-feature Correct answer.
  2. git branch new-feature
  3. git merge new-feature
  4. git remote add new-feature

Explanation

The checkout command with the -b flag both creates the named branch and moves HEAD onto it, so the working tree follows the new branch right away. The newer switch command offers the same behavior with the -c flag. Plain branch creation only makes the reference without changing where you are.

Question 26Version Control and Collaborative Workflows

What does a Git commit primarily record?

  1. A list of every file the developer edited that day
  2. A snapshot of the staged tree plus metadata and parent pointers Correct answer.
  3. A copy of the remote server's current state
  4. A diff that is applied to the remote on the next fetch

Explanation

A commit object stores a pointer to a tree object representing the full staged snapshot, along with author, committer, message, and references to parent commits. Git does not store per-file edit logs as the commit's identity. Diffs are computed later by comparing snapshots.

Question 27Version Control and Collaborative Workflows

A developer wants to see which commits exist on a feature branch but not yet on main. Which command shows exactly that set?

  1. git log --all
  2. git log feature..main
  3. git log main..feature Correct answer.
  4. git diff main

Explanation

The two-dot range A..B lists commits reachable from B but not from A, so main..feature shows work unique to the feature branch. Reversing the operands shows commits unique to main instead. The diff command compares working content rather than enumerating commits.

Question 28Version Control and Collaborative Workflows

What is the effect of running git fetch origin compared with git pull origin main?

  1. fetch deletes stale local branches; pull keeps them
  2. fetch updates remote-tracking refs without touching the current branch; pull also integrates into it Correct answer.
  3. fetch pushes local commits; pull retrieves remote commits
  4. fetch merges the remote branch into the working tree; pull only downloads objects

Explanation

Fetch downloads new objects and updates remote-tracking references such as origin/main, leaving your checked-out branch untouched. Pull performs a fetch and then integrates the upstream branch, by default with a merge or rebase depending on configuration. This distinction lets you inspect incoming changes before integrating them.

Question 29Version Control and Collaborative Workflows

During a merge, Git reports conflicts in two files. What is the correct next step after manually resolving the file contents?

  1. Stage the resolved files with git add, then commit the merge Correct answer.
  2. Delete the conflicted files and re-clone the repository
  3. Run git commit immediately without staging
  4. Run git merge --abort to finish the merge

Explanation

A conflicted merge pauses with conflict markers in the working tree. After editing the files to the desired content, you mark them resolved by staging them, then complete the merge with a commit. Aborting discards the merge entirely rather than finishing it.

Question 30Version Control and Collaborative Workflows

Which statement best describes a fast-forward merge?

  1. It creates a merge commit with two parents
  2. It moves the target branch pointer forward when no divergent commits exist Correct answer.
  3. It squashes all feature commits into one
  4. It always requires manual conflict resolution

Explanation

When the target branch has no commits that the source branch lacks, Git can simply advance the branch pointer to the source commit. No new merge commit is needed because history remains linear. Divergence is what forces a true merge commit or a rebase.

Question 31Version Control and Collaborative Workflows

A team wants each pull request reviewed by at least one other engineer before changes reach the protected main branch. Which mechanism enforces this?

  1. Branch protection rules requiring approvals Correct answer.
  2. A .gitignore entry for main
  3. A pre-commit hook installed locally
  4. Signed commits with GPG keys

Explanation

Branch protection settings on the hosting platform can require a minimum number of approving reviews and block direct pushes to the protected branch. Local hooks run only on the developer's machine and can be bypassed. Ignore files and signing affect different concerns.

Question 32Version Control and Collaborative Workflows

What is the primary purpose of a pull request in a collaborative workflow?

  1. To copy a repository to a personal account
  2. To run the test suite on every commit automatically
  3. To permanently lock a branch from further edits
  4. To propose, discuss, and review changes before merging Correct answer.

Explanation

A pull request is a review artifact that presents a branch's changes, hosts discussion and approval, and gates the merge. Copying a repository is forking, which is a separate action. Automated testing may be attached to a pull request but is not its purpose.

Question 33Version Control and Collaborative Workflows

A developer runs git rebase main while on a feature branch. What happens to the feature commits?

  1. They are merged into main with a merge commit
  2. They are deleted and replaced by main's history
  3. They are replayed onto the tip of main as new commits Correct answer.
  4. They are pushed to the remote automatically

Explanation

Rebase finds the common ancestor, takes the commits unique to the feature branch, and reapplies them one by one on top of the target branch. Because the parent changes, each replayed commit gets a new hash. The original commits remain reachable only through reflog or backup refs until garbage collection.

Question 34Version Control and Collaborative Workflows

Why is rewriting history on a shared branch with rebase considered risky?

  1. It permanently deletes the repository's remote configuration
  2. It disables future merges on that branch
  3. It converts all commits into annotated tags
  4. It changes commit hashes, forcing collaborators to reconcile diverged histories Correct answer.

Explanation

Rebase replaces commits with new ones that have different hashes, so anyone who based work on the old commits now has a diverged history. Pulling then requires careful reconciliation, often with a forced update. For this reason teams reserve rebasing for private branches.

Question 35Version Control and Collaborative Workflows

What does git cherry-pick abc123 do?

  1. Applies the changes introduced by commit abc123 onto the current branch Correct answer.
  2. Merges all commits from abc123's branch
  3. Reverts commit abc123 on its original branch
  4. Moves the current branch pointer to abc123

Explanation

Cherry-pick takes the patch introduced by the named commit and applies it as a new commit on the current branch. It does not bring along the commit's ancestors or affect the source branch. This is useful for porting a single fix without merging an entire branch.

Question 36Version Control and Collaborative Workflows

Which git command stages only specific hunks of a modified file for the next commit?

  1. git stash pop
  2. git checkout -- .
  3. git commit -a
  4. git add -p Correct answer.

Explanation

The patch mode of add interactively presents each hunk and lets you choose whether to stage it. This supports crafting focused commits from a file containing unrelated changes. Commit -a stages all tracked modifications at once, and checkout -- . discards working changes.

Question 37Version Control and Collaborative Workflows

A developer wants to temporarily set aside uncommitted work to switch branches, then reapply it later. Which pair of commands fits?

  1. git clean -fd, then git fetch
  2. git commit --amend, then git revert
  3. git stash, then git stash pop Correct answer.
  4. git reset --hard, then git reflog

Explanation

Stash saves dirty working-tree and index changes on a stack and restores a clean state so you can switch context. Later, stash pop reapplies the saved changes and removes the entry. Reset --hard and clean discard work rather than preserving it.

Question 38Version Control and Collaborative Workflows

In a forking workflow, how does a contributor typically propose changes to a project they cannot push to directly?

  1. Email a patch file to the maintainers only
  2. Push a branch to their fork and open a pull request against the upstream repository Correct answer.
  3. Clone the upstream repository into a new organization
  4. Commit directly to the upstream main branch

Explanation

Contributors without write access fork the repository, push a topic branch to their own copy, and open a pull request targeting the upstream project. Maintainers then review and merge. Direct pushes to upstream main are exactly what lack of access prevents.

Question 39Version Control and Collaborative Workflows

What does the HEAD reference point to in a Git repository?

  1. The currently checked-out commit or branch Correct answer.
  2. The oldest commit in history
  3. The most recent tag created
  4. The remote's default branch

Explanation

HEAD is a symbolic reference indicating where you currently are, usually pointing to a branch that in turn points to a commit. In detached HEAD state it points directly to a commit. It is not related to tags, remotes, or the root commit.

Question 40Version Control and Collaborative Workflows

A commit was pushed to a shared branch and later found to introduce a bug. Which command creates a new commit that undoes its changes while preserving history?

  1. git rebase -i <commit>
  2. git branch -d <commit>
  3. git reset --hard <commit>
  4. git revert <commit> Correct answer.

Explanation

Revert computes the inverse of the target commit and records it as a new commit, so shared history stays intact and other collaborators are unaffected. Reset rewrites the branch pointer and is unsafe on shared branches. Rebase rewrites history rather than recording an undo.

Question 41Version Control and Collaborative Workflows

What information does git blame typically show for each line of a file?

  1. The size of the file at each commit
  2. The last commit and author that modified that line Correct answer.
  3. The branch protection status of the file
  4. The number of times the file was merged

Explanation

Blame annotates each line with the commit that most recently changed it, along with author and date. This helps trace the origin of a change. It does not report merge counts, protection state, or file sizes.

Question 42Version Control and Collaborative Workflows

A developer accidentally commits a large binary file and wants to remove it from the most recent local commit before pushing. Which approach is appropriate?

  1. Amend the commit after unstaging the file Correct answer.
  2. Create a tag pointing at the previous commit
  3. Add the file to .gitignore and push
  4. Run git fetch --prune

Explanation

Because the commit has not been shared, amending lets you replace it with a corrected version that excludes the file. The file must first be removed from the index so the new snapshot omits it. Ignoring a file does not remove it from commits that already contain it.

Question 43Version Control and Collaborative Workflows

Which file is used to declare patterns for files that should remain untracked in a repository?

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

Explanation

The .gitignore file lists path patterns that Git should skip when reporting untracked files. It does not affect files already tracked. The other files configure attributes, submodules, and review ownership respectively.

Question 44Version Control and Collaborative Workflows

A team uses a trunk-based model with short-lived branches. Which practice best supports this model?

  1. Maintaining long-running release branches per developer
  2. Avoiding automated tests to speed up merges
  3. Keeping branches small and merging frequently behind automated checks Correct answer.
  4. Requiring manual merges only at quarter end

Explanation

Trunk-based development relies on small, frequent integrations to minimize divergence and merge pain, backed by automated checks that keep the trunk healthy. Long-lived branches increase conflict risk and delay feedback. Manual, infrequent merges run counter to the model.

Question 45Version Control and Collaborative Workflows

What does git tag -a v1.0 -m "release" create?

  1. A lightweight tag that is only a ref
  2. A new branch named v1.0
  3. A remote-tracking reference
  4. An annotated tag object storing a message and tagger Correct answer.

Explanation

The -a flag creates an annotated tag, which is a full object containing the tagger, date, and message, and it can be signed. Without -a, Git creates a lightweight tag that is merely a pointer. Tags are not branches and are not remote-tracking refs.

Question 46Version Control and Collaborative Workflows

A merge conflict arises because two branches edited the same lines of a configuration file. What does Git place in the working copy to help resolve it?

  1. Conflict markers delimiting the two versions Correct answer.
  2. A compiled binary of both versions
  3. A reference to the remote's copy of the file
  4. An automatic resolution chosen by the last committer

Explanation

Git inserts markers such as <<<<<<<, =======, and >>>>>>> around the competing sections so the developer can choose or combine content. It does not pick a winner automatically. After editing, staging the file marks the conflict resolved.

Question 47Version Control and Collaborative Workflows

A developer wants to combine several commits on a feature branch into one before merging, without changing the final tree content. Which command supports this interactively?

  1. git fetch --all
  2. git merge --no-ff <base>
  3. git diff <base>
  4. git rebase -i <base> Correct answer.

Explanation

Interactive rebase presents a commit list where actions such as squash or fixup combine commits, producing a cleaner history while preserving the resulting content. A no-ff merge creates a merge commit instead of squashing. Fetch and diff do not rewrite commits.

Question 48Version Control and Collaborative Workflows

In a code review, a reviewer requests changes on a pull request. What is the most effective next action for the author?

  1. Merge the pull request immediately to save time
  2. Force-push a rewritten history without explanation
  3. Close the pull request and open an unrelated one
  4. Push additional commits addressing the feedback to the same branch Correct answer.

Explanation

Adding commits to the source branch updates the open pull request, keeps the discussion context, and lets reviewers see the incremental response. Closing and reopening loses continuity. Merging before addressing feedback defeats the review gate.

Question 49Continuous Integration and Build Automation

In a CI pipeline, what is the primary purpose of a build artifact?

  1. To store the developer's local uncommitted changes for later inspection
  2. To act as a backup of the build agent's operating system
  3. To replace the need for version control branching
  4. To serve as a reusable output of a build that downstream stages or deployments can consume Correct answer.

Explanation

A build artifact is the durable, versioned output produced by a build job, such as a compiled binary, package, or container image. Persisting it lets later pipeline stages and deployments consume exactly the same bytes that were tested, which improves reproducibility and traceability.

Question 50Continuous Integration and Build Automation

Which practice most directly reduces the time a developer waits to learn that a commit broke the build?

  1. Triggering the pipeline automatically on every push to the main branch Correct answer.
  2. Increasing the number of parallel deployment environments
  3. Requiring manual approval before any build starts
  4. Running the full regression suite only nightly

Explanation

Automatic triggering on each push gives fast feedback so a broken change is identified close to when it was introduced. Nightly-only runs delay detection, and manual gates add latency rather than reducing it.