DevOps Engineering Practices Flashcards

Question 1

What does the term DevOps mean in a software organization?

Accepted Answer

DevOps is a set of cultural practices, tools, and principles that bring software development and IT operations together so that teams can build, test, and release software faster and more reliably. It emphasizes shared ownership of the software lifecycle, from code to production monitoring, rather than handing work between separate groups.

Question 2

Why do silos between development and operations teams slow down software delivery?

Accepted Answer

Silos slow delivery because each group optimizes for its own goals and hands work across a wall. Developers are rewarded for shipping changes, while operators are rewarded for stability, so changes queue up at the handoff. Problems surface late, information gets lost, and blame moves between teams instead of being solved together.

Question 3

What is the CALMS framework, and what do its letters stand for?

Accepted Answer

CALMS is a widely taught summary of DevOps values. The letters stand for Culture, Automation, Lean, Measurement, and Sharing. Culture focuses on trust and shared goals, automation reduces manual work, lean limits waste and batch size, measurement drives decisions with data, and sharing spreads knowledge across teams.

Question 4

What is blameless postmortem culture and why does it matter?

Accepted Answer

A blameless postmortem is a review of an incident that focuses on how systems and processes allowed the failure, not on which person caused it. It matters because engineers who fear punishment hide mistakes, while open reviews reveal weak spots, produce concrete follow-up actions, and help the whole team learn from each outage.

Question 5

What is shared ownership, and how does it change who is responsible for a service?

Accepted Answer

Shared ownership means the team that builds a service also runs it, carries the pager, and answers for its quality in production. Responsibility does not end when code is merged. This model gives developers direct feedback about operational pain, which encourages them to design systems that are easier to deploy, observe, and recover.

Question 6

Why do small batch sizes reduce risk in software releases?

Accepted Answer

Small batches reduce risk because each release contains fewer changes, so it is easier to understand what changed and why something broke. Failures are isolated quickly, rollbacks are simpler, and reviews receive more attention. Large batches hide problems among many edits and make recovery slow and stressful for everyone involved.

Question 7

How does a team build a culture of experimentation safely?

Accepted Answer

A team builds safe experimentation by making small, reversible changes behind feature flags, agreeing on success measures before a trial begins, and treating failed experiments as useful information rather than personal failures. Leaders reinforce this by funding learning time and celebrating well-documented lessons, so people feel free to test ideas.

Question 8

What is psychological safety, and why do DevOps teams rely on it?

Accepted Answer

Psychological safety is a shared belief that a person can raise concerns, admit mistakes, or ask questions without being humiliated or punished. DevOps teams rely on it because fast delivery depends on people reporting problems early, challenging risky changes, and asking for help. Without it, warning signs stay hidden until they become outages.

Question 9

What does continuous integration mean for everyday developer workflow?

Accepted Answer

Continuous integration is the practice of merging every developer's changes into a shared mainline frequently, often several times a day, and verifying each merge with an automated build and test run. The goal is to detect integration conflicts and defects within minutes rather than days, when they are cheap to fix.

Question 10

Why is a fast automated build important in continuous integration?

Accepted Answer

A fast automated build gives developers feedback while the change is still fresh in their minds. Long pipelines discourage frequent commits, so people batch work and integration problems pile up. Keeping builds quick usually means caching dependencies, running tests in parallel, and splitting slow suites so that most feedback arrives within a few minutes.

Question 11

What should happen when a commit breaks the main branch?

Accepted Answer

The team should treat a broken main branch as the top priority and restore a green build quickly, usually by fixing the problem or reverting the offending change. The mainline must always remain releasable, so nobody builds new work on a broken foundation.

Question 12

What is trunk-based development and how does it support continuous integration?

Accepted Answer

Trunk-based development is a branching strategy in which developers commit small changes directly to one shared branch, or use very short-lived branches that merge within a day or two. It supports continuous integration because work is integrated constantly, so long-running branches cannot drift far from the main codebase and create painful merges.

Question 13

What are automated tests in a CI pipeline, and what layers are commonly used?

Accepted Answer

Automated tests in a CI pipeline are checks that run without human intervention to verify code behavior after each change. Common layers form a pyramid: many fast unit tests check individual functions, fewer integration tests check how components work together, and a small number of end-to-end tests exercise complete user journeys.

Question 14

Why should a pipeline build an artifact once and promote that same artifact through later stages?

Accepted Answer

