OpenShift Interview Questions and Answers for 2026

Answer: OpenShift is Red Hat’s Kubernetes distribution: an enterprise platform that packages upstream Kubernetes with an opinionated, integrated set of day-1 and day-2 services, including OAuth-based authentication, a default ingress router, an internal image registry, source-to-image builds, a web console, and automated platform lifecycle through cluster operators. The one-line follow-up to have ready: it is Kubernetes plus the operational opinions enterprises otherwise assemble themselves, and that framing opens most OpenShift interview questions cleanly.

Upstream gives you a control plane and stops there; identity, ingress, registry, builds, the OS, and the upgrade process are all yours to assemble. OpenShift ships those as integrated, self-managing components: the OAuth server, the HAProxy router, the internal registry, BuildConfigs and S2I, RHEL CoreOS nodes, and the Cluster Version Operator driving upgrades. Almost all early OpenShift interview questions are really asking whether you understand this distinction: the distribution owns opinions so your team operates a product instead of assembling one.

A project is a Kubernetes namespace with extra OpenShift annotations that give it a user-facing identity: a display name and a description. Everything else is the same object, so quotas, RBAC, and NetworkPolicies apply at project scope. The practical knob worth naming: the self-provisioner cluster role decides who can create projects, and revoking it from authenticated users is a common hardening step that turns project creation into a reviewed request.

oc is kubectl plus OpenShift: every kubectl verb works, and on top of it oc knows platform objects like routes, build configs, image streams, and deployment configs, plus login against the OAuth server and convenience commands like oc new-app. The detail that lands: oc whoami and oc project confirm identity and current project, and because oc builds on kubectl, scripts written for kubectl largely port over. Interviewers open OpenShift interview questions with oc because daily fluency here predicts everything after.

A Route is OpenShift’s object for publishing a Service to the outside world on the cluster’s ingress domain, typically <name>.<project>.apps.example.com. It predates the Kubernetes Ingress resource and carries platform extras: TLS termination mode, weighted alternate backends, and a wide set of router-tuning annotations. You create one with oc expose service mysvc or let oc new-app do it. Routes are served by the default HAProxy router, which is the answer to the natural follow-up about what actually terminates the connection.

A BuildConfig is OpenShift’s declarative definition of an image build: where source comes from (usually Git), which strategy runs (Source-to-Image, Docker, or a custom image), what base image to use, and where output goes, normally a tag in an ImageStream. It also declares triggers, such as webhooks from GitHub or image changes, that start new builds automatically. One run of it produces a Build object, the same way a Deployment produces pods, which is the state-versus-instance distinction the follow-ups test.

Source-to-Image, or S2I, is a build mechanism that turns a source repository into a runnable image without a Dockerfile: the chosen builder image ships scripts, mainly assemble and run, and the platform injects your source and executes them. A Node builder runs your install and start steps; a Python builder runs pip install and picks an entrypoint. S2I matters because it standardizes builds across teams, which is the design rationale behind many OpenShift interview questions on the topic: consistent, auditable builds with vendor-maintained base images instead of hundreds of drifting Dockerfiles.

An ImageStream is a named collection of tags pointing at images, either pushed to the internal registry or imported from an external one. Workloads reference the stream tag rather than a pinned digest, which gives you indirection: an internal push or a scheduled external import updates the tag, and any Deployment watching it via an image change trigger rolls forward automatically. Streams also enable local aliasing and rollback between tags, and understanding that indirection is the hinge that later OpenShift interview questions about CI/CD turn on.

Every OpenShift cluster ships a private registry the platform uses for its own build outputs and your project images, backed per platform by storage like S3 or a PVC. Images land there as image-registry.openshift-image-registry.svc:5000/<project>/<name> and are reachable cluster-internally by default; exposure to the outside is deliberate configuration. Build outputs push there automatically, and oc adm prune images is how you reclaim space, which makes registry growth a classic beginner troubleshooting story.

A DeploymentConfig is OpenShift’s original rollout object, with features Deployments lacked for years: server-side rollouts run by a deployer pod, lifecycle hooks such as pre and mid-deploy commands, custom strategies, and native image change triggers. Upstream Deployments closed the functional gap over time, and Red Hat now recommends Deployments for new workloads while keeping DCs supported. The expected beginner answer: know both exist, prefer Deployments, and mention that scaffolding tools like oc new-app still generate DCs unless told otherwise.

A Security Context Constraint, or SCC, is OpenShift’s admission policy layer for pod security: a set of rules covering the UID a container may run as, host namespaces and paths, Linux capabilities, volume types, and privilege. Every pod is admitted against a constraint, and the default restricted-v2 refuses root and host access. This is the single most common beginner stumbling block when moving images from Docker Hub onto OpenShift, which is exactly why OpenShift interview questions about SCCs appear in nearly every loop at some depth.

Because most of them assume root, and the default SCC restricted-v2 requires non-root: arbitrary UIDs, no host namespaces, all capabilities dropped, RuntimeDefault seccomp. Images with hardcoded root, entrypoints that chown or bind low ports, or writes to root-owned paths fail at admission or crash at start. The professional fixes are publishing images that run as arbitrary UIDs, or a scoped exception such as the anyuid SCC granted to a dedicated service account, never to default. That fix hierarchy is precisely what OpenShift interview questions on this topic want to hear.

It is the platform’s front door for human authentication: users obtain OAuth tokens that then authenticate every API call, and those tokens map to identities the cluster records. It sits between users and the Kubernetes API server and is configured through identity providers, such as HTPasswd, LDAP, OIDC, or GitHub, declared in the cluster’s OAuth custom resource and managed by the authentication operator. Tokens expire and refresh on their own, and oc whoami shows who you are while oc whoami -t reveals the token in use.

It is the simplest local identity provider: user credentials live in an htpasswd-format file stored as a Secret in the openshift-config namespace, referenced by the OAuth configuration. You add users with the htpasswd tool, update the secret, and the change applies within a minute. It is meant for labs, proofs of concept, and break-glass access, not production, where LDAP or OIDC belongs. Being able to name that boundary, quick to stand up, wrong for production scale, answers both the definition and the follow-up that OpenShift interview questions attach to it.

The CLI asks the OAuth server to authenticate you against the configured identity provider, receives an access token, and stores it in your kubeconfig under the cluster context, alongside the API server URL. From then on every oc and kubectl call presents that token, and the API server maps it to your user for RBAC decisions. Useful checks to volunteer: oc whoami confirms the identity, oc whoami -t the token, and oc config current-context the cluster, which is how you avoid acting on the wrong cluster during an incident.

