# Interview Questions: Red Hat OpenShift: Enterprise Kubernetes Platform

# Part 1 Questions: Architecture & What OpenShift Adds Over Vanilla Kubernetes

## Conceptual

### 1. What does OpenShift actually add on top of upstream Kubernetes?
A curated operating system (RHCOS) and runtime (CRI-O), an operator-driven cluster-management model (the Cluster Version Operator, Machine Config Operator, and roughly two dozen Cluster Operators), a default-restrictive security posture, and built-in platform services (registry, router, build tooling) — all layered around an unmodified, CNCF-conformant Kubernetes API.

### 2. Why does OpenShift ship CRI-O instead of containerd by default?
CRI-O was built to implement exactly the Kubernetes CRI specification and nothing more, deliberately minimizing runtime attack surface compared to containerd, which grew out of Docker Engine's broader internals and historically carried API surface unrelated to what Kubernetes actually needs.

### 3. What is RHCOS, and why is it called immutable?
Red Hat Enterprise Linux CoreOS is the operating system every RHCOS-based node runs. It's "immutable" because the whole OS image updates atomically as a single OSTree commit rather than through incremental package updates, giving every node in a pool a single, diffable, rollback-able OS state.

### 4. What role does Ignition play, and how is it different from ongoing configuration management?
Ignition applies a node's declared initial state exactly once, on first boot, before the node's own init system starts. It is not a recurring configuration-management tool — ongoing changes are handled afterward by the Machine Config Operator rewriting `MachineConfig` objects.

### 5. What does the Cluster Version Operator actually manage?
It manages every other Cluster Operator as one tested, versioned release payload, reconciling the cluster toward the version declared in the `ClusterVersion` object and aggregating every operator's own `Available`/`Progressing`/`Degraded` conditions into one overall cluster health view.

### 6. What is a MachineConfigPool, and what problem does it solve?
A named group of nodes (selected by label) sharing one rendered `MachineConfig`. It lets the Machine Config Operator target node-level OS changes (kernel arguments, systemd units, sysctls) at a specific subset of nodes instead of the whole cluster, and rolls changes out one node at a time via cordon/drain/apply/reboot/uncordon.

### 7. What are the two operators that make up OLM, and what does each do?
The Catalog Operator resolves `Subscription`s against `CatalogSource`s and handles dependency resolution between Operators; the OLM Operator deploys the resolved `ClusterServiceVersion`'s resources and grants exactly the RBAC it declares needing.

### 8. What is the practical difference between IPI and UPI installation?
IPI (Installer-Provisioned Infrastructure) has the installer create every piece of infrastructure directly against the target platform's API. UPI (User-Provisioned Infrastructure) expects the operator to have already stood up load balancers, DNS, and machines, with the installer only handling bootstrap and cluster formation on top.

### 9. Why does a standard OpenShift control plane run three nodes rather than some other number?
Three is the minimum odd number that tolerates one node failure without losing etcd's Raft quorum — the same majority-based consensus requirement covered generally in this catalog's Kubernetes Deep Dive series.

### 10. What is a hosted control plane, and what trade-off does it make?
A cluster's control plane runs as ordinary pods on a separate, shared management cluster instead of dedicated nodes inside the cluster it serves — lower cost and faster provisioning per cluster, at the cost of the hosted cluster's availability now depending on the management cluster's own health.

### 11. What does the Cincinnati upgrade graph actually provide?
A graph of releases where each edge is a validated recommended upgrade path; some edges are flagged `SupportedButNotRecommended` for clusters matching a specific known-affected condition, so `oc adm upgrade` doesn't offer every newer version unconditionally.

## Applied / Scenario

### 12. A team assumes a fresh RHCOS worker node can be patched with `ssh` and `rpm -Uvh` like any RHEL server. What actually happens, and why?
The manual install may appear to succeed, but the next Machine Config Operator rollout reverts it, because the node's actual desired state lives in its `MachineConfig`, not in whatever the running filesystem happens to contain. The supported fix is an RHCOS extension or a custom `MachineConfig`, not a manual SSH session.

