EX280 Practice Test 24 — 15 Questions

Question 1

A cluster administrator needs to configure a generic ephemeral inline volume in a Pod specification. Where is the volume defined?

Accepted Answer

Directly in the Pod's spec.volumes array using the ephemeral volume source type.. A generic ephemeral inline volume is defined directly in the Pod's spec.volumes array using the ephemeral volume source type. This allows the volume to be created and destroyed alongside the Pod, with the underlying storage managed by a PersistentVolumeClaim template embedded in the Pod spec. The ephemeral volume source references a volumeClaimTemplate that specifies the StorageClass and size, enabling dynamic provisioning without a separate PVC object.

Answer

In the namespace ResourceQuota configuration.

Answer

In the StorageClass definition under the ephemeralTemplate field.

Answer

As a standalone PVC that is automatically annotated by the scheduler.

Question 2

An administrator must configure a NetworkPolicy in the 'secure-zone' namespace to explicitly deny all ingress traffic except for TCP traffic coming from pods labeled 'tier=frontend' in the 'frontend-zone' namespace. Which NetworkPolicy specification achieves this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend-zone
      podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP. It uses a single ingress rule with both a namespaceSelector matching the 'frontend-zone' namespace (via the automatic label kubernetes.io/metadata.name) and a podSelector matching pods with label tier=frontend. In Kubernetes NetworkPolicy, when multiple selectors are specified within the same 'from' element, they are ANDed together, meaning only pods that satisfy both conditions are allowed. The policy also sets podSelector: {} to apply to all pods in the secure-zone namespace, and policyTypes: [Ingress] to enforce the rule, effectively denying all other ingress traffic.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.128.0.0/14
    ports:
    - protocol: TCP

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend-zone
    ports:
    - protocol: TCP

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
        matchExpressions:
          - key: namespace
            operator: In
            values: [frontend-zone]
    ports:
    - protocol: TCP

Question 3

What is the primary function of a CSI (Container Storage Interface) Driver Operator in OpenShift?

Accepted Answer

To deploy, upgrade, and manage the CSI driver components (controller and node plugins) in the cluster.. A CSI Driver Operator in OpenShift is responsible for deploying, upgrading, and managing the lifecycle of a CSI driver's components — specifically the controller plugin (Deployment) and node plugin (DaemonSet) — in the cluster. It packages the driver as an Operator so that installation, configuration, and upgrades are handled declaratively via the Operator Lifecycle Manager (OLM).

Answer

To automatically back up etcd data onto persistent volumes.

Answer

To act as an NFS server running directly on control plane nodes.

Answer

To convert emptyDir volumes into encrypted block devices.

Question 4

A developer wants to expose an application using a secure Route that terminates TLS on the pod itself, avoiding decryption at the router layer. Which TLS termination type should be selected?

Accepted Answer

passthrough. Passthrough termination allows the router to forward encrypted traffic directly to the pod without decrypting it, so TLS is terminated at the pod itself. This meets the requirement of avoiding decryption at the router layer. Edge and reencrypt both involve decryption at the router, while 'none' means no TLS termination at all.

Answer

reencrypt

Answer

edge

Answer

none

Question 5

A developer has created a Kustomization file that applies a namespace prefix and some patches to base Kubernetes manifests. How can the developer apply these manifests to an OpenShift cluster using standard oc tooling without installing standalone Kustomize?

Accepted Answer

oc apply -k ./directory. The `oc apply -k ./directory` command uses the integrated Kustomize support in the oc CLI to build and apply the Kustomization. This is the standard way to apply Kustomize manifests in OpenShift without installing standalone Kustomize.

Answer

oc create -f kustomization.yaml

Answer

oc run -k ./directory

Answer

oc kustomize apply ./directory

Question 6

An administrator needs to expose an internal application running on port 8080 via an OpenShift Route using edge termination. Which object configuration correctly defines this Route?

Accepted Answer

kind: Route
metadata:
  name: my-app