A cluster operator is a self-managing controller that owns a platform component: authentication, networking, the registry, ingress, DNS, etcd, monitoring, storage, and more. Each reports health through standard conditions, Available, Progressing, and Degraded, so the whole platform state fits in one command: oc get clusteroperators. They are installed and upgraded by the Cluster Version Operator, which is why operator health also gates upgrades. This operator-per-component model is the platform’s spine, and nearly all advanced OpenShift interview questions route through it eventually.

The MCO manages everything at the node layer: the RHEL CoreOS operating system, kubelet configuration, kernel arguments, systemd units, files, and SSH keys. You declare a MachineConfig custom resource, the operator renders a new config per pool, then drains each node, applies the change, reboots it, and proceeds batch by batch according to the pool’s maxUnavailable. It is why nodes get patched without you ever SSHing in, and it is the operator scenario OpenShift interview questions most often build a stuck-node story around.

A pool is a group of nodes that receive the same machine configuration, selected by label: the built-in master and worker pools, plus custom pools you define, such as an infra pool. The pool carries rollout knobs like maxUnavailable and a paused flag that stops changes from applying while you investigate. Pool membership comes from matching labels, so moving a node between pools is a labeling act, and that relationship between labels and rollout groups is the detail interviewers probe next.

The Operator Lifecycle Manager is the package manager for operators: it watches Subscriptions, resolves versions from CatalogSources, such as the Red Hat and community catalogs, produces InstallPlans, and manages ClusterServiceVersions through install, upgrade, and cleanup. OLM handles dependency resolution and channel-based release tracks, so an operator upgrade is a channel or approval decision rather than manual YAML surgery. Day to day you meet it as oc get subs and oc get csv, the two listings that answer most operator-state OpenShift interview questions.

A Subscription ties one operator to a channel and a namespace, and OLM does the rest. The InstallPlan is the concrete set of resources OLM will apply, and its approval setting decides who says yes: Automatic applies new versions as the channel publishes them, Manual parks them until a human approves the plan. Use Manual for anything touching stateful or critical paths. That approval tradeoff, speed versus control, is the operational judgment this question is really scoring.

A ResourceQuota caps what one project may consume: CPU and memory requests or limits, object counts such as pods or PVCs, optionally scoped, for example to terminating versus non-terminating pods. When a quota exists, pods without explicit resource requests are rejected, because unrequested usage cannot be accounted against the budget. It is the platform’s answer to the noisy neighbor problem, and pairing quotas with LimitRanges so defaults exist is the one-two answer that OpenShift interview questions on multi-tenancy look for.

A LimitRange sets per-container or per-pod floors and ceilings inside a project: minimum and maximum requests and limits, a max ratio between them, and, most usefully, defaults injected into pods that specify none. With a LimitRange present, a sloppy deployment still lands with sane requests and limits instead of BestEffort scheduling, and admission rejects anything violating the bounds. The quota sets how much the project may spend; the limit range shapes each spend. That division of labor is the sentence this question exists to produce.

The router is OpenShift’s default ingress implementation: HAProxy pods managed by the Ingress Operator, fronting all HTTP and HTTPS routes on the cluster’s domain, load-balanced by a cloud service or DNS round robin. Routes configure how HAProxy behaves per host, and router-level settings, replicas, node placement, TLS profiles, wildcard support, are set on the IngressController resource in the openshift-ingress-operator namespace. Scaling the router is a field on that CR, not a manual deployment edit, and that managed-resource distinction is what OpenShift interview questions here are checking.

OVN-Kubernetes, Open Virtual Network integrated with Kubernetes, is the default CNI: it provides the pod overlay, service load balancing, and network policy enforcement. The legacy OpenShift SDN plugin has been retired, and clusters migrate to OVN-K during the upgrade that removes it. Knowing the current default matters because later questions about egress IPs, network policies, and multicast assume OVN-K semantics, and answering with the retired SDN plugin is a quiet date-stamp on your experience that experienced OpenShift interview questions are designed to catch.

oc logs pod-name for the current output, -c container for one container of many, and -f to follow; add --previous for the crashed instance of a restarted container. For a deployment-wide view use oc logs deploy/name to hit a current replica. When nothing comes out, the container is likely crash-looping before producing output, and oc get events or a fix to the command takes over. Log fluency is assumed at every tier, so fumbling this in OpenShift interview questions costs disproportionate credibility.

oc rollout status deploy/myapp blocks until the rollout completes or fails, while oc get pods -w streams the pod lifecycle live. Diagnosis on failure: oc describe pod for events such as ImagePullBackOff or quota rejection, then oc logs --previous for what the last container printed before dying. Rollback is oc rollout undo. That four-command sequence, status, describe, logs, undo, is the muscle memory the everyday OpenShift interview questions are screening for, and delivering it without hesitation reads as lived experience.

It drops you into a privileged pod on a specific node with the node’s filesystem mounted under /host, the supported way to inspect a host you cannot SSH into: check systemd units, read /etc, run chroot /host for full host tooling. Use it for read-mostly diagnostics and the documented workarounds, because changes made inside a debug pod vanish with the next machine config reconciliation. Mentioning that ephemeral nature, and pointing node changes at MachineConfigs instead, is the finishing touch for this entry in OpenShift interview questions.

oc adm is the administrative half of the CLI: oc adm top node and top pod for live consumption, oc adm drain before node work, oc adm taint for scheduling control, oc adm must-gather for support bundles, oc adm prune builds and prune images for reclamation, and oc adm policy for RBAC changes. The habit it signals: administrative action is deliberate and scoped, which is exactly the posture OpenShift interview questions on operations are designed to verify.

It scaffolds a whole application from one input: given a Git URL it detects the language, picks a matching builder image, creates a BuildConfig, an ImageStream, and a DeploymentConfig or Deployment wired together with an image change trigger, plus a Service; oc new-app . --name=api against a local directory does the same. Follow it with oc logs -f bc/api to watch the first build. It is the fastest way to demonstrate the platform’s build-to-route story live, which is why demos built on it appear throughout OpenShift interview questions.

A template is an OpenShift object bundling multiple resources with parameters: process it with oc process to substitute values, then pipe to oc apply -f -, and the web console can present it as a fillable form. Templates are parameter substitution with no lifecycle; Helm is a full package manager with release tracking, rollback, and upgrades, and OpenShift ships Helm support natively. The current guidance: templates remain fine for quick provisioning and catalog forms, Helm or GitOps for managed application lifecycles, and that comparison is a favorite follow-up in OpenShift interview questions.

