Red Hat Certified Specialist in OpenShift AI (EX267) Practice Exam Questions and – Part 15/25

Practice for the Red Hat Certified Specialist in OpenShift AI (EX267) exam with 18 exam-style practice questions, instant answer reveals, and concise explanations of every correct answer. Topics include: What is the name of the upstream open-source community project that Red Hat OpenShift AI is based upon?. Follow @CertPunch and visit certpunch.com for more certification practice exams and study content.

Prefer hands-on? Take this round as an interactive practice test — answer every question, get instant feedback, and see your score: Start the Red Hat Certified Specialist in OpenShift AI (EX267) practice test →

What you will practice

  • What is the name of the upstream open-source community project that Red Hat OpenShift AI is based upon?
  • What tool permits the tracking and logging of distinct ML parameters, operational metrics, and training run m…
  • To enable Data Science Pipelines in an OpenShift AI project, what resource must first be provisioned?
  • What protocol is typically used to send inference requests to a model deployed via OpenShift AI model serving?
  • What is the primary mechanism for transferring data between two sequential steps in a Data Science Pipeline?
  • Which configuration inside a custom serving runtime defines the port where KServe expects the container to ha…

Answers and explanations

Tap a question to expand the answer and the exam reasoning. Try to commit to your own pick first.

Q1. What is the name of the upstream open-source community project that Red Hat OpenShift AI is based upon?

Answer: D. Open Data Hub (ODH)

Red Hat OpenShift AI is built upon the Open Data Hub upstream community project. While Kubeflow is historically related and partially integrated, Open Data Hub is the specific upstream foundation tested on the exam.

Q2. What tool permits the tracking and logging of distinct ML parameters, operational metrics, and training run model weights?

Answer: A. Integrated MLflow Tracking Server instances

The integrated MLflow Tracking Server is the supported tool for logging machine learning parameters, metrics, and artifacts. Prometheus and Jaeger are used for infrastructure observability, not tracking model training data.

Q3. To enable Data Science Pipelines in an OpenShift AI project, what resource must first be provisioned?

Answer: A. An object storage Data Connection and a Pipeline Server

You must provision an object storage Data Connection and a Pipeline Server to enable Data Science Pipelines. The Pipeline Server uses this data connection to authenticate to S3 storage for saving pipeline artifacts and outputs.

Q4. What protocol is typically used to send inference requests to a model deployed via OpenShift AI model serving?

Answer: D. HTTP/REST or gRPC communication protocols

HTTP/REST or gRPC communication protocols are typically used to send inference requests to a deployed model via OpenShift AI model serving. Standard network protocols like FTP or SMTP are completely irrelevant to runtime model inferencing.

Q5. What is the primary mechanism for transferring data between two sequential steps in a Data Science Pipeline?

Answer: D. Pipeline artifact storage paths via object storage configuration

Sequential pipeline steps share data using object storage paths configured for pipeline artifacts. Exam tip: know that cross-step state relies on S3-compatible storage and Data Connections rather than ephemeral disk or memory.

Q6. Which configuration inside a custom serving runtime defines the port where KServe expects the container to handle traffic?

Answer: C. containerPort within runtime spec

A custom serving runtime defines its listening endpoint using the containerPort field in the runtime specification. Exam cue: KServe uses this declared port to route inference traffic, bypassing standard Service Mesh configurations.

Q7. What is a key difference between KServe and ModelMesh model serving approaches?

Answer: A. KServe isolates models per pod while ModelMesh packs models per pod

KServe deploys single models per pod for isolation, while ModelMesh packs multiple models into shared pods for efficiency. Understanding this resource allocation distinction is critical for choosing the right serving runtime.

Q8. Which runtime configuration allows multiple independent custom AI models to leverage the exact same container pod resources?

Answer: A. Multi-Model Serving Runtime configurations

Multi-Model Serving Runtime configurations allow several models to share a single pod's resources. Single-model serving isolates them, so select the multi-model runtime when optimizing for cluster resource efficiency.

Q9. How can you track the execution history, inputs, and outputs of data science workflow tasks?

Answer: D. Check the Pipeline Runs section in the dashboard

Execution history and artifacts for workflows are tracked in the Pipeline Runs section of the dashboard. Git history only tracks code changes, whereas pipeline runs log the actual inputs and outputs.

Q10. What deployment methodology allows OpenShift AI to scale inference pods down to absolute zero when there is zero incoming traffic?

Answer: C. Serverless Inference via Knative

Serverless inference via Knative scales your deployed models down to zero pods to conserve cluster resources. The OpenShift Serverless operator enables this behavior, but Knative provides the actual serverless inference functionality being described.

Q11. What is the effect of stopping a workbench within the OpenShift AI dashboard user interface?

Answer: D. The workbench pod is deleted but the persistent storage remains intact

Stopping a workbench deletes the running pod but preserves the attached persistent volume claim. This ensures your project files and data remain safely stored, allowing you to restart the workbench later without losing any progress.

Q12. Which serving architecture is designed for large language models (LLMs) requiring dedicated resources, advanced autoscaling, and raw performance?

Answer: D. KServe Single-Model Serving

KServe Single-Model Serving provides dedicated resources and advanced autoscaling for large language models. ModelMesh is designed for high-density, multi-model serving to share resources, making it unsuitable for massive LLMs.

Q13. Which storage property allows a Persistent Volume Claim to be mounted to multiple workbench pods simultaneously?

Answer: D. ReadWriteMany (RWX) profile

The ReadWriteMany access mode allows a persistent volume to be mounted as read-write by multiple nodes simultaneously. ReadWriteOnce restricts access to a single node, preventing concurrent mounting across separate workbench instances.

Q14. Which OpenShift technology provides the automatic scaling and routing features utilized by the KServe serving stack?

Answer: B. OpenShift Serverless and OpenShift Service Mesh

KServe uses Knative Serving on OpenShift Serverless for autoscaling and routing, often paired with Service Mesh. GitOps and Pipelines are deployment tools, while Serverless handles the scaling logic required for endpoints.

Q15. To deploy an ONNX model using multi-model serving, what minimum information must you supply in the Model Deployment form?

Answer: B. The model name, the storage data connection, and the path to the model file within the bucket

Deploying a model requires its name, a configured data connection, and the storage path. Dockerfiles are unnecessary because standard serving runtimes load models directly from the specified bucket via your data connection.

Q16. What happens to the running Pod of a workbench when a data scientist stops the workbench from the OpenShift AI dashboard?

Answer: D. The Pod is deleted, but the persistent volume claim (PVC) remains intact to preserve data

Stopping a workbench deletes the running pod but retains the PVC. This preserves your files and environment configuration for the next session. Beware of options claiming storage destruction, which only happens upon project deletion.

Q17. What occurs during a data science pipeline execution when an artifact is passed between two steps?

Answer: D. The artifact is uploaded to object storage and downloaded by the next step

Data science pipeline steps are ephemeral and share artifacts through object storage rather than direct memory access. The output of one step is uploaded to S3 and then downloaded by the subsequent step in the workflow.

Q18. To connect a workbench to an enterprise object storage system, which environment variables are typically generated by the Data Connection?

Answer: C. AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

OpenShift AI uses the S3 API standard for object storage connections, which maps credentials to the AWS environment variables. Workbenches read these keys to authenticate with the designated enterprise storage system.

More Red Hat Certified Specialist in OpenShift AI (EX267) drills and other practice exams are on @CertPunch. New rounds drop every few days at certpunch.com.

Scroll to Top