EX280 Security And SCC Practice Test 5 — 15 Questions

Question 1

When using OIDC for authentication, what does the 'issuer' field in the configuration represent?

Accepted Answer

The URL of the OIDC provider. In OpenShift's OIDC identity provider configuration, the 'issuer' field is the URL of the OIDC identity provider (IdP) that OpenShift will trust for authentication. OpenShift uses this URL to discover the provider's OIDC metadata via the /.well-known/openid-configuration endpoint, which supplies the authorization, token, and JWKS endpoints. The issuer value must exactly match the 'iss' claim in the tokens the IdP issues, otherwise token validation fails.

Answer

The secret key for the OIDC provider

Answer

The client ID of the OpenShift cluster

Answer

The hostname of the OpenShift API

Question 2

Where do you define the default image pull secrets for all service accounts in a namespace?

Accepted Answer

By linking the secret to the 'default' service account. Default image pull secrets for all service accounts in a namespace are defined by linking the secret to the 'default' service account. When a pod is created without specifying a service account, it uses the 'default' service account, and any image pull secrets attached to that service account are automatically used.

Answer

In the ClusterOperator configuration

Answer

In the Namespace metadata

Answer

In the project configuration object

Question 3

Which service account is used by default for pods that do not specify a service account in their manifest?

Accepted Answer

default. Every namespace in Kubernetes/OpenShift is automatically provisioned with a ServiceAccount named 'default'. When a pod manifest omits the spec.serviceAccountName (or spec.serviceAccount) field, the admission controller assigns this 'default' ServiceAccount to the pod. OpenShift additionally creates 'builder' and 'deployer' ServiceAccounts per namespace for build and deployment controllers, but these are never auto-assigned to arbitrary pods.

Answer

builder

Answer

system

Answer

deployer

Question 4

When creating a custom SCC, what is the best practice for assigning it to users?

Accepted Answer

Bind the SCC to a specific service account in a specific namespace. Binding a custom SCC to a specific service account in a specific namespace follows the principle of least privilege and is the OpenShift best practice. SCCs are applied to service accounts (or users/groups) via RBAC role bindings, and scoping to a specific service account in a specific namespace ensures the elevated permissions are granted only where needed, minimizing the blast radius of a compromised pod.

Answer

Bind the SCC to the 'cluster-admin' user

Answer

Bind the SCC to the 'system:authenticated' group

Answer

Assign the SCC to the namespace object directly

Question 5

What happens if a pod does not match any SCC?

Accepted Answer

The pod is rejected. If a pod does not match any SCC, the SCC admission controller rejects the pod outright — the API server returns a 'forbidden' error and the pod is never scheduled. There is no fallback to a default SCC; the pod's securityContext and volume definitions must satisfy at least one SCC bound to the pod's service account (or the creating user).

Answer

The pod runs with no constraints

Answer

The pod is assigned the 'restricted' SCC by default

Answer

The pod is assigned the 'privileged' SCC

Question 6

You are configuring an OAuth identity provider using 'htpasswd'. Which secret must contain the file?

Accepted Answer

A secret in 'openshift-config'. When configuring an OAuth identity provider using htpasswd in OpenShift, the htpasswd file must be stored in a Secret in the 'openshift-config' namespace. The OAuth configuration references this secret by name, and the OpenShift authentication operator mounts it into the OAuth pods. This is the documented and required location for identity provider secrets.

Answer

A ConfigMap in 'openshift-config'

Answer

A local file on the master node

Answer

A secret in 'openshift-authentication'

Question 7

Which TWO of the following are valid ways to secure a route?

Accepted Answer

Using 'edge' termination with a custom certificate. Option C is correct because configuring a route with 'edge' termination means TLS is terminated at the router (the ingress point), and supplying a custom certificate lets the router present a trusted certificate to external clients, which is a valid and common way to secure a route. Option E is correct because 'reencrypt' termination terminates TLS at the router and then re-encrypts the connection to the backend pod using a (possibly different) certificate, providing end-to-end encryption across the whole path, which is a valid secure route configuration. Option A is wrong because allowing all traffic on port 80 exposes plain HTTP with no encryption, so it does not secure the route. Option B is wrong because 'insecure edge termination' leaves the external connection unencrypted (or without proper certificate validation), defeating the purpose of securing the route. Option D is wrong because disabling TLS removes encryption entirely, which is the opposite of securing a route.

Answer

Allowing all traffic on port 80

Answer

Using insecure edge termination

Answer

Disabling TLS completely

Question 8

How can you view the list of all SCCs available in the cluster?

Accepted Answer

oc get scc. The correct command to view the list of all Security Context Constraints (SCCs) in an OpenShift cluster is oc get scc. This command retrieves and displays the SCC resources, which define the security contexts under which pods can run.

Answer

oc show scc

Answer

oc describe scc

Answer

oc list scc

Question 9

Which THREE of the following are required when configuring an OIDC identity provider?

Accepted Answer

Client Secret reference. When configuring an OIDC identity provider, the Client ID (C) is required because it uniquely identifies the relying party/application to the OpenID Provider during the authorization code flow. The Client Secret reference (A) is also required so the application can authenticate itself to the token endpoint and securely exchange the authorization code for tokens. The Issuer URL (E) is required because it identifies the OpenID Provider's metadata document (typically at /.well-known/openid-configuration), enabling discovery of endpoints such as authorization_endpoint, token_endpoint, and jwks_uri. The Htpasswd file path (B) is not part of OIDC; it belongs to HTTP Basic authentication using a local password file. The LDAP bind password (D) is also unrelated to OIDC, as it is used for LDAP directory authentication, not for OpenID Connect token exchange.

