OpenShift Interview Questions and Answers

What interviewers are testing: whether you name Routes, SCC, ImageStreams, and Cluster Operators as the OpenShift layer on standard Kubernetes.

Kubernetes is the open-source orchestration API and control plane. OpenShift is Red Hat's enterprise Kubernetes distribution that embeds Kubernetes and adds integrated components, hardened defaults, and a supported lifecycle.

OpenShift still runs standard Kubernetes objects—Deployments, Services, ConfigMaps, Secrets—so upstream YAML often works unchanged until you hit OpenShift-specific resources.

A strong answer is:

"Kubernetes is the API; OpenShift is a supported distribution with routes, SCC, integrated builds and registry, and Cluster Operators for upgrades. I deploy the same Deployments, but I expose them with Routes and I never ignore SCC when a pod fails to start."

What interviewers are testing: Whether you can separate Kubernetes control-plane components, OpenShift Cluster Operators, node management through MCO/RHCOS, ingress, registry, and workload placement.

In current OpenShift 4.20 clusters, control plane and compute nodes use RHCOS and are managed declaratively through platform Operators.

Day-2 operations lean on Cluster Operators—each reports health in ClusterOperator objects.

A strong answer is:

"OpenShift 4 is Kubernetes on RHCOS with extra controllers for routes, builds, and the integrated registry, plus OLM for Operators. I check ClusterOperator status when something platform-wide breaks—not just individual pods."

What interviewers are testing: Whether you can distinguish control-plane workloads from node-level DaemonSets and platform workloads that may be scheduled on compute/infra nodes.

Control plane nodes host the Kubernetes control plane and OpenShift-specific controllers:

• kube-apiserver — serves core and *.openshift.io APIs
• kube-scheduler and kube-controller-manager
• etcd (typically dedicated or co-located per topology)
• OpenShift API server and OpenShift controller manager
• Operator pods for platform components (authentication, console, DNS, etc.)

Compute nodes normally host application workloads. Platform workloads such as ingress routers, registry, and monitoring are scheduled according to their Operator configuration and may run on worker or dedicated infrastructure nodes. In compact/topology variants some roles colocate—know your cluster's control plane node count and whether masters are schedulable.

A strong answer is:

"The control plane runs the Kubernetes and OpenShift API servers, etcd, schedulers, and platform Operators. Application workloads normally run on workers. Some platform components have explicit placement rules—CNI/node agents run per node, while router, registry, and monitoring placement depends on cluster configuration."

What interviewers are testing: Whether you know node configuration is declarative and Operator-managed, and can explain why ad-hoc host mutation conflicts with the OpenShift lifecycle model.

RHCOS (Red Hat Enterprise Linux CoreOS) is the immutable OS image for OpenShift nodes. You do not ssh in to yum install packages—configuration is declarative.

The Machine Config Operator (MCO) applies MachineConfig objects that render into Ignition and roll out to nodes in a controlled pool (masters vs workers). Changes trigger cordoned reboots when required (kernel, kubelet flags).

A strong answer is:

"RHCOS is immutable—node changes go through MachineConfig and the MCO, not ad-hoc package installs. I treat worker pool updates like a rolling maintenance window because MCO may reboot nodes."

What interviewers are testing: Whether you use ClusterOperator conditions to diagnose platform-wide health and understand Available/Progressing/Degraded during incidents and upgrades.

Cluster Operators are the platform's own Operators—each manages a slice of cluster functionality and reports Available, Progressing, and Degraded in:

oc get clusteroperators

Examples: authentication, console, dns, ingress, image-registry, kube-apiserver, network, storage, machine-config.

During upgrades or incidents, oc adm upgrade and oc get co tell you whether the platform itself is healthy before you blame application Deployments.

A strong answer is:

"Cluster Operators are the managed control-plane services. If routes break cluster-wide, I check the ingress ClusterOperator before restarting random router pods."

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

oc is OpenShift's CLI—it wraps kubectl and adds OpenShift resources and workflows.

