OpenShift AI Interview Questions and Answers: 50 Questions for AI267 and EX267 Candidates

Key takeaways

• EX267 is the Red Hat Certified Specialist in OpenShift AI (course AI267). OpenShift Administration is EX280, a different exam.
• Know the lifecycle end to end: project and workbench, data connection, pipeline, model serving, monitoring.
• Be clear on model serving: single-model (KServe) versus multi-model serving, serving runtimes and InferenceServices.
• Expect GPU questions: operators, accelerator or hardware profiles, quotas and memory sizing.
• Feature names change between releases. Confirm details in the current Red Hat documentation.

What does an OpenShift AI interview actually test?

Employers hiring for MLOps, AI platform and OpenShift roles want to know that you can run the machine learning lifecycle on OpenShift and fix it when it breaks. Expect questions on installing the platform, setting up projects and storage, running pipelines, deploying models and handling GPUs. This list is written for the Red Hat OpenShift AI course (AI267) and exam (EX267). It replaces an older version of this page that mistakenly answered generic OpenShift administration questions. For cluster-level basics, see our OpenShift interview questions and Kubernetes interview questions.

What is the EX267 exam?

EX267 is the Red Hat Certified Specialist in OpenShift AI exam. The matching course is AI267. Like other Red Hat specialist exams, it is performance-based: you complete tasks in a live environment instead of choosing answers. The skills in the questions below map to the areas it tests: working with data science projects, workbenches, pipelines and model serving. Confirm the current objectives, duration and format on the Red Hat certification pages, since they change with releases.

OpenShift AI changes quickly. Names such as accelerator profiles versus hardware profiles, or which serving modes are available, differ between releases. When in doubt, say what you know and name the doc you would check. That is a good answer in an interview.

Fundamentals

1. What is Red Hat OpenShift AI?

A platform that runs on OpenShift for the machine learning lifecycle: development in workbenches, training, pipelines, model serving, monitoring and governance. OpenShift supplies the base: containers, scheduling, RBAC, storage and operations. OpenShift AI adds the data science tooling on top.

2. How does OpenShift AI relate to Open Data Hub?

Open Data Hub is the upstream community project. OpenShift AI is Red Hat's supported product built from that work, with a supported release cycle and documentation.

3. Why run data science on OpenShift instead of on individual laptops or VMs?

A shared platform gives reproducible environments, central access control, shared and scheduled GPU use, repeatable pipelines and a standard way to deploy models. Laptops and ad-hoc VMs give each person a different setup and no governance.

4. What are the main components?

The dashboard, data science projects, workbenches, data connections, pipelines, model serving with KServe, a model registry, distributed workload tooling, and monitoring and trust features such as TrustyAI. Which are enabled is controlled by the operator configuration.

5. Who uses OpenShift AI?

Data scientists work in workbenches and pipelines. ML or MLOps engineers build pipelines and serving. Platform administrators install the operator, GPUs, groups and quotas. Application developers consume the model endpoints.

6. How is EX267 different from EX280?

EX280 is OpenShift Administration: users, RBAC, networking, security and operators on a cluster. EX267 is the OpenShift AI specialist exam: working with the OpenShift AI platform, such as projects, workbenches, pipelines and model serving. EX280 skills help with the underlying platform, but the tasks differ. For cluster-level questions, see our OpenShift interview questions.

Installation and administration

7. How is OpenShift AI installed?

A cluster administrator installs the Red Hat OpenShift AI Operator from OperatorHub, then creates the configuration that tells it what to deploy: a DataScienceCluster resource (and its initialisation settings). The operator then deploys the dashboard and enabled components. Some serving features need extra operators, depending on release.

8. What is the DataScienceCluster resource?

A custom resource that lists components and whether each is Managed (installed and kept in the desired state) or Removed. For example, you may enable the dashboard, workbenches, pipelines and KServe and remove an unused component. Field names vary by release, so read the example in the operator's documentation.

9. What prerequisites should you check before installing?