### 13. A cluster install hangs at "waiting for bootstrap to complete" with no obvious error on the bootstrap machine itself. What's the first place to look?
The load balancer and DNS layer in front of the API server, since the bootstrap machine's own logs can look completely clean while the actual failure is a load balancer never adding the temporary API server as a healthy backend, or a DNS record that doesn't resolve.

### 14. `oc get clusteroperators` shows `ingress` as `Available=True`, `Progressing=True`, and `Degraded=True` simultaneously. What does this combination mean?
The router is still serving traffic (available) but is actively failing part of its reconciliation toward a new desired state (degraded) — a real, specific problem worth investigating via `oc describe clusteroperator ingress`, not a total outage.

### 15. A team manually edits a `Deployment`'s image tag to bypass OLM and get a bug fix faster than the vendor's next catalog channel update. What happens next?
OLM's Catalog Operator reconciles the `Subscription` back to the channel's last-known CSV, silently reverting the manual edit, since OLM treats the `Subscription` object as the source of truth, not the running `Deployment`'s current state.

### 16. A five-person startup running one small cluster is deciding between OpenShift and a managed EKS cluster with a hand-picked ingress controller. What's the honest framing of that decision?
OpenShift's opinionation pays off most clearly for organizations coordinating many teams or clusters at once; a small team on one cluster is exactly the profile where that opinionation may be pure overhead relative to a lighter, hand-assembled stack — the decision should hinge on whether the team's actual pain point matches what OpenShift specifically solves.

### 17. `oc adm upgrade` shows the desired target version under a "Supported but not recommended" heading. Should the team upgrade anyway to avoid falling behind on patches?
Only after checking whether the linked known issue actually applies to this cluster's specific configuration — if it doesn't, proceeding is reasonable; if it does, waiting for a subsequent patch release is the correct response, not proceeding purely to avoid staying on the current version slightly longer.

### 18. A cluster needs a custom kernel `sysctl` setting for only the nodes running one specific stateful workload, surviving node replacement via autoscaling. What's the right mechanism?
A `MachineConfig` targeting a custom `MachineConfigPool` whose node selector matches only those nodes — this makes the setting part of the node's own MCO-reconciled desired state, unlike a `DaemonSet initContainer`, which has no guarantee of running before the workload schedules onto a freshly-provisioned replacement node.

# Part 2 Questions: Projects, Security Context Constraints & Multi-Tenancy

## Conceptual

### 19. What does an OpenShift Project add on top of a bare Kubernetes Namespace?
A default `ResourceQuota` and `LimitRange` from the project template, default deny-across-namespace `NetworkPolicy`s, an automatic `admin`-role RoleBinding for the creator, and a dedicated UID/SELinux MCS range annotation — all applied automatically the moment the Project is created.

### 20. What is a Security Context Constraint, and how is it different from RBAC?
RBAC governs which objects a user can create, read, or modify. An SCC governs what a Pod itself is allowed to do at the kernel/runtime level (running as root, using host networking, requesting capabilities) regardless of who deployed it.

### 21. How does SCC admission actually choose which SCC a Pod runs under?
It evaluates every SCC the requesting Service Account is authorized to use, in priority order, and applies the first one whose constraints the Pod's actual requested spec satisfies — not the Pod's stated preference, and not necessarily the most permissive SCC available to that account.

### 22. Why does a container on OpenShift often not run as the UID its Dockerfile's `USER` instruction specifies?
Under the default `restricted-v2` SCC, the container runs as an arbitrary UID from that Project's own pre-allocated range unless `runAsUser` is left unset — a deliberate isolation guarantee that gives every Project distinct host-level UIDs.

### 23. Name one real gap between OpenShift's SCCs and upstream Pod Security Admission.
`restricted-v2` requires `runAsUser` to be unset or within the namespace's allocated range; a Pod hard-coding a specific non-root UID can satisfy upstream `restricted` perfectly well but still fail OpenShift's SCC admission for that reason.

### 24. What's the difference between the `admin` and `cluster-admin` ClusterRoles?
`admin` is scoped to one Project and deliberately excludes modifying that Project's own `ResourceQuota` or granting SCCs — it is not "cluster-admin at a smaller scope," since a Project's own trusted user still can't unilaterally escape the multi-tenancy boundaries set for them.

