EX280 Security And SCC Practice Test 4 — 15 Questions

Question 1

An administrator is managing service accounts and wants to understand how tokens work in OpenShift 4.14+. Which TWO statements are correct regarding ServiceAccount tokens in this version? (Choose TWO)

Accepted Answer

Long-lived API tokens are no longer automatically created as secrets when a new ServiceAccount is created.. Option D is correct because starting with OpenShift 4.14 (aligned with Kubernetes 1.24+ behavior), the legacy behavior of automatically generating a long-lived token Secret alongside every new ServiceAccount was removed, so no token Secret is created unless explicitly requested. Option E is correct because the modern mechanism uses the TokenRequest API to issue bound service account tokens that are audience-scoped, time-bound (expiring, typically via projected volumes), and ephemeral rather than permanent. Option A is wrong because ServiceAccounts remain a core, fully supported identity mechanism and are not deprecated in favor of OAuth user objects. Option B is wrong because tokens are delivered via projected volumes or the TokenRequest API, not stored in plaintext ConfigMaps. Option C is wrong because ServiceAccounts still authenticate to the Kubernetes API server using their bound tokens.

Answer

Service accounts are now deprecated in favor of OAuth user objects.

Answer

Tokens must be stored in plaintext ConfigMaps for pods to read them.

Answer

Service accounts can no longer authenticate against the Kubernetes API server.

Question 2

An administrator is troubleshooting an OAuth authentication failure where users receive an error indicating invalid credentials against an HTPasswd provider. Which TWO steps or checks are critical for resolving this issue? (Choose TWO)

Accepted Answer

Verify that the Secret containing the htpasswd file is located in the openshift-config namespace.. Option A is correct because in OpenShift, the OAuth provider configuration references the htpasswd Secret by name, and that Secret must reside in the openshift-config namespace for the OAuth server to read and use it; a Secret placed elsewhere will not be picked up and authentication will fail. Option D is correct because the htpasswd file must contain password hashes in a format the OAuth htpasswd identity provider supports, such as bcrypt (or the other supported crypt/SSHA variants), and an unsupported or malformed hash causes credential validation to fail even when the username is correct. Option B is not required because the OAuth server reads the referenced Secret dynamically, so restarting the kube-apiserver static pods is neither necessary nor the correct remediation. Option C is wrong because cluster-admin privileges are unrelated to credential validation and are not assigned automatically to all users. Option E is wrong because there is no such required label on the htpasswd Secret; the provider is bound to the Secret through the OAuth custom resource's htpasswd configuration, not through that label.

Answer

Restart the kube-apiserver static pods to apply the new password file.

Answer

Verify that all users have cluster-admin privileges assigned automatically.

Answer

Check that the Secret is labeled with security.openshift.io/htpasswd-provider=true.

Question 3

A cluster administrator needs to grant a Deployment in the production namespace permission to pull images from a private container registry. The image pull secret is named my-registry-secret. Which step must be performed so that pods created by this Deployment can successfully pull the image?

Accepted Answer

Patch the default ServiceAccount in the production namespace to include my-registry-secret in its imagePullSecrets array.. To allow pods created by a Deployment to pull from a private registry, the imagePullSecrets must be associated with the ServiceAccount used by the pods. By default, pods use the 'default' ServiceAccount in their namespace. Patching that ServiceAccount to include my-registry-secret in its imagePullSecrets array ensures that all pods using that ServiceAccount (including those from the Deployment) can authenticate to the registry.

Answer

Create a RoleBinding mapping the secret to the cluster-readers cluster role.

Answer

Annotate the Deployment resource with the full base64-encoded dockerconfigjson payload.

Answer

Run oc set data secrets/my-registry-secret --namespace=production.

Question 4

An administrator creates a new custom Security Context Constraint (SCC) named restrict-root. After creating the SCC resource, users complain that pods using a ServiceAccount tied to this SCC are still falling back to the restricted-v2 SCC. What is the most likely cause?

Accepted Answer