spec:
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080
  tls:
    termination: edge. The correct Route configuration for edge termination includes the tls stanza with termination: edge, which instructs the router to terminate TLS at the router and forward plain HTTP to the backend service on port 8080. The other options either use incorrect termination types or omit TLS entirely, which would not provide edge termination.

Answer

kind: Route
metadata:
  name: my-app
spec:
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080
  tls:
    termination: passthrough

Answer

kind: Route
metadata:
  name: my-app
spec:
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080

Answer

kind: Route
metadata:
  name: my-app
spec:
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080
  tls:
    termination: reencrypt

Question 7

What is the primary function of the 'self-provisioner' cluster role in OpenShift?

Accepted Answer

It allows authenticated users to create new projects.. The self-provisioner cluster role in OpenShift is a default cluster role bound to authenticated users, allowing them to create new projects (namespaces) on demand. This enables developers to self-service project creation without requiring an administrator to create namespaces for them. It is a key part of OpenShift's multi-tenant model.

Answer

It allows users to scale deployments automatically.

Answer

It allows users to provision persistent storage volumes.

Answer

It allows users to generate their own OAuth tokens.

Question 8

An administrator needs to create a service that exposes an application externally via an IP address allocated from an external cloud provider load balancer. Which service type must be used?

Accepted Answer

LoadBalancer. A Service of type LoadBalancer instructs the cloud provider's controller (or OpenShift's cloud provider integration) to provision an external load balancer with a public or private IP address, and the Service is exposed through that IP. This is the standard way to expose an application externally via a cloud LB in OpenShift/Kubernetes. The LoadBalancer type builds on NodePort and ClusterIP, adding the external IP allocation.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 9

A developer reports they cannot deploy applications because their deployment quota is exhausted. Upon inspecting the 'LimitRange' object in the namespace, you notice default limits are set. However, a specific container in their deployment YAML fails validation during creation with an admission webhook error stating 'container exceeds minimum cpu request'. Where must the adjustment be made to allow this specific deployment?

Accepted Answer

Update the container resource requests in the deployment YAML to meet or exceed the LimitRange minimums, or adjust the LimitRange object.. The admission webhook error 'container exceeds minimum cpu request' comes from the LimitRange's min constraint, which is enforced at pod admission time. To resolve it, the container's `resources.requests.cpu` must be raised to at least the LimitRange minimum, or the LimitRange's min value must be lowered to accommodate the container. Both are valid fixes, and the option correctly names both.

Answer

Modify the ClusterQuota object to increase the CPU limit.

Answer

Create a ClusterRoleBinding giving the developer cluster-admin rights to bypass admission webhooks.

Answer

Add the developer to the 'system:masters' group to override resource constraints.

Question 10

When setting up authentication and user provisioning in OpenShift 4, which THREE identity providers are natively supported out-of-the-box by the OAuth server configuration? (Choose THREE)

Accepted Answer

OpenID Connect (OIDC). OpenShift 4's OAuth server natively supports several identity providers configured through the OAuth custom resource, and OpenID Connect (OIDC) (A) is one of them, allowing integration with any OIDC-compliant provider such as Keycloak or Okta via the oidc identity provider type. HTPasswd (C) is also natively supported, using a secret containing an htpasswd-formatted file (created with htpasswd -c -B -b) to authenticate users against a static user list. LDAP (E) is natively supported as well, with the ldap identity provider type supporting direct binds, search-and-bind, and URL-based configurations against directory servers. The unmarked options do not belong because there is no 'Local Linux /etc/passwd direct sync daemon' identity provider (B) in OpenShift, and there is no 'Active Directory Domain Services native kernel module' identity provider (D); AD is integrated indirectly via LDAP or OIDC, not through a kernel module.

Answer

Local Linux /etc/passwd direct sync daemon

Answer

Active Directory Domain Services native kernel module

Question 11

Which TWO methods can an administrator use to inspect or troubleshoot Security Context Constraint (SCC) assignments for a specific ServiceAccount in a namespace?

Accepted Answer

