EX280 Security And SCC Practice Test 3 — 15 Questions

Question 1

A pod in the project `payments` is being rejected at admission with the error `unable to validate against any security context constraint`. The pod manifest explicitly sets `securityContext.runAsUser: 1000100000` and `fsGroup: 1000100000`. The `payments` ServiceAccount is bound to the `nonroot-v2` SCC, and the namespace is not exempt from SCC admission. Which SCC setting is most likely causing the rejection?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The SCC's `runAsUser` strategy is `MustRunAsRange`, and the requested UID 1000100000 falls outside the allowed UID range.. The `nonroot-v2` SCC uses a `MustRunAsRange` user strategy with a minimum UID of 1000, so a pod requesting UID 1000100000 exceeds the permitted range and is rejected during admission. The `fsGroup` and privilege-escalation settings are irrelevant to this specific error. To resolve the issue, either omit the explicit UID so the SCC assigns one from the namespace range, or bind the ServiceAccount to an SCC whose `runAsUser` range includes the requested UID.

Answer

The SCC's `runAsUser` strategy is `MustRunAsNonRoot`, which accepts the UID but rejects the explicit `fsGroup`.

Answer

The `payments` ServiceAccount is missing the `system:openshift:scc:nonroot-v2` ClusterRoleBinding, so all SCCs are denied.

Answer

The SCC lacks the `allowPrivilegeEscalation` admission plugin, so the explicit UID cannot be validated.

Question 2

A cluster administrator must allow a pod in namespace data-processing to use the hostPath volume /var/log/applogs for a log-forwarding sidecar. The pod currently uses the restricted-v2 SCC. Which step is required to permit this volume type?

Accepted Answer

Create a new SCC that allows hostPath volumes and bind it to the service account used by the pod, then remove the restricted-v2 binding.. To allow a hostPath volume, the pod must be admitted under an SCC that includes hostPath in its allowed volume plugins. Creating a custom SCC and binding it to the pod's service account grants the necessary permission without weakening the default restricted-v2 SCC for other workloads. The pod will then be evaluated against both SCCs and admitted if it satisfies at least one.

Answer

Set the pod's securityContext to privileged: true, which overrides the SCC and allows any volume type.

Answer

Add the hostPath volume to the pod spec; the restricted-v2 SCC will automatically allow it if the path is under /var/log.

Answer

Edit the restricted-v2 SCC to add hostPath to the allowed volume plugins list, then restart the kubelet on all nodes.

Question 3

An administrator wants to pull container images from a private container registry that requires authentication for a specific deployment. Where must the image pull secret be referenced so that the deployment pods can successfully pull the image?

Accepted Answer

In the Deployment configuration spec under template.spec.imagePullSecrets. The image pull secret must be referenced in the pod template spec under template.spec.imagePullSecrets so that the kubelet uses those credentials when pulling the image for each pod. This field accepts a list of Secret names in the same namespace, and OpenShift injects them into the pod's service account context at pull time. Placing it in the Deployment's pod template ensures every replica created by the ReplicaSet inherits the credential reference.

Answer

As an annotation on the cluster-scoped Namespace object

Answer

Inside the Route object spec under tls.imagePullSecret

Answer

As an environment variable named IMAGE_PULL_SECRET in the container specification

Question 4

An administrator needs to secure a Route with edge termination using a custom TLS certificate and private key. Which section of the Route manifest must contain these certificate details?

Accepted Answer

spec.tls.certificate, spec.tls.key, and spec.tls.caCertificate. For edge termination, the Route's spec.tls section holds the certificate, key, and optional CA certificate as plain string fields (not base64). The router terminates TLS at the edge using these values, then forwards plain HTTP to the pods. The correct fields are spec.tls.certificate, spec.tls.key, and spec.tls.caCertificate.

Answer

spec.endpoint.tls with base64 encoded string data

Answer

metadata.annotations containing openshift.io/tls-cert and openshift.io/tls-key

Answer

status.ingress.tls for automatic cert-manager synchronization

Question 5

An administrator needs to configure an authentication mechanism where users logging into the OpenShift web console are authenticated via an external corporate directory using LDAP. Which resource object should the administrator configure?

Accepted Answer

The cluster OAuth custom resource named cluster. In OpenShift, the cluster OAuth custom resource named `cluster` is the central configuration point for identity providers, including LDAP. Administrators configure the `spec.identityProviders` field to add an LDAP identity provider, specifying connection details, bind credentials, and attribute mappings. This resource is cluster-scoped and resides in the `openshift-config` namespace, and changes trigger a redeployment of the OAuth server pods.