A supported OpenShift version, enough CPU, memory and storage, cluster-admin access, a configured identity provider, S3-compatible object storage for models and pipeline artifacts, and, for GPUs, the Node Feature Discovery and NVIDIA GPU operators. Check which additional operators your serving mode needs in your release.

10. How do you control who can use OpenShift AI?

Through OpenShift groups. The dashboard settings define which groups are users and which are administrators. Within a project, the owner shares access through the Permissions settings, which create role bindings.

11. How do you make GPUs available to users?

Install Node Feature Discovery and the NVIDIA GPU Operator so nodes advertise GPUs, then define accelerator profiles (called hardware profiles in newer releases) so users can pick a GPU when creating a workbench or deployment. Workloads then request nvidia.com/gpu resources.

12. How do you add a custom notebook image?

Import the image in the dashboard settings so it appears as a workbench option. It must start the notebook server correctly and run with an arbitrary user ID, because OpenShift's default security context does not run containers as a fixed user. Base it on a supported image where possible.

13. Where do the platform components run?

In OpenShift namespaces created by the operator, commonly with names beginning redhat-ods-, plus each user project for their own workbenches, pipeline servers and model servers. Use oc get pods -n redhat-ods-applications to check the dashboard and core components.

14. Can OpenShift AI run in a disconnected environment?

Yes, with preparation. You mirror the required operator catalogue and container images to an internal registry and configure the cluster to pull from it. Model files and Python packages must also be available internally.

Data science projects and workbenches

15. What is a data science project?

An OpenShift project (namespace) enabled for OpenShift AI. It groups workbenches, storage, data connections, pipelines and model deployments for one team or purpose, and carries the access permissions.

16. What is a workbench?

A containerised development environment, such as JupyterLab, running as a pod in your project. You choose its image, size, accelerator and storage. Packages you install in a running pod are lost if the image is recreated, so keep reusable dependencies in your project files or a custom image.

17. Where is my work saved?

On the persistent volume attached to the workbench. Stopping the workbench stops the pod but keeps the storage. Deleting the storage deletes the work. Put important code in Git and large data in object storage.

18. What is a data connection?

A saved set of S3-compatible storage details (endpoint, bucket, region and keys) stored as a Secret in the project. It is injected into a workbench as environment variables and is used by pipelines and model serving to reach data and models. Newer releases may call these simply connections.

19. Why S3-compatible object storage?

It stores datasets, trained models and pipeline artifacts in a way that is shareable across workbenches, pipelines and serving. In labs, MinIO is often used. In production you might use OpenShift Data Foundation or a cloud bucket.

20. A workbench is stuck in Pending. How do you diagnose it?

Run oc describe pod and read the events. Common causes are an unbound PersistentVolumeClaim, a quota or limit in the project, no node with the requested GPU, or taints and node selectors that do not match. Fix the cause, not the pod.

21. How do you stop idle workbenches wasting GPUs?

Stop unused workbenches manually, enable idle notebook culling if your release provides it, and set quotas on GPU resources per project. Accountability matters here, because GPUs are expensive.

Pipelines

22. What are Data Science Pipelines?

A way to run a machine learning workflow as a series of container steps, such as prepare data, train, evaluate and register. They are based on Kubeflow Pipelines, so a pipeline is defined in code or built visually, compiled, uploaded and run, with every run recorded.

23. What does a pipeline server need?

A pipeline server created in the project, S3-compatible storage for artifacts and a database for metadata. The dashboard can set these up from a data connection. Without the pipeline server, runs cannot be created.

24. How do you define a pipeline in code?

With the Kubeflow Pipelines SDK. Each step is a component and the pipeline wires them together. A minimal version-two style example:

from kfp import dsl, compiler

@dsl.component(base_image="python:3.11")
def train(epochs: int) -> str:
 return f"trained for {epochs} epochs"

@dsl.pipeline(name="demo-training")
def demo(epochs: int = 3):
 train(epochs=epochs)

compiler.Compiler().compile(demo, "demo.yaml")

