More in Docker & Kubernetes — page 5
When to build an Operator vs a Helm chart
WHAT IT TESTS: tool selection judgment. OUTLINE: charts handle install-time templating; operators add continuous day-two logic like failover, backups, and scaling for stateful apps. RED FLAG: building an operator for a stateless app a chart would handle.
Adding a required field to a live CRD
WHAT IT TESTS: CRD schema evolution. OUTLINE: don't make it required immediately; add it optional with a default, introduce a new version with conversion, migrate existing objects, then tighten.
Finalizers for clean external cleanup
WHAT IT TESTS: pre-deletion hooks. OUTLINE: a finalizer is a key blocking deletion; deletion sets deletionTimestamp, the operator does cleanup then removes the finalizer so the object is purged.
The reconciliation loop in an Operator
WHAT IT TESTS: the control-loop model. OUTLINE: reconcile compares desired spec to observed state and converges them, idempotently; triggered by resource changes, watched dependents, and periodic resync.
Creating an instance of a custom resource
WHAT IT TESTS: using a CRD. OUTLINE: write a manifest with apiVersion (group/version), kind, metadata.name, and a spec matching the CRD schema, then kubectl apply -f it. RED FLAG: omitting the group in apiVersion or applying before the CRD is registered.
Core components of a Kubernetes Operator
WHAT IT TESTS: operator architecture. OUTLINE: a CRD defines the type, a controller watches instances via the API server and runs a reconcile loop, encoding operational knowledge to drive real state.
What is a Custom Resource Definition?
WHAT IT TESTS: extending the Kubernetes API. OUTLINE: a CRD registers a new resource kind so the API server stores and serves it like built-ins; it lets you model domain concepts declaratively. RED FLAG: confusing the CRD with the controller that acts on it.
Helm migration hooks under GitOps
WHAT IT TESTS: Helm hooks plus GitOps tension. OUTLINE: use a pre-upgrade hook Job with weights and delete policy; the challenge is GitOps tools render statically and reconcile, conflicting with Helm's imperative hook lifecycle. RED FLAG: ignoring idempotency.
GitOps repo layout for environment promotion
WHAT IT TESTS: multi-env GitOps design. OUTLINE: shared base plus per-env overlays via Kustomize or value files, promotion by PR moving a pinned version forward, separating app source from config repos. RED FLAG: branch-per-environment with merge drift.
Argo CD App of Apps pattern
WHAT IT TESTS: scaling GitOps management. OUTLINE: a parent Application whose manifests are themselves Application resources, so syncing one app declaratively manages many. RED FLAG: confusing it with ApplicationSet or with multi-source apps.
Managing secrets in a GitOps workflow
WHAT IT TESTS: secrets in declarative pipelines. OUTLINE: never commit plaintext; encrypt with Sealed Secrets or SOPS, or reference an external store via External Secrets Operator. RED FLAG: base64-encoding a Secret and calling it secure.
How GitOps controllers detect drift and sync
WHAT IT TESTS: reconciliation mechanics. OUTLINE: the controller renders desired manifests from Git, diffs them against live cluster objects, marks OutOfSync, then a sync applies the diff to converge. RED FLAG: thinking it only acts on Git commits.
Helm upgrade and rollback workflow
WHAT IT TESTS: Helm release lifecycle. OUTLINE: helm upgrade creates a new revision; helm history lists revisions; helm rollback reverts to a prior one; --atomic auto-rolls-back on failure. RED FLAG: reinstalling or deleting the release instead.
Override Helm values at install time
WHAT IT TESTS: Helm values overriding. OUTLINE: pass custom files with -f or --values, single keys with --set, and know precedence: defaults, then files, then --set. RED FLAG: editing the chart templates directly instead of supplying values.
What is the basic principle of GitOps?
WHAT IT TESTS: declarative continuous delivery. OUTLINE: Git holds desired state; a controller continuously reconciles the cluster to match it; benefits are auditability, rollback, and drift correction. RED FLAG: describing push-based scripts as GitOps.
What is a Helm chart?
WHAT IT TESTS: Kubernetes packaging basics. OUTLINE: a chart is a templated, versioned bundle of manifests with a values file; it solves config duplication and reuse across environments. RED FLAG: calling Helm a CI/CD or GitOps tool itself.
Head-based vs tail-based trace sampling
WHAT IT TESTS: trace sampling trade-offs. OUTLINE: head decides up front (cheap, may miss rare errors); tail decides after the trace completes (catches errors and slow traces but needs buffering). RED FLAG: claiming one is universally better.
Diagnose a Prometheus cardinality explosion
WHAT IT TESTS: operating Prometheus at scale. OUTLINE: find offenders via TSDB stats and topk count by __name__, identify unbounded labels, then drop or aggregate them with relabeling. RED FLAG: just scaling memory without fixing label design.
What is distributed tracing in microservices?
WHAT IT TESTS: observability across service boundaries. OUTLINE: a trace is a tree of spans tied by trace and span IDs, propagated via headers like W3C traceparent. RED FLAG: confusing tracing with plain logging or metrics.
Two ways to consume a ConfigMap in a Pod
WHAT IT TESTS: ConfigMap consumption patterns. OUTLINE: Inject keys as environment variables (good for a few simple settings), or mount the ConfigMap as a volume of files (good for config files and live updates).