EX280 Security And SCC Practice Test 2 — 15 Questions

Question 1

A pod fails to start with 'container has runAsNonRoot and image will run as root'. Which SCC field needs to be adjusted in a custom SCC to allow this image to run?

Accepted Answer

runAsUser: RunAsAny. The error 'container has runAsNonRoot and image will run as root' occurs when the container image is configured to run as UID 0 (root) but the SCC enforces runAsNonRoot. To allow the image to run as root, the SCC's runAsUser strategy must be set to RunAsAny, which permits any UID including root. This overrides the MustRunAsRange or MustRunAsNonRoot restrictions.

Answer

runAsUser: MustRunAsRange

Answer

readOnlyRootFilesystem: false

Answer

allowPrivilegedEscalation: true

Question 2

You have a private image registry that requires credentials. Where should you place the 'imagePullSecret' so that it is automatically injected into all pods created by a specific service account?

Accepted Answer

oc secrets link default . To automatically inject an image pull secret into all pods created by a specific ServiceAccount, the administrator should link the secret to that ServiceAccount using 'oc secrets link --for=pull'. This adds the secret to the ServiceAccount's imagePullSecrets field, and any pod using that ServiceAccount will inherit the credentials. The 'default' ServiceAccount is commonly used for this purpose.

Answer

oc annotate sa default imagePullSecret=<secret-name>

Answer

oc edit namespace --add-secret=

Answer

oc set image-pull-secret <secret-name>

Question 3

You want to ensure that all pods in a namespace are denied access to the host network. Which policy mechanism is most effective for this?

Accepted Answer

Configure an SCC with 'hostNetwork: false'. Security Context Constraints (SCCs) in OpenShift control pod-level security attributes, including whether a pod can use the host network (hostNetwork). Setting hostNetwork: false in an SCC and binding it to the namespace's service accounts denies pods the ability to request host networking. This is the most effective mechanism because SCCs are enforced by the API server at pod admission time, preventing the pod from being created with hostNetwork: true.

Answer

Configure the IngressController

Answer

Use a NetworkPolicy

Answer

Use an ImagePolicyWebhook

Question 4

You are hardening a cluster. Which Pod Security Standard level is the default in OpenShift 4.14 for new projects?

Accepted Answer

restricted. In OpenShift 4.14, the default Pod Security Standard (PSS) level enforced for new projects is restricted, aligning with the upstream Kubernetes Pod Security Admission restricted profile. This is set via the cluster-wide pod security configuration and applied through the restricted-v2 SCC. New namespaces get labels like pod-security.kubernetes.io/enforce: restricted by default.

Answer

baseline

Answer

privileged

Answer

enforce

Question 5

A pod requires access to the hostPath volume. Which SCC field must be configured to allow this?

Accepted Answer

volumes: ["hostPath"]. The SCC field that controls hostPath volume access is 'volumes', which is a list of allowed volume plugin types. To permit hostPath mounts, the SCC must include 'hostPath' in its volumes list, e.g., volumes: ["hostPath", "configMap", "secret"]. This is the exact field the SCC admission controller checks against the pod's volume definitions.

Answer

allowHostPath: true

Answer

privileged: true

Answer

mounts: host

Question 6

Which command displays the SCCs currently assigned to a specific service account?

Accepted Answer

oc adm policy who-can use scc. The command `oc adm policy who-can use scc` is specifically designed to show which users, groups, or service accounts have access to a given Security Context Constraint (SCC). When run with a service account, it lists the SCCs that the service account can use, effectively displaying the SCCs currently assigned to it. This is the correct tool because SCCs are cluster-level resources, and their assignment to service accounts is determined by RBAC bindings; `who-can` queries those bindings directly.

Answer

oc auth can-i -list

Answer

oc describe sa <sa-name>

Answer

oc get scc

Question 7

A container needs to run as a specific non-root UID. Which SCC field configuration is needed?

Accepted Answer

runAsUser: MustRunAs, uid: 1000. To force a container to run as a specific non-root UID, the Security Context Constraint (SCC) must use runAsUser with strategy MustRunAs and an explicit uid value (e.g., uid: 1000). MustRunAs requires the container to run as the specified UID and rejects any pod that requests a different one. This is the only option that pins the container to a single, specific UID.

Answer

runAsUser: MustRunAsRange

Answer

runAsUser: RunAsAny

Answer

runAsUser: None

Question 8

You are troubleshooting a TLS certificate issue on a route. Which command shows the current certificate status and details?

Accepted Answer

oc describe route . The 'oc describe route ' command outputs the full route specification including the TLS termination type, certificate details, and the status of the router's TLS configuration. It shows the certificate's subject, issuer, and validity, along with any conditions or errors reported by the ingress controller. This makes it the correct tool for troubleshooting TLS certificate issues on an OpenShift route.

Answer

oc check tls <route-name>

Answer

oc inspect route

Answer

oc get tls

Question 9

Which command removes an SCC from a service account?

Accepted Answer

oc adm policy remove-scc-from-user. The command 'oc adm policy remove-scc-from-user' is used to remove a Security Context Constraint (SCC) from a service account (which is a type of user in OpenShift). This command modifies the cluster role bindings that associate the SCC with the service account. The other options are not valid OpenShift commands for this purpose.

Answer

oc remove-scc

Answer