You then import demo.yaml in the project's pipeline page and start a run. Check the KFP documentation for the SDK version your release uses.

25. What is Elyra?

A JupyterLab extension that lets you build pipelines visually from notebooks and scripts by connecting nodes, then submit them to the pipeline server. It suits data scientists who prefer notebooks to writing SDK code.

26. What is the difference between an experiment, a run and a recurring run?

An experiment groups related runs. A run is one execution of a pipeline with specific parameters. A recurring run executes on a schedule, for example nightly retraining.

27. A pipeline step fails. How do you debug it?

Open the run in the dashboard and read the failed step's logs. For more detail, find the step's pod in the project and use oc logs. Typical causes are a missing Python package in the step image, wrong S3 credentials or paths, insufficient memory, or a code error.

28. How do pipeline steps pass data?

Small values pass as parameters. Larger data passes as artifacts that are stored in object storage and read by the next step. Pass references, not huge in-memory objects.

Model serving

29. What are the model serving options?

See the table below. Single-model serving, built on KServe, gives each model its own server and suits large models such as LLMs. Multi-model serving, based on ModelMesh, packs many small models onto shared servers. Availability and defaults differ by release, so check the documentation.

30. What is KServe?

A Kubernetes-native model serving layer. You declare an InferenceService that names a serving runtime and a model location. KServe creates the server pods, an endpoint and scaling behaviour.

31. What is the difference between a ServingRuntime and an InferenceService?

A ServingRuntime defines the model server: image, ports and arguments, for example OpenVINO Model Server or vLLM. An InferenceService deploys one specific model using a runtime, with its storage location and resources.

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: demo-model
 namespace: my-project
spec:
 predictor:
 model:
 modelFormat:
 name: onnx
 runtime: my-openvino-runtime
 storageUri: s3://my-bucket/models/demo

This is an illustration only. The dashboard normally fills storage details from a data connection and path, and field names can differ by release.

32. Which serving runtimes should you know?

OpenVINO Model Server for many traditional model formats, vLLM for large language models, and other runtimes provided by Red Hat for text generation. You can also bring a custom runtime if the model needs it.

33. Where does the model come from at deployment?

Usually from S3-compatible storage through a data connection and a path. Newer releases also support pulling models packaged as container images. The server's storage initialiser downloads the model before it starts.

34. What are serverless and raw deployment modes?

In serverless mode, scaling is handled by a Knative-based layer and can scale to zero, which saves resources but adds cold-start delay. Raw deployment uses ordinary Kubernetes Deployments and autoscalers, which is simpler and avoids cold starts. Which is available depends on release and configuration.

35. How do clients call a deployed model?

Over HTTP or gRPC using the inference endpoint. Predictive runtimes often follow the Open Inference Protocol, and LLM runtimes such as vLLM expose an OpenAI-compatible API. If authentication is on, include a token:

TOKEN=$(oc whoami -t)
curl -k -H "Authorization: Bearer $TOKEN" \
 -H "Content-Type: application/json" \
 -d @input.json \
 https://<endpoint-host>/v2/models/demo-model/infer

Use a dedicated service account token for real clients, not your own login token. For an LLM served with vLLM, call the OpenAI-style path such as /v1/chat/completions.

36. How do you secure a model endpoint?

Decide whether it needs an external route at all. Turn on token authentication and give each client its own service account token, apply network policies, and keep model storage credentials in Secrets. Do not leave a model endpoint open to the world by default.

37. How would you roll out a new model version safely?

Deploy the new version alongside the old one and shift a small share of traffic first, where your mode supports it (for example, a canary traffic percentage on the predictor), watch error rates and latency, then increase. Keep the old model version available for rollback.

38. An InferenceService is not Ready. What is your checklist?

Work in order: check the resource status and events, check the predictor pod, check the storage initialiser logs for S3 or path errors, confirm the runtime supports the model format, and confirm resources such as GPU are available. Commands are listed below.