### 25. What does default role reconciliation mean, and why does it matter?
OpenShift automatically restores any missing permission on its six default ClusterRoles on every control-plane restart and upgrade, meaning a direct edit to a default role is silently reverted — custom permissions must go through a new ClusterRole or an aggregated ClusterRole instead.

### 26. What is an aggregated ClusterRole, and what problem does it solve?
A ClusterRole carrying a label like `rbac.authorization.k8s.io/aggregate-to-admin: "true"`, automatically merged into `admin`'s effective permissions — the supported way to extend a default role (for a new Operator's CRD, for instance) without editing it directly and having the edit reverted.

### 27. What are the two main default network-isolation behaviors a fresh Project gets?
Pods within the Project can reach each other freely, and pods in any other Project cannot reach into it at all by default — a `NetworkPolicy` allowing same-namespace traffic is the entire default ingress policy.

## Applied / Scenario

### 28. A team grants an entire namespace the `anyuid` SCC because one legacy image needs root. What's the risk, and what's the fix?
Every Service Account in that namespace inherits the grant, widening the whole namespace's attack surface for one workload's need. The fix is scoping the grant to a dedicated Service Account used only by that one Deployment, leaving every other workload on its default `restricted-v2`.

### 29. A Pod fails to schedule with an error naming `restricted-v2` and a specific UID range; the Dockerfile has `USER 1001`. What's the honest fix?
Remove the hard-coded UID assumption entirely — leave `runAsUser` unset and design the image to work under an arbitrary UID via GID-0 group permissions, rather than trying to negotiate a specific UID into whatever range a given Project happens to allocate.

### 30. A security team asks why an application namespace has `anyuid` granted via a `RoleBinding` to `system:serviceaccounts:app-team` rather than to a specific Service Account. What's the risk?
Every current and future Service Account in that namespace — including ones created later by anyone with create access — automatically inherits the grant. Remediation means identifying the specific Deployment that actually needs it, creating a dedicated Service Account, and re-scoping the grant.

### 31. An organization leaves self-provisioning open for over a year and later finds hundreds of abandoned Projects consuming reserved quota. What's the fix, short of disabling self-service entirely?
Add a mandatory requester label via a customized project-request template, plus a scheduled job flagging Projects with no workload activity for a defined period — giving self-service convenience an automatic accountability mechanism instead of removing the convenience.

### 32. Two teams' services in different Projects need to talk to each other. What's the supported way to open exactly that one path without disabling the default isolation?
An additional `NetworkPolicy` in the target namespace with an `ingress.from` entry combining a `namespaceSelector` for the source Project and a `podSelector` for the specific source Pods, layered alongside (not replacing) the default deny.

### 33. A `ResourceQuota` set correctly when a Project was created is now being hit constantly as the team has tripled in size. What's the actual problem?
The quota was never revisited as the team grew — treating it as a set-once value rather than something reviewed alongside team/workload growth is how a control meant to protect shared infrastructure ends up blocking the very team it was scoped for.

### 34. How would a platform team attribute shared cluster infrastructure cost fairly across several Projects?
By tagging every Project with a cost-center/team label at creation (via the project template) and computing each Project's share proportional to either its `ResourceQuota` requests or its actual measured usage — an even split across Projects ignores real usage differences and is the naive baseline to avoid.

# Part 3 Questions: Networking, Routes & OpenShift Service Mesh

## Conceptual

### 35. What is OVN-Kubernetes, and what overlay protocol does it use?
OpenShift's default CNI, built on Open Virtual Network and Open vSwitch, using Geneve (a more extensible successor to VXLAN) to encapsulate Pod-to-Pod traffic crossing between nodes.

### 36. Why does a `NetworkPolicy` restricting egress commonly break DNS resolution unexpectedly?
Once any egress-covering `NetworkPolicy` selects a Pod, DNS resolution is ordinary UDP/TCP traffic subject to the same default-deny — an explicit rule allowing traffic to the cluster's DNS Pods is required alongside any application-specific egress rules.