Cluster admins hold the cluster-admin ClusterRole bound cluster-wide: control over every namespace, node, and cluster-scoped resource, effectively root on the platform. Project admins hold roles bound within one namespace, so they can manage workloads, secrets, and RBAC there and nowhere else. Real clusters minimize the cluster-admin list and delegate per project, because anyone with cluster admin can read every secret. Where you would draw that line, and why, is the judgment half of this and most RBAC-flavored OpenShift interview questions.

CRI-O is a lightweight container runtime implementing exactly the Kubernetes Container Runtime Interface: it pulls images, and runs them via runc and crun, with nothing else. OpenShift uses it because the platform wants the smallest, supported, security-focused surface, while Docker brought a daemon with features the cluster never needed and licensing friction. Practical takeaway: containerd and CRI-O both speak CRI, so images and OCI tooling are unchanged, and being able to say that calmly handles the runtime half of many OpenShift interview questions.

Three control plane machines for high availability, because etcd, the cluster’s state store, runs on the masters and needs quorum: losing one master is survivable, losing two takes the API with it. The control plane is self-hosted, meaning control plane components, etcd included, run as workloads managed by their own operators. Never colocate etcd with I/O-heavy workloads, since disk latency shows up as API slowness first. That quorum arithmetic is the factual core, and the latency caveat is the detail that elevates the answer.

Installer-provisioned infrastructure, IPI, has the OpenShift installer create every machine through a cloud or virtualization API, networks included, then bootstrap the cluster: fast, repeatable, opinionated. User-provisioned infrastructure, UPI, means you supply the machines and networking to a standard the installer’s generated Ignition configs expect: more control for air-gapped or unusual estates, more responsibility for getting DNS, load balancers, and load-bearing details right. Naming the tradeoff, speed and standards versus control, answers the shape most OpenShift interview questions expect on cluster provisioning.

They are the managed flavors: ROSA runs on AWS, Azure Red Hat OpenShift on Azure, and OpenShift Dedicated on Red Hat-hosted cloud accounts, with Red Hat and the cloud provider sharing operational duty for control plane, upgrades, and SLAs. Self-managed OpenShift puts all of that on your team. The interview angle is knowing what you give up: less direct control over the underlying machines and versions, in exchange for the provider carrying platform lifecycle. That shared-responsibility framing is the complete answer.

RHEL CoreOS is Red Hat’s container-optimized RHEL: a minimal, image-based operating system where changes ship as a new bootable image rather than package mutations. OpenShift uses it so the platform, through the Machine Config Operator, can manage the OS the same way it manages workloads: declaratively, atomically, and with rollback. You rarely SSH and patch; you declare a MachineConfig and the cluster rolls it out. That nodes-as-cattle-to-the-OS-level idea is the conceptual target of this recurring entry in OpenShift interview questions.

OpenShift Local, formerly CodeReady Containers, runs a minimal single-node OpenShift in a VM on your workstation, with the real operator stack, routes, registry, and builds intact. It is for learning, demos, and validating manifests against the real platform, explicitly not for production or meaningful performance work. It needs a chunky host, tens of gigabytes of RAM, and it must be renewed periodically. Recommending it unprompted as the cheapest honest way to practice this bank is a strong closing note in junior-facing OpenShift interview questions.

They hold the platform: openshift-apiserver, openshift-ingress, openshift-image-registry, openshift-monitoring, openshift-authentication, and dozens more, each owned by a cluster operator that will reconcile away your hand edits. The rule interviewers want stated plainly: treat them as read-only except through the operator-owned custom resources meant for configuration, because direct edits are reverted or flagged as cluster degradation. Knowing where the platform lives, and that it fights back, is the respect line this beginner topic is really drawing.

Answer: Edge termination decrypts TLS at the router and forwards plaintext HTTP to the pod, the common case when the cluster is trusted inside. Re-encrypt terminates at the router and opens a second TLS session to the pod, using a destinationCACertificate or the service CA, keeping the internal hop encrypted. Passthrough forwards the original TLS untouched, SNI-only routing, so the application itself must serve the certificate, typically a service serving cert. Expect follow-up OpenShift interview questions on insecureEdgeTerminationPolicy, which controls whether plain HTTP is blocked, allowed, or redirected.

Answer: The Ingress Controller resource, managed by the ingress operator, runs HAProxy deployments that watch Route objects and render them into router config, reloading on change; per-route behavior like timeouts is set through annotations the controller maps to HAProxy directives. Sharding splits the route space across multiple controllers: each gets a domain and a selector, by namespace or route label, so one team can have a dedicated router with its own tuning or node placement. The caveat to volunteer: shard domains change published hostnames, so plan DNS and certificates before splitting traffic.

Answer: Routes are the native, richer object: re-encrypt with destination CA, weighted alternate backends, wildcard policies, and a deep annotation set, and they are what oc expose produces. The Ingress resource is supported and implemented by the same router, and exists for Kubernetes API portability, so GitOps repos or tools written against upstream manifests work unchanged. The senior answer picks by constraint: choose Ingress when portability rules the pipeline, choose Route when you need platform features. That reasoned tie-break, not a preference, is what OpenShift interview questions on this topic are grading.

Answer: The platform runs the build as a pod: it clones source, injects it and any .s2i/environment values into the builder image, and executes the image’s assemble script; at deploy time the same image’s run script starts the app. Customize by committing a .s2i/bin directory whose scripts override or wrap the defaults, including save-artifacts for incremental builds that reuse previous dependencies. The caveat worth stating: script errors surface as a failed build pod, so read oc logs bc/name output, not just pod status, when builds break.

Answer: Source (S2I) needs no Dockerfile and inherits a maintained builder image, the fastest path to standardized builds. Docker runs your Dockerfile inside a build pod, the escape hatch when you need full control of layers and base images. Custom runs a builder image of your making whose entry script does everything, used for exotic toolchains. Pipeline strategy, the Jenkins-based legacy path, is deprecated in favor of OpenShift Pipelines (Tekton), so naming it as legacy is part of a current answer. Difficulty in OpenShift interview questions here comes from justifying the choice per workload, not listing four names.

Answer: A BuildConfig fires on GitHub or generic webhooks, on config changes, or on changes to an image it uses. Each run is a plain pod in your project: the source clone can use a source secret, input secrets like .npmrc or .netrc get mounted for the build only, and output push credentials come from the output secret. Webhook URLs carry a secret token, so treat them like credentials. The production caveat: build pods consume real resources, so quota them and prune old builds, because unbounded build history is a slow disk-fill incident.