oc delete scc-binding

Answer

oc patch scc

Question 10

You need to update the CA certificate used for the web console. Where is this configured?

Accepted Answer

In the 'console' operator configuration. The CA certificate used for the web console is configured in the 'console' operator configuration. The console operator manages the console deployment and its TLS certificates. To update the CA certificate, you modify the console operator's configuration, typically by updating the custom resource or the operator's config map.

Answer

In the cluster config map

Answer

In the authentication operator

Answer

In the 'ingress' operator configuration

Question 11

Which TWO service accounts have special roles in OpenShift projects regarding SCCs?

Accepted Answer

default. In OpenShift, every project is automatically provisioned with two special service accounts that receive dedicated SCC-related privileges: the 'default' service account (option C) and the 'builder' service account (option D). The 'default' service account is used by pods that do not specify a service account and is granted the 'restricted' SCC by default, while the 'builder' service account is used by build pods and is granted the 'privileged' SCC so builds can run with the elevated permissions they require. Both accounts are created per project and are bound to specific SCCs via default role bindings, which is why they are considered special in the context of SCCs. Option A ('oauth-proxy') is not a standard per-project service account with special SCC roles; it is typically a sidecar container image/account used for authentication proxying. Option B ('kube-system') is a namespace, not a service account, and option E ('system-admin') is a cluster role/cluster-admin-style identity rather than a per-project service account with special SCC treatment.

Answer

oauth-proxy

Answer

kube-system

Answer

system-admin

Question 12

Which THREE fields are critical for controlling pod volume access in an SCC?

Accepted Answer

readOnlyRootFilesystem. In an OpenShift Security Context Constraints (SCC), the readOnlyRootFilesystem field (B) is critical because it forces containers to mount their root filesystem read-only, preventing writes to the container's own filesystem and thus restricting volume-related write access. The fsGroup field (C) is critical because it defines the supplemental group that owns mounted volumes, controlling which group ID can read/write volume data via fsGroup-based permissions. The volumes field (E) is critical because it explicitly lists which volume plugin types (e.g., hostPath, emptyDir, persistentVolumeClaim, configMap, secret) a pod is allowed to use, directly gating volume access. The privileged field (A) governs whether a container can run in privileged mode with elevated capabilities, which is about host-level access rather than volume access control. The hostNetwork field (D) controls whether a pod shares the host's network namespace, which is a networking concern and unrelated to volume access.

Answer

privileged

Answer

hostNetwork

Question 13

Which TWO actions are necessary when migrating from Htpasswd to OIDC?

Accepted Answer

Update the OAuth cluster resource. Option B is correct because migrating from Htpasswd to OIDC requires updating the OAuth cluster resource (the cluster-scoped OAuth object named 'cluster') so that the API server's authentication configuration reflects the new identity provider instead of the old HTPasswd identity provider. Option E is correct because the new OIDC identity provider must be defined in the OAuth configuration, specifying the issuer URL, client ID, client secret, and claims mappings so users can authenticate via the OIDC provider. Option A is not required because the kube-apiserver is not restarted for this change; the OAuth server configuration is managed by the cluster's authentication operator, which reconciles the OAuth resource. Option C is not required because container images are unrelated to identity provider configuration. Option D is not required because existing secrets (such as the OIDC client secret) are created or referenced, not deleted wholesale.

Answer

Restart the kube-apiserver

Answer

Rebuild all container images

Answer

Delete all existing secrets

Question 14

Which THREE commands are used to manage service account secrets?

Accepted Answer

oc secrets link. In OpenShift, service account secrets are managed with the `oc secrets` subcommands: `oc secrets link` (B) attaches an existing secret to a service account so pods running as that SA can mount/use it, and `oc secrets add` (C) is the equivalent/alias command for adding a secret to a service account (e.g., for pulling images or mounting). `oc secrets new-dockercfg` (D) creates a new dockercfg-format secret specifically for use as a service account's image pull secret, which is a core service-account secret management operation. The other options are not valid for this purpose: `oc secret create` (A) is not a valid subcommand form (the correct verb is `oc secrets new` or `oc create secret`), and `oc secret update` (E) is not a supported command for managing service account secrets.

Answer

oc secret create

Answer

oc secret update

Question 15

A deployment named payments-api runs in namespace finance-prod and uses the default service account. Security auditors require that the containers run with a read-only root filesystem and prohibit privilege escalation. The deployment currently has no securityContext defined. Which action will enforce these requirements at the pod level?

Accepted Answer

Add securityContext.readOnlyRootFilesystem: true and securityContext.allowPrivilegeEscalation: false to each container in the pod template.. The container-level securityContext is where readOnlyRootFilesystem and allowPrivilegeEscalation are defined. The kubelet enforces these settings when starting the container, and the SCC admission controller validates that the pod's requests are permitted by the SCC bound to its service account. Setting them directly on each container ensures the desired hardening without needing to modify cluster-wide SCCs.

Answer

Create a new SecurityContextConstraints object that sets readOnlyRootFilesystem and allowPrivilegeEscalation, then bind it to the default service account.

Answer

Apply the restricted-v2 Security Context Constraint to the default service account in the finance-prod namespace.

Answer

Set the readOnlyRootFilesystem and allowPrivilegeEscalation fields in the pod's securityContext at the pod level, not per container.