### 37. What are the three Route TLS termination types, and where does encryption actually end in each?
Edge terminates at the router (plain HTTP to the Pod); passthrough never terminates at the router at all (the original TLS session reaches the Pod unmodified); re-encrypt terminates at the router and establishes a second, separate TLS session to the Pod.

### 38. What is router sharding, and what's the common misconfiguration around it?
Running multiple `IngressController`s, each scoped to a subset of Routes via a `namespaceSelector`/`routeSelector`. The common mistake is assuming a new sharded router automatically removes its matched Routes from the default router's own scope — the default keeps serving them unless explicitly excluded.

### 39. How does a plain Kubernetes `Ingress` object behave on OpenShift?
The route-controller-manager automatically generates a corresponding, fully-owned `Route` from it, translating its TLS configuration — the generated Route should never be hand-edited directly, since the controller reconciles it back to match the source `Ingress`.

### 40. What is Multus, and what does it not replace?
A meta-CNI plugin letting a Pod attach one or more additional network interfaces beyond the default cluster network — it doesn't replace the default network, and it's a specialized mechanism (NFV, SR-IOV workloads) rather than a general-purpose performance optimization.

### 41. What does OpenShift Service Mesh add that NetworkPolicy and Routes alone cannot?
Automatic mutual TLS between every enrolled service, fine-grained per-request traffic shaping (weighted routing by header, retries, circuit breaking), and deep service-to-service call observability, all without application code changes — at the cost of a real, ongoing operational commitment.

### 42. Does joining a namespace to the service mesh replace NetworkPolicy enforcement?
No — NetworkPolicy and Istio's `AuthorizationPolicy` are enforced completely independently; both must permit a request for it to succeed, and a pre-existing NetworkPolicy keeps applying in full regardless of mesh membership.

## Applied / Scenario

### 43. A team's egress-restricting `NetworkPolicy` passes every application-dependency test but breaks image pulls from an internal registry hostname the next day. What's the cause?
The dependency testing never specifically probed hostname-based resolution the way an image pull does — the fix is an explicit egress rule permitting DNS traffic to the cluster's DNS Pods, not reverting the policy.

### 44. A public application needs end-to-end encryption for compliance, but the team also wants the router to perform host-based routing and collect metrics. Which termination type fits, and why?
Re-encrypt — it satisfies "encrypted in transit end to end" via two separate TLS sessions while still letting the router see the decrypted request in between, which passthrough would sacrifice entirely since the router never decrypts passthrough traffic.

### 45. A platform team wants to isolate untrusted, multi-tenant Routes onto their own router without those Routes also being served by the default one. What's missing from just creating the new sharded IngressController?
An explicit exclusion configured on the default `IngressController` for that same selector, plus a separate DNS record pointing at the new sharded router's own exposure endpoint — neither is automatic.

### 46. An application team asks whether NetworkPolicy can provide universal mutual TLS between a dozen internal microservices. What's the honest answer?
No — NetworkPolicy is an IP/port-level allow/deny mechanism with no concept of encryption or cryptographic identity at all. OpenShift Service Mesh, via automatic sidecar-to-sidecar mTLS once namespaces are enrolled, is the right tool, with the added operational cost of running a mesh control plane worth naming upfront.

### 47. Two services in the same mesh-enrolled namespace can't reach each other, and Istio's `AuthorizationPolicy` looks correctly permissive. What's the next layer to check?
`NetworkPolicy` at the CNI level — since the two mechanisms are enforced independently, a correct `AuthorizationPolicy` says nothing about whether an existing `NetworkPolicy` is silently denying the same traffic, a gap easy to miss once a namespace is mentally framed as "Istio handles access control here now."

### 48. A team chooses passthrough TLS termination out of habit for a legacy migration, then finds host-based routing and router metrics stop working for that Route. Why?
Passthrough means the router never decrypts the traffic at all, so it can't inspect the request's hostname or gather request-level metrics — re-encrypt termination would restore both while keeping the connection encrypted end to end, once the actual requirement (encryption, not client-cert inspection) is named explicitly.

