Knowledge + Practice

CCNA Security And Scc Questions

48 questions · Security And Scc topic · All types, answers revealed

Practice these questions Exam hub All questions

1

Multi-Selecthard

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)

Select 2 answers

A.Verify that the Secret containing the htpasswd file is located in the openshift-config namespace.

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

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

D.Ensure the password hashes in the htpasswd file use a supported hashing algorithm such as bcrypt.

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

AnswersA, D

The HTPasswd identity provider requires its Secret to reside in the openshift-config namespace; the OAuth server only reads credentials from there. A Secret placed elsewhere leaves the provider unable to validate passwords, producing the invalid credentials error. Confirming this namespace satisfies the stem's configuration constraint.

Why this answer

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.

Exam trap

EX280 often tests the namespace requirement for identity provider Secrets (openshift-config) and the supported hash algorithm (bcrypt) — candidates incorrectly assume any namespace works or that MD5/crypt hashes are fine.

Practice this question →

2

MCQmedium

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?

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

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

C.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.

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

AnswerC

The SCC's admission check requires the pod's ServiceAccount to hold `use` permission on that specific SCC, granted through the `system:openshift:scc:restrict-root` ClusterRole. Without a RoleBinding or ClusterRoleBinding conferring it, authorisation fails and the pod silently falls back to `restricted-v2`, satisfying the stem's fallback symptom.

Why this answer

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).

Exam trap

EX280 often tests the misconception that creating an SCC resource is sufficient to make it apply — candidates forget that SCCs must be explicitly granted to a ServiceAccount via RBAC (system:openshift:scc:<name>), and that the admission controller otherwise falls back to default SCCs like restricted-v2.

How to eliminate wrong answers

Option A is wrong because the openshift.io/scc label is set automatically by the SCC admission controller on the pod, not on the SCC object itself — SCCs are matched by name, not by that label. Option B is wrong because custom SCCs are fully supported in OCP 4.14; no operator configuration change is required to enable them. Option D is wrong because Pod Security Standards admission operates at the namespace level and does not block creation of SCC resources — SCCs and PSA coexist, and SCC creation is not gated by PSA.

Practice this question →

3

Multi-Selectmedium

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

Select 2 answers

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

B.Use oc auth can-i create pods --as=system:serviceaccount:<namespace>:<serviceaccount-name> to test permissions.

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

D.Run oc adm policy who-can use scc restricted-v2 to see which users and service accounts have access to the SCC.

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

AnswersB, D

The can-i command with impersonation tests whether a specific ServiceAccount can create pods, revealing effective permissions granted through its SCC and role bindings. This satisfies the requirement to troubleshoot a named ServiceAccount's actual authorisation in its namespace.

Why this answer

Option B is correct because `oc auth can-i` with the `--as=system:serviceaccount:<namespace>:<serviceaccount-name>` 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.

Exam trap

EX280 often tests whether candidates rely on OpenShift 3 artifacts (scc.yaml files) or invented annotations instead of the supported oc auth can-i and oc adm policy who-can commands for SCC inspection.

Practice this question →

4

MCQeasy

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

A.oc get securityconstraints

B.oc get scc

C.oc adm policy list-constraints

D.oc describe clustersecurity

AnswerB

`oc get scc` queries the cluster's SecurityContextConstraints resource type directly, returning every SCC currently defined. This satisfies the stem's requirement to list active SCCs, since `oc get` retrieves resources of the named type from the API server without modifying them.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know the registered short name for OpenShift API resources — 'scc' for securitycontextconstraints — versus inventing plausible-sounding resource names like 'securityconstraints' or fake subcommands like 'list-constraints'.

How to eliminate wrong answers

Option A is wrong because 'securityconstraints' is not a valid resource name — the actual API resource is 'securitycontextconstraints' (short name 'scc'), so this command returns a 'resource not found' error. Option C is wrong because 'oc adm policy list-constraints' is not a real subcommand; oc adm policy supports add-scc-to-user, add-scc-to-group, remove-scc-from-user, and similar verbs, but not list-constraints. Option D is wrong because 'clustersecurity' is not an OpenShift resource type at all — there is no such API object to describe.

Practice this question →

5

Multi-Selectmedium

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)

Select 2 answers

A.HTPasswd

B.LDAP

C.CustomDatabaseProvider

D.LocalFileAuthService

E.ActiveDirectoryNativeProtocol

AnswersA, B

HTPasswd is a natively supported OpenShift identity provider that validates credentials against a locally generated htpasswd file. It satisfies the stem's native-support constraint, making it suitable for small or test clusters without external directory dependencies.

Why this answer

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.

Exam trap

EX280 often tests the list of supported identity providers, and candidates may mistakenly think that any database or file-based auth is natively supported, or confuse Active Directory with a separate provider when it's actually accessed via LDAP.

Practice this question →

6

MCQhard

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

A.A secret in the 'openshift-authentication' namespace

B.A project-level secret in the target application namespace

C.A secret in the 'kube-system' namespace

D.A generic secret in the 'openshift-config' namespace

AnswerD

A generic secret in the 'openshift-config' namespace satisfies the requirement to store the LDAP bind password for an external identity provider. OpenShift's OAuth configuration references this secret by name, so the bind password must reside there for the identity provider to authenticate against the LDAP server during bind operations.

Why this answer

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.

Exam trap

EX280 often tests the namespace boundary for cluster-wide configuration — candidates assume the secret goes in 'openshift-authentication' (where the OAuth server runs) rather than 'openshift-config' (where the OAuth CR and its referenced secrets live).

How to eliminate wrong answers

Option A is wrong because 'openshift-authentication' hosts the OAuth server pods and its own runtime secrets, not the user-supplied LDAP bind password — placing it there means the OAuth CR cannot reference it. Option B is wrong because identity providers are cluster-scoped, not project-scoped; a secret in an application namespace is invisible to the cluster OAuth configuration. Option C is wrong because 'kube-system' is a Kubernetes system namespace for control-plane components and is not where OpenShift expects identity provider secrets.