Answer: A build pushes its image to the output ImageStream, internal registry by default or an external one with a push secret. Chained builds are the pattern to name: a first build produces a fat artifact image, a second Docker-strategy build copies artifacts onto a slim runtime base, referenced via the first stream. Reclaim space with oc adm prune builds and oc adm prune images, ideally scheduled, because the internal registry grows monotonically otherwise. That pruning habit, or its absence, is a tell in mid-level OpenShift interview questions about long-lived clusters.

Answer: An ImageStream tag resolves to an image digest; pods referencing it pull either the external source or the stream’s local copy depending on referencePolicy (Local makes pulls resolve to the internal registry, which survives external credentials expiring). Tags on external images can be imported on a schedule, so an upstream tag update lands as a stream event and triggers rollouts via image change triggers. Pin to digest for immutability when needed. The mechanism detail interviewers chase is the trigger chain, which is exactly the hinge for the CI/CD-focused OpenShift interview questions that follow in senior rounds.

Answer: A config or image change creates a deployer pod that executes the strategy: Rolling scales new pods up in waves controlled by maxSurge and maxUnavailable with probes gating readiness, while Recreate scales the old generation to zero first, the right call for volumes that cannot be shared. Lifecycle hooks, pre, mid, and post, run commands against the new or old deployment mid-rollout, and failure at any point can pause the rollout for inspection. Since deployer pods are workloads, a wedged deploy is visible as a stuck deployer pod in the project, the first thing mid-level OpenShift interview questions expect you to check.

Answer: Red Hat recommends Deployments for new workloads: the upstream object has absorbed the missing features, integrates cleanly with GitOps and Helm, and avoids the DC-only deployer machinery. DeploymentConfigs remain supported, and legacy ones keep running, but there is no automatic conversion, so migration is authoring equivalent Deployment manifests, moving any pre and post hooks into tooling, and verifying image change triggers against ImageStreams, which Deployments support. Leading with the recommendation and the migration reality is the shape senior OpenShift interview questions reward on this topic.

Answer: At admission, the pod’s service account determines which SCCs it may use, since SCCs are cluster-scoped objects granted through RBAC with the use verb on role bindings; the admission plugin then evaluates the pod’s requested security context against every eligible SCC and applies the highest-priority one that satisfies all constraints. restricted-v2 is the floor every authenticated user gets. Two implications to state: permissions live in bindings, so oc adm policy add-scc-to-user anyuid -z mysa is the fix pattern, and the decision is per pod, which is why half-patched rollouts show mixed results in OpenShift interview questions about admission behavior.

Answer: anyuid lets pods run as any requested UID, the classic accommodation for vendor images assuming root. nonroot allows any non-zero UID, useful when an image manages its own user. privileged removes essentially all constraints, appropriate for platform components and rarely for tenant workloads. hostnetwork permits using the node’s network namespace, seen in CNI-adjacent and high-performance workloads. Each also has runAsUser strategy and capability implications, so grant the narrowest one that unblocks the image, and bind it to a service account, never a group of users. That narrowing principle is the graded half of these OpenShift interview questions.

Answer: OpenShift runs both systems: PSA labels on a namespace (pod-security.kubernetes.io/enforce and friends) and SCCs evaluated at admission. The supported position is that SCCs remain the enforcement mechanism, with PSA labels aligned to the equivalent SCC, restricted maps toward restricted-v2, privileged toward privileged; violations show up as warnings, and mismatched combinations can reject pods either system would otherwise admit. The practical rule: when a pod is denied, check both the namespace labels and the service account’s SCC bindings before concluding anything, because the two layers overlap in exactly the way OpenShift interview questions on security like to probe.

Answer: Every pod runs under a service account, defaulting to the project’s default one, and that identity owns its RBAC, including SCC eligibility. The clean remediation for a denial is a dedicated service account for the workload, a role binding granting it one specific SCC, and setting serviceAccountName on the workload; nothing else in the project gains the privilege. Granting SCCs to default or to broad groups is the anti-pattern to name explicitly, because it silently widens the blast radius of every other workload in the namespace, a distinction senior OpenShift interview questions listen for.

Answer: An Identity records one authentication from one provider, provider name plus provider-specific ID; a User is the platform principal that RBAC attaches to, and it can hold several identities via the mapping method. Methods: add links a new identity to a matching user name, the default; lookup only succeeds if a user already exists, good for gated onboarding; generate provisions the user on first login; deny refuses linking. The operational trap: deleting a user but leaving its identity can resurrect the mapping on next login, so clean up both, which is the nuance OpenShift interview questions on lifecycle management dig for.

Answer: Groups are OpenShift objects you create with oc adm groups new, and the enterprise pattern is LDAP sync: oc adm groups sync maps LDAP groups to OpenShift groups on a schedule, maintaining membership automatically from the directory of record. RBAC then binds roles to groups, not individuals, so onboarding and offloading happen upstream and propagate. Augmented detail to include: augmented users still need an identity provider for authentication, groups only shape authorization, and running sync as a scheduled job with a whitelist keeps membership auditable. Directory-driven authorization is the whole point of this entry in OpenShift interview questions.

Answer: Two families: OAuth tokens for humans, obtained at login, carried as bearer tokens, expiring per the OAuth configuration’s max age and revocable via oc adm logout-style flows on the OAuth server side; and service account tokens, projected into pods as bound, short-lived credentials that rotate automatically with the pod. oc whoami -t prints your current OAuth token, so never paste it into logs or CI without scoping. Older static SA tokens are deprecated, and long-lived automation should use bound tokens or its own identity, the hygiene point these OpenShift interview questions are really testing.

Answer: Every operator reports Available (component functional), Progressing (reconciling or rolling out), and Degraded (functional but impaired, investigate now), plus Upgradeable, which is the one that blocks: an operator that sets Upgradeable to False stops the Cluster Version Operator from starting an update until the reason clears. Read them with oc get co and drill with oc get co <name> -o yaml for condition messages. The triage order, Degraded conditions first, then Upgradeable blockers, then Progressing stragglers, is the repeatable answer OpenShift interview questions on cluster health want.

Answer: The CVO reads the desired state on the ClusterVersion resource, fetches the signed release payload image for that version, and installs or updates every cluster operator from it. Updates are chosen from a graph served by update services, and channels shape which edges exist: stable for recommended paths, fast for early access to the same artifacts, eus for extended-update-support jumps between even-numbered minors. Unsafe edges simply do not exist in the graph, which is why upgrades follow known-good paths. Explaining the graph model cleanly is the discriminator in upgrade-focused OpenShift interview questions.

