ca-fdops flashcards
ca-fdops · 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.
- Three Ways of DevOps
- A model describing DevOps principles: flow of work from development to operations, fast feedback loops, and a culture of continual experimentation and learning.
- DORA four key metrics
- Deployment frequency, lead time for changes, change failure rate, and time to restore service; together they measure software delivery performance.
- Blameless postmortem
- A structured review after an incident that focuses on systemic causes and contributing factors rather than individual fault, producing corrective actions to prevent recurrence.
- Conway's Law
- The observation that a system's architecture tends to mirror the communication structure of the organization that built it, so team design can influence system design.
- Git commit object
- An immutable Git object containing a tree reference, parent commit hashes, author and committer metadata, a message, and a content hash identifier.
- Git rebase versus merge
- Merge preserves history and creates a merge commit with two parents; rebase replays commits onto a new base, producing linear history but rewriting commit hashes.
- Trunk-based development
- A branching model where developers integrate small changes into a shared mainline at least daily, using short-lived branches and feature flags to hide incomplete work.
- Protected branch
- A version control rule that blocks direct pushes, requires passing status checks and reviews, and enforces merge policies before changes reach a branch.
- Hermetic build
- A build that runs in an isolated environment with pinned dependencies and no external state, producing reproducible outputs regardless of when or where it runs.
- Immutable build artifact
- A versioned, unchangeable output of a build pipeline stored in an artifact repository and promoted through environments without rebuilding.
- Fail-fast pipeline
- A CI design that runs the quickest and most likely-to-fail checks first, such as linting and unit tests, before slower integration and end-to-end stages.
- Flaky test
- A test that produces inconsistent pass or fail results without code changes, undermining pipeline trust; it should be quarantined and fixed or removed.
- Continuous delivery versus deployment
- Continuous delivery keeps the mainline always deployable with a manual release decision; continuous deployment automatically releases every change that passes the pipeline.
- Blue-green deployment
- A release technique running two identical environments where traffic switches atomically from the old version to the new, enabling rapid rollback.
- Canary release
- A deployment strategy that routes a small percentage of traffic to a new version, monitors error and latency metrics, then gradually increases traffic or rolls back.
- Expand-contract database migration
- A pattern that first adds backward-compatible schema changes, deploys code using them, then removes old structures, allowing old and new application versions to coexist.
- Idempotent configuration
- A property of infrastructure code where applying the same configuration repeatedly produces the same end state without unintended side effects or duplicate resources.
- Terraform state
- A file mapping declared infrastructure resources to real cloud objects, used to plan changes; remote state with locking prevents concurrent modifications.
- Configuration drift
- The divergence between the actual state of infrastructure and its declared or expected configuration, often caused by manual changes or unmanaged updates.
- Immutable infrastructure
- An approach where servers are replaced rather than modified in place, reducing configuration drift and making deployments more predictable and reproducible.
- Container isolation
- Containers share the host operating system kernel while using namespaces for process isolation and cgroups for resource limits, making them lighter than virtual machines.
- Kubernetes Pod
- The smallest deployable unit in Kubernetes, containing one or more containers that share a network namespace, storage volumes, and scheduling context.
- Readiness versus liveness probe
- A readiness probe controls whether a Pod receives traffic by removing it from Service endpoints; a liveness probe restarts a container that is unhealthy.
- Kubernetes resource requests and limits
- Requests determine how much CPU and memory the scheduler reserves for a Pod; limits cap usage and can cause throttling or OOMKill when exceeded.
- Shared responsibility model
- A cloud security framework where the provider secures physical infrastructure and the hypervisor, while the customer secures data, identity, and configuration in the cloud.
- Availability zone
- An isolated data center or group of data centers within a cloud region, designed so that a failure in one zone does not affect others.
- Cloud auto-scaling
- A mechanism that automatically adjusts compute capacity based on metrics such as CPU utilization or request count, within configured minimum and maximum bounds.
- Least privilege
- A security principle granting identities only the permissions required to perform their tasks, reducing the blast radius of compromised credentials or mistakes.
- Three pillars of observability
- Metrics, logs, and traces; metrics are aggregated numeric measurements, logs are discrete events, and traces follow a request across distributed services.
- Error budget
- The amount of unreliability permitted by a service level objective, calculated as one minus the SLO, used to balance release velocity against stability.
- Four golden signals
- Latency, traffic, errors, and saturation; these four metrics provide a compact view of service health and are commonly used for monitoring and alerting.
- SAST versus DAST
- Static application security testing analyzes source code without running it; dynamic application security testing probes a running application for vulnerabilities.