In an OpenShift interview, the questions typically fall into three categories: Architecture/Concepts, Security (SCCs/RBAC), and Developer Workflow (S2I/Builds).
Here is a curated list of the most common and high-impact questions for 2026.
1. Core Architecture & Concepts
Q1: What is the fundamental difference between OpenShift and Kubernetes?
Answer: While Kubernetes is an open-source orchestration engine, OpenShift is a downstream, enterprise-grade distribution of Kubernetes by Red Hat.
- The “Plus” Factor: OpenShift includes everything in Kubernetes but adds a built-in container registry, integrated CI/CD pipelines (Tekton), a developer-friendly web console, and enhanced security defaults.
- Security: By default, OpenShift forbids containers from running as
root, whereas vanilla Kubernetes is “open” by default.
Q2: What is an OpenShift “Project” vs. a Kubernetes “Namespace”?
Answer: A Project is simply an abstraction on top of a Kubernetes Namespace.
- It adds metadata and facilitates Self-Service: users can request projects via the CLI (
oc new-project) or Web Console. - It automatically applies default Resource Quotas and Limit Ranges to the namespace to prevent a single user from crashing the cluster.
Q3: Explain the role of the Router (HAProxy) in OpenShift.
Answer: In vanilla Kubernetes, you typically install an Ingress Controller (like NGINX). In OpenShift, the Router (based on HAProxy) is a core component. It provides the external entry point for traffic, mapping an external URL (a Route) to an internal Service.
2. Developer & Build Workflow
Q4: What is Source-to-Image (S2I) and why is it used?
Answer: S2I is a toolkit that allows developers to provide only their source code (via a Git URL). OpenShift then:
- Detects the language (Java, Python, Node, etc.).
- Injects the code into a “Builder Image.”
- Assembles the final application image.Benefit: Developers don’t need to know how to write a
Dockerfileor manage base images, ensuring consistent security patches at the base layer.
Q5: What is a BuildConfig?
Answer: A BuildConfig is the definition of the entire build process. It specifies:
- Source: Where the code is (Git).
- Strategy: How to build it (S2I, Docker, or Pipeline).
- Output: Where to push the resulting image (internal registry).
- Triggers: Events that start a build (e.g., a code commit or an update to the base image).
3. Security & Operations
Q6: What are Security Context Constraints (SCCs)?
Answer: SCCs are one of the most important security features in OpenShift. They control what actions a pod can perform.
- Restricted SCC: The default. It prevents pods from running as root and limits access to the host filesystem.
- Anyuid SCC: Often used when migrating legacy Docker images that must run as a specific user.
- Privileged SCC: Full access (usually reserved for infra components like logging or monitoring).
Q7: How does OpenShift handle Persistent Storage?
Answer: OpenShift uses the Persistent Volume (PV) and Persistent Volume Claim (PVC) model.
- An administrator provisions PVs (storage chunks).
- A developer requests storage via a PVC.
- OpenShift uses Storage Classes to dynamically provision storage on the fly (e.g., on AWS EBS or VMware vSphere) when a PVC is created.
4. Scenario-Based “Pro” Question
Q8: “A pod is failing with a CrashLoopBackOff. How do you troubleshoot it in OpenShift?”
Answer: Walk through these 4 steps to show you have hands-on experience:
- Check Status:
oc get podsto see the status. - Examine Logs:
oc logs <pod_name>(use--previousif the container already restarted). - Inspect Events:
oc describe pod <pod_name>to look for failed mounts, scheduling issues, or “Back-off” events. - Debug Session: Use
oc debug pod/<pod_name>to launch a terminal inside a clone of the failing pod to inspect the filesystem and environment variables.
5. Rapid-Fire Command Cheat Sheet
| Task | Command |
| Login | oc login <api-url> |
| Create App | oc new-app https://github.com/user/repo |
| Scale App | oc scale --replicas=3 dc/my-app |
| Expose Service | oc expose svc/my-service |
| View Resources | oc get all |
| Check SCCs | oc get scc |
For the Administrator track, the interview will shift away from “how to deploy an app” toward Cluster Health, Lifecycle Management, and Infrastructure Stability.
In OpenShift 4.x (the modern standard), the “Operator-focused” architecture is the star of the show. Here are the heavy-hitting admin questions you should be ready for.
1. The Operator Framework
Q1: What is the “Operator Pattern” and why is it central to OpenShift 4?
Answer: In OpenShift 4, the entire cluster is managed by Operators. An Operator is a custom controller that encodes human operational knowledge into software.
- The Loop: It constantly monitors the Actual State of a component (like the Internal Registry or Monitoring stack) and compares it to the Desired State. If they differ, the Operator automatically fixes it.
- Cluster Version Operator (CVO): This is the “Master Operator” that manages the updates of the cluster itself, ensuring all core components are at the correct version.
Q2: How do you perform a Cluster Upgrade in OpenShift 4?
Answer: Upgrades are managed via the Cluster Version Operator (CVO).
- Process: You typically update the “Channel” (e.g.,
stable-4.14) and then trigger the upgrade via the console oroc adm upgrade. - Mechanism: The CVO orchestrates the update of every operator in the cluster. The Machine Config Operator (MCO) handles the rolling reboot of nodes to update the underlying Red Hat Enterprise Linux CoreOS (RHCOS).
2. Infrastructure & Nodes
Q3: What is the Machine Config Operator (MCO)?
Answer: The MCO is one of the most important components for an admin. It treats the underlying nodes like “cattle, not pets.”
- It manages the operating system (RHCOS) itself.
- If you need to change a kernel parameter, add a SSH key, or change a NTP setting across 50 nodes, you create a
MachineConfigobject. The MCO then applies that change and reboots nodes in a rolling fashion to ensure zero downtime.
Q4: Explain the difference between IPI and UPI installation.
Answer: * IPI (Installer-Provisioned Infrastructure): Full automation. The OpenShift installer has credentials to your cloud (AWS, Azure, etc.) and creates the VMs, VPCs, and Load Balancers for you.
- UPI (User-Provisioned Infrastructure): The admin manually creates the infrastructure (VMs, networking, storage). You then run the installer to “bootstrap” OpenShift onto those pre-existing resources. (Common in highly regulated or air-gapped environments).
3. Storage & Networking
Q5: How do you troubleshoot a Node that is in “NotReady” status?
Answer: I follow a systematic checklist:
- Check Node Details:
oc describe node <node_name>to look at the “Conditions” section (e.g.,MemoryPressure,DiskPressure, orNetworkUnavailable). - Verify Kubelet: SSH into the node (or use
oc debug node) and check the kubelet logs:journalctl -u kubelet. - Resource Usage: Check if the node has run out of PIDs or Disk space.
- CSRs: If the node was recently added/rebooted, check if there are pending Certificate Signing Requests:
oc get csrand approve them if necessary.
Q6: What is the “In-tree” to CSI migration?
Answer: Older versions of OpenShift used storage drivers built directly into the Kubernetes binary (“In-tree”). Modern OpenShift is moving to CSI (Container Storage Interface) drivers. As an admin, this means storage is now handled by standalone operators, allowing for easier updates without upgrading the whole cluster.
4. Security & Etcd
Q7: Why is the etcd backup critical, and how do you perform it?
Answer: etcd is the “brain” of the cluster; it stores every configuration and state. If etcd is lost, the cluster is dead.
- Backup: You use the
cluster-etcd-operator. I would run a specific debug script provided by Red Hat:oc debug node/<master-node> -- /usr/local/bin/cluster-backup.sh /home/core/assets/backup. - Strategy: Always take a backup before a cluster upgrade.
5. Monitoring & Logging
Q8: What stack does OpenShift use for Cluster Monitoring?
Answer: OpenShift comes with a pre-configured Prometheus, Grafana, and Alertmanager stack (managed by the Monitoring Operator).
- Note: Admins use this to monitor cluster health (CPU/Mem of nodes).
- User Workload Monitoring: In newer versions, admins can enable “User Workload Monitoring” to allow developers to use the same Prometheus stack for their own applications without interfering with the cluster’s core monitoring.
Summary Checklist for your Interview
[!TIP]
If they ask about a problem you can’t solve: Always mention “Looking at the Operators.” In OpenShift 4, if something is broken, check
oc get clusteroperators.If one is
DEGRADED=True, that is your smoking gun.
OCP can run on different environment, such as on-premise (VMware/Bare Metal) or a managed service (ROSA/ARO)
Infra Cloud Solutions 