Red Hat OpenShift Administration interview questions

An integrated, supported platform: a web console and oc CLI, built-in image registry, Routes for ingress, stricter security by default (Security Context Constraints, non-root containers), Operators and OperatorHub for platform services, monitoring and logging stacks, and cluster updates handled by the Cluster Version Operator.

What they are checking: Knowing it is Kubernetes plus opinions and support.

Likely follow-up: Why do some public images fail to run on OpenShift?

Best fix: rebuild or choose an image that runs as a non-root user and writes only to allowed paths. If the workload truly needs extra rights, create a dedicated service account and grant it a specific SCC (such as anyuid) for that project only, never to all users.

What they are checking: Least privilege with SCCs.

Likely follow-up: How do you check which SCC a pod was admitted with?

A Service gives pods a stable internal IP and DNS name. A Route exposes a Service outside the cluster through the router (HAProxy) with a hostname and TLS options (edge, passthrough, re-encrypt). Ingress objects also work and are turned into Routes.

What they are checking: Clear traffic path from user to pod.

Likely follow-up: When would you use passthrough TLS?

oc describe pod for events, oc logs --previous for the last crash output, then check probes (a wrong liveness probe kills a healthy app), missing config or secrets, permissions and resource limits (OOMKilled). oc debug starts a copy of the pod with a shell to test.

What they are checking: Using events, previous logs and oc debug.

Likely follow-up: What is the difference between readiness and liveness probes?

Set ResourceQuotas per project for CPU, memory, storage and object counts, LimitRanges for default requests and limits, and use a project template so every new project gets them automatically.

What they are checking: Multi-tenant control.

Likely follow-up: What happens to a pod with no requests in a project with a quota?

Software that runs inside the cluster and manages an application the way an expert would: install, upgrade, back up, scale and heal, driven by custom resources. OpenShift itself is run by operators, and OperatorHub offers databases, monitoring and more.

What they are checking: Understanding the operator pattern.

Likely follow-up: How do you control operator upgrades with approval?

Check the update channel and graph, read the release notes, make sure all cluster operators are healthy and not degraded, take an etcd backup, then start the update from the console or oc adm upgrade. Control plane updates first, then worker nodes through machine config pools, which you can pause.

What they are checking: Health checks and etcd backup first.

Likely follow-up: How do you back up etcd?

A PersistentVolumeClaim using a StorageClass that provisions volumes dynamically, mounted into the deployment (or a StatefulSet for apps that need stable identity). Choose the access mode (RWO or RWX) the app needs and check the backend supports it.

What they are checking: PVC, StorageClass and access modes.

Likely follow-up: Why does RWX matter when you scale a deployment?

Connect an identity provider (LDAP, OIDC), sync groups, and use RoleBindings per project with the admin, edit or view roles. Cluster-admin stays with a few platform admins, and the kubeadmin user is removed after setup.

What they are checking: RBAC by project and identity provider.

Likely follow-up: Why should you remove the kubeadmin user?

Give them templates and examples that already follow platform rules, write short how-to guides, pair with them on the first deployment, and turn repeated questions into documentation or automation. A platform team succeeds when developers ship without needing them.

What they are checking: Platform-as-a-product thinking.

Likely follow-up: How do you collect feedback from developer teams?