Building once protects the team from a subtle risk: a rebuild for production can pull different dependency versions or introduce small compiler differences, so the tested code is not the code that ships. Promoting one immutable artifact through test, staging, and production keeps evidence tied to exactly what is deployed.

Question 15

How do feature flags help teams integrate unfinished work safely?

Accepted Answer

Feature flags let teams merge code that is incomplete or not yet ready for users by wrapping new behavior in a conditional switch that stays off in production. Flags can later be turned on for a small audience, and they can be removed once the feature is fully adopted.

Question 16

What is a code review gate, and how does automation strengthen it?

Accepted Answer

A code review gate is a required checkpoint, such as peer approval, that a change must pass before it can merge into the main branch. Automation strengthens the gate by running linters, security scanners, and tests before a human reviewer spends time on the change, so reviewers focus on design and logic.

Question 17

How do continuous delivery and continuous deployment differ?

Accepted Answer

Continuous delivery means every change that passes automated checks is kept in a releasable state and can be deployed to production, usually with a manual approval step. Continuous deployment goes one step further by releasing every passing change to production automatically, with no human gate between a passing build and live users.

Question 18

What stages does a typical deployment pipeline move a change through?

Accepted Answer

A typical deployment pipeline moves a change through a series of automated stages: build, unit and integration tests, packaging, deployment to a test environment, acceptance or security checks, and finally production. Each stage either passes the artifact forward or stops it with clear feedback, so only verified changes reach users.

Question 19

What is a canary release and when is it useful?

Accepted Answer

A canary release sends a small share of production traffic to the new version while most users stay on the current version. Teams compare error rates and latency between the two groups, then expand the rollout or roll back. It is useful when the risk of a change is uncertain.

Question 20

What is a blue-green deployment, and what advantage does it offer?

Accepted Answer

A blue-green deployment keeps two identical production environments, called blue and green. One serves live traffic while the other receives the new release, is tested, and then takes over traffic through a router switch. The main advantage is fast rollback, because traffic can return to the previous environment almost instantly.

Question 21

Why are database schema changes harder to deploy than application code changes?

Accepted Answer

Application code can be replaced in seconds, but a database holds state that outlives any release. A schema change that drops a column can break the old version during a rolling deployment. Teams use expand and contract migrations, adding new structures first and removing old ones only after all code has moved over.

Question 22

Why do deployment pipelines need rollback plans even when tests pass?

Accepted Answer

Passing tests show that code behaves as expected in test conditions, but production has traffic, data, and dependencies that tests cannot fully reproduce. A rollback plan defines how to restore the last known good version quickly if real users reveal a problem. Practicing that rollback beforehand makes it a routine action.

Question 23

How does a progressive rollout reduce the blast radius of a faulty release?

Accepted Answer

A progressive rollout exposes a release to increasing groups of users over time, such as one region, then a small percentage of servers, then everyone. If monitoring shows errors at any stage, the rollout pauses or reverts before most users are affected. Limiting the blast radius turns an outage into a contained incident.

Question 24

What are release gates, and what criteria might they check?

Accepted Answer

Release gates are automated or manual checkpoints that decide whether a build may move to the next environment or to production. Typical criteria include passing test suites, zero critical security findings, acceptable performance benchmarks, an approved change record, and a stable error budget. A gate should be fast and based on objective signals.

Question 25

What does it mean to manage infrastructure as code?

Accepted Answer

Managing infrastructure as code means describing servers, networks, load balancers, and other resources in version-controlled files instead of configuring them by hand. The files are read by tools that create or change resources to match the description. Because the definition is code, it can be reviewed, tested, reused, and rebuilt consistently.

Question 26

Why is a declarative approach often preferred for infrastructure definitions?

Accepted Answer

A declarative approach describes the desired end state, such as three web servers with a given version, and lets the tool work out the steps needed to reach it. This reduces errors from missing or out-of-order commands. Running the same definition again should produce the same result, which makes changes predictable and repeatable.

Question 27

What is idempotence, and why does it matter for automation scripts?

Accepted Answer

Idempotence means that running an operation several times produces the same final state as running it once. It matters for automation because pipelines retry steps after network failures and engineers rerun playbooks after partial failures. An idempotent script can be safely repeated without creating duplicate resources or breaking what already works.

Question 28

What is configuration drift, and how do teams prevent it?

Accepted Answer

