Red Hat Certified OpenShift Application Developer Free Practice Questions
This deck covers core OpenShift concepts tested in the practice bank: deploying applications using DeploymentConfig and StatefulSet, automating builds with BuildConfig and ImageStream, exposing services via Routes, and securing clusters with ServiceAccounts, SecurityContextConstraints, and ImagePolicy webhooks. You'll decide which resource to use for stateful workloads, how to trigger rollouts, and how to inject configuration. Master these decisions to confidently manage application lifecycles on Red Hat OpenShift.
What this Red Hat Certified OpenShift Application Developer 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.
Application Deployment and Management
This section focuses on defining and managing application deployments. The practice bank emphasizes DeploymentConfig (OpenShift-specific, supports triggers) and StatefulSet (for stateful apps). 'oc new-app' streamlines initial resource creation, while 'oc set image' updates container images. Understanding the difference between DeploymentConfig and Deployment (Kubernetes native) is key. Rollouts are triggered by image changes in BuildConfig.
- Use DeploymentConfig for most stateless apps; supports build and image change triggers.
- StatefulSet is the Kubernetes resource for stateful applications requiring stable identities.
- 'oc new-app' automates creation of builds, services, and deployment configs from source or image.
- 'oc set image' updates the container image for a deployment config or deployment.
Build and Release Automation
BuildConfig defines how source code is built into a container image. ImageStream tracks image tags and can trigger deployments when images update. The practice bank highlights that an image change in BuildConfig triggers a new deployment for a DeploymentConfig. External DNS provider integration automatically manages Route hostnames—a facet of release automation.
- BuildConfig specifies build source, strategy, and output; automates image creation.
- ImageStream tracks image tags and can trigger builds or deployments on updates.
- Image change in BuildConfig is a trigger for DeploymentConfig new deployments.
- External DNS provider integration auto-updates DNS records when Routes are created.
Networking and External Access
Route resources expose services externally via hostnames and load balancing. The practice bank reinforces that Routes provide external HTTP/HTTPS access, not build pipelines or storage. External DNS integration is a feature that automates DNS management. Understanding Route's role is crucial for making applications accessible outside the cluster.
- Route provides external hostname and load balancing for services.
- Routes are used for HTTP/HTTPS access; not for builds, replicas, or storage.
- External DNS integration can automatically update records when Routes are created or modified.
Security and Configuration
SecurityContextConstraints define pod-level security policies. ServiceAccounts provide identity for pod processes. ConfigMaps store non-confidential configuration (env vars, files); Secrets for sensitive data. ImagePolicy webhook enforces that only approved images are deployed. The practice bank tests the difference between ConfigMap and Secret and the role of ServiceAccounts.
- SecurityContextConstraints control allowed capabilities, user IDs, etc. for pods.
- ServiceAccount provides an identity for processes in pods to interact with API.
- ConfigMap stores non-sensitive config; Secret stores sensitive data (e.g., passwords).
- ImagePolicy webhook validates images against approval policies before deployment.
Practice Red Hat Certified OpenShift Application Developer 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.
Which resource definition is required to deploy a containerized application on OpenShift?
Show hint
Define and manage application deployments
Study workflow
Turn one Red Hat Certified OpenShift Application Developer attempt into a study plan
- 1
Deploy a Stateless Application
Use 'oc new-app' with source or image to create a BuildConfig and DeploymentConfig automatically. Alternatively, manually define a DeploymentConfig YAML specifying containers, replicas, and triggers. Apply with 'oc apply -f'. This automates build and deployment lifecycle.
- 2
Trigger a New Deployment on Image Update
Set up a BuildConfig that outputs to an ImageStream. In the DeploymentConfig, add an image change trigger referencing that ImageStream. When a new image tag is pushed (e.g., via 'oc start-build'), the trigger automatically initiates a rollout. Verify with 'oc rollout status'.
- 3
Expose a Service via Route
After creating a Service, run 'oc expose service <service-name>' to generate a Route. This creates a hostname for external access. Edit the Route YAML to secure it with TLS or customize the hostname. Use 'oc get route' to see the URL.
- 4
Inject Configuration via ConfigMap
Create a ConfigMap from literal values or files using 'oc create configmap'. Then in your DeploymentConfig or Deployment, reference the ConfigMap under 'env' (key-value) or 'volumes' (config file). Apply the update. For secrets, use 'oc create secret generic' and reference similarly.
- 5
Enforce Image Approval with ImagePolicy
Define an ImagePolicy webhook configuration that specifies allowed image registries or tags. Apply as an admission webhook. Then test by deploying an image not matching policy; the deployment should be rejected. This ensures only approved container images run in the cluster.
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.
When should I use a DeploymentConfig instead of a Deployment?+
Use DeploymentConfig when you need OpenShift-specific features like image change triggers from ImageStreams, or when migrating from earlier OpenShift versions. Deployment is the Kubernetes-native resource, better for portability. Both support rollbacks.
How do I automatically redeploy when a ConfigMap changes?+
DeploymentConfig does not automatically redeploy on ConfigMap changes. You need to manually trigger a rollout (e.g., 'oc rollout latest') or use a deployment strategy that restarts pods. Alternatively, use tools like Reloader or a sidecar watcher.
What is the difference between a BuildConfig and a DeploymentConfig?+
A BuildConfig defines how to build a container image from source code (e.g., Dockerfile or S2I). A DeploymentConfig defines how to run that image (replicas, environment, probes). They are often used together: BuildConfig produces an image, and DeploymentConfig runs it.
How can I restrict which images are deployed in OpenShift?+
Use an ImagePolicy webhook that validates image references against policies (e.g., allow only images from trusted registries). You can also use ImageStreamTags with import policies. This prevents running unapproved or vulnerable images.
What is the purpose of a ServiceAccount in OpenShift?+
A ServiceAccount provides an identity for processes running inside a pod. It allows pods to authenticate to the Kubernetes API server and perform authorized operations. For example, a pod can use its ServiceAccount token to list pods or update resources.
Build the next review session
Browse another free bank or use the study strategy guide to turn your misses into spaced review.