Use oc for day-to-day OpenShift work; kubectl still works when kubeconfig is valid—handy in CI that only ships kubectl.

A strong answer is:

"oc is kubectl plus OpenShift ergonomics—login, projects, new-app, routes, builds. Under the hood it's the same API; I use oc for platform workflows and kubectl in generic pipelines when only kubeconfig is available."

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

oc login authenticates against the OpenShift OAuth server and writes credentials into kubeconfig:

oc login https://api.cluster.example.com:6443 -u developer
oc whoami
oc project demo

• User and groups come from OAuth identity providers (htpasswd, LDAP, OIDC)
• Project maps to a Kubernetes namespace with extra metadata and default RBAC
• oc status summarizes resources in the current project

In interviews, mention least privilege: developers get edit in their project, not cluster-admin.

A strong answer is:

"oc login stores a token or cert in kubeconfig and binds me to a project namespace. I verify with oc whoami and oc project before applying YAML so I don't patch production by mistake."

What interviewers are testing: whether you define an OpenShift project compared to a Kubernetes namespace and connect it to project in production—not textbook definitions only.

A project is a Kubernetes namespace plus OpenShift defaults:

oc new-project shop creates the namespace shop and a Project resource. kubectl get ns still lists it.

A strong answer is:

"A project is a namespace with OpenShift RBAC templates and metadata. It is an administrative and policy scope—not hard multi-tenant isolation by itself."

What interviewers are testing: whether you contrast OpenShift Route (HAProxy) with Ingress and TLS termination modes.

A Route is an OpenShift-specific north-south HTTP/TLS API integrated with the OpenShift ingress/router stack. It exposes a Service on the cluster router (HAProxy) with a hostname under the cluster apps domain. Kubernetes Ingress remains a supported standard API on OpenShift.

oc expose service myapp --hostname=myapp.apps.cluster.example.com
oc get route myapp

A strong answer is:

"Route is OpenShift's native exposure API on the platform router; Ingress is the standard Kubernetes API and is also supported. I choose edge termination for HTTPS at the router and passthrough when the pod must terminate TLS itself."

What interviewers are testing: whether you define Route TLS termination modes. and connect it to Edge in production—not textbook definitions only.

Edge is common for web apps where the pod listens on HTTP behind the router. Passthrough is required for custom cipher control or mutual TLS to the app. A TLS-mode/backend-protocol mismatch can make the Route fail even when the pod is running—for example, an edge Route forwards HTTP while the backend expects HTTPS.

A strong answer is:

"Edge terminates TLS at the router; passthrough sends encrypted traffic straight to the pod; re-encrypt terminates at the router and opens a new TLS session to the backend. I match the mode to what the application actually listens for."

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

Current OpenShift 4.20 clusters use OVN-Kubernetes as the cluster network provider. OpenShift SDN is historical and was removed beginning with OpenShift 4.17. Core concepts mirror upstream:

• Pod network — each pod gets a cluster-routable IP
• Services — ClusterIP, NodePort, LoadBalancer (cloud integrator)
• DNS — CoreDNS (*.svc.cluster.local)
• NetworkPolicy — optional micro-segmentation (supported with OVN-Kubernetes); see Kubernetes NetworkPolicy for upstream policy patterns
• Egress — EgressIP, egress firewall (OpenShift-specific objects for controlled egress)

The router is separate from CNI—it publishes Routes to external clients. Interviewers often pair "pod cannot reach Service" (CNI/DNS) with "Route returns 503" (endpoints, selector, port).

A strong answer is:

"Pod-to-pod traffic is CNI; cluster DNS resolves Services; Routes are the north-south HTTP layer on the router. I split troubleshooting—internal connectivity vs external Route—because they involve different components."

What interviewers are testing: whether you explain SCC as OpenShift's pod security gate—not just 'run as non-root'.

SCC are OpenShift's pod security enforcement—they gate which securityContext settings a pod may use (user ID, capabilities, volumes, host paths).