The ServiceAccount lacks the RBAC permission to use the restrict-root SCC via a ClusterRoleBinding or RoleBinding to the system:openshift:scc:restrict-root ClusterRole.. In OpenShift, an SCC is only usable by a ServiceAccount if that ServiceAccount has been granted permission to use it. This is done by binding the ServiceAccount to the ClusterRole named system:openshift:scc:<scc-name> (or the equivalent RoleBinding in the namespace). Without that RBAC binding, the SCC admission controller ignores the custom SCC and the pod falls back to the default SCC assigned to the ServiceAccount (restricted-v2 in OCP 4.x).

Answer

The SCC object is missing the metadata.labels.openshift.io/scc label set to restrict-root.

Answer

Custom SCCs are disabled by default in OpenShift Container Platform 4.14 and require an operator configuration change.

Answer

The Pod Security Standards admission plugin is blocking custom SCC creation at the namespace level.

Question 5

A developer deploys an application using a Route that terminates TLS using the Edge termination strategy. The developer wants to ensure that all insecure HTTP traffic to the route is automatically redirected to HTTPS. Where must this setting be configured?

Accepted Answer

In the Route resource spec.tls.insecureEdgeTerminationPolicy field set to Redirect.. For an edge-terminated Route, the redirect of insecure HTTP to HTTPS is controlled by spec.tls.insecureEdgeTerminationPolicy set to Redirect. The router (HAProxy) reads this field and issues a 301/302 redirect for any plain HTTP request hitting the route. This is the supported, declarative way to enforce HTTPS on a Route.

Answer

By modifying the haproxy.config global template ConfigMap in the openshift-ingress namespace.

Answer

In the IngressController custom resource under spec.routeAdmission.wildcardPolicy.

Answer

In the Service resource annotations using route.openshift.io/termination: redirect.

Question 6

A cluster administrator wishes to enforce the restricted Pod Security Standard across an entire namespace named auditing-ns. Which label should the administrator apply to the namespace to enforce this policy while generating audit warnings for non-compliant pods?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted and pod-security.kubernetes.io/audit: restricted. To enforce the restricted Pod Security Standard across a namespace and generate audit warnings, the administrator must apply the 'pod-security.kubernetes.io/enforce: restricted' label to enforce the policy and 'pod-security.kubernetes.io/audit: restricted' to log audit events for non-compliant pods. These labels are part of the Kubernetes Pod Security Admission (PSA) feature, which OpenShift 4.x uses.

Answer

security.openshift.io/scc.enforce: restricted-v2

Answer

security.openshift.io/pod-security-standard: enforce-restricted

Answer

admission.cluster.openshift.io/validate-psa: true

Question 7

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 8

Which TWO actions are required when configuring an external OpenID Connect (OIDC) identity provider in OpenShift Container Platform?

Accepted Answer

Reference a Secret containing the clientSecret used to authenticate against the OIDC provider.. When configuring an external OIDC identity provider in OpenShift Container Platform, the OAuth configuration (a custom resource of kind OAuth) requires an identityProvider entry of type OpenIDConnect that references a Secret holding the clientSecret used to authenticate the cluster's OAuth server against the OIDC provider, so option A is correct. The same identityProvider stanza must also specify the issuer URL, which points to the OIDC provider's discovery endpoint (/.well-known/openid-configuration) so OpenShift can retrieve the provider's metadata such as authorization and token endpoints, making option D correct. Option B is wrong because OAuthClient resources represent OAuth clients that consume the cluster's OAuth server (for example, service accounts or external applications), not individual cluster users, and they are not created per user for an external IdP. Option C is wrong because LDAP synchronization is only relevant to the LDAP identity provider and is not part of OIDC configuration. Option E is wrong because openshift-install is used for cluster installation and does not generate a self-signed CA for the API server as part of configuring an external OIDC identity provider.

Answer

Create a dedicated OAuthClient resource for every single cluster user.

Answer

Deploy an internal LDAP directory synchronization cronjob inside the openshift-authentication namespace.

Answer

Generate a self-signed CA certificate for the API server using openshift-install.

Question 9

You are integrating an external LDAP identity provider. Which secret must be created to store the bind password for the LDAP server?

Accepted Answer