Practice this question →

7

Multi-Selectmedium

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)

Select 2 answers

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

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

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

D.Long-lived API tokens are no longer automatically created as secrets when a new ServiceAccount is created.

E.Bound service account tokens are ephemeral and time-bound by default using TokenRequest API.

AnswersD, E

OpenShift 4.14 stopped auto-generating long-lived token secrets for new ServiceAccounts, so no legacy secret-backed token appears. This satisfies the stem's version-specific constraint: administrators must now create tokens explicitly via TokenRequest rather than relying on automatic secret creation.

Why this answer

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.

Exam trap

EX280 often tests the misconception that service accounts are deprecated or that tokens are still automatically created as Secrets; candidates must remember that bound tokens are now ephemeral and generated on-demand.

Practice this question →

8

Multi-Selecthard

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)

Select 3 answers

A.routeAdmissionLimit

B.networkPolicyMode

C.requiredDropCapabilities

D.allowPrivilegedContainer

E.volumes

AnswersC, D, E

requiredDropCapabilities is a valid SCC field specifying Linux capabilities forcibly removed from containers, such as NET_RAW. It is a genuine configuration option, satisfying the stem's requirement to identify fields controllable within a custom SCC definition.

Why this answer

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.

Exam trap

EX280 often tests the misconception that SCCs include networking or routing fields, when they are strictly about pod security contexts.

Practice this question →

9

Multi-Selectmedium

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

Select 2 answers

A.Htpasswd

B.Local file system user list

C.LDAP

D.Custom SSH keys

E.Direct database connection

AnswersA, C

OpenShift's OAuth server ships an identity provider that authenticates users against an htpasswd file of bcrypt-hashed credentials. It is a supported method for validating usernames and passwords, satisfying the question's requirement for a native OpenShift authentication mechanism.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know the supported OAuth identity providers, so the trap is selecting plausible-sounding but unsupported methods like 'local file system user list' or 'direct database connection' instead of the actual providers HTPasswd and LDAP.

Practice this question →

10

MCQhard

A security team requires that a specific ServiceAccount `app-sa` in project `prod` be allowed to run pods that use the `hostNetwork` namespace, while all other ServiceAccounts in `prod` must remain restricted. The administrator creates a new SCC `hostnet-scc` with `allowHostNetwork: true` and binds it only to `app-sa`. A developer then creates a pod using the `default` ServiceAccount with `hostNetwork: true` in its manifest. What is the result?

A.The pod is rejected because the `default` ServiceAccount is not bound to an SCC that allows `hostNetwork`.

B.The pod is rejected because `hostNetwork` requires the `privileged` SCC, which is not bound to any ServiceAccount.

C.The pod is admitted but runs without host networking, because the SCC silently strips the `hostNetwork` field.

D.The pod is admitted because SCCs are evaluated cluster-wide and any SCC allowing `hostNetwork` permits the pod.

AnswerA

SCC admission evaluates the pod against the SCCs bound to its ServiceAccount. The `default` ServiceAccount in `prod` is bound only to the restricted SCCs, which set `allowHostNetwork: false`. Since the pod requests `hostNetwork`, no bound SCC accepts it, and admission rejects the pod. Only pods using `app-sa` can leverage `hostnet-scc`.

Why this answer

SCC admission is scoped to the ServiceAccount used by the pod. Because the developer used the `default` ServiceAccount, which is bound only to restricted SCCs, the request for `hostNetwork` is rejected even though `hostnet-scc` exists. Only pods running under `app-sa` can use the custom SCC.

SCCs are not evaluated cluster-wide, and disallowed fields cause rejection rather than silent removal.

Exam trap

The trap here is believing that creating an SCC that allows a setting makes that setting available cluster-wide, when SCC access is granted per ServiceAccount through bindings.

Practice this question →

11

MCQmedium

What happens if a pod does not match any SCC?

A.The pod runs with no constraints

B.The pod is rejected

C.The pod is assigned the 'restricted' SCC by default

D.The pod is assigned the 'privileged' SCC

AnswerB

OpenShift's Security Context Constraints admission controller evaluates every pod against defined constraints; if no SCC matches the pod's requested security context, admission is denied. The pod is therefore rejected rather than defaulted or run with elevated privileges, enforcing cluster security policy.

Why this answer

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).

Exam trap

EX280 often tests the assumption that OpenShift falls back to a default SCC like 'restricted' — in reality, no match means hard rejection, and candidates who assume a fallback pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because OpenShift never runs pods without SCC evaluation — SCC admission is mandatory, not optional, so 'no constraints' is not a possible state. Option C is wrong because 'restricted' is not an automatic fallback; it is only applied if the pod's securityContext actually satisfies the restricted SCC's requirements (e.g., no privileged, no hostPath, runAsNonRoot). Option D is wrong because 'privileged' is never assigned by default — it must be explicitly bound to a service account, and assigning it automatically would defeat the purpose of SCCs.

Practice this question →

12

Multi-Selecthard

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)

Select 2 answers

A.Defining the secret inside the cluster Ingress controller custom resource spec

B.Placing the pull secret in the global openshift-config ConfigMap

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

D.Linking the image pull secret to the ServiceAccount referenced by the deployment's pod spec via oc secrets link

E.Adding the secret to the imagePullSecrets array within the pod template specification of a Deployment

AnswersD, E

Linking via `oc secrets link` attaches the pull secret to the ServiceAccount, so every pod using that account inherits the credentials automatically. This satisfies the scenario's requirement to associate a secret with a workload without editing each pod spec, and remains the standard cluster-wide approach for authenticating to private registries.

Why this answer

