IBM DevOps and Software Engineering study materials
IBM DevOps and Software Engineering study resources

IBM DevOps and Software Engineering flashcards

IBM DevOps and Software Engineering · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

DevOps definition
A collaborative culture and set of practices that unify software development and IT operations to deliver applications and services faster, with higher quality and greater reliability.
CALMS framework
A model for evaluating DevOps maturity across five areas: Culture, Automation, Lean, Measurement, and Sharing. It emphasizes people and process alongside tooling.
Three Ways of DevOps
The principles of flow (left-to-right delivery), feedback (right-to-left amplification), and continuous experimentation and learning. They guide DevOps transformation efforts.
DORA metrics
Four key metrics: deployment frequency, lead time for changes, change failure rate, and mean time to restore. They measure software delivery performance and operational stability.
Continuous Integration
A practice where developers merge code into a shared repository frequently, at least daily, and each merge triggers automated build and test to detect integration problems early.
Continuous Delivery vs Deployment
Continuous Delivery keeps software always releasable but requires manual approval to deploy. Continuous Deployment automatically releases every change that passes the pipeline to production.
Infrastructure as Code
Managing and provisioning computing infrastructure through machine-readable definition files rather than manual configuration, enabling version control, repeatability, and auditability.
Value stream mapping
A lean technique that visualizes the steps, wait times, and handoffs required to deliver value to a customer, helping identify waste and reduce lead time.
Agile Manifesto values
Four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
Scrum pillars
Transparency, inspection, and adaptation. These empirical process control pillars enable Scrum teams to manage complex work and adjust based on observed outcomes.
Product Owner role
The Scrum role responsible for maximizing product value by managing and prioritizing the Product Backlog, defining acceptance criteria, and representing stakeholder interests to the team.
Scrum Master role
A servant leader who coaches the team on Scrum practices, removes impediments, facilitates Scrum events, and fosters self-management and continuous improvement.
Sprint
A fixed-length iteration, typically one to four weeks, during which a Scrum team builds a potentially releasable product Increment. Its length stays consistent to reduce variability.
Daily Scrum
A 15-minute timeboxed event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is not a status report to management.
Definition of Done
A shared checklist of quality criteria that an Increment must satisfy to be considered complete. It ensures transparency and consistent quality across the team.
User story format
A concise requirement written as: As a <role>, I want <feature>, so that <benefit>. Acceptance criteria specify the conditions for the story to be considered complete.
Story points
A relative unit of estimation based on complexity, effort, and uncertainty, often using the Fibonacci sequence. Points are team-specific and not comparable across teams.
Velocity
The average number of story points a team completes per Sprint, used for forecasting future capacity. It should not be used to compare productivity across different teams.
Kanban WIP limits
Constraints on the number of work items allowed in a workflow stage. They expose bottlenecks, improve flow, and reduce cycle time by preventing overloading.
Cloud native
An approach to building and running applications that exploits cloud computing's elasticity, using containers, microservices, service meshes, immutable infrastructure, and declarative APIs.
Twelve-Factor App
A methodology for building portable, scalable cloud applications through twelve principles including codebase, dependencies, config, backing services, build-release-run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.
Jenkinsfile
A text file checked into source control that defines a Jenkins pipeline using declarative or scripted syntax. It enables pipeline-as-code and versioned build definitions.
GitHub Actions workflow
An automated process defined in a YAML file under .github/workflows, triggered by events such as push or pull request. It contains jobs and steps run on runners.
Trunk-based development
A branching strategy where developers commit to a single shared trunk frequently, using short-lived feature branches and feature flags to avoid long-lived divergence.
GitFlow branching model
A branching strategy using feature, develop, release, and hotfix branches to isolate work and manage releases. It suits scheduled release cycles but adds complexity for continuous delivery.
Dockerfile layer caching
Each Dockerfile instruction creates a read-only image layer. Docker caches layers and reuses them if the instruction and context are unchanged, speeding rebuilds.
Blue-green deployment
A release technique that runs two identical environments, blue and green, and switches traffic from one to the other after verification, enabling quick rollback.
Canary release
A deployment pattern that routes a small percentage of user traffic to a new version before full rollout, allowing early detection of defects with limited impact.
Container vs virtual machine
Containers share the host operating system kernel and package only the application and dependencies, while virtual machines include a full guest OS, making containers lighter and faster to start.
Kubernetes control plane
The set of components managing cluster state: kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. Worker nodes run the kubelet and kube-proxy.
Kubernetes Deployment
A workload object that manages ReplicaSets to provide declarative updates, scaling, and rollback for stateless applications. It ensures the desired number of Pods runs.
Kubernetes Service types
ClusterIP exposes a service internally, NodePort exposes it on each node's IP, LoadBalancer provisions a cloud load balancer, and ExternalName maps to a DNS name.