Common SCC names (exact defaults depend on cluster version and upgrade history):

In current OpenShift, restricted-v2 is the normal baseline SCC for ordinary authenticated workloads; it defaults security settings such as a project-assigned UID range.

When a pod is rejected, events mention unable to validate against any SCC:

oc describe pod failing-pod
oc get events --field-selector involvedObject.name=failing-pod

Fix by adjusting the Deployment securityContext to match a restrictive SCC, or granting a service account access to a specific SCC (with approval)—not by blindly switching to privileged.

A strong answer is:

"SCC are OpenShift's pod security gate. I read the SCC denial in events, then either fix the securityContext to satisfy the restrictive default or request a tighter custom SCC—not privileged by default."

What interviewers are testing: Whether you understand how service-account identity, SCC authorization, SCC priority, and admission selection work together.

A user or service account can be authorized to use an SCC through RBAC and, for existing/custom SCCs, through users or groups listed directly on the SCC. Admission gathers the SCCs the identity may use, then orders and validates them.

Workflow:

1. Pod spec references serviceAccountName
2. Admission determines which SCCs the user or service account is authorized to use
3. Eligible SCCs are ordered according to SCC selection rules; admission attempts to validate and default the pod against those constraints

oc describe scc restricted-v2
oc adm policy who-can use scc restricted-v2
oc auth can-i use scc/restricted-v2 --as system:serviceaccount:demo:default -n demo

oc adm policy who-can use scc <name> and oc auth can-i use scc/<name> show RBAC-based access only; oc describe scc shows direct users/groups on the SCC.

Granting anyuid to a default SA is a common interview trap—prefer fixing the image to run as an assigned non-root UID.

A strong answer is:

"I first determine which SCCs the service account is authorized to use, then inspect the SCC actually selected or the admission errors rather than assuming a particular SCC won."

What interviewers are testing: Whether you separate OAuth authentication from Kubernetes RBAC authorization and can verify effective permissions with oc auth can-i.

Authentication flows through OAuth identity providers to Kubernetes user names and groups. Authorization is standard Kubernetes RBAC plus OpenShift cluster roles:

oc auth can-i create deployments --as developer -n demo
oc describe rolebinding -n demo

OpenShift also supports Groups from LDAP/OIDC mapped to ClusterRoleBindings. Separate cluster-admin access from day-to-day edit in a single project. For upstream RBAC mechanics, see Kubernetes RBAC.

A strong answer is:

"Users authenticate via OAuth; RBAC grants admin/edit/view per project. I verify with oc auth can-i and I never hand cluster-admin to application teams."

What interviewers are testing: Whether you can distinguish an Operator/controller from OLM's lifecycle objects—Subscription, InstallPlan, CSV, CatalogSource, and OperatorGroup.

Operators package domain knowledge in a controller plus CRDs. OLM (Operator Lifecycle Manager) manages Operator installation and upgrades through Subscriptions, InstallPlans, ClusterServiceVersions, CatalogSources, and OperatorGroups.

Platform components (ingress, registry, monitoring) are themselves Operators. Application Operators (Postgres, Kafka) follow the same OLM flow.

A strong answer is:

"Operators are controllers with CRDs; OLM manages their lifecycle via Subscription and InstallPlan. I check CSV and subscription status when an Operator never reaches Ready."

What interviewers are testing: Whether you understand ImageStream tags as image metadata/promotion abstractions and do not confuse them with a registry or automatic Deployment rollout mechanism.

An ImageStream is an OpenShift API object that tracks image tags and metadata. Its tags can point to images produced in the integrated registry or imported/referenced from external registries—it does not require the image to reside in the internal registry.

oc get imagestream
oc describe imagestream ruby-27-centos7

ImageStreams decouple what image to run from a raw external registry URL. Builds commonly push to image-registry.openshift-image-registry.svc:5000/project/image:tag, but output can be configured differently.