Option D is correct because `oc secrets link <serviceaccount> <secret> --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.

Exam trap

EX280 often tests the distinction between cluster-wide pull secrets (openshift-config) and per-workload/ServiceAccount pull secrets — candidates may incorrectly choose a global ConfigMap or namespace annotation.

Practice this question →

13

Multi-Selectmedium

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

Select 2 answers

A.Allowing all traffic on port 80

B.Using insecure edge termination

C.Using 'edge' termination with a custom certificate

D.Disabling TLS completely

E.Using 'reencrypt' termination to ensure end-to-end encryption

AnswersC, E

Edge termination stops TLS at the router using a certificate you supply, rather than the router's default. Supplying a custom certificate satisfies the stem's requirement for a valid way to secure a route, with traffic to the pod left unencrypted.

Why this answer

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.

Exam trap

EX280 often tests route termination types — candidates confuse 'edge' with 'passthrough' or assume any mention of TLS is automatically secure, missing that 'insecure edge' and 'disable TLS' are explicitly non-secure.

Practice this question →

14

MCQeasy

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?

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

B.In the Route resource spec.tls.insecureEdgeTerminationPolicy field set to Redirect.

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

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

AnswerB

With edge termination, the router handles TLS, so redirection of plain HTTP must be declared on the Route itself. Setting spec.tls.insecureEdgeTerminationPolicy to Redirect makes the router issue an HTTP 301 to HTTPS for insecure requests.

Why this answer

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.

Exam trap

EX280 often tests whether candidates reach for global router ConfigMap edits or Service annotations instead of the Route's own spec.tls.insecureEdgeTerminationPolicy field, which is the only supported per-route redirect control.

How to eliminate wrong answers

Option A is wrong because editing the haproxy.config template ConfigMap in openshift-ingress is a global, unsupported hack that affects all routes and is overwritten by the ingress operator. Option C is wrong because spec.routeAdmission.wildcardPolicy on the IngressController governs subdomain/wildcard admission, not HTTP-to-HTTPS redirection. Option D is wrong because route.openshift.io/termination is a Service annotation used for certain load-balancer integrations, not the mechanism that sets redirect behaviour on a Route's TLS spec.

Practice this question →

15

Multi-Selectmedium

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

Select 3 answers

A.seLinuxContext

B.namespaceSelector

C.runAsUser

D.imagePullPolicy

E.allowedCapabilities

AnswersA, C, E

`seLinuxContext` sits in the SCC `spec` section, defining the SELinux context (user, role, type, level) that OpenShift applies to containers in matching pods. It satisfies the stem's requirement for a commonly found `spec` parameter, alongside `seccompProfiles` and `allowedCapabilities`, which govern mandatory access controls.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can distinguish SCC spec fields (seLinuxContext, runAsUser, allowedCapabilities) from unrelated Kubernetes fields like namespaceSelector and imagePullPolicy — the trap is picking fields that sound security-related but belong to other objects.

Practice this question →

16

MCQeasy

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

A.A ServiceAccount with special token annotations

B.A Secret containing the htpasswd flat-file data

C.A ConfigMap containing plain-text user credentials

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

AnswerB

HTPasswd identity providers read username and bcrypt-hashed password pairs from a flat file, so OpenShift stores that file's contents in a Secret and mounts it into the OAuth pods. A ConfigMap would expose the credentials in plain text, violating the requirement to hold hashed password data securely.

Why this answer

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.

Exam trap

EX280 often tests the misconception that ConfigMaps are used for authentication data or that a dedicated custom resource exists for HTPasswd, when in fact a Secret in the openshift-config namespace is required.

How to eliminate wrong answers

Option A is wrong because ServiceAccounts are used for pod identity and API access, not for storing user credential files; they do not hold htpasswd data. Option C is wrong because ConfigMaps store non-sensitive configuration data in plain text and are not used for authentication secrets; storing hashed passwords in a ConfigMap would be insecure and is not how the HTPasswd provider works. Option D is wrong because there is no custom resource kind called HTPasswdProvider; the HTPasswd provider is configured via the OAuth custom resource (kind: OAuth) that references a Secret, not a separate CRD.

Practice this question →

17

MCQmedium

An administrator is reviewing why a pod in the `legacy` namespace runs as UID 1000070000 even though the pod manifest does not specify a `runAsUser`. The namespace annotation `openshift.io/sa.scc.uid-range` is `1000070000/10000`. Which SCC behavior explains the observed UID?

A.The SCC's `runAsUser` strategy `MustRunAsRange` mutates the pod to use the first UID in the namespace's allocated range.

B.The SCC's `runAsUser` strategy `RunAsAny` allows the container runtime to pick a random UID from the host's user namespace.

C.The SCC's `fsGroup` strategy `MustRunAs` sets the pod's `runAsUser` to the namespace's supplemental group ID.

D.The SCC's `supplementalGroups` strategy `RunAsAny` causes the kubelet to assign the first UID in the namespace range.

AnswerA

When a pod omits `runAsUser`, an SCC using `MustRunAsRange` assigns a UID from the namespace's allocated range. The range is defined by the `openshift.io/sa.scc.uid-range` annotation, and the first UID in that range is used by default. This explains why the pod runs as 1000070000 without an explicit manifest value.

Why this answer

The `MustRunAsRange` user strategy mutates pods that omit `runAsUser`, assigning the first UID from the namespace's allocated range recorded in the `openshift.io/sa.scc.uid-range` annotation. That is why the pod runs as 1000070000 despite having no explicit user in its manifest. The other strategies either permit any UID, control groups rather than users, or do not assign UIDs at all.

Exam trap

The trap here is assuming the container runtime or kubelet chose the UID, when in fact the SCC admission plugin mutated the pod to the first UID in the namespace range.

Practice this question →

18

MCQmedium

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

A.oc adm top scc

B.oc adm policy scc-review

C.oc get scc --debug

D.oc explain scc

AnswerB

The scc-review subcommand evaluates a pod specification against Security Context Constraints and reports exactly which fields cause rejection, directly satisfying the need to diagnose why an SCC is refused rather than merely listing or binding policies.

Why this answer

'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.

Exam trap

The trap is assuming that 'oc explain scc' or 'oc get scc' will diagnose admission failures — those only show schema or list SCCs. The exam expects you to know that 'oc adm policy scc-review' (and its sibling 'scc-subject-review') is the actual diagnostic command for SCC rejection.

How to eliminate wrong answers

Option A is wrong because 'oc adm top scc' is not a valid command — 'oc adm top' works for nodes and pods (metrics), not SCCs. Option B is correct. Option C is wrong because 'oc get scc --debug' is not a real flag combination for diagnosing admission; --debug is not a supported flag on 'oc get scc' for this purpose.

Option D is wrong because 'oc explain scc' only prints the API field documentation for the SecurityContextConstraints kind — it does not evaluate or diagnose a specific pod's SCC admission.

Practice this question →

19

MCQmedium

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?

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

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

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

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

AnswerA

This combination directly enables the hostPath volume plugin through allowHostDirVolumePlugin while leaving privileged containers and host networking disallowed. It satisfies the requirement to mount /var/log without granting broader host access, and it keeps the SCC aligned with the principle of least privilege for the log-forwarding workload.

Why this answer

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.

Exam trap

The trap here is assuming that allowing a hostPath volume automatically requires allowPrivilegedContainer to be true, when the two controls are independent and the host directory plugin alone is sufficient.

Practice this question →

20

MCQeasy

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?

A.oc add scc privileged default -n web-apps

B.oc adm policy add-scc-to-user privileged -z default -n web-apps

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

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

AnswerB

The add-scc-to-user subcommand binds an SCC to a service account, and the -z flag targets the 'default' service account while -n scopes it to the web-apps namespace. This grants the account permission to run pods requesting privileged access.

Why this answer

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.

Exam trap

EX280 often tests the confusion between creating/modifying an SCC object and binding an SCC to a user or service account, leading candidates to choose 'oc apply' or 'oc patch' instead of the correct 'oc adm policy add-scc-to-user' command.

How to eliminate wrong answers

Option A is wrong because 'oc add scc' is not a valid OpenShift command; SCC management is done through 'oc adm policy' subcommands. Option C is wrong because 'oc apply scc' is used to create or update an SCC object from a file, not to associate an SCC with a service account, and the '--user' flag is not valid for this purpose. Option D is wrong because patching the SCC directly modifies the SCC's user list globally, which is not namespace-scoped and is not the recommended way to grant SCC access to a service account; it also bypasses the proper RBAC binding mechanism.

Practice this question →

21

MCQeasy

A cluster administrator wants to prevent any pod in the `finance` namespace from requesting the `NET_RAW` capability, which is not needed by the applications there. The administrator plans to modify the SCC bound to the namespace's default ServiceAccount. Which SCC field should be used to explicitly drop `NET_RAW`?

A.`defaultAddCapabilities: ["NET_RAW"]`

B.`seLinuxContext: MustRunAs` with a custom `seLinuxOptions` type of `net_raw`

C.`requiredDropCapabilities: ["NET_RAW"]`

D.`allowedCapabilities: ["NET_RAW"]`

AnswerC

`requiredDropCapabilities` forces the listed capabilities to be removed from every container admitted under the SCC. Putting `NET_RAW` there guarantees no pod using that SCC can retain it, even if the pod manifest requests it. This is the correct field for enforcing a capability restriction across a namespace.

Why this answer

Capability restrictions in an SCC are enforced through `requiredDropCapabilities`, which removes the listed capabilities from every container admitted under that SCC. Listing `NET_RAW` there prevents pods in the `finance` namespace from retaining it, regardless of what the pod manifest requests. The allow list and default-add list have the opposite effect, and SELinux fields govern labels rather than capabilities.

Exam trap

The trap here is confusing `allowedCapabilities` with `requiredDropCapabilities`, since both are lists of capability names but only one removes them.

Practice this question →

22

MCQeasy

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?

A.As an annotation on the cluster-scoped Namespace object

B.Inside the Route object spec under tls.imagePullSecret

C.In the Deployment configuration spec under template.spec.imagePullSecrets

D.As an environment variable named IMAGE_PULL_SECRET in the container specification

AnswerC

Specifying imagePullSecrets inside the pod template spec ensures pods created by the deployment use the credentials.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that imagePullSecrets belongs in the pod template spec (template.spec.imagePullSecrets), not at the Deployment top level or in unrelated objects like Routes or Namespaces.

How to eliminate wrong answers

Option A is wrong because Namespace annotations are metadata only and are never consumed by the kubelet or container runtime for image authentication. Option B is wrong because a Route object handles ingress traffic and TLS termination; it has no imagePullSecret field and is unrelated to registry authentication. Option D is wrong because IMAGE_PULL_SECRET as an environment variable is just a string passed to the container process and has no effect on the CRI image pull mechanism.

Practice this question →

23

Multi-Selectmedium

An administrator is preparing a custom SecurityContextConstraints (SCC) named app-scc to allow pods to run with a specific user ID and to use the host network. Which two fields must be set in the SCC to achieve these requirements? (Choose two.)

Select 2 answers

A.allowPrivilegedContainer: true

B.allowHostNetwork: true

C.readOnlyRootFilesystem: true

D.runAsUser: MustRunAs with a specific UID range

E.seLinuxContext: RunAsAny

AnswersB, D

The allowHostNetwork field, when set to true, permits pods to use the host's network namespace. This is necessary for the pods to bind to host ports or access host network interfaces. Without this field, the SCC will deny any pod that requests hostNetwork: true in its spec.

Why this answer

The runAsUser field with MustRunAs ensures the pod runs with a specific UID, and allowHostNetwork enables the use of the host network namespace. These two fields directly address the stated requirements. Other fields like allowPrivilegedContainer or seLinuxContext are unrelated and would unnecessarily broaden the SCC's permissions.

Exam trap

The trap here is confusing container-level securityContext fields with SCC fields, such as assuming readOnlyRootFilesystem is part of an SCC, when it is not.

Practice this question →

24

MCQhard

A security team wants to ensure that all pods in a new namespace called secure-apps run with a specific SELinux context level. They create a custom SCC named selinux-scc with seLinuxContext: MustRunAs and a specific level. After binding the SCC to the default service account in secure-apps, pods still fail to start with an SELinux relabeling error. What is the most likely cause?

A.The node's SELinux policy does not include the specified level, so the container runtime cannot apply the context.

B.The seLinuxContext field in the SCC must be set to RunAsAny to allow pods to start without specifying seLinuxOptions.

C.The pod's securityContext does not specify the required seLinuxOptions, so the SCC's MustRunAs strategy rejects the pod.

D.The SCC was not bound to the correct service account; it must be bound to the default service account in the openshift-infra namespace.

AnswerC

When seLinuxContext uses MustRunAs, the pod must explicitly request an SELinux context that falls within the allowed range. If the pod spec omits seLinuxOptions, the admission controller cannot verify compliance and rejects the pod. The pod template must include seLinuxOptions with the appropriate level, matching the SCC's allowed range.

Why this answer

With seLinuxContext set to MustRunAs, the pod must include seLinuxOptions in its securityContext that match the allowed SELinux context. Omitting these options causes the admission controller to reject the pod. The solution is to add the correct seLinuxOptions to the pod template, ensuring it aligns with the SCC's allowed range.

Exam trap

The trap here is assuming that the SCC alone will enforce the SELinux context without the pod explicitly requesting it, when MustRunAs requires the pod to specify matching options.

Practice this question →

25

MCQhard

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

A.A secret in 'openshift-config'

B.A ConfigMap in 'openshift-config'

C.A local file on the master node

D.A secret in 'openshift-authentication'

AnswerA

The `htpasswd` identity provider reads its credential file from a Secret in the `openshift-config` namespace, referenced by the OAuth custom resource's `spec.htpasswd.fileData.name` field. Placing it there satisfies OpenShift's requirement that identity provider secrets reside in that dedicated namespace, not the cluster or application namespaces.

Why this answer

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.

Exam trap

EX280 often tests the misconception that identity provider files can be stored in ConfigMaps or in the 'openshift-authentication' namespace, when the correct location is a Secret in 'openshift-config'.

How to eliminate wrong answers

Option B is wrong because a ConfigMap is used for non-sensitive configuration data, and the htpasswd file contains password hashes that must be stored securely in a Secret. Option C is wrong because OpenShift is a containerized platform; storing the file locally on a master node is not how the OAuth operator consumes identity provider data and would not survive upgrades or be replicated. Option D is wrong because the 'openshift-authentication' namespace hosts the OAuth server pods, but the secret must be created in 'openshift-config' where the OAuth custom resource resides; the operator then projects it into the authentication namespace.

Practice this question →

26

MCQeasy

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

A.builder

B.default

C.system

D.deployer

AnswerB

Pods without a serviceAccountName field are automatically assigned the 'default' service account in their namespace. OpenShift creates this account in every namespace, granting it minimal permissions, so the pod authenticates to the API with that identity unless the manifest specifies otherwise.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse OpenShift's auto-created per-namespace ServiceAccounts (builder, deployer, default) with the one actually assigned when a pod omits the field — the answer is always 'default', not builder or deployer.

How to eliminate wrong answers

Option A is wrong because 'builder' is a per-namespace ServiceAccount used by OpenShift BuildConfig pods to run builds, not the fallback for generic workloads. Option C is wrong because 'system' is not a ServiceAccount name — 'system:serviceaccount:<ns>:<name>' is the identity format used in RBAC bindings, not a default account. Option D is wrong because 'deployer' is a per-namespace ServiceAccount used by DeploymentConfig rollout pods, not the default for pods that omit the field.

Practice this question →

27

MCQeasy

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

A.oc get identityproviders

B.oc describe auth

C.oc get oauth cluster -o yaml

D.oc get configmap oauth -n openshift-config

AnswerC

The oauth cluster resource is a singleton holding the cluster-wide OAuth configuration, including the identityProviders list. Retrieving it as YAML with oc get oauth cluster -o yaml shows every currently active identity provider and its settings.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that OAuth configuration is stored in a cluster-scoped custom resource called 'oauth' (not a ConfigMap or a resource named 'identityproviders'), and that the correct command to view it is `oc get oauth cluster -o yaml`.

How to eliminate wrong answers

Option A is wrong because there is no resource type called 'identityproviders' in OpenShift; identity providers are defined within the OAuth cluster resource, not as standalone objects. Option B is wrong because 'auth' is not a valid OpenShift resource type; the correct resource is 'oauth' (oauth.config.openshift.io), and 'describe' would not show the full YAML configuration anyway. Option D is wrong because the OAuth configuration is not stored in a ConfigMap named 'oauth' in the openshift-config namespace; it is a custom resource, and while some configuration may be in ConfigMaps, the active identity providers are part of the OAuth cluster resource.

Practice this question →

28

Multi-Selectmedium

Which THREE components are involved in TLS termination for routes?

Select 3 answers

A.Secret

B.Route

C.IngressController

D.Service

E.ConfigMap

AnswersA, B, C

The Secret holds the TLS certificate and private key consumed during handshake. It must be of type kubernetes.io/tls and referenced by the Route, supplying the cryptographic material the IngressController presents to clients, satisfying the scenario's requirement for certificate storage.

Why this answer

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.

Exam trap

EX280 often tests the confusion between components that store TLS material (Secret) and those that define routing (Route) or manage the router (IngressController), leading candidates to incorrectly include Service or ConfigMap.

Practice this question →

29

MCQeasy

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

A.oc get scc

B.oc show scc

C.oc describe scc

D.oc list scc

AnswerA

Running oc get scc queries the OpenShift API for the SecurityContextConstraints resource type, listing every SCC defined in the cluster. This directly satisfies the requirement to view all available SCCs, since SCCs are cluster-scoped objects retrieved through the standard oc get verb.

Why this answer

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.

Exam trap

EX280 often tests basic oc command syntax, and candidates may confuse the verbs get, describe, and list, or invent non-existent commands like show.

How to eliminate wrong answers

Option B is wrong because oc show scc is not a valid oc command; the correct verb is get. Option C is wrong because oc describe scc requires a specific SCC name to provide detailed information, and without a name, it will not list all SCCs. Option D is wrong because oc list scc is not a valid oc command; the correct verb is get.

Practice this question →

30

Multi-Selecthard

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

Select 3 answers

A.Client Secret reference

B.Htpasswd file path

C.Client ID

D.LDAP bind password

E.Issuer URL

AnswersA, C, E

A client secret reference is mandatory because the OpenID Connect authorisation code flow requires the relying party to authenticate itself to the token endpoint. Red Hat OpenShift, through its OAuth configuration, stores this as a Kubernetes Secret and references it, satisfying the provider's confidential-client credential requirement during code exchange.

Why this answer

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.

Exam trap

EX280 often tests the confusion between identity provider types, tricking candidates into selecting LDAP or HTPasswd fields (bind password, htpasswd path) that belong to entirely different provider configurations.

Practice this question →

31

MCQeasy

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

A.In the ClusterOperator configuration

B.In the Namespace metadata

C.By linking the secret to the 'default' service account

D.In the project configuration object

AnswerC

Linking the image pull secret to the namespace's 'default' service account makes OpenShift use those credentials for pods that specify no service account, since every pod defaults to it. This satisfies the requirement of defining pull secrets for all service accounts in the namespace.

Why this answer

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.

Exam trap

EX280 often tests the misconception that image pull secrets can be set at the namespace level, when they are actually linked to service accounts.

How to eliminate wrong answers

Option A is wrong because ClusterOperator configuration manages cluster-wide operators, not image pull secrets. Option B is wrong because Namespace metadata does not include image pull secrets. Option D is wrong because the project configuration object (if it exists) does not control image pull secrets.

Practice this question →

32

MCQeasy

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?

A.The destination CA certificate to validate the backend pod's TLS certificate

B.A base64 encoded kubeconfig file for the ingress operator

C.An identity provider public key for JSON Web Token validation

D.A client certificate for mutual TLS authentication against the OAuth server

AnswerA

Re-encrypt termination means the router decrypts and then re-encrypts traffic to the backend, so it must trust the pod's serving certificate. Supplying the destination CA certificate lets the router validate that backend certificate, which passthrough and edge termination do not require.

Why this answer

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.

Exam trap

EX280 often tests the misconception that re-encrypt termination only requires the router certificate, confusing it with edge termination where the backend is unencrypted.

How to eliminate wrong answers

Option B is wrong because a kubeconfig file is used for cluster authentication and authorization, not for TLS termination on a Route. Option C is wrong because an identity provider public key is used for validating JSON Web Tokens in OAuth/OIDC flows, which is unrelated to re-encrypt TLS. Option D is wrong because a client certificate for mutual TLS against an OAuth server is used for API authentication, not for securing traffic between the router and backend pods.

Practice this question →

33

MCQhard

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

A.Enable 'insecureEdgeTerminationPolicy: Allow'

B.Configure a ServiceMesh resource

C.Set 'termination: reencrypt' in the spec.tls section

D.Set 'termination: edge' and add a proxy

AnswerC

Setting termination to reencrypt makes the router decrypt incoming traffic with the edge certificate, then re-encrypt it with the pod's certificate before forwarding. This satisfies the re-encryption requirement, unlike passthrough or edge termination, which do not re-encrypt to the backend.

Why this answer

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.

Exam trap

EX280 often tests the confusion between edge and reencrypt termination, and candidates incorrectly select edge plus a proxy instead of setting termination: reencrypt.

How to eliminate wrong answers

Option A is wrong because insecureEdgeTerminationPolicy: Allow controls whether plain HTTP is allowed alongside HTTPS at the edge; it does not configure re-encryption. Option B is wrong because ServiceMesh is a separate Istio-based feature for mTLS and traffic management, not the mechanism for a standard OpenShift Route with re-encrypt termination. Option D is wrong because termination: edge terminates TLS at the router and forwards plain HTTP to the backend — it does not re-encrypt, and adding a proxy is not how re-encryption is achieved.

Practice this question →

34

MCQmedium

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

A.Bind the SCC to the 'cluster-admin' user

B.Bind the SCC to a specific service account in a specific namespace

C.Bind the SCC to the 'system:authenticated' group

D.Assign the SCC to the namespace object directly

AnswerB

Binding an SCC to a specific service account within a namespace follows least privilege, granting only that workload the required permissions. Cluster-wide or user-based grants would over-privilege unrelated pods, so scoping to the service account is the recommended practise.

Why this answer

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.

Exam trap

EX280 often tests the misconception that SCCs can be assigned to namespaces or broad groups, when in fact best practice requires binding SCCs to specific service accounts via RBAC to enforce least privilege.

How to eliminate wrong answers

Option A is wrong because binding an SCC to the cluster-admin user grants cluster-wide elevated permissions to a human user, violating least privilege and creating a significant security risk — SCCs should be bound to service accounts that pods run as, not to administrative users. Option C is wrong because binding to the system:authenticated group applies the SCC to every authenticated user in the cluster, which is an extremely broad grant that effectively removes the security boundary the SCC is meant to enforce. Option D is wrong because SCCs cannot be assigned directly to a namespace object — SCCs are bound to subjects (users, groups, or service accounts) through RBAC, and the namespace is the scope of the service account, not the target of the SCC binding.

Practice this question →

35

MCQhard

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?

A.Create a dedicated ServiceAccount, a Role granting get and list on pods, and a RoleBinding linking them in the namespace

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

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

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

AnswerA

A dedicated ServiceAccount with a namespaced Role granting only get and list on pods, bound via RoleBinding, delivers exactly the API permissions required while honouring least privilege. ClusterRole or broader verbs would exceed the pod-status querying need.

Why this answer

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.

Exam trap

EX280 often tests the misconception that the default ServiceAccount is 'safe' or that SCC roles grant API permissions — candidates must distinguish authentication/authorization (RBAC) from pod security admission (SCC).

How to eliminate wrong answers

Option B is wrong because binding cluster-admin via ClusterRoleBinding grants full cluster-wide control to the default ServiceAccount — the exact opposite of least privilege, and it also pollutes the shared default SA. Option C is wrong because there is no such annotation (rbac.authorization.k8s.io/authtype) — RBAC is granted through Roles/ClusterRoles and Bindings, never through annotations. Option D is wrong because system:openshift:scc:restricted is a SecurityContextConstraints role controlling pod security admission, not API access to pods; it does not grant get/list on pods.

Practice this question →

36

MCQmedium

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?

A.spec.endpoint.tls with base64 encoded string data

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

C.spec.tls.certificate, spec.tls.key, and spec.tls.caCertificate

D.status.ingress.tls for automatic cert-manager synchronization

AnswerC

Edge termination places the certificate and private key on the router, so they belong in the Route's spec.tls fields: certificate, key and caCertificate. It satisfies the custom TLS certificate requirement, unlike re-encrypt or passthrough termination, which handle certificates differently.

Why this answer

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.

Exam trap

EX280 often tests whether candidates mistakenly believe Route TLS fields are base64-encoded or stored in annotations, when they are actually plain string fields under spec.tls.

How to eliminate wrong answers

Option A is wrong because there is no spec.endpoint.tls section in a Route, and Route TLS fields are plain strings, not base64-encoded. Option B is wrong because TLS material is not supplied via annotations like openshift.io/tls-cert; those annotations do not exist for Route TLS. Option D is wrong because status.ingress.tls is a read-only status field populated by the router, not a place to configure certificates, and cert-manager does not sync into it.

Practice this question →

37

Multi-Selecthard

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

Select 3 answers

A.Passthrough

B.Edge

C.Proxy

D.FullMesh

E.Re-encrypt

AnswersA, B, E

Passthrough termination forwards encrypted traffic straight to the pod without decrypting at the router, so the application handles TLS itself. It is one of the three termination types OpenShift Routes support natively, satisfying the stem's requirement alongside edge and re-encrypt.

Why this answer

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.

Exam trap

EX280 often tests the exact set of Route TLS termination types — candidates may invent or recall 'Proxy' or 'FullMesh' from other contexts (e.g., service mesh, load balancers) and select them. The exam expects you to know only edge, passthrough, and re-encrypt are valid.

Practice this question →

38

MCQhard

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

A.The secret key for the OIDC provider

B.The client ID of the OpenShift cluster

C.The hostname of the OpenShift API

D.The URL of the OIDC provider

AnswerD

The issuer field holds the HTTPS URL identifying the OIDC provider, matching the `iss` claim in issued tokens. OpenShift uses it to discover endpoints via `/.well-known/openid-configuration` and to validate that tokens originate from the trusted identity source, satisfying the requirement to bind authentication to a specific provider.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse the OIDC 'issuer' (the IdP's URL) with the client ID, client secret, or the cluster's own OAuth endpoint — all of which are separate configuration fields.

How to eliminate wrong answers

Option A is wrong because the secret key (client secret) is a separate credential configured alongside the client ID, not the issuer; the issuer is a URL, not a secret. Option B is wrong because the client ID identifies the OpenShift OAuth client registered with the IdP, not the IdP itself. Option C is wrong because the OpenShift API hostname is the OAuth server endpoint used by clients, not the identity provider's issuer URL.

Practice this question →

39

Multi-Selectmedium

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)

Select 2 answers

A.hardened

B.restricted

C.baseline

D.secured

E.isolated

AnswersB, C

The restricted level is one of Kubernetes' three Pod Security Standards, alongside baseline and privileged. It enforces the strictest controls, including non-root execution, dropped capabilities and seccomp profiles. OpenShift's Security Context Constraints map to these levels, so selecting restricted satisfies the requirement to limit pod creation by namespace.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can distinguish the three real PSA levels (privileged, baseline, restricted) from plausible-sounding fakes like 'hardened', 'secured', or 'isolated' — memorizing the exact three names is essential.

Practice this question →

40

MCQmedium

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?

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

B.The cluster OAuth custom resource named cluster

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

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

AnswerB

The cluster OAuth custom resource configures identity providers for the web console, including LDAP, by defining the external directory connection and attribute mappings. Editing it satisfies the requirement to authenticate console users against the corporate directory.

Why this answer

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.

Exam trap

EX280 often tests the location and name of the OAuth custom resource, tricking candidates into choosing a non-existent Authentication CR or a ConfigMap instead of the correct OAuth CR in `openshift-config`.

How to eliminate wrong answers

Option A is wrong because a Secret named `identity-provider` in `openshift-authentication` is not the correct resource; identity provider configuration is stored in the OAuth CR, and any referenced secrets (like bindPassword) are in `openshift-config`. Option C is wrong because there is no Authentication custom resource named `cluster` in `kube-system`; the correct resource is OAuth in `openshift-config`. Option D is wrong because a ConfigMap named `ldap-config` in `openshift-config` is not used for identity provider configuration; LDAP settings are part of the OAuth CR.

Practice this question →

41

Multi-Selecteasy

Which TWO security standards are natively tracked in OpenShift?

Select 2 answers

A.isolated

B.custom

C.restricted

D.privileged

E.secure

AnswersC, D

The `restricted` SCC enforces the tightest pod security by dropping all Linux capabilities, blocking host networking and privileged escalation, and requiring non-root execution. It satisfies the stem's demand for a natively tracked OpenShift security standard, since SCCs ship with the platform and are enforced by the API server during pod admission.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can distinguish built-in SCCs from made-up names — the trap is selecting plausible-sounding options like 'isolated' or 'secure' that don't exist in the default SCC set.

Practice this question →

42

MCQeasy

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

A.restricted

B.anyuid

C.nonroot

D.privileged

AnswerA

OpenShift assigns the restricted SCC to authenticated non-service-account users by default, permitting only minimal, non-root access. This satisfies the stem's constraint of the default SCC for regular authenticated users, since service accounts instead receive the anyuid or nonroot SCCs depending on their namespace role bindings.

Why this answer

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.

Exam trap

EX280 often tests the confusion between the default SCC for authenticated users (restricted) versus service accounts, and the misconception that anyuid or nonroot is granted by default.

How to eliminate wrong answers

Option B is wrong because anyuid allows containers to run as any UID including root and is not granted by default to authenticated users — it must be explicitly bound. Option C is wrong because nonroot is a stricter SCC that requires a specific non-root UID and is not the default for authenticated users. Option D is wrong because privileged grants full host access and is never assigned by default; it must be explicitly granted to specific service accounts.

Practice this question →

43

Multi-Selectmedium

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)

Select 3 answers

A.root-container-v1

B.custom-app-scc

C.nonroot

D.restricted-v2

E.privileged

AnswersC, D, E

The nonroot SCC ensures pods run as a non-root UID without restricting capabilities as heavily as restricted.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can distinguish built-in SCCs from custom ones; the trap is selecting plausible-sounding names like 'root-container-v1' or 'custom-app-scc' that are not actually shipped by OpenShift.

Practice this question →

44

Multi-Selectmedium

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

Select 2 answers

A.Reference a Secret containing the clientSecret used to authenticate against the OIDC provider.

B.Create a dedicated OAuthClient resource for every single cluster user.

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

D.Provide the issuer URL pointing to the OIDC provider's discovery endpoint.

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

AnswersA, D

The client secret authenticates OpenShift to the OpenID Connect provider during the authorisation code exchange, so it must be supplied via a Secret. It satisfies the stem's requirement by providing the credential the identity provider expects.

Why this answer

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.

Exam trap

EX280 often tests identity provider configuration details — candidates confuse OIDC with LDAP (picking directory sync) or assume per-user OAuthClients, missing that OIDC uses a single client with issuer URL and client secret.

Practice this question →

45

MCQeasy

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?

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

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

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

D.Patch the default ServiceAccount in the production namespace to include my-registry-secret in its imagePullSecrets array.

AnswerD

Patching the default ServiceAccount adds my-registry-secret to its imagePullSecrets array, so the kubelet automatically injects those credentials into every pod that omits an explicit serviceAccountName. Since the Deployment's pods use the default ServiceAccount, this satisfies the private registry authentication requirement without editing the pod template.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that image pull secrets must be linked to a ServiceAccount (or pod spec), so the trap is selecting an RBAC-related answer (RoleBinding) or a secret modification command that does not actually associate the secret with the pods.

How to eliminate wrong answers

Option A is wrong because a RoleBinding grants RBAC permissions to a subject (user, group, or service account) and has no relationship to image pull secrets; mapping a secret to cluster-readers does not enable registry authentication. Option B is wrong because annotating the Deployment with a base64-encoded dockerconfigjson payload is not a supported mechanism for image pull authentication; the correct approach is to reference a Secret of type kubernetes.io/dockerconfigjson via imagePullSecrets. Option C is wrong because 'oc set data secrets/my-registry-secret' modifies the contents of the secret (e.g., adding a key-value pair) but does not associate it with any ServiceAccount or pod, so it does not solve the pull authentication problem.

Practice this question →

46

MCQhard

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

A.A Secret in the same namespace as the route

B.A ConfigMap in the 'openshift-config' namespace

C.A custom resource definition of type TLS

D.The ingress controller configuration

AnswerA

OpenShift routes reference a TLS certificate and private key held in a Secret within the route's own namespace; the router reads that Secret to serve the custom certificate. This satisfies the stem's requirement to terminate TLS with a custom certificate rather than the default router certificate.

Why this answer

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.

Exam trap

EX280 often tests the misconception that TLS certificates for routes are stored in ConfigMaps or in the openshift-config namespace, but the correct answer is always a Secret in the same namespace as the route.

How to eliminate wrong answers

Option B is wrong because ConfigMaps are intended for non-sensitive configuration data and are not used to store TLS private keys; also, the 'openshift-config' namespace is for cluster-wide configuration, not per-route TLS. Option C is wrong because there is no custom resource definition of type TLS in OpenShift for route termination; TLS certificates are stored in Secrets, not CRDs. Option D is wrong because the ingress controller configuration is a cluster-wide resource that defines default certificates and router behavior, but it cannot be used to specify a custom certificate for an individual route.

Practice this question →

47

MCQmedium

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?

A.pod-security.kubernetes.io/enforce: restricted and pod-security.kubernetes.io/audit: restricted

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

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

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

AnswerA

Namespace labels drive Pod Security Admission. Setting enforce to restricted blocks non-compliant pods, while audit set to restricted records violations in the audit log without blocking, satisfying the requirement for enforcement plus audit warnings across auditing-ns.

Why this answer

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.

Exam trap

EX280 often tests the exact label syntax for Pod Security Admission — candidates may confuse SCC-related labels or invent non-existent annotation keys.

How to eliminate wrong answers

Option B is wrong because 'security.openshift.io/scc.enforce' is not a valid label for Pod Security Admission; SCCs (Security Context Constraints) are a separate OpenShift mechanism and are not configured via namespace labels. Option C is wrong because 'security.openshift.io/pod-security-standard' is not a recognized label — the correct prefix is 'pod-security.kubernetes.io/'. Option D is wrong because 'admission.cluster.openshift.io/validate-psa' is not a valid label or configuration key for enforcing PSA.

Practice this question →

48

Multi-Selecthard

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

Select 2 answers

A.A route to the registry

B.A docker-registry type secret

C.Linking the secret to the service account

D.Creating a new ClusterRole

E.Updating the node configuration

AnswersB, C

A docker-registry secret holds the registry credentials in the required format, which OpenShift uses when authenticating to the private registry. Creating it satisfies the requirement for storing authentication details before linking them to the service account.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know both halves — the Secret alone is insufficient; it must be linked to the ServiceAccount (or referenced as imagePullSecrets) for the pull to succeed.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Security And Scc questions.

Start 20-question session