Answer

A Secret named identity-provider in the openshift-authentication namespace

Answer

An Authentication custom resource named cluster in the kube-system namespace

Answer

A ConfigMap named ldap-config in the openshift-config namespace

Question 6

When configuring an OAuth identity provider of type HTPasswd, which object type must be created to store the username and hashed password pairs?

Accepted Answer

A Secret containing the htpasswd flat-file data. In OpenShift, the HTPasswd identity provider requires a Secret of type Opaque that contains a key named 'htpasswd' holding the flat-file data generated by the htpasswd command. This Secret is created in the openshift-config namespace and referenced in the OAuth custom resource. The Secret stores the username and bcrypt-hashed password pairs, which the OAuth server uses to authenticate users.

Answer

A ServiceAccount with special token annotations

Answer

A ConfigMap containing plain-text user credentials

Answer

A custom resource of kind HTPasswdProvider in the openshift-config namespace

Question 7

An administrator needs to configure re-encrypt TLS termination on a Route. In addition to the router certificate, what other certificate component must typically be provided in the route configuration?

Accepted Answer

The destination CA certificate to validate the backend pod's TLS certificate. In re-encrypt TLS termination, the router decrypts incoming traffic and then re-encrypts it before forwarding to the backend pod. To validate the backend pod's certificate during this second TLS handshake, the router must trust the CA that signed the pod's certificate. Therefore, the destination CA certificate is required in the Route configuration, in addition to the router's own certificate.

Answer

A base64 encoded kubeconfig file for the ingress operator

Answer

An identity provider public key for JSON Web Token validation

Answer

A client certificate for mutual TLS authentication against the OAuth server

Question 8

An application deployed in a secured namespace requires access to the Kubernetes API to query pod statuses. The administrator wants to follow the principle of least privilege. How should the administrator configure the ServiceAccount and RBAC?

Accepted Answer

Create a dedicated ServiceAccount, a Role granting get and list on pods, and a RoleBinding linking them in the namespace. Least privilege means granting only the permissions the application actually needs, scoped to the namespace where it runs. A dedicated ServiceAccount isolates the identity, a namespaced Role with get/list on pods grants exactly the required verbs, and a RoleBinding ties them together within the namespace. This avoids cluster-wide permissions and avoids reusing the default ServiceAccount.

Answer

Bind the cluster-admin ClusterRole to the default ServiceAccount in the namespace using a ClusterRoleBinding

Answer

Annotate the default ServiceAccount with rbac.authorization.k8s.io/authtype: reader

Answer

Grant the system:openshift:scc:restricted ClusterRole to the ServiceAccount using a RoleBinding

Question 9

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 10

An administrator is securing routes in an OpenShift cluster. Which THREE TLS termination types are supported natively by OpenShift Routes? (Choose THREE)

Accepted Answer

Passthrough. OpenShift Routes natively support three TLS termination types: Edge, Passthrough, and Re-encrypt. Option A (Passthrough) is correct because the router forwards encrypted traffic directly to the pod without terminating TLS, letting the application handle the certificate. Option B (Edge) is correct because TLS is terminated at the router, which then forwards plain HTTP to the backend pods. Option E (Re-encrypt) is correct because TLS is terminated at the router and a new TLS connection is established to the backend using a separate certificate. Option C (Proxy) is not a valid OpenShift Route termination type, and Option D (FullMesh) is not a supported termination type either; both are distractors not recognized by the Route API.

Answer

Proxy

Answer

FullMesh

Question 11

An administrator needs to troubleshoot an image pull failure caused by missing credentials. Which TWO locations or methods can be used to associate an image pull secret with a workload in OpenShift? (Choose TWO)

Accepted Answer

Linking the image pull secret to the ServiceAccount referenced by the deployment's pod spec via oc secrets link. Option D is correct because `oc secrets link --for=pull` associates the pull secret with a ServiceAccount, and any pod that references that ServiceAccount in its pod spec automatically inherits the secret for image pulls. Option E is correct because a Deployment's pod template can explicitly list the secret under `spec.template.spec.imagePullSecrets`, which causes the kubelet to use those credentials when pulling the container image. Option A is incorrect because the Ingress controller custom resource spec configures routing/TLS behavior, not workload image pull credentials. Option B is incorrect because the global pull secret is stored in the `openshift-config` namespace as the `pull-secret` Secret (referenced by cluster configuration), not as a ConfigMap. Option C is incorrect because there is no supported `openshift.io/image-pull-secret-ref` annotation on a Namespace for associating pull secrets with workloads.

