Top OpenShift Interview Questions for Beginners

techhadoop kubernetes

OpenShift (OCP) Interview Questions

Beginner Level

Q1. What is OpenShift and how does it differ from Kubernetes?

A: OpenShift is Red Hat’s enterprise Kubernetes platform — Kubernetes is the engine, OpenShift is the car built around it.

Kubernetes:                        OpenShift:
─────────────────────────          ─────────────────────────
Container orchestration            Kubernetes + enterprise layer
You bring your own:                Built-in:
  - CI/CD                            - CI/CD (Tekton Pipelines)
  - Image registry                   - Internal registry
  - Ingress controller               - HAProxy router
  - Auth                             - OAuth server
  - Monitoring                       - Prometheus + Grafana
  - Developer tools                  - Developer console
  - Security policies                - SCCs (stricter than PSP)

Key differences:

FeatureKubernetesOpenShift
SecurityPod Security AdmissionSecurity Context Constraints (SCC)
RoutingIngress (install separately)Routes (built-in HAProxy)
RegistryExternalBuilt-in image registry
CI/CDExternalTekton + ArgoCD built-in
AuthExternal OIDCBuilt-in OAuth + Entra ID / LDAP
CLIkubectloc (superset of kubectl)
ProjectsNamespacesProjects (namespaces + annotations)
ConsoleBasic dashboardRich developer + admin console

Q2. What is a Project in OpenShift vs a Namespace in Kubernetes?

A: A Project is OpenShift’s wrapper around a Kubernetes Namespace — it adds metadata, annotations, and access control.

# When you create a Project:
oc new-project my-app \
  --display-name="My Application" \
  --description="Production app for team A"
# OCP automatically creates:
# 1. Namespace: my-app
# 2. RoleBinding: admin role for creator
# 3. NetworkPolicy: default isolation
# 4. LimitRange: default resource limits
# 5. ResourceQuota: (if configured by admin)

Key differences:

NamespaceProject
Creationkubectl create namespaceoc new-project
Access controlManual RBACAuto-assigns creator as admin
AnnotationsManualDisplay name, description built-in
TemplatesNoneProject templates supported
Self-serviceAdmin onlyCan be enabled for developers

Q3. What is a Security Context Constraint (SCC) in OpenShift?

A: SCC is OpenShift’s mechanism to control what a pod is allowed to do at the OS level — more powerful than Kubernetes Pod Security Admission.

SCC controls:
├── Which user IDs a pod can run as
├── Which Linux capabilities it can use
├── Whether it can run as root
├── Whether it can mount host paths
├── Which SELinux labels it can use
└── Whether it can use privileged mode

Built-in SCCs (ordered most to least restrictive):

SCCWhat it allows
restricted-v2Default — no root, random UID, no host access
restrictedLegacy default
baselineSome relaxed restrictions
nonrootAny non-root UID
nonroot-v2Updated nonroot
hostmount-anyuidCan mount host paths
hostnetworkCan use host network
hostnetwork-v2Updated hostnetwork
privilegedUnrestricted — cluster admin only
anyuidAny UID including root
# Check which SCC a pod is using
oc get pod api-pod -o jsonpath='{.metadata.annotations.openshift\.io/scc}'
# Check what SCC a service account can use
oc adm policy who-can use scc restricted
# Add SCC to service account
oc adm policy add-scc-to-user anyuid \
  -z my-service-account \
  -n my-namespace
# View all SCCs
oc get scc
# Describe an SCC
oc describe scc restricted-v2

Q4. What is the difference between oc and kubectl?

A: oc is a superset of kubectl — every kubectl command works with oc, plus OCP-specific commands.

# Everything kubectl does:
oc get pods
oc apply -f deployment.yaml
oc describe node worker-1
# OCP-specific additions:
oc new-project myapp              # create project
oc new-app --image=nginx          # deploy from image
oc expose service api             # create Route
oc rollout latest dc/api          # rollout DeploymentConfig
oc adm policy add-scc-to-user    # manage SCCs
oc adm top nodes                  # node resource usage
oc adm must-gather                # collect diagnostics
oc login https://api.cluster.com  # authenticate to cluster
oc whoami                         # current user
oc projects                       # list projects
oc status                         # project overview
oc debug node/worker-1            # debug a node
oc rsh pod/api-pod                # remote shell into pod
oc cp file.txt api-pod:/tmp/      # copy files to pod
oc port-forward pod/api 8080:8080 # port forward

Q5. What is a DeploymentConfig vs a Deployment in OpenShift?