Answer: Pre-flight: confirm oc get co is fully Available and nothing blocks Upgradeable, take an etcd backup, and check your operators’ compatibility with the target version. Then oc adm upgrade to see offers and oc adm upgrade --to-latest to start. The CVO rolls control plane operators first, API stays up through it, then worker-facing components, and finally the Machine Config Operator drains and reboots nodes pool by pool under maxUnavailable. Watch with oc get clusterversion and per-node progress. Control plane before workers, nodes last, is the sequencing sentence upgrade-tier OpenShift interview questions exist to extract.

Answer: The controller merges your MachineConfig with the base and rendered configs into one per-pool desired state; each node’s machine-config-daemon compares current versus desired, drains the node respecting PodDisruptionBudgets, writes the new files or ignition-layered OS state, updates kubelet config if touched, and reboots. The pool proceeds only as nodes rejoin healthy, bounded by maxUnavailable. Two caveats: a paused pool silently stops applying anything, and a stuck drain blocks the pool, so PDB hygiene matters before node-touching changes. That drain-then-reboot loop is the core mechanism behind half the node-tier OpenShift interview questions.

Answer: Kubelet changes go through a KubeletConfig custom resource targeting machine config pools by selector, so values like maxPods or log verbosity roll out with the MCO’s drain-and-reboot discipline instead of hand edits that reconciliation would revert. Node-level sysctls and performance tuning belong to the Node Tuning Operator, where a Tuned object declares profiles per node label. Unsafe sysctls additionally need enabling at the API level. Declaring, not editing, is the theme, and naming both CRs is what distinguishes an operator-fluent answer to these OpenShift interview questions from a book answer.

Answer: Back up before upgrades and before risky changes using the documented flow: run the cluster-backup.sh script from an etcd member via a debug pod, which snapshots the store plus static pod manifests to a safe location. Recovery is a restore procedure, not a copy-back: you re-provision control plane machines pointed at the snapshot, so it is disruptive and tested rarely, which is exactly why it must be rehearsed. Also know the platform handles routine compaction and defragmentation automatically. Backup cadence plus restore rehearsal is the full-credit shape of these OpenShift interview questions on state.

Answer: The platform issues and rotates nearly everything: kubelet and component certificates rotate automatically, and the service CA operator mints serving certificates for any service annotated with service.beta.openshift.io/serving-cert-secret-name, trusted cluster-wide via the service CA bundle. To make pods trust a custom CA, put it in the user-ca-bundle configmap and reference it through the proxy or image registry configuration as appropriate. The incident to have ready: an app behind passthrough serving its own expired cert, since rotation is platform-managed only for platform-issued material, a distinction that recurs in OpenShift interview questions on TLS.

Answer: The cluster monitoring operator deploys Prometheus, Alertmanager, and node exporters for platform health, with retention and storage configurable through its config map; user workload monitoring is a separate stack you enable by setting enableUserWorkload: true in the cluster-monitoring-config, which deploys dedicated Prometheus and Thanos Ruler instances for tenant namespaces. Your pods then need nothing special beyond standard metrics endpoints and optionally ServiceMonitors via the included Operator. Capacity caveat: tenant scrape volume is real, so set retention deliberately. Naming the two-stack split is the detail these OpenShift interview questions separate on.

Answer: The cluster logging operator deploys a collector per node, Vector in current versions, replacing the earlier Fluentd, that tails container and journal logs; storage moved to LokiStack via the Loki operator after Elasticsearch-based logging reached end of life, and ClusterLogForwarder ships selected logs to external endpoints such as syslog or cloud services. Deployment is declarative: a ClusterLogging instance plus a LokiStack for retention. The operational caveat: forwarding filters and retention are where cost lives, so scope what you keep. Knowing the Vector and LokiStack transition dates this topic in OpenShift interview questions as a freshness probe.

Answer: A PVC names a StorageClass; the class’s CSI provisioner creates the backing volume on the infrastructure you run, cloud disks or an on-prem array, and binds it to the claim, with the cluster default class marked via the storageclass.kubernetes.io/is-default-class annotation so bare claims still bind. Access modes constrain the win: RWO attaches to one node, RWX requires a filesystem-sharing backend, ROX for read-only sharing. Expansion works where the driver allows it via allowVolumeExpansion. Quota objects count PVCs separately from compute, a pairing that shows up in storage-focused OpenShift interview questions.

Answer: OpenShift Data Foundation, the Ceph-based software-defined stack formerly called OCS, is the full solution: block, file, and object with RWX, replication, and multi-attach patterns, sized for real clusters and priced accordingly. LVM Storage is the lightweight option for smaller footprints and single-node or edge clusters, giving local PVCs and thin provisioning without a Ceph fleet. The judgment call interviewers want: match storage weight to workload criticality, and never let the default class silently point at something unsuitable for stateful services. Picking by constraint, not brand loyalty, is the mature form of these OpenShift interview questions.

Answer: Quotas can be scoped, for example Terminating or NotTerminating by active deadline, and BestEffort or NotBestEffort by QoS, letting you budget bursty versus guaranteed work separately. The admission behavior to know cold: once any compute quota exists in a project, a pod without explicit requests is rejected outright, because unrequested usage cannot be accounted; object-count quotas similarly refuse creating the object past the cap. Paired with a LimitRange injecting defaults, this becomes invisible; without one, it is a confusing CreateContainerConfigError-adjacent failure. That pairing explains most quota confusion in OpenShift interview questions.

Answer: CatalogSources hold the catalogs (index images); a Subscription pins an operator to a channel and namespace; OLM resolves it into an InstallPlan listing exact resources; approving the plan yields a ClusterServiceVersion, the operator’s installed manifestation carrying its CRDs, RBAC, and deployment. States tell the story: subscription healthy, plan pending approval, CSV progressing or succeeded. Drill with oc get catalogsource,sub,csv in the operator’s namespace. The vocabulary chain, catalog to subscription to plan to CSV, is precisely the sequence operator-lifecycle OpenShift interview questions ask you to narrate.

Answer: An OperatorGroup, one per namespace, declares which namespaces the operators installed there may target, and its selected namespaces must match the operator’s declared install mode: OwnNamespace watches its own, SingleNamespace one other, MultiNamespace several, AllNamespaces the cluster. Install a mode-mismatched operator into the wrong group and the subscription stalls with a resolution failure, the classic silent hang. Cluster-wide capabilities still require cluster-scoped RBAC regardless of mode. Naming the mismatch symptom, subscription stuck, plan never generated, is the diagnostic detail these OpenShift interview questions fish for.