oc get inferenceservice -n my-project
oc describe inferenceservice demo-model -n my-project
oc get pods -n my-project
oc logs <predictor-pod> -c storage-initializer -n my-project
oc logs <predictor-pod> -c kserve-container -n my-project
oc get events -n my-project --sort-by=.lastTimestamp

39. How much GPU memory does an LLM need?

A rough guide: parameters multiplied by bytes per parameter, plus extra for the key-value cache and overhead. A 7-billion-parameter model in 16-bit precision (2 bytes) needs roughly 14 GB for weights alone. Quantisation to 8-bit or 4-bit reduces that, at some cost in accuracy. Always test with real context lengths.

Governance, monitoring and generative AI

40. What is the model registry?

A component that stores model metadata: names, versions, storage locations and descriptions. It gives teams one place to record which model version was trained from what and where it is deployed.

41. What is TrustyAI?

A component for trustworthy AI monitoring. It can compute fairness metrics, explain predictions and watch for data drift on served models. Newer releases also add guardrails features for LLMs. Check which are generally available in your release.

42. How do you monitor served models?

Use the metrics that runtimes expose, collected by OpenShift monitoring for user workloads, and build dashboards and alerts on latency, request rate, errors and GPU use. Monitor model quality (drift) as well as infrastructure.

43. What is retrieval-augmented generation (RAG)?

A pattern where documents are split, converted to embeddings and stored in a vector database. At question time the system retrieves relevant chunks and gives them to the LLM as context, so answers come from your data. OpenShift AI hosts the model and supporting services. Confirm which RAG components are supported in your release.

44. What are distributed workloads in OpenShift AI?

Tooling for running training or data processing across many pods or GPUs, using frameworks such as Ray and PyTorch distributed jobs, with Kueue managing queues and quotas so teams share GPUs fairly.

45. How can GPUs be shared?

By time-slicing a GPU between workloads, by partitioning supported GPUs with Multi-Instance GPU (MIG), or by queueing jobs with quotas. The right choice depends on isolation needs and hardware.

46. What are the main security controls?

Project-level RBAC, network policies, Secrets for credentials, restricted security context constraints, authenticated model endpoints, trusted base images and supply-chain checks for notebook images and model files, and encrypted storage.

Scenario questions

47. A data scientist cannot see the GPU option when creating a workbench. What do you check?

Check that nodes advertise GPUs (oc describe node), that the GPU operator is healthy, that an accelerator or hardware profile exists and is enabled, that the user's group has permission, and that quotas allow GPU requests.

48. A model works in a notebook but fails when served. Why?

Common causes: the model was saved in a format the runtime does not support, library versions differ between the notebook and the runtime, the input shape or preprocessing differs, or the model needs files that were not uploaded. Test the exported artifact with the runtime locally first.

49. Traffic is spiky and latency must stay low. How would you serve?

Prefer a mode that keeps warm replicas rather than scaling to zero, use autoscaling on request metrics, size GPU or CPU resources for peak load, and load test. Accept the cost of idle capacity as the price of latency.

50. How would you take a notebook model to production?

Move the code into a pipeline with parameters, store the model in object storage, record it in the model registry, deploy with an InferenceService, add monitoring and alerts, and schedule retraining. Keep code in Git and automate with CI.

How should you prepare?

1. Build one end-to-end project. Create a project, workbench and S3 connection, train a small model, wrap training in a pipeline, deploy it and call the endpoint with curl.
2. Break it on purpose. Use a wrong S3 path, remove a GPU, or request too much memory, then diagnose with oc describe and oc logs.
3. Know OpenShift basics cold. Projects, RBAC, routes, storage and operators underpin everything above.
4. Read the current documentation on docs.redhat.com for your release and note what is new.
5. Practise explaining. Answer each question above aloud in under a minute, then add one real failure mode.

Next steps

Pick ten questions you could not answer and build a small lab for each. For a trainer-led path that includes labs on this platform, see our OpenShift AI (AI267 and EX267) course. For platform basics, read the OpenShift interview questions for job seekers.

Related reading

• Openshift vs. Kubernetes | Which is right for you?