Red Hat Certified OpenShift Architect Free Practice Questions
This practice bank exercises core Red Hat OpenShift architect knowledge, focusing on resource organization, scheduling, builds, networking, configuration management, security, deployment strategies, high availability, automation, resource governance, storage, access control, templating, DNS, and health checks. To succeed, you must differentiate between analogous resources (e.g., Route vs. Service vs. Ingress), understand control plane components, and recognize where specific policies apply. The questions test decision-making on isolating workloads with Projects, managing image compliance via ImagePolicyWebhook, and ensuring application resilience through pod distribution and health probes. Mastery requires linking each component to its architectural role rather than memorizing isolated facts.
What this Red Hat Certified OpenShift Architect practice set measures
This is an analysis of the practice bank, not a claim about the vendor's live exam blueprint. Use it to identify the knowledge, judgment, and recall patterns exercised here, then verify your coverage against the current official exam guide.
Resource Organization and Multi-Tenancy
The practice bank emphasizes how OpenShift organizes workloads and enforces boundaries. A Project provides a namespace-like boundary for resource isolation and access policies, distinct from permanent storage or hardware definitions. Confusion often arises between Projects and other grouping mechanisms; Projects are the primary multi-tenancy unit. Understanding when to use Projects versus simple namespaces is key. The questions test the ability to apply Projects for logical separation without conflating them with storage or compute constructs.
- Projects isolate resources and RBAC policies for a set of workloads.
- They are not tied to hardware or used as permanent storage.
- Templates enable reusable deployment configurations across projects.
- ConfigMaps and Secrets decouple configuration from images, not from projects.
Application Lifecycle and Configuration
This section covers the build and deployment pipeline in OpenShift. BuildConfig defines how to build a container image from source, automating CI/CD. DeploymentConfig manages replica set lifecycles and rolling updates, distinguishing it from simple Kubernetes Deployments. The questions test the ability to select the correct resource for exposing applications externally (Route) versus internal access (Service). Health checks (probes) ensure containers are restarted if they fail to serve traffic, directly impacting availability decisions. Resource limits defined in the Pod specification govern CPU and memory consumption.
- BuildConfig automates image creation from source; it does not govern networking.
- DeploymentConfig handles rollouts and scaling, not storage or authentication.
- Route provides external HTTP/HTTPS access; Service offers stable internal endpoints.
- Health checks trigger container restarts on failure, improving availability.
Security and Access Control
OpenShift enforces security through multiple complementary mechanisms. ImagePolicyWebhook validates image provenance before deployment, ensuring only approved images run. RBAC provides fine-grained access control over resources. SecurityContextConstraints and Pod Security Admission manage runtime security but are not the primary image governance tools. The practice bank requires distinguishing image governance from access control and runtime security. Questions also explore how PersistentVolumeClaims request storage and how secrets are decoupled from images, reinforcing least-privilege patterns.
- ImagePolicyWebhook approves images at admission time; ImageStreamTags track versions.
- RBAC controls who can perform actions on resources.
- PersistentVolumeClaims request storage from the cluster; they do not affect networking.
- ConfigMaps and Secrets decouple sensitive configuration from images.
Cluster Services and Resilience
High availability and cluster infrastructure are central to the architect role. Distributing replicas across nodes prevents downtime during maintenance. Operators automate management of stateful applications, handling upgrades and backups. CoreDNS provides internal DNS for service discovery. The scheduler assigns pods to nodes based on resource availability. Questions test whether you can identify the responsible component for scheduling (Scheduler) versus other control plane elements. Understanding these services ensures reliable and scalable cluster operations.
- Pod distribution across nodes improves availability during node drains.
- Operators automate lifecycle management for complex stateful applications.
- CoreDNS resolves service names for inter-pod communication.
- Scheduler selects suitable nodes for new pods based on policies.
- ResourceQuota and LimitRange manage namespace-level consumption.
Practice Red Hat Certified OpenShift Architect with real flashcards
Read the prompt, commit to an answer, then flip the card. Move through the deck at your own pace and repeat any topic that does not come back quickly.
Card 1 of 20
1 reviewed this session
Static practice bank
Start the 15-question diagnostic
The complete question bank is embedded in this pre-rendered page. There is no database request or second content download when you begin.
What is the primary purpose of a Project in OpenShift?
Show hint
Understand core OpenShift multi-tenancy concepts
Study workflow
Turn one Red Hat Certified OpenShift Architect attempt into a study plan
- 1
Review Each Question Without Looking at Answers
Read each question carefully and attempt to answer based on your existing knowledge. Note any uncertainties. This reveals gaps and builds recall, especially for differentiating similar resources.
- 2
Analyze the Explanation for Every Question
After answering, read the provided explanation. Focus on why the correct answer is right and how it connects to core architectural concepts. Highlight any new distinctions, such as Route vs. Ingress.
- 3
Group Questions by Underlying Domain
Categorize each question into domains like multi-tenancy, builds, networking, security, storage, and scheduling. Identify which domains you frequently answer incorrectly and target those for deeper study.
- 4
Create Your Own Variant Questions
For each question, change one parameter (e.g., 'What if the requirement is internal-only traffic?') and reason which resource would apply. This deepens understanding beyond memorization.
- 5
Use Flashcards to Reinforce Weak Areas
Generate spaced-repetition flashcards for concepts you find challenging. Quiz yourself daily until you can describe each component's role without hesitation.
FAQ
Questions about this exam practice page
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
What is the difference between a Project and a Namespace in OpenShift?+
In OpenShift, a Project is a Kubernetes Namespace with additional annotations and policies. Projects provide enhanced multi-tenancy features like per-project access control and network isolation, while a plain Namespace lacks those OpenShift-specific extensions.
When should I use a Route versus a Service of type LoadBalancer?+
Use a Route for HTTP/HTTPS traffic with hostname-based routing, TLS termination, and path rewriting. A LoadBalancer Service does not provide these features and is suitable for non-HTTP protocols or when using an external load balancer directly.
How does ImagePolicyWebhook enforce image compliance?+
ImagePolicyWebhook is an admission controller that calls an external policy server to verify the image before allowing the pod to be created. It can block images from untrusted registries or enforce signing requirements, complementing but not replacing RBAC.
What is the role of an Operator in managing stateful applications?+
An Operator encodes domain-specific operational knowledge into software to automate the full lifecycle of a stateful application—including provisioning, scaling, upgrades, backups, and recovery. It extends the Kubernetes API to manage these tasks without manual intervention.
How do health checks improve application availability in OpenShift?+
Health checks (liveness and readiness probes) monitor container health. Liveness probes restart unhealthy containers; readiness probes stop sending traffic to unready pods. Together, they ensure only healthy instances serve requests, maintaining application availability during failures.
Build the next review session
Browse another free bank or use the study strategy guide to turn your misses into spaced review.