A: DeploymentConfig (DC) is OpenShift’s original deployment resource — predates Kubernetes Deployment. OCP 4.x supports both but Deployment is now recommended.

DeploymentConfigDeployment
OriginOpenShift nativeKubernetes native
TriggersImage change, config changeManual or external
Lifecycle hooksPre/mid/post hooksInit containers
Rolling strategyCustom strategiesRollingUpdate / Recreate
RecommendedLegacy — avoid for new apps✅ Use this
APIapps.openshift.io/v1apps/v1
# OLD way — DeploymentConfig (avoid for new apps)
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: api
spec:
  replicas: 3
  triggers:
  - type: ImageChange          # ← OCP-specific trigger
    imageChangeParams:
      automatic: true
      containerNames:
      - api
      from:
        kind: ImageStreamTag
        name: api:latest
  - type: ConfigChange
  template:
    spec:
      containers:
      - name: api
        image: api:latest
---
# NEW way — Deployment (recommended)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: image-registry.openshift-image-registry.svc:5000/production/api:latest

Q6. What is an ImageStream in OpenShift?

A: An ImageStream is an OpenShift abstraction that tracks container images and their tags — like a pointer to images that can trigger deployments automatically.

External Registry          ImageStream              Deployment
─────────────────          ──────────────           ──────────
quay.io/myapp:1.0  ───▶   myapp:1.0  ─────────▶   Pod runs
quay.io/myapp:1.1  ───▶   myapp:1.1  ─────────▶   Auto-redeploy!
quay.io/myapp:latest───▶   myapp:latest
# ImageStream definition
apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: api
  namespace: production
spec:
  lookupPolicy:
    local: true              # allow pods to reference by ImageStream name
---
# ImageStreamTag — points to specific image
apiVersion: image.openshift.io/v1
kind: ImageStreamTag
metadata:
  name: api:latest
  namespace: production
tag:
  from:
    kind: DockerImage
    name: quay.io/mycompany/api:latest
  importPolicy:
    scheduled: true          # periodically re-import
    importMode: Legacy
# Import image into ImageStream
oc import-image api:latest \
  --from=quay.io/mycompany/api:latest \
  --confirm \
  -n production
# List ImageStreams
oc get imagestreams -n production
# View tags
oc get imagestreamtag -n production
# Check image digest
oc describe imagestreamtag api:latest -n production

Q7. What is the OpenShift internal image registry?

A: OCP ships with a built-in container image registry running inside the cluster — no external registry needed.

Registry endpoint:
image-registry.openshift-image-registry.svc:5000   (internal)
default-route-openshift-image-registry.apps.cluster.com  (external)
Push/pull flow:
Developer → oc build / Tekton → Internal Registry → Deployment
# Expose registry externally (if needed)
oc patch configs.imageregistry.operator.openshift.io/cluster \
  --type=merge \
  -p '{"spec":{"defaultRoute":true}}'
# Login to internal registry
oc registry login
# Push image to internal registry
podman push myimage:latest \
  image-registry.openshift-image-registry.svc:5000/myproject/myimage:latest
# Configure registry storage (production — use S3 / Azure Blob)
oc edit configs.imageregistry.operator.openshift.io cluster

Intermediate Level

Q8. How does OpenShift handle multi-tenancy and namespace isolation?

A: OCP uses multiple layers for multi-tenancy:

1. Projects + RBAC

# Each team gets their own project
# RBAC controls who can do what
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-admin
  namespace: team-a
subjects:
- kind: Group
  name: team-a-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

2. NetworkPolicy / OVN-Kubernetes

# Default deny all — then allow specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: team-a
spec:
  podSelector: {}         # all pods
  policyTypes:
  - Ingress
  - Egress
---
# Allow only within namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}    # only from same namespace

3. ResourceQuota per Project

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "20"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "10"
    services.loadbalancers: "0"   # no LB services — use Routes

4. LimitRange — default resource limits

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - type: Container
    default:
      cpu: 500m
      memory: 256Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    max:
      cpu: "2"
      memory: 2Gi

Q9. Explain OpenShift OAuth and authentication mechanisms.

A: OCP has a built-in OAuth server that acts as an identity broker:

User/CLI
   │
   ▼
OCP OAuth Server (oauth-openshift.apps.cluster.com)
   │
   ├──▶ HTPasswd (local users — dev/test)
   ├──▶ LDAP / Active Directory
   ├──▶ OpenID Connect (Azure AD / Okta / Google)
   ├──▶ GitHub / GitLab

Leave a Reply