A generic secret in the 'openshift-config' namespace. When configuring an LDAP identity provider in OpenShift, the bind password must be stored in a generic Secret created in the 'openshift-config' namespace. The OAuth custom resource (cluster-scoped) references this secret via the ldap.bindPassword.name field, and the openshift-config namespace is the designated location for cluster-wide identity provider configuration.

Answer

A secret in the 'openshift-authentication' namespace

Answer

A project-level secret in the target application namespace

Answer

A secret in the 'kube-system' namespace

Question 10

You need to allow a specific service account to run pods as root. Which command should you use to associate the 'privileged' SCC with the 'default' service account in the 'web-apps' namespace?

Accepted Answer

oc adm policy add-scc-to-user privileged -z default -n web-apps. The correct command to associate a Security Context Constraint (SCC) with a service account in OpenShift is 'oc adm policy add-scc-to-user'. The '-z' flag specifies the service account name, and '-n' specifies the namespace. This command adds the 'privileged' SCC to the 'default' service account in the 'web-apps' namespace, allowing pods running under that service account to request privileged access and run as root. This is the standard administrative operation for granting SCC permissions.

Answer

oc add scc privileged default -n web-apps

Answer

oc apply scc privileged --user=default -n web-apps

Answer

oc patch scc privileged -p '{"users": ["default"]}'

Question 11

How do you view the currently active OAuth identity providers in an OpenShift cluster?

Accepted Answer

oc get oauth cluster -o yaml. The OAuth server configuration in OpenShift is stored in a cluster-scoped custom resource named 'cluster' of type 'oauth.config.openshift.io'. Running `oc get oauth cluster -o yaml` retrieves this resource and displays the full configuration, including the `spec.identityProviders` list that defines the currently active identity providers. This is the canonical way to inspect which identity providers are configured and their order of precedence.

Answer

oc get identityproviders

Answer

oc describe auth

Answer

oc get configmap oauth -n openshift-config

Question 12

Which tool should be used to troubleshoot why an SCC is being rejected for a pod?

Accepted Answer

oc adm policy scc-review. 'oc adm policy scc-review' is the dedicated diagnostic command that evaluates whether a given pod (or a ServiceAccount with a given set of security context settings) would be admitted by any SCC. It reports which SCCs the subject can use and why a pod may be rejected, making it the correct tool for troubleshooting SCC rejection.

Answer

oc adm top scc

Answer

oc get scc --debug

Answer

oc explain scc

Question 13

You need to terminate TLS for a route using a custom certificate. Which object must contain the TLS key and certificate?

Accepted Answer

A Secret in the same namespace as the route. In OpenShift, TLS termination for a Route is configured by referencing a TLS certificate and key stored in a Kubernetes Secret. The Secret must reside in the same namespace as the Route because Routes are namespace-scoped resources and can only reference Secrets within their own namespace. The Secret must be of type kubernetes.io/tls and contain tls.crt and tls.key. This design ensures isolation and proper RBAC control.

Answer

A ConfigMap in the 'openshift-config' namespace

Answer

A custom resource definition of type TLS

Answer

The ingress controller configuration

Question 14

Which SCC is assigned by default to authenticated users who are not service accounts?

Accepted Answer

restricted. In OpenShift, authenticated users who are not service accounts are automatically granted the 'restricted' SCC (and in newer versions restricted-v2) via the system:authenticated group binding. This is the default least-privilege SCC that allows pods to run without root, with dropped capabilities. It is assigned by the cluster's default SCC admission configuration, not by any user action.

Answer

anyuid

Answer

nonroot

Answer

privileged

Question 15

A developer needs to expose a service via a route with re-encryption. What is required in the Route configuration?

Accepted Answer

Set 'termination: reencrypt' in the spec.tls section. A re-encrypt route terminates TLS at the router and then re-encrypts traffic to the backend pod using a separate certificate. This is configured by setting termination: reencrypt in the route's spec.tls section, along with a destination CA certificate so the router can validate the backend's certificate. The reencrypt termination type is the defining configuration element.

Answer

Enable 'insecureEdgeTerminationPolicy: Allow'

Answer

Configure a ServiceMesh resource

Answer

Set 'termination: edge' and add a proxy