# Part 4 Questions: BuildConfigs, S2I, ImageStreams & OpenShift Pipelines/GitOps

## Conceptual

### 49. What is Source-to-Image, and what two scripts does every builder image implement?
A build mechanism that assembles source code into a runnable image using a builder image's `assemble` (build the source) and `run` (start the application) scripts — no Dockerfile is written or needed.

### 50. What does an ImageStreamTag provide that a plain Docker tag doesn't?
A versioned, auditable history of every image it has ever pointed to, plus native trigger support (`ImageChange` triggers) — a plain tag is a mutable pointer with no built-in history or trigger mechanism.

### 51. How does a plain Kubernetes `Deployment` get ImageStream-driven automatic rollout without using the older `DeploymentConfig` object?
Via the `image.openshift.io/triggers` annotation, which patches the Deployment's container image field directly whenever the named ImageStreamTag updates.

### 52. What is the core architectural difference between Tekton and a traditional Jenkins-style CI system?
Every Tekton stage runs as an ordinary Kubernetes Pod — there is no separate CI server process or agent fleet; the Kubernetes API server plus Tekton's controllers is the entire CI system, inheriting Kubernetes' own scheduling and RBAC automatically.

### 53. What's the difference between a `Task`, a `Pipeline`, a `PipelineRun`, and a `TaskRun`?
`Task` and `Pipeline` are pure, reusable definitions with no execution logic; a `PipelineRun` is one actual execution of a `Pipeline`, and a `TaskRun` is one `Task`'s execution within that run, ultimately a real Pod.

### 54. What does Argo CD's `selfHeal: true` sync policy actually do?
It reverts manual drift in the cluster back to whatever the Git repository declares, typically within seconds of detecting the difference — a manual `oc edit`/`oc scale` against a self-healed resource is not a permanent change.

### 55. What problem does the app-of-apps pattern solve, and how?
Managing many `Application` objects by hand — it makes the `Application` objects themselves GitOps-managed, so a single root `Application` watching a directory of other `Application` manifests creates and manages every child automatically.

### 56. Why can't a Kubernetes `Secret` be safely committed directly to a GitOps repository?
Its data is only base64-encoded, not encrypted — a private repository's access controls are the only real protection, which is rarely as tightly scoped as a dedicated secret manager. Sealed Secrets or the External Secrets Operator solve this instead.

## Applied / Scenario

### 57. An S2I build for a Java application fails during `assemble` with an out-of-memory error, though the deployed application runs fine within its own memory limit. What's the likely cause?
The build Pod inherits the namespace's `LimitRange` default, sized for the application's runtime footprint, not for `assemble`'s own resource-hungry compilation phase — the fix is an explicit `resources` override on the `BuildConfig` itself.

### 58. A team wants developers to deploy an internal tool from source quickly, but wants any production service to go through a multi-stage pipeline with a security scan and manual approval. Should they standardize on one mechanism for both?
No — BuildConfig/S2I fits the fast, low-setup internal-tool case; Tekton `Pipeline`s with a manual-approval gate fit the multi-stage production requirement. Forcing one mechanism to cover both is a worse fit for at least one case.

### 59. An `Application` with `selfHeal: true` shows `OutOfSync` after an engineer manually edits a ConfigMap during an incident. What happens, and what should the team do instead?
Argo CD reverts the manual edit back to Git's declared state, likely before the fix is even confirmed to work. The correct approach is committing the fix to Git and letting Argo CD apply it, or explicitly pausing that Application's auto-sync first if an immediate change is genuinely necessary.

### 60. A team adopts Argo Rollouts on top of an existing hand-maintained weighted Route split. What actually changes?
Nothing about the underlying traffic-splitting mechanism — Rollouts drives the same Route-weight primitive automatically, on a schedule, optionally gated by an `AnalysisTemplate` querying real metrics, turning a manual process into a codified, repeatable one.

### 61. A team wants the same application deployed identically across twelve regional clusters and is currently hand-writing twelve Argo CD `Application` objects. What's the better pattern?
`ApplicationSet` with a cluster generator — it produces one `Application` per registered cluster from a single template, so adding a new cluster produces its `Application` automatically, without changing the underlying per-cluster reconciliation model at all.