ImageStreams can participate in image-change automation, but the exact rollout mechanism depends on the workload. Historical DeploymentConfig image triggers are deprecated along with DeploymentConfig; for modern Deployments, use the supported image-update or GitOps workflow for your platform.

A strong answer is:

"ImageStreams track image tags and metadata and are useful for import, promotion, and build workflows. I do not assume an ordinary Kubernetes Deployment automatically rolls out on an ImageStreamTag change; I use the supported image-update or GitOps mechanism."

What interviewers are testing: Whether you can trace source input, build strategy, Build pod, output destination, and registry permissions when a build fails.

A BuildConfig describes how to produce an image—source Git, Dockerfile, or binary input—and runs Build objects.

Build strategies:

Pipeline build strategy (historical Jenkins Pipeline integration) is legacy/deprecated territory—do not design new platforms around it.

BuildConfig, S2I, and OpenShift-native build objects remain important in existing environments, but many current OpenShift platforms use external CI, OpenShift Pipelines/Tekton, or GitOps-driven image delivery instead of centering on BuildConfig.

oc new-build ruby~https://github.com/sclorg/ruby-ex.git
oc start-build ruby-ex --follow
oc logs -f build/ruby-ex-1

Failed builds often trace to Git clone, S2I assemble, or push to registry—each phase logs separately.

A strong answer is:

"BuildConfig is OpenShift's native build abstraction—it can participate in CI workflows, but modern platforms often use Tekton/OpenShift Pipelines or external CI to orchestrate the full pipeline. I follow oc start-build logs and check registry push permissions when compile succeeds but push fails."

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

S2I injects source into a builder image; the Docker build strategy builds a container image from your Dockerfile using OpenShift's build infrastructure, which uses Buildah in current OpenShift.

A strong answer is:

"S2I when a standard builder fits and we want less Dockerfile glue; Docker build when we need multi-stage images or a base the platform doesn't ship. Both strategies produce container images; the Build output can target an ImageStreamTag in the integrated registry or another configured registry destination."

What interviewers are testing: Whether you know standard Kubernetes Deployments are preferred for new OpenShift workloads and can explain how OpenShift-specific security, image, and exposure workflows fit around them.

Deployments are upstream Kubernetes objects—OpenShift does not replace them. oc new-app can create application resources such as a Deployment, Build, ImageStream, and Service depending on the input. External exposure is normally added separately with oc expose service ... to create a Route.

As of OpenShift 4.14, DeploymentConfig is deprecated. It remains supported for existing applications, but Kubernetes Deployment is recommended for new workloads. DeploymentConfig received only security and critical fixes after deprecation.

Best practices interviewers expect:

• Set requests/limits and probes (same as Kubernetes)
• Respect SCC—run as non-root when possible
• Use controlled ImageStream promotion when that is the platform workflow, and prefer immutable digests when exact image reproducibility is required
• Use ConfigMaps/Secrets for config—not baked in images

oc set resources deployment/myapp --requests=cpu=100m,memory=128Mi
oc rollout status deployment/myapp

A strong answer is:

"Deployments are standard Kubernetes rolling updates. On OpenShift I add SCC-compliant securityContext, pull from ImageStream tags, and expose with a Route after the Deployment is healthy."

What interviewers are testing: Whether you debug Pending PVCs from the claim outward—events, StorageClass, CSI provisioner, quota, backend, then platform Operator health.

OpenShift consumes Kubernetes PersistentVolume, PersistentVolumeClaim, and StorageClass—usually provided by CSI drivers (cloud disks, NFS, Ceph, etc.).

Check the storage ClusterOperator when provisioning failures appear platform-wide, then inspect the specific StorageClass, CSI driver/operator, PVC events, quotas, and backend storage. For generic Pending PVC triage, see Kubernetes PVC pending errors.

A strong answer is:

"I start with PVC events and StorageClass/provisioner details. If multiple workloads fail, I also check the storage ClusterOperator and the CSI driver's Operator health."