Answer: Catalogs are images, so air-gapped clusters mirror them: you use oc-mirror or equivalent to copy operator catalogs, release images, and their dependencies into a private registry, then point the cluster at the mirror through ImageDigestMirrorSet (the successor to ImageContentSourcePolicy) and reduced CatalogSources referencing the mirrored index. Registry credentials and CA trust live in the usual cluster config. The failure mode to volunteer: partial mirrors that miss a dependency make subscriptions resolve forever, so validate the mirror set against the full dependency closure. Mirroring discipline is the differentiator in disconnected-cluster OpenShift interview questions.

Answer: By default, with OVN-Kubernetes, all pods in all namespaces can reach each other unless policies say otherwise; there is no built-in multitenant isolation. Isolation is opt-in via NetworkPolicy: a default-deny ingress policy per namespace, then explicit allows from labeled sources, plus egress policies where needed. OVN-K enforces these at the node level. The gap to name: NetworkPolicy is L3/L4, so exfiltration over allowed ports stays possible until you add egress firewalls or service meshes. Default-allow, isolate deliberately is the sentence that completes this tier of OpenShift interview questions on networking.

Answer: Two orthogonal tools. Egress IPs assign stable source addresses to a namespace’s outbound traffic, defined on the NetAttach or egress IP configuration and placed on nodes that can route them, so external systems can firewall by known IP instead of node churn. An EgressFirewall, one per project, filters outbound destinations by CIDR and port, allow or deny, enforced by OVN. Together they answer the compliance question, predictable identity plus egress restriction. The caveat: egress IP capacity is per node, so placement planning is part of a real answer in networking-heavy OpenShift interview questions.

Answer: Replicas for router capacity, nodePlacement to pin routers onto infra nodes, endpointPublishingStrategy (LoadBalancer service, HostNetwork, NodePort) to fit the platform, tlsSecurityProfile to enforce modern cipher policy cluster-wide, and route admission settings such as wildcard policy allowance. Per-route behavior, timeouts, proxy buffering, stays in annotations, but fleet posture lives on the controller CR. Editing the router deployment directly is the anti-pattern, since the operator reconciles it back. That declarative-boundary point is what separates operator-era answers in OpenShift interview questions from handcrafted-cluster habits.

Answer: Infra nodes are labeled workers dedicated to platform components: the router, registry, monitoring, and logging stacks move there via their operators’ node selectors, leaving worker capacity purely for tenant workloads. Benefits: tenant scaling never disturbs ingress or observability, resource contention drops, and in Red Hat licensing terms platform-only nodes do not run your subscriptions’ application load. Migration order matters, monitoring before logging before registry, with storage and LoadBalancer implications checked. The licensing plus stability duo is the complete answer, and it recurs in cost-focused OpenShift interview questions.

Answer: Built-in project roles are admin, edit, and view, bound with oc adm policy add-role-to-user or add-role-to-group -n project; cluster-wide grants use ClusterRoleBindings, and the sudoer cluster role enables impersonation for audited acts-as operations. Audit with oc adm policy who-can and oc auth can-i checks before scripting privileged changes, and keep a break-glass cluster-admin credential separate from daily identity. Least privilege plus auditable escalation is the posture OpenShift interview questions on RBAC are verifying when they ask how you run access.

Answer: The request authenticates via your OAuth token, authorizes through RBAC, then passes admission: validating and mutating webhooks, quota and LimitRange accounting, and finally SCC evaluation, which may mutate the pod’s security context to fit the constraint. The scheduler then places the pod, kubelet pulls via the CRI-O runtime with mirror resolution, and the sandbox starts. Knowing the full chain means knowing all the rejection points: auth, admission, quota, SCC, scheduling, pulling, the exact checklist scenario-tier OpenShift interview questions expect when a pod never starts.

Answer: oc adm must-gather runs a collector pod that pulls cluster state, operator namespaces, pod specs, events, and key logs into a tarball you attach to the case; scope it for speed with a specific namespace or a specialized gather image, for example the networking one, when the problem is bounded. For node-level depth, oc debug node plus sosreport captures host state the cluster view cannot see. Time-box big gathers, they are heavy. Must-gather fluency signals real support interaction, which is the credibility these operational OpenShift interview questions seek.

Answer: It periodically sends a masked snapshot of cluster configuration and health to Red Hat’s hybrid cloud console and surfaces back targeted recommendations, known issues your specific configuration hits, upgrade risks, and misconfigurations, visible as the cluster’s Advisor health checks. It works in disconnected modes with reduced data, and it can be disabled, though most shops keep it for the early-warning value. The operational habit it enables: checking Insights findings before upgrades, since Red Hat flags exactly the configurations that historically break them, a practice senior OpenShift interview questions increasingly expect you to mention.

Answer: Read the event text first: oc describe pod shows the exact denial, usually a container image requesting UID 0 against restricted-v2. Second, check what the pod may use: oc get pod -o yaml for its service account, then oc adm policy who-can use scc anyuid style checks or oc get rolebinding -o yaml in the namespace. Third, decide the fix path: best is making the image run as an arbitrary non-root UID, second-best is binding one SCC like anyuid to a dedicated service account and setting serviceAccountName. This SCC-denial order, event, eligibility, narrowest fix, is the most frequent shape in scenario OpenShift interview questions.

Answer: The router says it has no usable backend, so verify the chain it reads. One: oc get endpoints <service> in the route’s namespace; empty endpoints mean the selector matches nothing or readiness probes fail, and that resolves most cases. Two: compare the route’s target port with the service port using oc get route,svc -o yaml, a mismatch here produces exactly this symptom. Three: check pods are in the route’s namespace and not crash-looping post-readiness. Four: check router logs for the host mapping. Ordering matters because endpoints are where readiness truth lives, and stating that reasoning is what the 503 version of OpenShift interview questions scores.

Answer: Identify the termination mode first, because it decides who holds the cert: oc get route -o yaml shows termination and tls.certificate. For edge or re-encrypt, the route object carries the cert, so verify the new certificate and key actually landed, the key matches, and the full chain is present, since a missing intermediate produces warnings that openssl will confirm with openssl s_client against the host. For passthrough, the app serves its own cert, so the fix is inside the workload or its service serving cert. Finish by checking insecureEdgeTerminationPolicy for redirect behavior. That mode-first order is the reasoning TLS questions in OpenShift interview scenarios reward.