Answer

Defining the secret inside the cluster Ingress controller custom resource spec

Answer

Placing the pull secret in the global openshift-config ConfigMap

Answer

Annotating the Namespace with openshift.io/image-pull-secret-ref

Question 12

An administrator is configuring authentication in OpenShift. Which TWO of the following identity provider types are natively supported by the OpenShift OAuth server? (Choose TWO)

Accepted Answer

HTPasswd. Option A (HTPasswd) is correct because the OpenShift OAuth server natively supports the HTPasswd identity provider, which validates users against a flat file of bcrypt-hashed credentials generated with htpasswd and referenced via the htpasswd secret. Option B (LDAP) is correct because OpenShift ships a built-in LDAP identity provider that binds and searches an LDAPv3 directory (for example via ldap:// or ldaps:// URLs) using configured bindDN, bindPassword, and attribute mappings. The remaining options are not real OpenShift identity provider types: CustomDatabaseProvider and LocalFileAuthService are fabricated names, and ActiveDirectoryNativeProtocol is not a provider — Active Directory is integrated through the LDAP identity provider rather than a dedicated native protocol.

Answer

CustomDatabaseProvider

Answer

LocalFileAuthService

Answer

ActiveDirectoryNativeProtocol

Question 13

An administrator is reviewing the default Security Context Constraints in OpenShift 4.14+. Which THREE of the following SCCs are built-in and provided out-of-the-box by OpenShift? (Choose THREE)

Accepted Answer

nonroot. Option C (nonroot) is correct because OpenShift ships a built-in nonroot SCC that allows pods to run as any non-root UID while still restricting privileged access, and it is part of the default SCC set. Option D (restricted-v2) is correct because it is the default SCC assigned to authenticated users in OpenShift 4.14+, replacing the older restricted SCC with stricter seccomp and capability requirements. Option E (privileged) is correct because the privileged SCC is a built-in SCC that allows full unrestricted host access and is provided out-of-the-box for system workloads. Options A (root-container-v1) and B (custom-app-scc) are not built-in SCCs; they appear to be custom or fabricated names, and OpenShift does not provide them by default.

Answer

root-container-v1

Answer

custom-app-scc

Question 14

An administrator is auditing Security Context Constraints and wants to identify which settings can be controlled within a custom SCC definition. Which THREE fields are valid configuration options inside an SCC resource? (Choose THREE)

Accepted Answer

requiredDropCapabilities. Option C, requiredDropCapabilities, is a valid SCC field that lists Linux capabilities (e.g., KILL, MKNOD, SYS_ADMIN) which are dropped from all containers, and it is commonly used to enforce a baseline of reduced privileges. Option D, allowPrivilegedContainer, is a valid boolean SCC field that determines whether a pod may request a privileged container, directly controlling a key privilege-escalation vector. Option E, volumes, is a valid SCC field that enumerates the volume plugin types (such as configMap, emptyDir, hostPath, persistentVolumeClaim) a pod is permitted to use, restricting host-level storage access. The unmarked options do not belong because routeAdmissionLimit and networkPolicyMode are not fields in the OpenShift SecurityContextConstraints API; route and network policy behavior is governed by other resources like Route and NetworkPolicy objects, not by SCCs.

Answer

routeAdmissionLimit

Answer

networkPolicyMode

Question 15

An administrator needs to restrict pod creation based on Pod Security Standards namespaces. Which TWO of the following are valid Pod Security Standard levels defined by Kubernetes and supported in OpenShift? (Choose TWO)

Accepted Answer

restricted. Option B (restricted) is correct because the Kubernetes Pod Security Standards define exactly three levels — privileged, baseline, and restricted — and restricted is the most stringent, enforcing hardening such as requiring non-root execution, dropping all capabilities, and disallowing hostPath/host namespaces. Option C (baseline) is correct because it is the minimally restrictive level that still blocks known privilege escalations (e.g., hostNetwork, hostPID, privileged containers) while allowing default pod configurations. OpenShift supports these levels via namespace labels such as pod-security.kubernetes.io/enforce=baseline or restricted, which is how an administrator restricts pod creation per namespace. Options A (hardened), D (secured), and E (isolated) are not valid Pod Security Standard levels defined by Kubernetes; they are not recognized values for the pod-security.kubernetes.io/enforce label and therefore would not restrict pod creation as intended.

Answer

hardened

Answer

secured

Answer

isolated