### 62. A security review finds a Tekton pipeline's `buildah` Task running under the `privileged` SCC and asks whether that's necessary. What should the team check first?
Whether the specific OpenShift Pipelines version in use supports rootless Buildah (user namespaces, fuse-overlayfs) under a much narrower SCC — a `privileged` grant inherited from an older setup is a common, fixable case of a wider-than-needed grant.

# Part 5 Questions: Day-2 Operations: Cluster Operators, Upgrades & Observability

## Conceptual

### 63. In what order does an OpenShift cluster upgrade actually roll out?
The control plane updates first (API server, etcd, controllers), then the Machine Config Operator rolls the new configuration to the master pool, then to worker pool(s), and finally every Cluster Operator reconciles to the new release.

### 64. What are the two objects required together for cluster autoscaling to work at all?
A single, cluster-wide `ClusterAutoscaler` defining overall policy, and at least one `MachineAutoscaler` targeting a specific `MachineSet` with min/max bounds — the `ClusterAutoscaler` alone has nothing it's authorized to scale.

### 65. What does a `MachineHealthCheck`'s `maxUnhealthy` threshold protect against?
It stops automatic remediation once more than that percentage of targeted Machines are simultaneously unhealthy, on the reasoning that a failure affecting that many at once is more likely a systemic issue than independent hardware failures, where mass-replacement could make things worse.

### 66. What two artifacts does `cluster-backup.sh` produce, and why are both required for a restore?
An etcd data snapshot and a separate archive of static pod manifests and certificates — the certificates alone can't reconstruct cluster state, and the snapshot alone can't restart a control plane with no static pod definitions to boot from.

### 67. Why doesn't an etcd backup protect application data living in PersistentVolumes?
etcd stores only the cluster's own configuration metadata, never the actual data a PersistentVolume holds — OADP/Velero, covering both manifests and volume snapshots, is the complementary mechanism for that failure class.

### 68. Why does OpenShift deploy a separate Prometheus instance for user workload monitoring instead of sharing the platform's own?
To isolate the two — a misbehaving or runaway application-level `PrometheusRule` can't degrade the platform team's own visibility into cluster health, the same isolation principle Projects apply to multi-tenancy generally.

### 69. What does a `ClusterLogForwarder` pipeline actually define?
A named route from a specific log input (`application`, `infrastructure`, or `audit`) to one or more outputs (the in-cluster LokiStack, or an external system like Splunk or Kafka) — one forwarder can route different log classes to different destinations simultaneously.

### 70. What does `installPlanApproval: Manual` actually change about an OLM Operator's upgrade behavior?
A new CSV version's `InstallPlan` sits in a pending, unapproved state indefinitely until a human explicitly patches it as approved — nothing times out or auto-applies it, giving a deliberate review gate before any Operator upgrade takes effect.

## Applied / Scenario

### 71. A cluster upgrade has run for over an hour with no ClusterOperator reporting Degraded. What are the first two things to check?
Whether the relevant `MachineConfigPool`s are genuinely still `Updating` (a large node count can legitimately take a long time), and whether an overly strict `PodDisruptionBudget` is blocking the MCO's drain step on a specific node — neither produces ClusterOperator-level degradation.

### 72. A team creates a `ClusterAutoscaler` object but the cluster never scales up despite Pods stuck Pending. What's missing?
A `MachineAutoscaler` targeting the specific `MachineSet`(s) — without one bound to it, the `ClusterAutoscaler` has no MachineSet it's authorized to adjust, regardless of unschedulable Pods.

### 73. A disaster-recovery plan only includes etcd backups. A production incident destroys a PersistentVolume backing a critical stateful application. What does restoring the etcd backup recover, and what does it miss?
It recovers every Kubernetes object definition, including the PersistentVolumeClaim referencing the now-destroyed volume, but not the actual data that lived on it — OADP with volume-snapshot backup is the missing piece for exactly this failure class.