Configuration drift is the difference between the configuration an environment should have and what it actually has, usually caused by manual changes. Teams prevent it by making version-controlled definitions the only path for changes, running checks that compare live systems with the desired state, and rebuilding servers rather than patching them by hand.

Question 29

How should secrets such as passwords and API keys be handled in configuration?

Accepted Answer

Secrets should never be stored in plain text in source control. Instead, teams keep them in a dedicated secrets manager or encrypted store, inject them into running workloads at deploy time, and rotate them regularly. Access is limited to the services and people that need it, and reads are recorded in an audit log.

Question 30

What is the purpose of a configuration management tool compared with a provisioning tool?

Accepted Answer

A provisioning tool creates infrastructure resources, such as virtual machines, networks, and databases, from a desired definition. A configuration management tool then sets up what runs inside those resources, including packages, files, services, and settings. Many teams use both, provisioning the platform first and configuring the software afterward.

Question 31

How can teams test infrastructure code before applying it to production?

Accepted Answer

Teams can validate infrastructure code with linters and formatters, run static analysis for policy violations, and apply changes to a disposable test environment. Plan or preview output shows the resources a change would create, modify, or delete, so reviewers can check it before anything runs. Tests can then confirm the environment behaves correctly.

Question 32

Why should infrastructure definitions be stored in the same version control system as application code?

Accepted Answer

Keeping infrastructure definitions beside application code creates one traceable history of how the system and its environment changed together. Reviewers can see which code release required which infrastructure change, and rollbacks can restore both consistently. It also lets the same review, branching, and approval practices apply to every change.

Question 33

What is observability, and how does it differ from basic monitoring?

Accepted Answer

Observability is the ability to understand a system's internal state by examining the data it emits, such as logs, metrics, and traces. Basic monitoring watches predefined indicators and alerts when a known threshold is crossed. Observability goes further by letting engineers ask new questions about unexpected behavior without shipping new instrumentation.

Question 34

What are the three commonly cited pillars of observability telemetry?

Accepted Answer

The three commonly cited pillars are logs, metrics, and traces. Logs are timestamped records of discrete events, metrics are numeric measurements aggregated over time, and traces follow a single request as it moves across services. Used together, they help teams see what happened, how often, and where time was spent.

Question 35

What is a service level indicator, and how does it differ from a service level objective?

Accepted Answer

An indicator is a measured quantity that reflects user experience, while an objective is the target that quantity should meet over a time window. For example, an indicator might be the share of requests that succeed, and the objective might set a success goal across a rolling period.

Question 36

What is an error budget and how do teams use it?

Accepted Answer

An error budget is the amount of unreliability a service may have over a period while still meeting its objective. Teams use it to balance feature work against stability: when the budget is healthy, they can ship faster, and when it is nearly spent, they slow releases and focus on reliability work.

Question 37

Why are alerts based on symptoms preferred over alerts based on causes?

Accepted Answer

Symptom alerts are preferred because they fire when users are affected, such as during elevated error rates or slow responses. Cause alerts, such as one busy host, may fire often without harming anyone, creating noise that trains people to ignore pages. Focusing on symptoms keeps paging meaningful and directs responders toward user-visible problems.

Question 38

What is an incident response process, and what roles help run it?

Accepted Answer

An incident response process is a repeatable way to detect, contain, communicate about, and resolve a production problem. Teams often assign an incident commander to coordinate decisions, a communications lead to update stakeholders, and technical responders to diagnose and fix the issue. Clear roles prevent duplicated effort and confusion during stressful outages.

Question 39

How do on-call rotations and runbooks support reliable operations?

Accepted Answer

On-call rotations spread operational responsibility across the team so that someone is able to respond to production alerts. Runbooks are written step-by-step guides for diagnosing and fixing known problems, which lets responders act quickly even when they did not build the system. Together they reduce response time and dependence on a few experts.

Question 40

How do teams decide which production metrics deserve dashboards and alerts?

Accepted Answer

Teams start by choosing metrics that reflect service health, such as latency, errors, traffic, and saturation, known as the four golden signals. They add resource measures only when they explain a symptom. Every dashboard panel and alert should answer a question someone asks during an investigation, so unused views should be removed.

DevOps Engineering Practices Flashcards

1Culture and Collaboration Foundations

2Continuous Integration Practices

3Continuous Delivery and Deployment

4Infrastructure as Code and Configuration

5Monitoring, Feedback and Reliability

Learning Resources