Answer

Htpasswd file path

Answer

LDAP bind password

Question 10

Which THREE parameters are commonly found in the SCC 'spec' section?

Accepted Answer

seLinuxContext. The SCC (SecurityContextConstraints) 'spec' section defines the security settings that pods may use, and seLinuxContext (A) is a valid spec field that specifies the SELinux context strategy (MustRunAs, RunAsAny) and required level/role/type/user for containers. runAsUser (C) is also a valid spec field that controls the UID strategy (MustRunAsRange, MustRunAsNonRoot, RunAsAny) and the allowed UID range for containers. allowedCapabilities (E) is likewise a valid spec field listing the Linux capabilities containers are permitted to add beyond the default set. namespaceSelector (B) is not an SCC spec parameter—it belongs to NetworkPolicy, PodAffinity, or admission webhook configurations—and imagePullPolicy (D) is a container image field in a Pod spec, not part of SecurityContextConstraints.

Answer

namespaceSelector

Answer

imagePullPolicy

Question 11

Which TWO authentication methods are supported by the OpenShift OAuth server?

Accepted Answer

Htpasswd. The OpenShift OAuth server supports the Htpasswd identity provider (option A), which validates credentials against a flat file of bcrypt-hashed username/password entries, and the LDAP identity provider (option C), which binds to an external LDAP directory (e.g., Active Directory or OpenLDAP) to authenticate users. These are two of the built-in identity provider types configured via the OAuth custom resource, alongside others like BasicAuth, RequestHeader, GitHub, GitLab, Google, Keystone, and OpenID Connect. Option B is incorrect because OpenShift does not offer a generic 'local file system user list' provider — local users are managed through Htpasswd files or the OAuth access tokens, not by enumerating OS users. Option D is incorrect because SSH keys are used for node/SSH access, not for OAuth authentication to the API. Option E is incorrect because the OAuth server does not connect directly to a database for user authentication; directory-based auth is done via LDAP or similar providers.

Answer

Local file system user list

Answer

Custom SSH keys

Answer

Direct database connection

Question 12

Which THREE components are involved in TLS termination for routes?

Accepted Answer

Secret. In OpenShift, TLS termination for routes requires a Secret (option A) that holds the TLS certificate and private key, which the router uses to serve HTTPS. The Route (option B) is the object where you configure TLS termination (e.g., spec.tls.termination: edge, passthrough, or reencrypt) and reference the certificate. The IngressController (option C) is the router component that actually performs TLS termination and enforces the route's TLS settings. A Service (option D) only provides internal load balancing to pods and does not handle TLS certificates or termination. A ConfigMap (option E) stores non-sensitive configuration data and is not used to hold TLS certificates or keys for route termination.

Answer

Service

Answer

ConfigMap

Question 13

Which TWO security standards are natively tracked in OpenShift?

Accepted Answer

restricted. In OpenShift, Security Context Constraints (SCCs) are the native mechanism for controlling pod permissions, and the platform ships with several predefined SCCs, including restricted and privileged. The restricted SCC is correct because it is the default, most locked-down policy that enforces running as a non-root user, drops capabilities, and uses a restricted SELinux context. The privileged SCC is correct because it is a built-in policy that grants broad access, allowing privileged containers, host networking, host PID/IPC, and all capabilities for cluster-admin workloads. The options isolated, custom, and secure are not native OpenShift SCC names, so they are not tracked as built-in security standards.

Answer

isolated

Answer

custom

Answer

secure

Question 14

Which TWO things must be configured to use a Private Image Registry?

Accepted Answer

A docker-registry type secret. To pull images from a private image registry, Kubernetes needs credentials, which are supplied via a docker-registry type secret (option B) containing the registry URL, username, and password/token in .dockerconfigjson format. That secret must then be linked to the service account (option C) used by the pod (e.g., via the imagePullSecrets field or the service account's imagePullSecrets), so the kubelet can authenticate when pulling the image. A route to the registry (A) is only needed for external network access and is not a required configuration element for using a private registry. Creating a new ClusterRole (D) is unnecessary because image pulling is governed by node credentials and imagePullSecrets, not RBAC ClusterRoles. Updating the node configuration (E) is not required since authentication is handled through the secret and service account rather than by reconfiguring nodes.

Answer

A route to the registry

Answer

Creating a new ClusterRole

Answer

Updating the node configuration

Question 15

An administrator is preparing a custom Security Context Constraint (SCC) that will be granted to a specific ServiceAccount used by a log-forwarding DaemonSet. The DaemonSet pods must be able to mount a hostPath volume at /var/log but must not run as UID 0 and must not use the host network. Which SCC field combination must the administrator set to allow only the hostPath mount while still blocking privileged escalation and host networking?

Accepted Answer

Set allowHostDirVolumePlugin: true, allowPrivilegedContainer: false, and allowHostNetwork: false in the custom SCC.. A custom SCC must explicitly enable the host directory volume plugin so the DaemonSet can mount /var/log, while privileged containers and host networking remain disabled to preserve isolation. The other combinations either grant excessive privileges that the scenario forbids or disable the hostPath plugin and break the workload's core function.

Answer

Set allowHostDirVolumePlugin: true, allowPrivilegedContainer: true, and allowHostNetwork: false in the custom SCC.

Answer

Set allowHostDirVolumePlugin: false, allowPrivilegedContainer: false, and allowHostNetwork: false in the custom SCC.

Answer

Set allowHostDirVolumePlugin: false, allowPrivilegedContainer: false, and allowHostNetwork: true in the custom SCC.