What interviewers are testing: Whether you understand the Image Registry Operator, platform-dependent storage configuration, ImageStreams, internal access, and optional external exposure.

The Image Registry Operator manages the OpenShift image registry and its storage configuration. Builds push here; ImageStreams point to it.

Operational notes:

• Production registry storage must use a supported persistent backend appropriate to the platform. On some platforms the registry is automatically configured; on others it starts as Removed until an administrator configures storage and enables it.
• oc registry info can show registry connection information. External exposure through the default registry Route is optional and must be enabled when required.
• Pull secrets may be required for cross-project pulls

Image promotion between environments often uses oc image mirror or GitOps with external registries in multi-cluster setups.

A strong answer is:

"The integrated registry is the default build output target. I size its storage backend and use image mirroring or external registries when promoting to DR or prod clusters."

What interviewers are testing: Whether you understand the update graph and can interpret ClusterVersion, ClusterOperator, and MachineConfigPool state during a rollout.

Upgrades are managed by the Cluster Version Operator. Updates follow the configured OpenShift update channel and the supported update graph; administrators review available/recommended updates rather than manually jumping to arbitrary versions.

oc adm upgrade
oc get clusterversion
oc get clusteroperators
oc get mcp

Flow:

1. Admin reviews available versions on the channel—upgrade paths are determined by the current release, channel, supported upgrade graph, and conditional update recommendations (not arbitrary version jumps)
2. Control plane updates; ClusterOperators report Progressing
3. Machine Config pools roll out node OS/config changes and may drain/reboot workers as needed
4. ClusterVersion reports DONE or blocks on a degraded Operator

Watch ClusterOperator and MachineConfigPool health during upgrades. Pausing a MachineConfigPool is a controlled troubleshooting step—not a routine default.

A strong answer is:

"Upgrades follow the supported channel graph—oc adm upgrade shows what is actually available. I watch ClusterOperators and machine config pools; a degraded ingress or DNS operator blocks a safe rollout."

What interviewers are testing: Whether you read ReplicaSet/Deployment events for SCC admission failures rather than assuming a Pending pod is the primary signal.

Ordered checklist:

1. oc describe replicaset <name> — read FailedCreate / SCC validation message; see Kubernetes Deployment not creating pods for the generic ReplicaSet event pattern
2. oc get events -n <project> --sort-by=.lastTimestamp — confirm SCC denial text
3. Compare pod securityContext (runAsUser, capabilities, volumes) with oc describe scc restricted-v2 (or the restrictive SCC in use)
4. Fix Deployment to run non-root, drop CAP_SYS_ADMIN, avoid hostPath unless allowed
5. If the image requires a fixed UID outside the project's assigned range, determine the minimum SCC policy that permits that UID. Prefer a dedicated custom SCC for the service account when possible rather than broad anyuid or privileged access

A strong answer is:

"I read the SCC denial in describe/events, align securityContext with the restrictive SCC in use, and only escalate SCC bindings with security review—never default to privileged."

What interviewers are testing: Whether you distinguish missing/unready endpoints, Service/Route port mismatches, router health, and TLS backend problems when HAProxy returns 503.

A router-generated 503 usually points to no usable backend or inability to reach the backend. Check endpoints/readiness, Service ports, Route targetPort, router logs, and TLS mode—not a DNS typo (that tends toward connection errors).

A strong answer is:

"I start with endpoints and readiness, then verify Service/Route port alignment and router logs. A 503 tells me to prove whether the router has a healthy reachable backend before changing DNS."

What interviewers are testing: Whether you separate compile success from registry push authorization, storage, and network path to the output destination.

Common causes:

• Registry storage full or registry Operator degraded
• Service account lacks system:image-builder or push role in project
• Output target in another project — build service account lacks permission to push to the destination ImageStream/repository
• Network policy blocking registry Service from build pod

oc logs build/myapp-3
oc get co image-registry

A strong answer is:

"Push failures after a good compile point at registry health and RBAC—image-builder rights and a healthy image-registry ClusterOperator—not the Git URL."