Answer: Read the build log end to end, not just the tail: oc logs build/<name> shows the assemble script’s actual error, and the line usually names the layer that changed. Distinguish the three common classes: source changed (new dependency incompatible with the builder image’s runtime), builder image changed (stream moved to a newer language version with breaking defaults), or environment changed (a missing secret or .s2i/environment value, often after a credentials rotation). Then pin deliberately: reference a specific builder tag, fix the dependency, or restore the secret, and re-run with a clean build. Correlating the failure line to which input drifted is the exact skill mid-senior OpenShift interview questions are testing with this scenario.

Answer: Rollouts only happen if something is watching, so check the trigger chain in order. One: does the Deployment or DC carry an image change trigger on that ImageStream tag, visible in oc get deploy/dc -o yaml? Scaffolds created outside oc new-app often lack it. Two: did the stream actually update, oc get is <name> -o yaml for the tag’s digest and timestamp; a push to a different tag or project is the classic miss. Three: if the tag is external, check the scheduled import actually ran. The fix is adding the trigger or oc set triggers, then verifying the rollout starts. Trigger-chain literacy is precisely what this genre of OpenShift interview questions measures.

Answer: Never restart anything first. One: read the Degraded condition’s message, oc get co <name> -o yaml, which usually names the resource it cannot reconcile. Two: inspect the operator’s own namespace: pods with oc get pods -n <operator-ns>, then its logs for reconciliation errors. Three: check the operands it manages, since a Degraded ingress operator usually points at router pods or LoadBalancer service trouble. Four: correlate recent change, an upgrade, a MachineConfig rollout, or a hand edit someone made to a managed resource. Report before repairing, because Degraded is diagnostic state, and killing pods destroys the evidence the condition preserves, a discipline senior OpenShift interview questions explicitly grade.

Answer: Layer the checks: oc get clusterversion for overall state and any failing condition; then oc get mcp to see whether the worker pool shows an updating node with UPDATED= False; then that node: oc get node <name> for status, and oc describe node for the drain or machine-config event blocking it. The two classic culprits: a drain wedged on a PodDisruptionBudget that cannot be satisfied, and a machine-config-daemon failing mid-update, visible in the node’s MCD logs. Resolve the PDB or the daemon error, and the pool resumes. That clusterversion, pool, node funnel is the canonical stuck-upgrade order in OpenShift interview scenarios.

Answer: Establish scope first: oc get mcp tells you whether one node or the whole pool is churning, which decides urgency. Then get on the box through the platform: oc debug node/<name>, read the machine-config-daemon logs and journalctl -b -1 for what the previous boot failed at, since a bad ignition-layered file or kubelet config is usually visible there. Check whether the pool is paused and by whom. Remediation is reverting the offending MachineConfig or fixing the pool state, not hand-repairing the node, because reconciliation will replay your config. That scope-then-boot-log order is the expected frame for node-tier OpenShift interview scenarios.

Answer: Work from provider inward. One: confirm the secret content is valid htpasswd format, oc get secret htpass-secret -n openshift-config -o yaml and decode, since a malformed file or wrong key name breaks the whole provider. Two: check the authentication operator and OAuth pods are healthy, oc get co authentication and pods in openshift-authentication, because a bad OAuth CR triggers reconciliation failures you can read in their logs. Three: test with oc login as a known user. Four: for a single user failing while others succeed, check the User and Identity objects still link, since deletions half-applied cause exactly that. Format, operator, single-user split is the order this authentication scenario tests.

Answer: oc describe pod gives the scheduler’s verdict, and quota rejections name the exact budget exceeded. Then confirm: oc get resourcequota,limitrange in the namespace, compare usage against the cap, and check whether quota was added or tightened overnight, which oc get resourcequota -o yaml and the project’s events will show. Two subtleties to name: a newly added quota rejects pods lacking requests, so previously BestEffort workloads start failing, and object-count quotas can block scale-outs that compute headroom allows. The fix is requests plus a LimitRange so defaults exist. Quota-admission reading is the mechanism behind this Pending scenario in OpenShift interview questions.

Answer: This is LimitRange admission, not runtime eviction: the events say the container’s requests or limits violate the namespace’s floor, ceiling, or max limit-to-request ratio. Read the LimitRange with oc get limitrange -o yaml, then compare the workload’s resources block against it. Two shapes recur: workloads migrated from clusters without limits carrying values above the ceiling, and containers specifying a limit but no request where the ratio rule rejects the implied request. Fix the manifest to fit policy, or have the platform team adjust the range deliberately. Distinguishing admission rejection from kubelet eviction, and proving which from events, is the precise skill this scenario-grade OpenShift interview question examines.

Answer: Check the reference chain. One: what does the pod actually pull, oc get pod -o jsonpath='{.spec.containers[*].image}'; an external-style reference instead of the internal registry path means the workload bypasses the ImageStream and its referencePolicy. Two: does the ImageStream exist and hold the tag, since a missing stream removes the Local pull-through the platform normally arranges. Three: is a pull secret involved, stale credentials on a service account produce 401s in events. The clean fix is referencing the istag so pulls resolve internally. Reference-versus-registry-path mismatch is the root cause most variants of this OpenShift interview scenario hide.

Answer: Read the chain from the top: oc get sub -o yaml for the installedCSV it expects, then oc get ip for the InstallPlan, which is either awaiting manual approval, the silent one, or failing with a resolution message. A failing plan usually means catalog or dependency trouble: check CatalogSource pod health in openshift-marketplace, then the OperatorGroup, since an install mode versus target-namespace mismatch produces exactly this stall. Then oc get csv phase messages for the operator’s own install failure. Approval state, catalog health, OperatorGroup, CSV message is the four-step ladder OLM scenarios in OpenShift interview questions expect.

Answer: Treat it as a bad controller spec, since the operator faithfully reconciles toward whatever was just applied. Read the ingress operator and controller status, oc get co ingress and oc get ingresscontroller -n openshift-ingress-operator -o yaml, then the router pods’ logs in openshift-ingress for the config error, commonly an invalid TLS profile, a bad endpointPublishingStrategy for the platform, or a node selector matching no nodes. Revert the offending field to the previous value and let it stabilize before reapplying a corrected change incrementally. During the outage, note traffic can still flow via surviving replicas if the change rolled gradually. Spec-first, logs-second, revert-third is the order router-change OpenShift interview scenarios reward.