Use oc auth can-i create pods --as=system:serviceaccount:: to test permissions.. Option B is correct because `oc auth can-i` with the `--as=system:serviceaccount::` flag performs a SubjectAccessReview impersonating the ServiceAccount, letting an administrator verify whether that ServiceAccount can perform an action (such as creating pods) that is gated by SCC admission, which directly tests effective SCC-derived permissions. Option D is correct because `oc adm policy who-can use scc restricted-v2` queries the RBAC rules bound to the SCC's `use` verb and lists exactly which users, groups, and ServiceAccounts (including those in the target namespace) are authorized to use that SCC, which is the standard way to inspect SCC assignments. Option A is not correct because SCCs are stored as cluster-scoped API objects (retrievable via `oc get scc`), not in a static `/etc/origin/master/scc.yaml` file on control plane nodes. Option C is not correct because SCC assignment is not controlled by a `kubernetes.io/scc-assignment-override` annotation on the ServiceAccount; it is determined by RBAC bindings to the SCC's `use` verb. Option E is not correct because kube-apiserver static pod logs may show admission denials but do not enumerate or inspect SCC assignments for a specific ServiceAccount.

Answer

Examine the /etc/origin/master/scc.yaml file on control plane nodes.

Answer

Inspect the service account's annotations for the kubernetes.io/scc-assignment-override key.

Answer

Check the logs of the kube-apiserver static pod for SCC admission failures.

Question 12

An administrator needs to view the current list of active Security Context Constraints installed in an OpenShift cluster. Which command should be executed?

Accepted Answer

oc get scc. The `oc get scc` command is the correct way to list Security Context Constraints in an OpenShift cluster. SCC is the official short name (singular/plural) registered for the securitycontextconstraints resource in the OpenShift API, so `oc get scc` returns the full list of active SCCs such as restricted, anyuid, hostaccess, and privileged.

Answer

oc get securityconstraints

Answer

oc adm policy list-constraints

Answer

oc describe clustersecurity

Question 13

An administrator needs to modify the default Ingress controller configuration to change its replica count and adjust the router deployment parameters. Which resource should the administrator edit?

Accepted Answer

ingresscontroller.operator.openshift.io named 'default'. The Ingress controller configuration in OpenShift is managed by the IngressController operator resource named 'default' in the openshift-ingress-operator namespace. To change replica count and router deployment parameters, the administrator edits this ingresscontroller.operator.openshift.io custom resource. The operator then reconciles the changes into the router Deployment.

Answer

deployment named router-default in openshift-ingress namespace

Answer

configmap named router-config in openshift-ingress-operator

Answer

service named router-default-http in openshift-ingress

Question 14

Which TWO of the following are valid built-in default project roles in OpenShift that can be assigned to users within a namespace? (Choose TWO)

Accepted Answer

admin. In OpenShift, the built-in default project (namespace-scoped) roles that can be bound to users within a namespace include admin and edit, so options A and C are correct. The admin role grants full control over a project, including managing roles and bindings within that namespace, while the edit role allows creating, modifying, and deleting most resources in the project but not managing roles or bindings. These roles are part of the standard OpenShift RBAC set (admin, edit, view, and sometimes self-provisioner) applied per namespace. Option B (security-admin) is not a built-in default project role; security context constraints are managed via cluster roles such as system:cluster-admin or specific SCC-related roles. Option D (node-admin) is not a built-in project role; node management is a cluster-level concern handled by cluster roles. Option E (cluster-admin) is a cluster-scoped role, not a namespace-scoped default project role, so it does not fit the scenario.

Answer

security-admin

Answer

node-admin

Answer

cluster-admin

Question 15

An administrator needs to deploy a containerized web application using a Git repository as the source without writing a Dockerfile. Which OpenShift build strategy should be used?

Accepted Answer

Source-to-Image (S2I) strategy. The Source-to-Image (S2I) strategy builds application images by combining builder images with source code, without requiring a Dockerfile. OpenShift injects the source into the builder image, runs assemble/run scripts, and produces a runnable image. This is the standard approach for deploying from Git when no Dockerfile exists.

Answer

Docker strategy

Answer

Custom strategy

Answer

Pipeline strategy