### 74. A platform team needs to replace one specific worker node showing early disk SMART warnings, without waiting for it to become unhealthy enough for MachineHealthCheck to act. What's the precise way to do this?
Annotate that specific Machine with `machine.openshift.io/delete-machine="true"`, then scale its MachineSet down and back up — this proactively removes exactly the flagged machine rather than leaving the choice to the MachineSet controller's default newest-first heuristic.

### 75. A team wants one alert correlating an application's real error rate against whether underlying nodes are under memory pressure, without a separate observability tool. Is this achievable with the built-in stack?
Yes — Thanos Querier federates queries across both the platform and user-workload Prometheus instances, so a single PromQL expression in a namespaced `PrometheusRule` can reference both a user-workload metric and a platform-level metric in one query.

### 76. A security team asks why audit logs need to reach an external SIEM while application logs stay in the in-cluster LokiStack, and whether this needs two collection agents. What's the actual answer?
No second agent is required — a single `ClusterLogForwarder` can route the `audit` input to an external SIEM output while routing the `application` input to the in-cluster LokiStack output, both from the same underlying collected log stream.

## Quick-Fire Recall

| Term | One-line answer |
|---|---|
| RHCOS | Immutable, OSTree-based OS every RHCOS node runs |
| CRI-O | The Kubernetes-only container runtime OpenShift ships by default |
| Ignition | One-shot, first-boot provisioning tool |
| Cluster Version Operator | Manages every other Cluster Operator as one tested release payload |
| MachineConfigPool | A named group of nodes sharing one rendered MachineConfig |
| OLM | Operator Lifecycle Manager — Catalog Operator + OLM Operator |
| IPI / UPI | Installer-provisioned vs. user-provisioned infrastructure |
| Hosted control plane | Control plane runs as pods on a separate management cluster |
| Cincinnati | The upgrade-graph service behind conditional update warnings |
| Project | A Namespace plus default quota/RBAC/UID-range/network-isolation bundle |
| SCC | Security Context Constraint — governs what a Pod may do at the kernel level |
| `restricted-v2` | The default SCC for ordinary application workloads |
| UID range annotation | Gives every Project's Pods distinct, namespace-allocated host UIDs |
| Aggregated ClusterRole | Extends `admin`/`edit` without editing them directly |
| OVN-Kubernetes | OpenShift's default CNI, built on OVN/OVS with Geneve encapsulation |
| Route | OpenShift's native ingress object, richer than Kubernetes Ingress |
| Edge / passthrough / re-encrypt | The three Route TLS termination types |
| Router sharding | Multiple IngressControllers, each scoped to a Route subset |
| Multus | Meta-CNI attaching additional network interfaces beyond the default |
| OpenShift Service Mesh | Istio via the Sail Operator — mTLS, traffic shaping, observability |
| S2I | Source-to-Image — assembles source via a builder image's assemble/run scripts |
| ImageStream / ImageStreamTag | Versioned, triggerable image reference abstraction |
| Tekton Task/Pipeline/PipelineRun | Reusable definition, ordered graph, and one actual execution |
| Argo CD Application | Core GitOps object reconciling a cluster destination to a Git source |
| selfHeal / prune | Reverts drift / deletes orphaned resources not in Git |
| App-of-apps | Pattern making Application objects themselves GitOps-managed |
| Sealed Secrets | Encrypts a Secret so it's safe to commit to Git |
| Argo Rollouts | Automates progressive, analyzed traffic-weight shifts |
| ClusterAutoscaler / MachineAutoscaler | Cluster-wide policy / per-MachineSet bounds, both required together |
| MachineHealthCheck | Automatic detection and replacement of an unhealthy Machine |
| cluster-backup.sh / cluster-restore.sh | The etcd snapshot backup and restore scripts |
| OADP | Application-level (including PersistentVolume data) backup, complements etcd backup |
| User workload monitoring | Separate, isolated Prometheus/Thanos Ruler for application-defined metrics |
| ClusterLogForwarder | Routes named log inputs to one or more outputs |
| LogQL | Loki's PromQL-like query language for logs |
| `installPlanApproval: Manual` | Requires explicit human review before an Operator upgrade applies |