Answer: Pending means no binder matched, so enumerate the causes in likelihood order: the named StorageClass does not exist or is misspelled; a default class is absent and the claim names none; capacity or topology cannot be satisfied, common on zonal cloud disks where the volume must share the pod’s zone; or the requested access mode, typically RWX, is unavailable on any provisioner. Check oc get sc, the PVC events, and the CSI driver’s pods in openshift-cluster-csi-drivers. The platform-layer lesson to state: storage problems live at the class-and-driver layer, not the pod layer, and saying that framing earns the point in storage OpenShift interview scenarios.

Answer: Establish the boundary first: does the same lookup work inside the target project, and does the failure affect all services or cross-project only? DNS is served by the DNS operator’s CoreDNS pods, so oc get co dns and their pod health rule out platform failure; a oc debug pod with nslookup and reading /etc/resolv.conf shows what the client is actually querying. If the platform is healthy, the answer is usually policy or identity: a NetworkPolicy default-deny in the target namespace, or the caller simply lacking any route in, since DNS for a service exists cluster-wide even when traffic is blocked. Platform health, client config, then policy is the order DNS-flavored OpenShift interview scenarios grade.

Answer: With passthrough, the router is SNI-only, so the certificate is served by the application pod, and the failure means that cert expired or was replaced without its chain. Confirm with openssl s_client -connect <host>:443 -servername <host> through the router, reading the presented dates and chain, then inspect the serving secret the app mounts: if it is a service serving cert, check the annotation and let the service CA rotate it, and if it is a manually loaded cert, replace the secret and restart or hot-reload the app. The platform lesson: passthrough moves certificate lifecycle into the workload, which is the operational trade this OpenShift interview scenario is really asking you to articulate.

Answer: Builds are pods, so diagnose it as one. One: oc get pods for the build pod’s scheduler message, which usually names the binding failure. Two: quota, a project ResourceQuota with tight compute caps starves build pods first because they burst. Three: capacity, no schedulable node matching the build’s placement, often after tainted infra isolation. Four: stuck webhooks or admission on the build pod itself, visible in events. Five: the cluster-wide builds configuration restricting concurrent builds. Naming that builds are ordinary pods under ordinary admission is the insight the build-pending variant of OpenShift interview scenarios is probing.

Answer: Read one event verbatim: the registry hostname and the auth or not-found distinction decide the branch. 401 or 403 means credentials: check the pull secret on the workload’s service account, oc get sa <name> -o yaml, verify expiry and that the secret’s dockerconfigjson actually covers that registry path. Manifest unknown or forbidden with valid auth means the tag or repository path is wrong, or the external registry requires an ImageDigestMirrorSet you have not configured in a restricted network. Fix at the service account or mirror layer, then let the rollout proceed. Auth-versus-path split first, secret second, mirror third is the ladder registry PullBackOff OpenShift interview scenarios expect.

Answer: The workloads were quietly relying on a broad SCC binding, and without it admission no longer permits their root entrypoints, so containers die at start and the deployment retries. Confirm from events and previous-container logs: permission denied on a bind or setuid is the signature. The right response is not re-granting the loose binding: audit which images genuinely need elevated UID, fix the images to run as arbitrary non-root users, and issue narrow grants to dedicated service accounts where a vendor image cannot be changed. Governance pressure plus technical fix is the complete answer, and saying both is what separates senior responses in SCC-revocation OpenShift interview scenarios.

Answer: Establish what is filling the disk before touching pods: oc debug node, then df -h against the node root and container storage, followed by du over /var/lib/containers and /var/log to split images from logs. Common culprits in order: unbounded application logs, an unpinned accumulation of unused images that garbage collection is not keeping up with, and crash-looping pods rewriting layers. Reclaim with image pruning and retention settings, fix the noisy logger, and set eviction thresholds and monitoring so pressure alerts before evictions. Growth attribution before cleanup is the discipline this node-storage OpenShift interview scenario tests.

Answer: A stuck drain is almost always a PodDisruptionBudget that no longer has a legal eviction: usually a singleton with a PDB requiring one available replica, or a StatefulSet mid-failover. Verify with oc get pdb -A and oc describe node to see the blocking pod, then choose deliberately: scale the application to allow an eviction, temporarily relax the PDB with change control, or in a genuine emergency use a forced drain accepting the availability hit. After the update, restore the PDB. Naming the tradeoff rather than reaching for force immediately is the judgment the drain-stall variant of OpenShift interview scenarios scores.

Answer: Triangulate the layer: if the API answers for a token but passwords fail, the OAuth server or its identity provider is the suspect; if even tokens fail, the authentication operator or API server itself is down. Check oc get co authentication and the pods in openshift-authentication and openshift-oauth-apiserver, reading recent events and logs for restart loops or certificate trouble. Recent-change correlation is decisive: an identity provider config edit, an expired secret, or a DNS or load balancer change in front of OAuth. While degraded, machine identities and existing tokens still work, which is your bridge for fixes. That token-versus-password split is the entry point these authentication-outage OpenShift interview scenarios are built around.

Answer: Suspect sharding first: if a new IngressController with a namespace or label selector was added, the route may now be picked up by a different shard whose domain and certificates differ, producing wrong hostnames or TLS errors. Verify where the route actually lives: oc get route -A and compare its labels and namespace against each controller’s selector, then check external DNS still points at the right router’s LoadBalancer. The fix is aligning the route’s labels or the shard selectors so ownership is unambiguous, plus a documented convention so it stays that way. Ownership-by-selector ambiguity is the root cause this routing OpenShift interview scenario hides.

Answer: Suspect etcd pressure on the control plane, since every API call transits it and slow disks surface as API latency and watch streams lag. Evidence path: oc get co etcd for Degraded conditions, etcd pod metrics for slow apply and fsync latencies, and node-level disk I/O on the masters, confirming whether a colocated workload or a noisy storage backend is competing. The structural fix is what you state for prevention: masters are control-plane-only, etcd lives on fast local storage, and nothing tenant-side should ever schedule there. Control-plane hygiene as latency defense is the depth marker in this performance-flavored tier of OpenShift interview scenarios.

Answer: Pruning removes manifests and tags from the registry’s metadata, but physical bytes only vanish after the storage backend’s own garbage collection runs, and layers stay while any manifest still references them. Check what still pins the layers: tags in other ImageStreams, including stopped pipelines’ outputs, and running pods referencing old digests. Then trigger the registry’s garbage collection per the documented procedure for your storage backend, scheduling it off-peak since it is I/O heavy. The two-phase truth, prune is metadata, GC is bytes, is precisely the mechanism this registry-housekeeping OpenShift interview scenario exists to distinguish.