What interviewers are testing: Whether you inspect Subscription, InstallPlan, and CSV conditions—including manual approval and catalog health—before blaming SCC.

Checklist:

1. oc get subscription,installplan,csv -n <operator-namespace>
2. Manual approval — approve the InstallPlan when required:

oc patch installplan <plan-name> \
  -n <namespace> \
  --type merge \
  -p '{"spec":{"approved":true}}'

3. CatalogSource pod healthy; index image pulled
4. oc describe csv <csv-name> -n <operator-namespace> — inspect CSV conditions; check Subscription/InstallPlan before assuming SCC blocked deployment
5. SCC/RBAC — Operator SA can run its pods
6. Webhook timeouts — OLM conversion webhooks blocked by network policy

A strong answer is:

"I inspect Subscription, InstallPlan, CatalogSource, and CSV conditions in order. Pending can come from approval, catalog/dependency resolution, RBAC/SCC, or failed Operator deployment prerequisites—I use the conditions to identify which."

What interviewers are testing: Whether you combine RBAC, quotas, NetworkPolicy, SCC, and registry boundaries instead of treating a project as hostile isolation.

Strong design themes:

Project boundaries alone are not hostile multi-tenant isolation; combine RBAC, NetworkPolicy, SCC, quotas, and potentially dedicated nodes/clusters depending on trust requirements.

A strong answer is:

"One project per team with quota, network policy, and edit RBAC—shared cluster upgrades coordinated centrally. I avoid shared anyuid SCC and I use GitOps or CI for promotions between dev and prod namespaces."

What interviewers are testing: whether you define OpenShift Pipelines / Tekton and connect it to OpenShift Pipelines in production—not textbook definitions only.

OpenShift Pipelines is Red Hat's distribution and integration of Tekton—Kubernetes-native CI/CD pipeline resources on the cluster.

Distinguish from:

A strong answer is:

"Tekton gives me Tasks and PipelineRuns as Kubernetes resources. For new delivery platforms I often use Tekton or external CI, but I still understand BuildConfig because it remains supported and common in existing OpenShift environments."

What interviewers are testing: whether you define OpenShift GitOps and connect it to OpenShift GitOps in production—not textbook definitions only.

OpenShift GitOps is Red Hat's supported Argo CD integration for continuous delivery:

• Git holds desired application and configuration state
• A controller reconciles cluster state to Git
• In a GitOps operating model, desired changes normally flow through reviewed Git changes and Argo CD reconciliation rather than direct imperative changes

GitOps is not equivalent to Pipelines—they complement each other in many platforms.

A strong answer is:

"Pipelines build and test; GitOps deploys and reconciles. I keep desired state in Git and let Argo CD sync—easier to audit than scattered oc apply from CI."

What interviewers are testing: whether you demonstrate solid command of project—the trap is textbook recall without production context.

A project (namespace) is an administrative and policy scope, not automatic hard isolation:

A strong answer is:

"A project scopes RBAC and quota—it is not a security cell by itself. Regulated tenants need network policy, tight SCC, and often dedicated clusters or nodes."

What interviewers are testing: whether you demonstrate solid command of Platform monitoring—the trap is textbook recall without production context.

Platform monitoring covers etcd, API server, router, registry, and ClusterOperators. User-workload monitoring lets application teams expose ServiceMonitors and alerts within scoped namespaces—when the cluster admin enables it.

A strong answer is:

"Platform monitoring is for cluster health; user-workload monitoring extends Prometheus to app namespaces when enabled. I do not conflate the two when designing on-call routing."

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

During upgrade troubleshooting:

oc get clusterversion
oc get clusteroperators
oc get mcp

ClusterVersion may show Progressing while individual ClusterOperators update; MachineConfigPools show whether worker nodes finished config rolls and reboots.

A strong answer is:

"ClusterVersion is the release; ClusterOperators are platform health; MachineConfigPools are node rollout state. I check all three during upgrades—not just whether pods look fine."