Courseiva

CCNA User And RBAC Management Questions

59 questions · User And RBAC Management · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selectmedium

An administrator is preparing to grant a ServiceAccount named 'reporter-sa' in the 'monitoring' namespace read-only access to pods and services across all namespaces in the cluster. Which TWO actions should the administrator take? (Choose two.)

Select 2 answers
A.Assign the 'cluster-admin' ClusterRole to 'reporter-sa' to guarantee visibility into all namespaces.
B.Ensure the ServiceAccount subject in the binding specifies the name 'reporter-sa' and the namespace 'monitoring'.
C.Create a ClusterRoleBinding that binds the 'view' ClusterRole to the 'reporter-sa' ServiceAccount in the 'monitoring' namespace.
D.Add the 'reporter-sa' ServiceAccount to the 'system:authenticated' group to inherit read access.
E.Create a RoleBinding in each namespace that binds the 'view' ClusterRole to 'reporter-sa'.
AnswersB, C

ServiceAccount subjects in RBAC bindings must include both the name and the namespace because ServiceAccount names are only unique within a namespace. Specifying 'reporter-sa' with namespace 'monitoring' ensures the binding matches the intended identity and not a same-named account elsewhere.

Why this answer

Cluster-wide read access for a ServiceAccount is achieved with a ClusterRoleBinding to the 'view' ClusterRole, with the subject identifying both the ServiceAccount name and its namespace. Together these two actions grant the required permissions across all namespaces while keeping the account read-only and avoiding per-namespace maintenance.

Exam trap

The trap here is thinking a ServiceAccount subject needs only a name, when RBAC requires the namespace as well because ServiceAccount names are namespace-scoped.

Practice this question →
2
Multi-Selecteasy

Which THREE of the following actions can a user with the default OpenShift 'view' role perform within a project? (Choose THREE)

Select 3 answers
A.Delete PersistentVolumeClaims
B.View ConfigMaps
C.Modify RoleBindings within the project
D.List and read Pods
E.View Deployments and Services
AnswersB, D, E

Viewing ConfigMaps is permitted because the default OpenShift `view` role grants read-only access to most project-scoped resources, excluding Secrets and role bindings. ConfigMaps hold non-sensitive configuration data, so read access aligns with the role's constraint of allowing inspection without permitting modification or exposure of credentials.

Why this answer

The default OpenShift 'view' role is a ClusterRole aggregated to grant read-only access to most project-scoped resources, so option B (View ConfigMaps) is correct because ConfigMaps are readable via get/list/watch verbs under the view role. Option D (List and read Pods) is correct because the view role includes get, list, and watch on pods and pod logs. Option E (View Deployments and Services) is correct because the view role grants read access to Deployments, Services, and other workload/networking resources in the project.

Option A (Delete PersistentVolumeClaims) is incorrect because delete is a write verb not granted by the view role; that requires edit or admin. Option C (Modify RoleBindings within the project) is incorrect because managing RoleBindings requires admin-level permissions, not the read-only view role.

Exam trap

EX280 often tests the exact boundaries of default roles, so candidates must remember that 'view' is strictly read-only and cannot delete PVCs or modify RoleBindings.

Practice this question →
3
MCQmedium

A developer needs to know if their pod's service account has permissions to create pods in another namespace named 'target-ns'. Which command can the developer run to check this?

A.oc auth can-i create pods -n target-ns
B.oc get rolebindings -n target-ns --user=self
C.oc check-permission create pods -n target-ns
D.oc describe authorization -n target-ns
AnswerA

oc auth can-i submits a SubjectAccessReview for the current service account against the specified verb and resource, honouring the -n flag to target 'target-ns'. It returns yes or no, directly answering whether pod creation is permitted there.

Why this answer

The 'oc auth can-i' command is the OpenShift-native way to perform a SelfSubjectAccessReview against the API server, returning yes or no for a specific verb/resource combination. Adding '-n target-ns' scopes the check to the target namespace, so the developer can verify whether their current service account or user can create pods there. This is the exact command documented for permission troubleshooting in OpenShift.

Exam trap

EX280 often tests whether candidates know the exact oc subcommand for permission checks — many confuse it with kubectl auth can-i syntax variants or invent plausible-sounding commands like 'oc check-permission' that do not exist.

How to eliminate wrong answers

Option B is wrong because 'oc get rolebindings' lists RoleBinding objects but does not evaluate effective permissions — the developer would have to manually trace subjects, roles, and cluster-scoped bindings, which is error-prone and does not account for ClusterRoleBindings. Option C is wrong because 'oc check-permission' is not a real oc subcommand; the correct verb is 'auth can-i'. Option D is wrong because 'oc describe authorization' is not a valid command — authorization is evaluated through SubjectAccessReview/SelfSubjectAccessReview APIs, surfaced via 'oc auth can-i'.

Practice this question →
4
MCQmedium

A cluster administrator wants to grant a group of users read access to all Pod logs across every namespace in the cluster. Which ClusterRole and binding approach should be used?

A.ClusterRole with apiGroups: [''], resources: ['pods/log'], verbs: ['get'] bound via ClusterRoleBinding
B.RoleBinding in each individual namespace pointing to the 'view' ClusterRole
C.SecurityContextConstraints modification
D.ClusterRole with apiGroups: ['apps'], resources: ['deployments/scale'], verbs: ['get']
AnswerA

pods/log is a subresource, so the ClusterRole must specify resources: ['pods/log'] with verb get, and a ClusterRoleBinding grants it cluster-wide across all namespaces. A RoleBinding would restrict access to one namespace, failing the every-namespace requirement.

Why this answer

To grant read access to pod logs across all namespaces, you need a ClusterRole that grants 'get' on the 'pods/log' subresource in the core API group, bound with a ClusterRoleBinding to the target group. The ClusterRoleBinding ensures the permission applies cluster-wide rather than in a single namespace. This is the canonical RBAC pattern for cross-namespace log access.

Exam trap

EX280 often tests the confusion between RoleBinding and ClusterRoleBinding — candidates must recognize that cluster-wide access requires a ClusterRoleBinding, and that 'pods/log' is a separate subresource from 'pods'.

How to eliminate wrong answers

Option B is wrong because RoleBindings are namespace-scoped — you would need to create one in every namespace, which is operationally fragile and does not scale; a ClusterRoleBinding is the correct cluster-wide mechanism. Option C is wrong because SecurityContextConstraints govern pod security contexts, not log access, and have nothing to do with RBAC permissions on the pods/log subresource. Option D is wrong because it targets the 'apps' API group and the 'deployments/scale' subresource, which controls deployment scaling, not pod log retrieval.

Practice this question →
5
MCQmedium

An administrator wants members of the LDAP-backed group 'cn=auditors,ou=groups,dc=corp' to have read-only access to every project in the cluster, including future ones, without granting them any write capability. Which action achieves this?

A.Create a ClusterRoleBinding that binds the group to the 'edit' ClusterRole.
B.Create a RoleBinding in each namespace that binds the group to the 'view' ClusterRole.
C.Create a ClusterRoleBinding that binds the group to the 'cluster-admin' ClusterRole.
D.Create a ClusterRoleBinding that binds the group to the 'view' ClusterRole.
AnswerD

A ClusterRoleBinding grants the referenced ClusterRole across all namespaces, present and future, without per-project maintenance. Binding the LDAP group to the 'view' ClusterRole gives exactly read-only access cluster-wide, matching the requirement and avoiding any write verbs.

Why this answer

A ClusterRoleBinding to the 'view' ClusterRole is the correct mechanism because it applies cluster-wide and automatically covers namespaces created later. It grants only read verbs, satisfying the no-write constraint, and binding a group means all LDAP members inherit the access without per-user configuration.

Exam trap

The trap here is choosing a per-namespace RoleBinding for read access, forgetting that ClusterRoleBindings are what extend a ClusterRole's permissions to all current and future namespaces.

Practice this question →
6
MCQeasy

What is the primary function of the 'self-provisioner' cluster role in OpenShift?

A.It allows users to scale deployments automatically.
B.It allows users to provision persistent storage volumes.
C.It allows authenticated users to create new projects.
D.It allows users to generate their own OAuth tokens.
AnswerC

The self-provisioner cluster role is bound by default to the authenticated-users group, permitting any logged-in user to create new projects without administrator intervention. This satisfies the requirement that authenticated users can self-service their own namespaces.

Why this answer

The self-provisioner cluster role in OpenShift is a default cluster role bound to authenticated users, allowing them to create new projects (namespaces) on demand. This enables developers to self-service project creation without requiring an administrator to create namespaces for them. It is a key part of OpenShift's multi-tenant model.

Exam trap

EX280 often tests the confusion between cluster roles that allow project creation (self-provisioner) and those that allow resource creation within a project (admin/edit/view) — candidates may incorrectly associate self-provisioner with storage or scaling.

How to eliminate wrong answers

Option A is wrong because scaling deployments is controlled by roles like edit or admin within a project, not by the self-provisioner cluster role. Option B is wrong because provisioning persistent storage volumes is typically an administrator or storage-provisioner function, not granted by self-provisioner. Option D is wrong because generating OAuth tokens is handled by the OAuth server and is not related to the self-provisioner role.

Practice this question →
7
MCQhard

A developer reports they cannot deploy applications because their deployment quota is exhausted. Upon inspecting the 'LimitRange' object in the namespace, you notice default limits are set. However, a specific container in their deployment YAML fails validation during creation with an admission webhook error stating 'container exceeds minimum cpu request'. Where must the adjustment be made to allow this specific deployment?

A.Update the container resource requests in the deployment YAML to meet or exceed the LimitRange minimums, or adjust the LimitRange object.
B.Modify the ClusterQuota object to increase the CPU limit.
C.Create a ClusterRoleBinding giving the developer cluster-admin rights to bypass admission webhooks.
D.Add the developer to the 'system:masters' group to override resource constraints.
AnswerA

Admission validation compares each container's requests against the LimitRange minimums, so the fix lies either in raising the container's cpu request in the deployment spec or lowering the LimitRange floor; the LimitRange alone does not grant the pod.

Why this answer

The admission webhook error 'container exceeds minimum cpu request' comes from the LimitRange's min constraint, which is enforced at pod admission time. To resolve it, the container's `resources.requests.cpu` must be raised to at least the LimitRange minimum, or the LimitRange's min value must be lowered to accommodate the container. Both are valid fixes, and the option correctly names both.

Exam trap

EX280 often tests whether candidates understand that LimitRange admission is not bypassable via RBAC — the trap is picking cluster-admin or system:masters as a way to override resource constraints.

How to eliminate wrong answers

Option B is wrong because ClusterQuota (ClusterResourceQuota) governs aggregate namespace consumption across projects — it does not set per-container minimums and cannot override a LimitRange min constraint. Option C is wrong because cluster-admin rights do not bypass LimitRange admission; LimitRange is enforced by the LimitRanger admission plugin for all users regardless of RBAC. Option D is wrong because adding a user to system:masters grants cluster-admin but still does not exempt them from LimitRange admission — resource constraints are not RBAC-gated.

Practice this question →
8
MCQeasy

Which command is used to remove a role binding named 'dev-binding' from a namespace named 'development'?

A.oc revoke rolebinding dev-binding -n development
B.oc delete rolebinding dev-binding -n development
C.oc drop rolebinding dev-binding -n development
D.oc remove rolebinding dev-binding -n development
AnswerB

`oc delete rolebinding` targets the namespaced RoleBinding resource directly, and the `-n development` flag scopes the operation to the required namespace, satisfying the stem's constraint. RoleBindings exist within a namespace, so this combination removes exactly the named binding without affecting cluster-scoped ClusterRoleBindings.

Why this answer

RoleBindings are standard Kubernetes/OpenShift resources, so they are removed with the generic 'oc delete' verb followed by the resource type and name. The command 'oc delete rolebinding dev-binding -n development' deletes the named RoleBinding from the development namespace, immediately revoking the permissions it granted. There is no dedicated 'revoke', 'drop', or 'remove' verb for rolebindings in oc.

Exam trap

EX280 often tests whether candidates invent non-existent oc verbs like 'revoke', 'drop', or 'remove' instead of using the universal 'delete' verb that applies to all resources.

How to eliminate wrong answers

Option A is wrong because 'oc revoke' is not a valid oc subcommand — there is no revoke verb in the CLI; permissions are removed by deleting the binding or using 'oc adm policy remove-role-from-user'. Option C is wrong because 'oc drop' does not exist as a subcommand in oc; it is a fabricated verb. Option D is wrong because 'oc remove' is not a valid oc subcommand either — removal of rolebindings is done via delete or the 'oc adm policy remove-*' helpers.

Practice this question →
9
MCQeasy

Which command is used to create a new cluster role named 'storage-reader' that permits getting and listing PersistentVolumes cluster-wide?

A.oc new clusterrole storage-reader --permissions=pv:get,list
B.oc create role storage-reader --cluster --verb=get,list --resource=persistentvolumes
C.oc adm create-role storage-reader --cluster-wide --verbs=get,list --resources=pv
D.oc create clusterrole storage-reader --verb=get,list --resource=persistentvolumes
AnswerD

`oc create clusterrole` builds a ClusterRole, which grants permissions cluster-wide rather than within a namespace. Specifying `--verb=get,list` with `--resource=persistentvolumes` matches the required read operations on PersistentVolumes, satisfying the stem's cluster-wide scope constraint that a namespaced Role could not provide.

Why this answer

The correct command is `oc create clusterrole storage-reader --verb=get,list --resource=persistentvolumes`. This uses the `oc create clusterrole` subcommand, which is the standard OpenShift/Kubernetes imperative command for creating a ClusterRole resource. The `--verb` flag specifies the allowed actions (get, list), and `--resource` specifies the target resource type (persistentvolumes).

This directly creates a ClusterRole named 'storage-reader' with the desired permissions cluster-wide.

Exam trap

EX280 often tests the distinction between namespaced Roles and cluster-scoped ClusterRoles, and candidates may mistakenly use `oc create role` with a `--cluster` flag, which does not exist.

How to eliminate wrong answers

Option A is wrong because `oc new clusterrole` is not a valid subcommand; `oc new` is used for creating applications from source code, not RBAC resources. Option B is wrong because `oc create role` creates a namespaced Role, not a ClusterRole; the `--cluster` flag does not exist for this subcommand. Option C is wrong because `oc adm create-role` is not a valid command; `oc adm` has subcommands like `policy` but not `create-role`, and the flags `--cluster-wide` and `--resources` are incorrect.

Practice this question →
10
Multi-Selecteasy

When setting up authentication and user provisioning in OpenShift 4, which THREE identity providers are natively supported out-of-the-box by the OAuth server configuration? (Choose THREE)

Select 3 answers
A.OpenID Connect (OIDC)
B.Local Linux /etc/passwd direct sync daemon
C.HTPasswd
D.Active Directory Domain Services native kernel module
E.LDAP
AnswersA, C, E

OpenShift 4 ships an OpenID Connect identity provider as a built-in OAuth server configuration type. It maps claims from an OIDC issuer to OpenShift identities and groups, requiring only a client secret and issuer URL to configure natively.

Why this answer

OpenShift 4's OAuth server natively supports several identity providers configured through the OAuth custom resource, and OpenID Connect (OIDC) (A) is one of them, allowing integration with any OIDC-compliant provider such as Keycloak or Okta via the oidc identity provider type. HTPasswd (C) is also natively supported, using a secret containing an htpasswd-formatted file (created with htpasswd -c -B -b) to authenticate users against a static user list. LDAP (E) is natively supported as well, with the ldap identity provider type supporting direct binds, search-and-bind, and URL-based configurations against directory servers.

The unmarked options do not belong because there is no 'Local Linux /etc/passwd direct sync daemon' identity provider (B) in OpenShift, and there is no 'Active Directory Domain Services native kernel module' identity provider (D); AD is integrated indirectly via LDAP or OIDC, not through a kernel module.

Exam trap

EX280 often tests whether candidates can identify the real OpenShift identity provider types versus fabricated ones like 'Local Linux /etc/passwd direct sync daemon' or 'Active Directory Domain Services native kernel module' that sound technical but do not exist.

Practice this question →
11
Multi-Selecteasy

Which TWO of the following are valid built-in default project roles in OpenShift that can be assigned to users within a namespace? (Choose TWO)

Select 2 answers
A.admin
B.security-admin
C.edit
D.node-admin
E.cluster-admin
AnswersA, C

The `admin` role is a built-in OpenShift project role granting full control over resources within a namespace, including managing quotas and viewing or modifying most objects, but excluding cluster-scoped changes. It satisfies the stem's requirement for a default role assignable to users inside a single project.

Why this answer

In OpenShift, the built-in default project (namespace-scoped) roles that can be bound to users within a namespace include admin and edit, so options A and C are correct. The admin role grants full control over a project, including managing roles and bindings within that namespace, while the edit role allows creating, modifying, and deleting most resources in the project but not managing roles or bindings. These roles are part of the standard OpenShift RBAC set (admin, edit, view, and sometimes self-provisioner) applied per namespace.

Option B (security-admin) is not a built-in default project role; security context constraints are managed via cluster roles such as system:cluster-admin or specific SCC-related roles. Option D (node-admin) is not a built-in project role; node management is a cluster-level concern handled by cluster roles. Option E (cluster-admin) is a cluster-scoped role, not a namespace-scoped default project role, so it does not fit the scenario.

Exam trap

EX280 often tests whether candidates confuse project-scoped roles (admin, edit, view) with cluster-scoped roles (cluster-admin, node-admin), leading them to pick cluster-admin as a namespace role when it is not.

Practice this question →
12
MCQeasy

An administrator needs to grant read-only access to pods across all namespaces to a specific service account named 'monitor-sa' in the 'monitoring' project. Which RBAC resource configuration is required?

A.A SecurityContextConstraints object assigned to the ServiceAccount
B.A ClusterRole and a RoleBinding in the monitoring namespace
C.A ClusterRole and a ClusterRoleBinding
D.A Role and a RoleBinding in the monitoring namespace
AnswerC

A ClusterRole defines permissions cluster-wide, and binding it via ClusterRoleBinding to the 'monitor-sa' service account grants read-only pod access across every namespace. A Role with RoleBinding would only apply within the 'monitoring' namespace, failing the all-namespaces constraint.

Why this answer

To grant read-only access to pods across all namespaces, the permissions must be cluster-scoped. A ClusterRole defines the permissions (e.g., get, list, watch on pods), and a ClusterRoleBinding binds that ClusterRole to the service account, granting access cluster-wide. This is the correct RBAC configuration for cross-namespace access.

Exam trap

EX280 often tests the distinction between RoleBinding and ClusterRoleBinding for cross-namespace access, causing candidates to choose namespace-scoped bindings when cluster-wide access is required.

How to eliminate wrong answers

Option A is wrong because SecurityContextConstraints control pod security, not RBAC permissions for reading pods. Option B is wrong because a RoleBinding in the monitoring namespace only grants permissions within that namespace, not across all namespaces. Option D is wrong because a Role and RoleBinding are namespace-scoped and cannot grant cluster-wide access.

Practice this question →
13
MCQmedium

You need to ensure that a specific ServiceAccount named 'builder-sa' in the 'cicd' project can use the 'privileged' SecurityContextConstraints. Which command accomplishes this?

A.oc annotate serviceaccount builder-sa scc=privileged -n cicd
B.oc adm policy add-scc-to-user privileged system:serviceaccount:cicd:builder-sa
C.oc set scc privileged --serviceaccount=builder-sa -n cicd
D.oc create rolebinding privileged-binding --clusterrole=privileged --serviceaccount=cicd:builder-sa
AnswerB

`oc adm policy add-scc-to-user` binds the SCC directly to the ServiceAccount's user identity, `system:serviceaccount:cicd:builder-sa`, satisfying the requirement that only `builder-sa` in the `cicd` project gains `privileged`. This grants the SCC via a RoleBinding rather than altering the SCC's own user list, which is the supported OpenShift mechanism.

Why this answer

`oc adm policy add-scc-to-user privileged system:serviceaccount:cicd:builder-sa` is the correct command to grant the 'privileged' SCC to the 'builder-sa' ServiceAccount in the 'cicd' project. It adds the ServiceAccount to the SCC's users list, allowing pods running as that SA to request privileged access.

Exam trap

EX280 often tests whether candidates know the specific `oc adm policy add-scc-to-user` syntax for SCC assignment — the trap is confusing SCC assignment with RBAC RoleBindings or attempting to use annotations or `oc set` commands.

How to eliminate wrong answers

Option A is wrong because annotating a ServiceAccount with scc=privileged does not grant SCC permissions — SCCs are not selected via annotations on ServiceAccounts. Option C is wrong because `oc set scc` is not a valid command for assigning SCCs to ServiceAccounts. Option D is wrong because creating a RoleBinding to a ClusterRole named 'privileged' does not grant SCC access — SCCs are not RBAC ClusterRoles and require the `oc adm policy add-scc-to-user` or `add-scc-to-group` commands.

Practice this question →
14
MCQeasy

Which default OpenShift cluster role grants full administrative privileges to manage all resources within a specific project when bound via a RoleBinding?

A.edit
B.view
C.cluster-admin
D.admin
AnswerD

The `admin` cluster role grants full management of resources within a project, including roles and bindings, when bound through a RoleBinding. It is the default role intended for project administrators, unlike `edit` or `view`, which omit permission management.

Why this answer

The 'admin' cluster role is a default OpenShift role that grants full read/write access to most resources within a project, including the ability to manage roles and rolebindings inside that namespace. When bound via a RoleBinding (namespace-scoped), it confers project-level administrative rights without granting cluster-wide privileges. This is distinct from 'cluster-admin', which is a cluster-scoped role granting unrestricted access across all projects and cluster resources.

Exam trap

EX280 often tests the distinction between 'admin' (namespace-scoped full control) and 'cluster-admin' (cluster-wide full control) — candidates who equate 'full administrative privileges' with cluster-admin miss the 'within a specific project' qualifier.

How to eliminate wrong answers

Option A is wrong because 'edit' allows create/update/delete on most workload resources but explicitly denies access to roles, rolebindings, and resource quotas — it is not full administrative control. Option B is wrong because 'view' is read-only and cannot modify any resource. Option C is wrong because 'cluster-admin' is a cluster-scoped role that grants full control over the entire cluster, not just a specific project, and binding it via a RoleBinding is unusual and over-privileged for the stated requirement.

Practice this question →
15
MCQmedium

You need to verify whether a particular ServiceAccount in your project has permissions to read Secrets. Which command tests this authorization?

A.oc auth can-i get secrets --as=system:serviceaccount:<namespace>:<serviceaccount-name>
B.oc describe rolebinding --serviceaccount=<serviceaccount-name>
C.oc check secrets --serviceaccount=<serviceaccount-name>
D.oc adm verify-sa <serviceaccount-name>
AnswerA

`oc auth can-i` performs a SubjectAccessReview against the API server, returning yes or no for the specified verb and resource. The `--as` flag impersonates the ServiceAccount, so the check reflects that account's actual RBAC bindings in the namespace, directly answering whether it can read Secrets.

Why this answer

`oc auth can-i get secrets --as=system:serviceaccount:<namespace>:<serviceaccount-name>` submits a SubjectAccessReview to the API server impersonating the named service account, returning the effective allow/deny decision for the `get` verb on `secrets`. This is the only command among the options that actually evaluates RBAC rather than merely displaying configuration. It works regardless of whether the permission comes from a RoleBinding, ClusterRoleBinding, or an aggregated role.

Exam trap

EX280 often tests whether candidates pick a command that merely displays role bindings instead of one that actually evaluates effective permissions — only `oc auth can-i --as=system:serviceaccount:...` performs the authorization check.

How to eliminate wrong answers

Option B is wrong because `oc describe rolebinding` is not a valid subcommand form for querying a specific SA's permissions — you would need to list rolebindings and inspect each one, and even then you'd only see the binding, not the resolved effective permission. Option C is wrong because `oc check secrets` is not a real OpenShift CLI command; it is a fabricated verb. Option D is wrong because `oc adm verify-sa` does not exist — there is no such subcommand for verifying service account authorization in the oc CLI.

Practice this question →
16
MCQmedium

A cluster administrator has created a custom ClusterRole named 'pod-debugger' with permissions to execute commands in pods. They want to ensure that only users in the 'development' group can utilize this role within the 'app-dev' project. How should they configure this?

A.Modify the 'pod-debugger' ClusterRole directly to include a namespace selector for 'app-dev'.
B.Create a Role in the 'app-dev' namespace and assign it to the 'pod-debugger' subject.
C.Create a RoleBinding in the 'app-dev' namespace referencing the 'pod-debugger' ClusterRole and the 'development' group.
D.Create a ClusterRoleBinding for the 'development' group pointing to 'pod-debugger'.
AnswerC

A RoleBinding in the 'app-dev' namespace grants the 'pod-debugger' ClusterRole's permissions solely within that project, satisfying the constraint that only the 'development' group may execute commands in pods there. Unlike a ClusterRoleBinding, which would extend access cluster-wide, this namespace-scoped binding correctly limits the group's permissions to 'app-dev'.

Why this answer

A RoleBinding can reference a ClusterRole, and when it does, the permissions defined in the ClusterRole are granted only within the namespace where the RoleBinding is created. By creating a RoleBinding in the 'app-dev' namespace that references the 'pod-debugger' ClusterRole and binds it to the 'development' group, the administrator ensures that only members of that group can use the role's permissions within that specific project. This is the standard OpenShift/Kubernetes pattern for scoping cluster-defined roles to a single namespace.

Exam trap

EX280 often tests the misconception that ClusterRoles can be namespace-scoped or that ClusterRoleBindings can be limited to a namespace; the key is remembering that only RoleBindings can scope a ClusterRole to a namespace.

How to eliminate wrong answers

Option A is wrong because ClusterRoles are cluster-scoped and do not support namespace selectors; they cannot be restricted to a specific namespace by modifying the ClusterRole itself. Option B is wrong because creating a Role in 'app-dev' and assigning it to the 'pod-debugger' subject is conceptually backwards—the subject should be the 'development' group, and the Role should define permissions, not be assigned to a ClusterRole. Option D is wrong because a ClusterRoleBinding grants permissions across the entire cluster, not just within the 'app-dev' namespace, which violates the requirement to limit access to that project.

Practice this question →
17
MCQhard

An administrator must allow the ServiceAccount 'report-sa' in the 'metrics' namespace to list nodes cluster-wide, but must not grant any other cluster-level access. Which command accomplishes this?

A.oc adm policy add-cluster-role-to-user cluster-reader -z report-sa -n metrics
B.oc adm policy add-cluster-role-to-user node-viewer -z report-sa -n metrics
C.oc adm policy add-cluster-role-to-user system:node-reader -z report-sa -n metrics
D.oc create clusterrole node-lister --verb=list --resource=nodes, then oc adm policy add-cluster-role-to-user node-lister -z report-sa -n metrics
AnswerD

Creating a custom ClusterRole with only the list verb on nodes and binding it to the service account via 'add-cluster-role-to-user' gives exactly the required cluster-scoped permission. Because nodes are cluster-scoped, a ClusterRole and ClusterRoleBinding are necessary, and the narrow verb list enforces least privilege.

Why this answer

Only a custom ClusterRole containing the single list verb on nodes, bound with a ClusterRoleBinding to the service account, satisfies the constraint. Built-in read-oriented roles like 'cluster-reader' are too broad, and no default node-lister role exists. The 'oc adm policy add-cluster-role-to-user' command with the '-z' flag correctly targets the service account.

Exam trap

The trap here is assuming a built-in read role like cluster-reader is the least-privilege choice for node visibility, when it actually grants read access to almost everything cluster-wide.

Practice this question →
18
MCQhard

An OpenShift administrator must give the user 'dana' permission to list and watch pods and services across every project in the cluster, but nothing else. The administrator decides to create a new ClusterRole named 'ns-reader' containing only those rules and bind it to dana. Which command correctly creates this ClusterRole?

A.oc adm policy add-cluster-role-to-user ns-reader dana --verb=list,watch --resource=pods,services
B.oc create role ns-reader --verb=list,watch --resource=pods,services -n default
C.oc create clusterrolebinding ns-reader --clusterrole=view --user=dana
D.oc create clusterrole ns-reader --verb=list,watch --resource=pods,services
AnswerD

The oc create clusterrole subcommand generates a ClusterRole (cluster-scoped, not namespaced) with the given verbs and resources. Because it is a ClusterRole, binding it via a ClusterRoleBinding later grants dana the list and watch verbs on pods and services in every project. This matches the requirement exactly without granting create, delete, or other verbs.

Why this answer

The task requires a new cluster-scoped ClusterRole with only list and watch on pods and services. The oc create clusterrole subcommand is the direct imperative way to author that object from the CLI, producing a ClusterRole that can later be bound cluster-wide. Creating a namespaced Role, binding the broad view role, or using add-cluster-role-to-user all fail to produce the narrowly scoped ClusterRole described.

Exam trap

The trap here is confusing the namespaced oc create role with the cluster-scoped oc create clusterrole, since a Role cannot grant access across every project.

Practice this question →
19
Multi-Selecteasy

Which TWO of the following tasks can a user with the default OpenShift 'admin' role perform within their project? (Choose TWO)

Select 2 answers
A.Create, modify, and delete workloads and services within the project.
B.Modify cluster-wide ClusterRoles and ClusterRoleBindings.
C.Create and modify Roles and RoleBindings within the project.
D.Create new projects cluster-wide without restrictions.
E.Modify global SecurityContextConstraints.
AnswersA, C

The default OpenShift `admin` role grants full control over project-scoped resources, so creating, modifying and deleting workloads and services falls squarely within it. This satisfies the stem's constraint of actions performed within the user's own project, since the role binds to that namespace rather than the whole cluster.

Why this answer

Option A is correct because the default OpenShift 'admin' role is a project-scoped role that grants full control over resources inside the project namespace, including creating, modifying, and deleting workloads (Deployments, Pods, etc.) and Services. Option C is correct because the 'admin' role also includes permissions to manage project-local RBAC objects, i.e., create and modify Roles and RoleBindings within that project. Option B is incorrect because ClusterRoles and ClusterRoleBindings are cluster-scoped resources, and the 'admin' role does not grant cluster-level RBAC administration (that requires cluster-admin or similar).

Option D is incorrect because creating new projects cluster-wide is governed by the self-provisioner ClusterRoleBinding, not by the project 'admin' role. Option E is incorrect because SecurityContextConstraints are cluster-scoped resources, and modifying them requires cluster-level privileges, not the project 'admin' role.

Exam trap

EX280 often tests the boundary between project-scoped admin and cluster-scoped cluster-admin — candidates must remember that the admin role cannot touch ClusterRoles, ClusterRoleBindings, SCCs, or create projects cluster-wide.

Practice this question →
20
Multi-Selectmedium

Which THREE of the following objects can be used to enforce resource governance and consumption limits within an OpenShift project? (Choose THREE)

Select 3 answers
A.SecurityContextConstraints
B.LimitRange
C.NetworkPolicy
D.ResourceQuota
E.ClusterResourceQuota
AnswersB, D, E

A LimitRange sets default, minimum and maximum CPU and memory values per pod or container within a project, preventing unbounded requests. It enforces consumption limits at the individual workload level, satisfying the governance requirement in the stem.

Why this answer

LimitRange (B) is correct because it sets default, minimum, and maximum CPU/memory requests and limits for individual pods and containers within a project, enforcing per-object consumption boundaries. ResourceQuota (D) is correct because it caps the aggregate resource consumption of an entire project, such as total CPU/memory requests and limits, pod counts, and object counts. ClusterResourceQuota (E) is correct because it applies quota enforcement across multiple projects selected by label or annotation, governing total consumption at a cluster-scoped level.

SecurityContextConstraints (A) govern pod security privileges (e.g., allowed UIDs, SELinux, privileged mode), not resource consumption limits, and NetworkPolicy (C) controls pod-level network traffic, so neither enforces resource governance.

Exam trap

EX280 often tests the confusion between security and network policies (SCC, NetworkPolicy) and actual resource governance objects (LimitRange, ResourceQuota, ClusterResourceQuota).

Practice this question →
21
MCQhard

A user reports that 'oc get pods -n analytics' returns a Forbidden error, but 'oc get pods -n analytics --as=system:admin' succeeds. The administrator confirms the user is a member of the LDAP group 'data-team' and that a ClusterRoleBinding grants 'view' to that group. What should the administrator check first to explain the discrepancy?

A.Whether the identity provider is sending group membership in the OAuth token, since missing group claims would prevent the ClusterRoleBinding from matching.
B.Whether the 'view' ClusterRole has been extended with an aggregationRule that removes get and list from pods.
C.Whether the 'analytics' namespace has a ResourceQuota that blocks read operations for non-admin users.
D.Whether the user authenticated to OpenShift via the 'kube:admin' identity rather than the LDAP identity provider.
AnswerA

OpenShift RBAC matches subjects by user, group, and service account. If the LDAP identity provider is not configured to map group membership into OAuth group claims, the user's token will not carry 'data-team', so the ClusterRoleBinding to that group never matches. Verifying group claims in the identity configuration is the most direct first check.

Why this answer

RBAC matches group subjects using the groups carried in the user's OAuth token. If the LDAP identity provider does not map group membership into group claims, the user is authenticated but lacks the 'data-team' group, so the ClusterRoleBinding never applies. Inspecting the identity provider's group mapping and the token's groups resolves the discrepancy.

Exam trap

The trap here is assuming that LDAP group membership alone satisfies a group-based binding, when OpenShift only matches groups that the identity provider actually places into the OAuth token.

Practice this question →
22
MCQeasy

Which command allows an administrator to delete a user object named 'old-user' from the OpenShift cluster?

A.oc deactivate user old-user
B.oc delete user old-user
C.oc purge user old-user --force
D.oc remove user old-user
AnswerB

`oc delete user old-user` targets the cluster-scoped OpenShift User object directly, removing the identity record that grants cluster access. This satisfies the stem's requirement to delete the user object itself, rather than merely removing a project membership or identity provider entry.

Why this answer

The correct command is 'oc delete user old-user'. This command removes the user object from the OpenShift cluster. OpenShift users are represented as cluster-scoped resources, and the standard 'oc delete' verb is used to remove them.

Other options are not valid OpenShift commands.

Exam trap

The trap is confusing OpenShift user management with other systems that might use terms like 'deactivate' or 'remove', leading candidates to choose invalid commands.

How to eliminate wrong answers

Option A is wrong because 'oc deactivate' is not a valid command for user objects. Option C is wrong because 'oc purge' is not a valid command. Option D is wrong because 'oc remove' is not a valid command; the correct verb is 'delete'.

Practice this question →
23
MCQhard

A cluster administrator wants to restrict a specific group of developers from creating persistent volume claims (PVCs) larger than 50Gi in the 'data-tier' namespace, while still allowing smaller PVCs. How should this be implemented?

A.Configure a LimitRange object in the 'data-tier' namespace with max storage constraints for persistent volume claims.
B.Set a StorageClass default size restriction.
C.Apply a ClusterRole restricting PVC creation sizes.
D.Configure an egress firewall rule blocking large volume attachments.
AnswerA

A LimitRange with a `max` storage constraint on `persistentvolumeclaim` enforces the 50Gi ceiling at admission time within the 'data-tier' namespace, rejecting oversized PVCs while permitting smaller requests. This satisfies the per-namespace, per-group restriction without altering cluster-wide quota behaviour.

Why this answer

A LimitRange object in the 'data-tier' namespace can enforce a maximum storage request for PersistentVolumeClaims, rejecting any PVC that requests more than 50Gi. This is the native Kubernetes mechanism for per-namespace resource constraints on PVCs.

Exam trap

EX280 often tests the distinction between LimitRange (per-object min/max) and ResourceQuota (aggregate namespace limits) — candidates pick ClusterRole or StorageClass because they conflate RBAC/provisioning with resource constraints.

How to eliminate wrong answers

Option B is wrong because StorageClasses define provisioning parameters (disk type, reclaim policy) and do not enforce per-PVC size caps. Option C is wrong because ClusterRoles govern API verb permissions (create, get, delete), not the content or size of the resource being created. Option D is wrong because egress firewall rules control network traffic, not storage provisioning, and would not prevent large PVC creation.

Practice this question →
24
MCQmedium

A cluster administrator has created a new ProjectRequest template to ensure that every newly created project automatically includes a predefined LimitRange. Where must this template be configured so that it applies cluster-wide to all new projects?

A.In the namespace openshift-config as a ConfigMap named project-request
B.In the kube-system namespace as a Secret named default-project-template
C.As an annotation on the default ProjectTemplate object in the openshift namespace
D.In the cluster resource project.config.openshift.io/cluster under the projectRequestTemplate field
AnswerD

Configuring the template in the cluster resource project.config.openshift.io/cluster under projectRequestTemplate applies it cluster-wide, satisfying the requirement that every newly created project automatically receives the predefined LimitRange. The ProjectRequest controller reads this cluster-scoped resource when provisioning projects, so the LimitRange is injected without per-project intervention.

Why this answer

The cluster-wide ProjectRequest template is configured by editing the project.config.openshift.io/cluster resource and setting the projectRequestTemplate field to reference a template in the openshift-config namespace. This is the documented, supported mechanism for customizing what every new project receives.

Exam trap

EX280 often tests whether candidates know the template must be referenced from the project.config.openshift.io/cluster CR, not merely created as a ConfigMap — the ConfigMap alone is inert.

How to eliminate wrong answers

Option A is wrong because while the template itself lives in openshift-config, simply creating a ConfigMap named project-request does not wire it into the cluster — the project.config.openshift.io/cluster resource must reference it. Option B is wrong because there is no such Secret-based mechanism in kube-system for project templates. Option C is wrong because annotations on a ProjectTemplate object are not how cluster-wide defaults are applied; the config CR is the authoritative source.

Practice this question →
25
MCQhard

An administrator is troubleshooting a service account named 'cicd-bot' in the 'ci-cd' namespace that is failing to read pods in the 'production' namespace, despite a RoleBinding existing. Upon inspection, the RoleBinding references a Role (not a ClusterRole) in the 'ci-cd' namespace. Why is the service account failing to access resources in 'production'?

A.Standard Roles are namespace-scoped and cannot grant permissions to resources in another namespace
B.Roles cannot reference service accounts as subjects unless they are in the openshift-infra namespace
C.Service accounts cannot use RoleBindings, they require ClusterRoleBindings for any authorization
D.The service account token has expired and must be manually regenerated using oc adm ca
AnswerA

Roles are namespace-scoped, so a Role in 'ci-cd' can only grant access to resources within 'ci-cd'. The RoleBinding therefore cannot extend permissions into 'production', regardless of the subject. To grant cross-namespace access, the binding must reference a ClusterRole combined with a RoleBinding in 'production', or a ClusterRoleBinding.

Why this answer

Roles in OpenShift are namespace-scoped and can only grant permissions to resources within their own namespace. A RoleBinding in the 'ci-cd' namespace referencing a Role in the same namespace cannot grant access to resources in the 'production' namespace. To grant cross-namespace access, a ClusterRole and ClusterRoleBinding (or RoleBinding referencing a ClusterRole) are required.

Exam trap

EX280 often tests the scope of Roles versus ClusterRoles, and candidates may incorrectly assume that a RoleBinding can grant cross-namespace permissions if the Role is defined elsewhere.

How to eliminate wrong answers

Option B is wrong because Roles can reference service accounts as subjects regardless of namespace; the restriction is on the resources, not the subjects. Option C is wrong because service accounts can use RoleBindings for namespace-scoped permissions; ClusterRoleBindings are only needed for cluster-wide access. Option D is wrong because token expiration would cause authentication failure, not authorization failure; the error is about permissions, not token validity.

Practice this question →
26
Multi-Selecthard

An administrator needs to restrict a user group named 'contractors' so they can view pods and services, but cannot view secrets across the 'staging' namespace. Which THREE of the following steps or configurations are valid and necessary to achieve this? (Choose THREE)

Select 3 answers
A.Create a ClusterRoleBinding referencing the view ClusterRole and set an exclusion filter for secrets
B.Create a custom Role in the staging namespace that explicitly includes rules for verbs get, list, watch on resources pods and services
C.Bind the custom Role to the contractors group using a RoleBinding in the staging namespace
D.Assign the cluster-admin ClusterRole to the contractors group with a negative weight annotation
E.Omit 'secrets' from the resources list in the custom Role definition
AnswersB, C, E

A custom Role scoped to the staging namespace grants only get, list and watch on pods and services, satisfying the least-privilege constraint. Because RBAC is additive, omitting secrets from the rules denies access to them, as no ClusterRole binding grants it. A RoleBinding then binds this Role to the contractors group.

Why this answer

Option B is correct because a namespaced Role must explicitly grant the desired permissions, and listing resources pods and services with verbs get, list, watch provides exactly the read-only access required in the staging namespace. Option C is correct because a RoleBinding in the staging namespace binds that Role to the contractors group, scoping the permissions to only that namespace. Option E is correct because RBAC is additive and deny-by-default, so simply not including secrets in the Role's resources list ensures the group cannot view secrets.

Option A is incorrect because ClusterRoleBinding grants cluster-wide permissions and RBAC has no exclusion filter mechanism. Option D is incorrect because there is no negative weight annotation concept in Kubernetes RBAC, and cluster-admin would grant full access.

Exam trap

EX280 often tests the misconception that RBAC supports deny rules or exclusion filters — in reality, RBAC is purely additive, so you must omit resources to restrict access.

Practice this question →
27
MCQmedium

A security audit requires identifying all users who have direct cluster-admin privileges assigned via individual user bindings rather than groups. How can an administrator inspect the cluster-admin ClusterRoleBinding subjects?

A.oc describe clusterrolebinding cluster-admin --users-only
B.oc get users --filter='cluster-admin'
C.oc adm policy list-cluster-admins
D.oc get clusterrolebinding cluster-admin -o jsonpath='{.subjects[*]}'
AnswerD

The jsonpath filter extracts only the subjects array from the cluster-admin ClusterRoleBinding, revealing each User and Group entry. This directly satisfies the audit's need to distinguish individual user bindings from group bindings without parsing full YAML output.

Why this answer

The cluster-admin ClusterRoleBinding object stores its subjects (Users, Groups, ServiceAccounts) in the .subjects array of its JSON representation. Using 'oc get clusterrolebinding cluster-admin -o jsonpath="{.subjects[*]}"' extracts every subject entry, allowing the administrator to enumerate exactly which individual users, groups, and service accounts hold cluster-admin. This is the canonical way to audit direct user bindings versus group-derived bindings.

Exam trap

EX280 often tests whether candidates know the exact oc CLI syntax for RBAC inspection — the trap is inventing plausible-sounding flags like '--users-only' or subcommands like 'list-cluster-admins' that do not exist.

How to eliminate wrong answers

Option A is wrong because 'oc describe' does not support a '--users-only' flag — that flag does not exist in the oc CLI, so the command errors out. Option B is wrong because 'oc get users' lists User objects and has no '--filter' flag for role bindings; it cannot correlate users with cluster-admin privileges. Option C is wrong because 'oc adm policy list-cluster-admins' is not a valid subcommand of 'oc adm policy' — the real subcommands are add-cluster-role-to-user, remove-cluster-role-from-user, etc., so this command fails.

Practice this question →
28
MCQeasy

Which command allows an administrator to view details of a specific project named 'web-app', including its annotations and status?

A.oc inspect project web-app
B.oc describe project web-app
C.oc show project web-app
D.oc get project web-app --details
AnswerB

`oc describe project web-app` queries the Project resource and renders its full human-readable description, including annotations, status phase, and metadata. Unlike `oc get`, which returns raw fields, `describe` aggregates related events and conditions, directly satisfying the stem's requirement to view annotations and status for the named project.

Why this answer

The `oc describe project web-app` command is correct because `oc describe` is the standard OpenShift/Kubernetes subcommand for retrieving detailed, human-readable information about a resource, including its annotations, status, labels, and related events. For a Project resource, this output aggregates metadata such as the project's display name, description, status phase (Active/Terminating), and any annotations. It is the only option that uses a valid `oc` verb (`describe`) to produce the verbose, multi-section output the question requires.

Exam trap

EX280 often tests the distinction between `oc get` (summary output) and `oc describe` (detailed output with annotations and status), and candidates may incorrectly assume a `--details` flag exists for `oc get` or that `inspect`/`show` are valid verbs.

How to eliminate wrong answers

Option A is wrong because `oc inspect` is not a valid `oc` subcommand; there is no `inspect` verb in the OpenShift CLI, so the command would fail with an unknown command error. Option C is wrong because `oc show` does not exist as an `oc` subcommand; while `show` appears in some other tools, it is not part of the `oc` CLI grammar. Option D is wrong because `oc get project web-app --details` is invalid: `--details` is not a supported flag for `oc get` (the correct flag for extra output is `-o wide` or `-o yaml`), and `oc get` alone returns only a summary table, not the full annotations and status details.

Practice this question →
29
MCQmedium

You need to assign the 'cluster-reader' ClusterRole to an LDAP group named 'ldap-auditors' across the entire cluster. Which command accomplishes this?

A.oc set cluster-role cluster-reader --group=ldap-auditors
B.oc adm policy add-role-to-group cluster-reader ldap-auditors --global
C.oc adm policy add-cluster-role-to-group cluster-reader ldap-auditors
D.oc create rolebinding ldap-auditors --clusterrole=cluster-reader --group=ldap-auditors --cluster
AnswerC

`oc adm policy add-cluster-role-to-group` binds the ClusterRole to an LDAP group via a ClusterRoleBinding, granting permissions cluster-wide rather than within a single namespace. This satisfies the stem's requirement to assign `cluster-reader` to `ldap-auditors` across the entire cluster, since the group name maps directly to the identity provider's group claim.

Why this answer

`oc adm policy add-cluster-role-to-group` is the canonical OpenShift command that binds a ClusterRole to a group at the cluster scope, creating a ClusterRoleBinding. Passing 'cluster-reader' as the role and 'ldap-auditors' as the group grants the LDAP group cluster-wide read access.

Exam trap

EX280 often tests the distinction between namespaced RoleBindings and cluster-scoped ClusterRoleBindings, so options using `add-role-to-group` or `create rolebinding` look similar but grant the wrong scope.

How to eliminate wrong answers

Option A is wrong because `oc set cluster-role` is not a valid oc subcommand — `set` manages images, env, resources, etc., not RBAC. Option B is wrong because `add-role-to-group` creates a namespaced RoleBinding, and the `--global` flag is not a valid flag for that command; it would not grant cluster-wide access. Option D is wrong because `oc create rolebinding` creates a namespaced RoleBinding and does not accept a `--cluster` flag; cluster-wide bindings require `oc create clusterrolebinding` or the `oc adm policy` command.

Practice this question →
30
MCQmedium

You need to assign a custom ClusterRole named 'operator-viewer' to all authenticated users cluster-wide. Which command accomplishes this?

A.oc adm policy add-cluster-role-to-group operator-viewer system:authenticated
B.oc adm policy add-cluster-role-to-user operator-viewer --all-users
C.oc set role operator-viewer --cluster --to-all
D.oc create clusterrolebinding all-users --clusterrole=operator-viewer --user=system:everyone
AnswerA

Binding the ClusterRole to the `system:authenticated` group grants it to every authenticated user cluster-wide, satisfying the stem's requirement. `oc adm policy add-cluster-role-to-group` creates a ClusterRoleBinding, which is cluster-scoped, unlike a RoleBinding that would only apply within one namespace.

Why this answer

The command `oc adm policy add-cluster-role-to-group operator-viewer system:authenticated` correctly binds the custom ClusterRole `operator-viewer` to the `system:authenticated` group, which includes all authenticated users cluster-wide. This is the standard OpenShift way to grant a cluster role to a group, and `system:authenticated` is the built-in group automatically assigned to any user who has successfully authenticated. The `add-cluster-role-to-group` subcommand creates a ClusterRoleBinding, ensuring the role applies across all projects and namespaces.

Exam trap

EX280 often tests the distinction between `system:authenticated` and non-existent groups like `system:everyone`, and candidates may incorrectly assume that `--all-users` is a valid flag for `oc adm policy add-cluster-role-to-user`.

How to eliminate wrong answers

Option B is wrong because `oc adm policy add-cluster-role-to-user` does not support an `--all-users` flag; it requires a specific user or `--serviceaccount`, and there is no built-in mechanism to target all users via that subcommand. Option C is wrong because `oc set role` is not a valid command for role bindings; `oc set` is used for modifying resources like environment variables or images, not for policy management. Option D is wrong because `system:everyone` is not a valid user or group in OpenShift; the correct group for all authenticated users is `system:authenticated`, and `system:everyone` does not exist, so the binding would not apply to any real users.

Practice this question →
31
MCQmedium

You need to create a Role that allows reading and writing ConfigMaps and Secrets only within the 'database' project. Which API groups and resource types should be included in the rules?

A.apiGroups: ['rbac.authorization.k8s.io'], resources: ['roles', 'rolebindings'], verbs: ['*']
B.apiGroups: [''], resources: ['configmaps', 'secrets'], verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
C.apiGroups: [''], resources: ['pods/exec'], verbs: ['create']
D.apiGroups: ['apps'], resources: ['configmaps', 'secrets'], verbs: ['*']
AnswerB

ConfigMaps and Secrets belong to the core API group, represented by the empty string `''`, not `apps` or `batch`. Listing them under `apiGroups: ['']` with the required verbs restricts access to those two resource types within the database project.

Why this answer

ConfigMaps and Secrets belong to the core API group, represented as an empty string ('') in RBAC rules. The correct verbs for read and write access are get, list, watch (read) and create, update, patch, delete (write). This Role, when bound within the 'database' project via a RoleBinding, grants the intended permissions.

Exam trap

EX280 often tests whether candidates know that core Kubernetes resources like ConfigMaps and Secrets use an empty string for apiGroups — the trap is selecting a named API group like 'apps' or 'rbac.authorization.k8s.io' out of habit.

How to eliminate wrong answers

Option A is wrong because it targets the rbac.authorization.k8s.io API group and roles/rolebindings resources, which manage RBAC objects, not ConfigMaps or Secrets. Option C is wrong because pods/exec is a subresource of pods used for executing commands in containers, unrelated to ConfigMaps and Secrets. Option D is wrong because ConfigMaps and Secrets are not in the 'apps' API group — that group contains Deployments, StatefulSets, etc.

Practice this question →
32
MCQmedium

A system administrator needs to revoke the 'admin' role from user 'bob' in the 'finance' project without deleting the project or affecting other users. Which command should be used?

A.oc revoke role admin bob --namespace=finance
B.oc delete user bob -n finance
C.oc remove-user bob --project=finance
D.oc adm policy remove-role-from-user admin bob -n finance
AnswerD

`oc adm policy remove-role-from-user` deletes only the named rolebinding entry for bob in the finance namespace, revoking the admin role without touching the project or other users' bindings. The `-n finance` flag scopes the change to that project.

Why this answer

The correct command to revoke a role from a user in a specific project is 'oc adm policy remove-role-from-user admin bob -n finance'. This command removes the role binding that grants the 'admin' role to user 'bob' in the 'finance' namespace, without affecting other users or the project itself.

Exam trap

EX280 often tests the confusion between deleting a user and revoking a role; candidates might think deleting the user is necessary, but that would remove the user entirely, not just the role in one project.

How to eliminate wrong answers

Option A is wrong because 'oc revoke role' is not a valid OpenShift command; the correct subcommand is 'oc adm policy remove-role-from-user'. Option B is wrong because 'oc delete user bob' would delete the user entirely from the cluster, which is not desired and would affect all projects. Option C is wrong because 'oc remove-user' is not a valid command; the correct approach is to remove the role binding, not the user from the project.

Practice this question →
33
MCQhard

A cluster administrator notices that a user 'bob' is unable to create new projects using the 'oc new-project' command, even though bob can view existing projects. What is the root cause and standard remediation?

A.bob needs an explicit RoleBinding for the 'admin' role in the default namespace
B.bob's user object is missing the 'project-creator' annotation
C.bob lacks the 'self-provisioner' cluster role, which can be granted via cluster-admin binding
D.bob must be added to the cluster-admin group in the oauth configuration
AnswerC

Granting bob the `self-provisioner` cluster role restores his ability to create projects, since OpenShift's project request API authorises creation through that role rather than ordinary namespace write access. A cluster-admin must bind it, typically via `oc adm policy add-cluster-role-to-user self-provisioner bob`, satisfying the stem's remediation requirement.

Why this answer

In OpenShift, the ability for authenticated users to create their own projects is controlled by the 'self-provisioner' ClusterRole, bound via the 'self-provisioners' ClusterRoleBinding to the 'system:authenticated' group by default. If an administrator removes or restricts this binding, users like bob lose the ability to run 'oc new-project' even though they can still view existing projects.

Exam trap

EX280 often tests whether candidates know that project self-provisioning is controlled by the 'self-provisioner' ClusterRole and its binding, not by namespace-level RoleBindings or user annotations.

How to eliminate wrong answers

Option A is wrong because a RoleBinding to 'admin' in the default namespace only grants namespace-scoped permissions there; it does not enable cluster-level project creation. Option B is wrong because there is no 'project-creator' annotation on user objects — project creation is governed by RBAC, not annotations. Option D is wrong because adding bob to cluster-admin would grant far more privilege than needed and is not the standard remediation; the correct fix is restoring the self-provisioner binding.

Practice this question →
34
MCQeasy

Which command is used to switch the active project context to a namespace named 'staging' in the OpenShift CLI?

A.oc config set-namespace staging
B.oc project staging
C.oc use project staging
D.oc switch-context staging
AnswerB

`oc project staging` changes the active namespace in your kubeconfig context, so subsequent `oc` commands target the staging namespace without repeated `-n` flags. This directly satisfies the stem's requirement to switch project context, since OpenShift projects map one-to-one onto Kubernetes namespaces.

Why this answer

The `oc project <name>` command is the documented OpenShift CLI method for switching the active project (namespace) context for subsequent commands. It updates the current context in the kubeconfig so that all future `oc` commands target the 'staging' namespace without needing `-n staging`. This is functionally equivalent to `oc config set-context --current --namespace=staging` but is the idiomatic OpenShift shortcut.

Exam trap

EX280 often tests whether candidates confuse the OpenShift-specific `oc project` shortcut with generic kubectl-style `oc config` subcommands, so options like `oc config set-namespace` look plausible but do not exist.

How to eliminate wrong answers

Option A is wrong because `oc config set-namespace` is not a valid subcommand — the correct form is `oc config set-context --current --namespace=<name>`. Option C is wrong because `oc use project` is not a real oc command; `use` is not an oc verb. Option D is wrong because `oc switch-context` does not exist; context switching is done via `oc config use-context` or `oc project`.

Practice this question →
35
MCQhard

An administrator creates a new project request template that includes a custom RoleBinding. However, when users create new projects, the RoleBinding fails to bind because it references a ClusterRole that does not exist in the template namespace. How are ClusterRoles referenced in project templates resolved?

A.ClusterRoles must be defined inside the same project request template YAML file.
B.ClusterRoles must be created cluster-wide prior to template instantiation because RoleBindings within the template reference them.
C.Project request templates do not support RoleBindings; only ResourceQuotas are allowed.
D.The RoleBinding must use a Namespaced Role instead of a ClusterRole.
AnswerB

ClusterRoles are cluster-scoped resources, so a RoleBinding inside a project template can only reference one that already exists cluster-wide. The template's namespace-scoped RoleBinding cannot create or resolve a missing ClusterRole, so the referenced ClusterRole must pre-exist before instantiation to satisfy the binding.

Why this answer

RoleBindings inside a project request template reference ClusterRoles by name, and those ClusterRoles must already exist cluster-wide before the template is instantiated. The template does not embed or create ClusterRoles; it only creates namespaced resources in the new project. If the referenced ClusterRole is missing, the RoleBinding fails to bind.

Exam trap

EX280 often tests the scope distinction between namespaced and cluster-scoped resources — candidates forget that ClusterRoles cannot be defined inside a namespaced project template and must pre-exist cluster-wide.

How to eliminate wrong answers

Option A is wrong because project request templates create namespaced objects in the new project — they cannot define cluster-scoped ClusterRoles inside the template YAML. Option C is wrong because project request templates do support RoleBindings (and RoleBindings referencing ClusterRoles) in addition to ResourceQuotas and LimitRanges. Option D is wrong because the issue is not the use of a ClusterRole — ClusterRoles are the correct, intended reference for shared permissions; the problem is that the ClusterRole does not exist yet.

Practice this question →
36
Multi-Selecteasy

Which THREE of the following commands are valid OpenShift CLI commands for managing user policies and role assignments? (Choose THREE)

Select 3 answers
A.oc user modify-role
B.oc set policy-binding
C.oc adm policy add-role-to-user
D.oc adm policy remove-role-from-user
E.oc adm policy add-cluster-role-to-group
AnswersC, D, E

add-role-to-user binds a ClusterRole or local Role to a user within a namespace, creating a RoleBinding. It is a valid oc adm policy subcommand for granting role assignments, satisfying the requirement to manage user policies via the CLI.

Why this answer

Option C, `oc adm policy add-role-to-user`, is correct because it is the standard administrative command for binding a role to a user within a specific project namespace, granting that user the permissions defined by the role. Option D, `oc adm policy remove-role-from-user`, is correct because it is the counterpart command that removes an existing role binding from a user in a project, revoking those permissions. Option E, `oc adm policy add-cluster-role-to-group`, is correct because it binds a ClusterRole to a group at the cluster scope, which is the proper way to grant cluster-wide permissions to multiple users at once.

Option A, `oc user modify-role`, is not a valid OpenShift CLI command; user objects are managed with commands like `oc adm policy` or `oc create user`, and there is no `modify-role` subcommand. Option B, `oc set policy-binding`, is also invalid; the `oc set` command manages resources like env, image, and resources, not policy bindings, which are handled exclusively through `oc adm policy`.

Exam trap

EX280 often tests whether candidates can distinguish real `oc adm policy` subcommands from plausible-sounding but nonexistent commands like `oc user modify-role` or `oc set policy-binding` — memorizing the `oc adm policy` verb set is essential.

Practice this question →
37
Multi-Selecthard

Which TWO of the following conditions must be met for a ServiceAccount from 'namespace-a' to successfully access API resources in 'namespace-b'? (Choose TWO)

Select 2 answers
A.The source namespace must disable its LimitRange objects.
B.An administrative override annotation must be placed on the target namespace.
C.A RoleBinding must exist in 'namespace-b' referencing the ServiceAccount as 'system:serviceaccount:namespace-a:sa-name'.
D.The ServiceAccount must be granted cluster-admin rights cluster-wide.
E.A Role or ClusterRole must grant the necessary API verb permissions.
AnswersC, E

A RoleBinding in 'namespace-b' grants permissions within that namespace only, satisfying the cross-namespace access constraint. Referencing the ServiceAccount as 'system:serviceaccount:namespace-a:sa-name' correctly identifies the subject from the foreign namespace, since RoleBindings can bind subjects from any namespace while their Role's permissions remain scoped to their own namespace.

Why this answer

Option C is correct because Kubernetes RBAC bindings are namespaced: to grant a ServiceAccount from namespace-a permissions in namespace-b, a RoleBinding must be created in namespace-b that references the subject as 'system:serviceaccount:namespace-a:sa-name'. Option E is correct because the RoleBinding only associates the subject with permissions; the actual API verb permissions (get, list, watch, create, etc.) on the target resources must be defined in a Role (namespaced) or ClusterRole that the binding references. Option A is incorrect because LimitRange objects only enforce resource quota defaults/limits on pods and containers and have no bearing on RBAC authorization.

Option B is incorrect because Kubernetes RBAC has no 'administrative override annotation' mechanism for namespaces; access is governed solely by Roles/ClusterRoles and their bindings. Option D is incorrect because cluster-admin is not required and would be excessive; a namespaced Role plus RoleBinding in namespace-b is sufficient and follows least privilege.

Exam trap

EX280 often tests the misconception that cross-namespace access requires cluster-admin or a special annotation, when in fact it is achieved with a namespaced RoleBinding referencing the fully qualified ServiceAccount name plus a Role granting the verbs.

Practice this question →
38
MCQhard

An OpenShift cluster integrates with an LDAP server where user attribute names differ from default settings (e.g., mail instead of preferredUsername). Where are these LDAP attribute mappings configured?

A.In the kube-apiserver ConfigMap under LDAP settings
B.In the GroupSync CRD resource settings
C.In the LDAP identity provider specification under the 'attributes' mapping fields
D.In the project request template annotations
AnswerC

LDAP attribute mappings belong in the identity provider's `attributes` section, where `id`, `preferredUsername`, `name` and `email` each map to a specific LDAP attribute. Defining `preferredUsername: mail` satisfies the stem's non-default naming constraint, since OpenShift reads these mappings directly from the OAuth identity provider configuration.

Why this answer

LDAP attribute mappings are configured in the LDAP identity provider specification under the `attributes` field. This section maps LDAP attributes (e.g., mail, uid) to OpenShift identity attributes like preferredUsername, name, and email. Administrators edit the OAuth custom resource to set these mappings.

Exam trap

EX280 often tests the location of LDAP attribute mappings, causing candidates to confuse it with GroupSync or kube-apiserver configuration.

How to eliminate wrong answers

Option A is wrong because the kube-apiserver ConfigMap does not contain LDAP settings; LDAP is configured in the OAuth server configuration. Option B is wrong because GroupSync CRD is for synchronizing groups, not for mapping user attributes. Option D is wrong because project request template annotations are for project metadata, not identity provider attribute mapping.

Practice this question →
39
Multi-Selectmedium

Which TWO of the following statements regarding OpenShift Projects and Namespaces are correct? (Choose TWO)

Select 2 answers
A.A single namespace can contain multiple distinct OpenShift projects.
B.Namespaces created via 'oc create namespace' automatically instantiate project request templates.
C.Every Project in OpenShift has a corresponding underlying Kubernetes Namespace.
D.Projects can be nested hierarchically within other projects.
E.A Project is a Kubernetes Namespace with additional OpenShift annotations and management capabilities.
AnswersC, E

OpenShift Projects are a wrapper around Kubernetes Namespaces, so each Project always maps one-to-one to an underlying Namespace. This satisfies the stem's requirement for a correct statement: the Project adds annotations, RBAC and quota management on top, but the Namespace itself remains the actual cluster-scoped resource.

Why this answer

Option C is correct because OpenShift Projects are implemented as an abstraction layer over Kubernetes Namespaces: every Project object has a 1:1 relationship with an underlying Namespace of the same name, which is where the actual workloads and resources reside. Option E is correct because a Project is essentially a Kubernetes Namespace enriched with OpenShift-specific annotations (such as openshift.io/display-name, openshift.io/requester, and openshift.io/sa.scc.*) plus additional management features like project request templates, self-provisioning, and role bindings. Option A is incorrect because the relationship is one-to-one, not one-to-many: a single Namespace maps to exactly one Project, and a Project cannot span multiple Namespaces.

Option B is incorrect because project request templates are applied when a user creates a Project via 'oc new-project' or the web console's project request flow, not when a Namespace is created directly with 'oc create namespace', which bypasses the ProjectRequest API. Option D is incorrect because Projects and Namespaces are flat, non-hierarchical constructs; OpenShift does not support nesting Projects within other Projects.

Exam trap

EX280 often tests the misconception that `oc create namespace` and `oc new-project` are interchangeable — they are not, because only the latter invokes the project request template and OpenShift-specific annotations.

Practice this question →
40
MCQhard

An administrator needs to ensure that no pod in the 'secure-zone' namespace can run with root privileges or use host networking. Which mechanism natively enforces this across all pods in the namespace?

A.Setting container securityContext in every deployment manually
B.Assigning a restrictive SecurityContextConstraints (SCC) policy to the service accounts running the pods
C.Configuring a NetworkPolicy to block root network namespaces
D.ResourceQuota limits on security capabilities
AnswerB

SCCs are the native OpenShift admission mechanism that validates pod security context against assigned policy before creation. A restrictive SCC bound to the namespace's service accounts blocks root UID, privileged mode and hostNetwork cluster-wide within that namespace.

Why this answer

SecurityContextConstraints (SCCs) are OpenShift's native cluster-level policy objects that control pod security settings such as running as root, host networking, and volume types. Assigning a restrictive SCC to the service accounts used by pods in the namespace enforces these restrictions across all pods.

Exam trap

EX280 often tests the misconception that NetworkPolicy or ResourceQuota can enforce pod security, when only SCCs (or Pod Security Admission in newer versions) control root and host networking.

How to eliminate wrong answers

Option A is wrong because manually setting securityContext in each deployment is not a namespace-wide enforcement mechanism and can be bypassed or forgotten. Option C is wrong because NetworkPolicy controls network traffic, not pod security contexts or host networking privileges. Option D is wrong because ResourceQuota limits resource consumption (CPU, memory, object counts), not security capabilities.

Practice this question →
41
MCQeasy

Which command allows an administrator to view all currently configured SecurityContextConstraints in an OpenShift cluster?

A.oc describe scc-cluster
B.oc get securitycontextconstraints
C.oc get scc --namespaced
D.oc get policies -n openshift-config
AnswerB

`oc get securitycontextconstraints` queries the cluster's SCC API resource directly, returning every SecurityContextConstraints object currently defined. It satisfies the stem's requirement to view all configured SCCs without filtering or describing a single instance. The plural resource name ensures the full cluster-wide list is displayed.

Why this answer

SecurityContextConstraints (SCCs) are cluster-scoped resources in OpenShift, so they are queried with the standard 'oc get' verb using the resource name 'securitycontextconstraints' (or its short form 'scc'). The command 'oc get securitycontextconstraints' returns the list of all SCCs currently defined in the cluster, such as restricted, anyuid, hostaccess, and privileged. Because SCCs are not namespaced, no -n flag is required or meaningful.

Exam trap

EX280 often tests whether candidates confuse cluster-scoped resources (SCCs, PVs, nodes, clusterroles) with namespaced ones, tricking them into adding -n or --namespaced flags that don't apply.

How to eliminate wrong answers

Option A is wrong because 'scc-cluster' is not a valid resource type or SCC name — 'oc describe' requires an existing resource, and no SCC called 'scc-cluster' exists by default. Option C is wrong because SCCs are cluster-scoped resources and do not support the '--namespaced' flag; that flag would produce an error or be ignored. Option D is wrong because 'policies' is not the resource type for SCCs, and SCCs do not live in the openshift-config namespace — they are cluster-scoped.

Practice this question →
42
MCQhard

An OpenShift administrator needs to restrict developers so they cannot delete any PersistentVolumeClaims in the 'finance-prod' namespace, even though they have the 'admin' role. How can this override be achieved?

A.Add a negative annotation to the user's account object.
B.Configure a LimitRange object with delete blocks.
C.Create a DenyRoleBinding specifying delete verb exclusion for persistentvolumeclaims.
D.Create a custom Role that omits the 'delete' verb for persistentvolumeclaims, remove the 'admin' role binding, and bind this custom Role instead.
AnswerD

Replacing the built-in 'admin' ClusterRole binding with a custom Role that omits the delete verb on persistentvolumeclaims directly removes the permission, since OpenShift RBAC is additive and no other binding grants it. This satisfies the requirement that developers cannot delete PVCs in finance-prod despite previously holding admin.

Why this answer

To prevent deletion of PVCs despite the 'admin' role, you must remove the role binding that grants the admin role and instead bind a custom Role that includes all necessary permissions except the 'delete' verb for persistentvolumeclaims. This effectively overrides the default admin permissions by not granting delete rights.

Exam trap

EX280 often tests the misconception that RBAC supports deny rules or negative permissions; candidates may look for a DenyRoleBinding or annotation, but OpenShift only allows additive permissions.

How to eliminate wrong answers

Option A is wrong because there is no such thing as a negative annotation on a user account to deny specific verbs; OpenShift RBAC is additive and does not support deny rules. Option B is wrong because LimitRange objects enforce resource constraints, not API access controls. Option C is wrong because there is no DenyRoleBinding object in Kubernetes/OpenShift; RBAC only allows allow rules, and you cannot specify verb exclusions in a binding.

Practice this question →
43
MCQhard

An administrator configures an OAuth provider with user mapping method 'lookup'. What does this mapping method do when a user authenticates for the first time?

A.It rejects all login attempts unless the user is member of the 'system:masters' group.
B.It requires that a User object already exists and is pre-associated with the identity; otherwise, login fails.
C.It automatically creates a new User object and links it to the incoming Identity.
D.It maps all incoming users to a single shared service account.
AnswerB

The 'lookup' mapping method performs no provisioning: it searches for an existing User object already linked to the incoming identity and authenticates against it. If no pre-associated User exists, authentication fails, satisfying the stem's first-login scenario where no automatic account creation occurs.

Why this answer

The 'lookup' mapping method in OpenShift's OAuth configuration requires that a User object already exists and is pre-associated with the incoming Identity. When a user authenticates for the first time, the OAuth server checks if an Identity exists for the provider's user ID; if not, it attempts to find a User with that identity. If no such User exists, login fails.

This is in contrast to the 'claim' method, which dynamically creates User and Identity objects based on claims from the identity provider.

Exam trap

EX280 often tests the distinction between OAuth mapping methods, particularly confusing 'lookup' with 'claim', where 'claim' auto-creates users while 'lookup' requires pre-existing User objects.

How to eliminate wrong answers

Option A is wrong because 'lookup' does not enforce membership in 'system:masters'; that group is for cluster administrators and is unrelated to the mapping method. Option C is wrong because automatic creation of a new User object and linking it to the Identity is the behavior of the 'claim' mapping method, not 'lookup'. Option D is wrong because mapping all users to a single shared service account is not a supported mapping method; it would be a severe security risk and is not how OpenShift OAuth works.

Practice this question →
44
MCQmedium

You are configuring an OAuth identity provider in OpenShift using the HTPasswdPasswordIdentityProvider method. Where must the generated htpasswd user credentials file be stored so the cluster authentication operator can read it?

A.In the 'openshift-authentication' namespace as a ConfigMap
B.In the target user's project namespace as a Secret
C.In the 'openshift-config' namespace as a Secret
D.On the master node filesystem at '/etc/origin/master/htpasswd'
AnswerC

The OAuth authentication operator reads identity provider configuration only from the openshift-config namespace, so the htpasswd file must exist there as a Secret. Storing it elsewhere, such as openshift-config-managed or a user project, prevents the operator from resolving the HTPasswd identity provider.

Why this answer

In OpenShift 4, the OAuth configuration is defined in the cluster-scoped OAuth custom resource, and any referenced identity provider secrets must live in the openshift-config namespace. The authentication operator watches this namespace and mounts the referenced Secret into the openshift-authentication pods. Therefore, the htpasswd file must be uploaded as a Secret in openshift-config and referenced via the htpasswd.fileData.name field.

Exam trap

EX280 often tests the OpenShift 3 vs OpenShift 4 configuration model, so candidates who remember the old /etc/origin/master/htpasswd path or assume any namespace works will pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because openshift-authentication is where the OAuth server pods run, not where identity provider secrets are stored; ConfigMaps are also not used for htpasswd data. Option B is wrong because user project namespaces are not watched by the authentication operator and cannot supply cluster-wide identity provider credentials. Option D is wrong because /etc/origin/master/htpasswd is the OpenShift 3.x path on master nodes; OpenShift 4 is operator-managed and does not use that filesystem location.

Practice this question →
45
Multi-Selecthard

Which TWO of the following actions occur when a user is deleted from an OpenShift cluster using 'oc delete user <username>'? (Choose TWO)

Select 2 answers
A.The User resource object is removed from the cluster database.
B.External identity provider records are automatically deleted from LDAP or OIDC servers.
C.All namespaces owned or created by the user are permanently deleted.
D.The user's active OAuth access and refresh tokens are revoked.
E.All RoleBindings and ClusterRoleBindings referencing the user are automatically deleted.
AnswersA, D

Deleting a User resource removes only that object from etcd; the identity provider entry and any Identity objects linked to it remain untouched. This satisfies the stem's constraint that the action targets the cluster's User object specifically, since `oc delete user` never reaches external identity stores or automatically prunes associated Identity records.

Why this answer

Option A is correct because 'oc delete user <username>' removes the User resource object itself from etcd, the cluster's backing datastore, so the user no longer exists as an OpenShift API object. Option D is correct because deleting the User triggers revocation of that user's OAuth access tokens and refresh tokens, invalidating existing sessions so the identity can no longer authenticate. Option B is wrong because OpenShift does not write back to external identity providers; LDAP or OIDC records are managed outside the cluster and are untouched.

Option C is wrong because namespaces are independent resources and are not garbage-collected when a user is deleted. Option E is wrong because RoleBindings and ClusterRoleBindings are not automatically removed; they may remain and reference a now-nonexistent user until manually cleaned up.

Exam trap

EX280 often tests the misconception that deleting a User cascades to external IdP accounts, namespaces, or RBAC bindings — candidates must remember that User deletion only removes the cluster-side User object and its OAuth tokens.

Practice this question →
46
MCQeasy

An administrator needs to provision a new user named 'sarah' using the HTPasswd identity provider. After updating the htpasswd file and secret, Sarah logs in successfully. What command should the administrator run to verify that OpenShift has successfully created the corresponding User object for Sarah?

A.oc get account sarah
B.oc get user sarah
C.oc get identity htp:sarah
D.oc describe htpasswd-user sarah
AnswerB

Running `oc get user sarah` queries the cluster's User resource directly, confirming that the HTPasswd identity provider's successful login triggered automatic User object creation. This satisfies the stem's verification requirement precisely, since the User object is the artefact OpenShift generates on first authentication, not the Identity or Secret.

Why this answer

When an HTPasswd identity provider authenticates a user for the first time, OpenShift automatically creates a User object whose name matches the username supplied in the htpasswd file. The correct command to confirm this is `oc get user sarah`, which queries the cluster-scoped User resource. This verifies that the identity provider successfully mapped the login to a User object.

Exam trap

EX280 often tests the distinction between Identity and User objects in OpenShift's authentication model, causing candidates to pick `oc get identity` when the question specifically asks about the User object.

How to eliminate wrong answers

Option A is wrong because 'account' is not a valid OpenShift resource type — there is no `oc get account` command. Option C is wrong because `oc get identity htp:sarah` would list the Identity object (named with the provider prefix 'htp:'), not the User object the question asks about. Option D is wrong because 'htpasswd-user' is not a real OpenShift resource kind, so the command would fail.

Practice this question →
47
Multi-Selecthard

Which THREE of the following fields are required when defining a custom Role or ClusterRole resource YAML? (Choose THREE)

Select 3 answers
A.namespace
B.apiVersion
C.subjects
D.rules
E.kind
AnswersB, D, E

Every Role or ClusterRole manifest requires apiVersion to select the correct RBAC API group and version, here rbac.authorization.k8s.io/v1. Without it, the API server cannot decode the resource, so the field is mandatory alongside kind and metadata.

Why this answer

Option B (apiVersion) is required because every Kubernetes manifest must declare the API group/version, and for RBAC roles this is rbac.authorization.k8s.io/v1. Option E (kind) is required because the manifest must specify whether the object is a Role or a ClusterRole. Option D (rules) is required because rules define the actual permissions (apiGroups, resources, verbs) that the Role or ClusterRole grants.

Option A (namespace) is not required: a Role's namespace is set in metadata.namespace (or defaults to the current context), and a ClusterRole is cluster-scoped and has no namespace at all. Option C (subjects) is not required for a Role or ClusterRole; subjects belong to a RoleBinding or ClusterRoleBinding, which associates the role with users, groups, or service accounts.

Exam trap

EX280 often tests whether candidates confuse Role/ClusterRole fields with RoleBinding/ClusterRoleBinding fields — the trap is including 'subjects' in a Role definition or expecting a 'namespace' field in the spec.

Practice this question →
48
MCQmedium

A platform administrator is auditing RBAC in the 'payments' namespace. They notice that the group 'contractors' can list and get secrets in that namespace, but the administrators never created a RoleBinding or ClusterRoleBinding granting those permissions. Which mechanism most likely granted this access?

A.The ServiceAccount of the kube-controller-manager reconciles missing RoleBindings by copying them from the 'default' namespace.
B.A ClusterRoleBinding to a default cluster role such as 'view' or 'edit' grants the group access across all namespaces, including 'payments'.
C.A RoleBinding was automatically created by the OpenShift OAuth server when the group first authenticated.
D.The 'system:authenticated' group is implicitly bound to 'cluster-admin' in every namespace for convenience.
AnswerB

ClusterRoleBindings apply cluster-wide, so binding the group 'contractors' to a default aggregated role like 'view' or 'edit' grants its permissions inside every project, including 'payments'. This explains how the group can list and get secrets without any namespace-scoped RoleBinding existing in that namespace.

Why this answer

Because ClusterRoleBindings are cluster-scoped, binding a group to an aggregated role such as 'view' or 'edit' gives that group the role's rules in every namespace. Auditing only namespace-scoped RoleBindings will miss this, which is why the group can read secrets in 'payments' without any local binding. Checking cluster-scoped bindings is essential during RBAC audits.

Exam trap

The trap here is assuming that missing RoleBindings in a namespace mean no access exists, while forgetting that ClusterRoleBindings silently grant the same permissions cluster-wide.

Practice this question →
49
Multi-Selectmedium

Which THREE of the following are valid parameters that can be specified in a LimitRange object specification? (Choose THREE)

Select 3 answers
A.max
B.replicas
C.defaultRequest
D.min
E.clusterWideAccess
AnswersA, C, D

`max` caps the maximum compute resources a container or pod may request or consume within the namespace, enforced by the LimitRange admission controller at creation time. It satisfies the stem's requirement for a valid LimitRange spec parameter, sitting alongside `min`, `maxLimitRequestRatio` and `defaultRequest`.

Why this answer

In a Kubernetes LimitRange spec, the max field (option A) sets the maximum compute resource limits (e.g., cpu, memory) that a container or Pod may request/limit within the namespace, so it is a valid parameter. The defaultRequest field (option C) specifies the default resource requests applied to containers that do not declare their own requests, making it a valid LimitRange parameter. The min field (option D) defines the minimum resource requests/limits a container or Pod must specify, and is also a valid LimitRange parameter.

Option B (replicas) is not part of LimitRange; replica counts belong to workload controllers such as Deployments or ReplicaSets. Option E (clusterWideAccess) is not a LimitRange field; it is unrelated to resource governance and resembles a storage or access setting rather than a LimitRange parameter.

Exam trap

EX280 often tests whether candidates confuse LimitRange fields (max, min, default, defaultRequest, maxLimitRequestRatio) with ResourceQuota fields (requests.cpu, limits.memory, pods, etc.) or workload fields like replicas.

Practice this question →
50
MCQmedium

You need to inspect the effective permissions of a service account named 'cicd-bot' in the 'ci-cd' namespace to see if it can list deployments. Which command should you run?

A.oc auth can-i list deployments --as=system:serviceaccount:ci-cd:cicd-bot -n ci-cd
B.oc adm policy who-can get deployments -n ci-cd
C.oc describe serviceaccount cicd-bot -n ci-cd
D.oc get rolebindings --serviceaccount=cicd-bot
AnswerA

The --as flag performs user impersonation, letting you evaluate RBAC as the service account system:serviceaccount:ci-cd:cicd-bot. Combined with -n ci-cd, this tests whether that account can list deployments in its own namespace, satisfying the effective-permissions check.

Why this answer

`oc auth can-i` performs a SubjectAccessReview against the OpenShift API server, and the `--as=system:serviceaccount:<namespace>:<name>` flag impersonates the service account so the answer reflects that SA's effective RBAC permissions rather than the current user's. Adding `-n ci-cd` scopes the check to the ci-cd namespace, which is required because RoleBindings are namespace-scoped. This is the canonical way to verify whether a specific SA can perform a verb on a resource.

Exam trap

EX280 often tests whether candidates confuse inspecting a service account's metadata (`oc describe sa`) with actually evaluating its effective RBAC permissions — only `oc auth can-i --as=system:serviceaccount:...` performs a real authorization check.

How to eliminate wrong answers

Option B is wrong because `oc adm policy who-can get deployments` only lists which users/groups/SAs can perform the verb — it does not impersonate a specific service account, and it also asks about `get` rather than `list`, which are distinct RBAC verbs. Option C is wrong because `oc describe serviceaccount` only shows the SA's secrets, image pull secrets, and tokens — it does not enumerate the roles or permissions bound to the SA. Option D is wrong because `oc get rolebindings --serviceaccount=cicd-bot` is not a valid flag for that subcommand and would not resolve the effective permission anyway; rolebindings must be inspected individually and then correlated with roles.

Practice this question →
51
MCQmedium

An administrator wants to prevent non-admin users from creating any new projects in the OpenShift cluster. How can this be accomplished?

A.Set the project request limit quota to zero globally.
B.Delete the 'cluster-admin' role from all users.
C.Delete the 'self-provisioner' ClusterRoleBinding attached to the 'system:authenticated' group.
D.Modify the OAuth configuration to reject all login requests.
AnswerC

Removing the self-provisioner ClusterRoleBinding from system:authenticated strips the cluster-wide permission that lets any authenticated user create projects, satisfying the constraint of blocking all non-admin project creation. Administrators retain access through their own bindings, so no legitimate admin capability is lost.

Why this answer

The ability for authenticated users to create projects is granted by the self-provisioner ClusterRole, which is bound to the system:authenticated group via a ClusterRoleBinding. Removing that binding revokes the self-provisioner capability cluster-wide, preventing non-admin users from creating new projects. This is the standard OpenShift method to disable self-provisioning.

Exam trap

EX280 often tests the specific ClusterRoleBinding that enables self-provisioning, and candidates may confuse it with quota or OAuth settings.

How to eliminate wrong answers

Option A is wrong because project request limits are not a global quota setting; quotas apply to resources within projects, not project creation itself. Option B is wrong because deleting the cluster-admin role from users does not specifically prevent project creation and would have broader, unintended consequences. Option D is wrong because modifying OAuth to reject logins would block all authentication, not just project creation, and is overly drastic.

Practice this question →
52
Multi-Selectmedium

Which THREE of the following are valid identity provider types supported natively in OpenShift Container Platform? (Choose THREE)

Select 3 answers
A.ActiveDirectoryDirectIdentityProvider
B.LocalDatabaseIdentityProvider
C.OpenIDConnectIdentityProvider
D.LDAPPasswordIdentityProvider
E.HTPasswdPasswordIdentityProvider
AnswersC, D, E

OpenIDConnectIdentityProvider is a native OpenShift identity provider type, configured via an OAuth custom resource. It authenticates users against an external OIDC issuer, making it one of the valid provider kinds alongside HTPasswd, LDAP and others.

Why this answer

Option C, OpenIDConnectIdentityProvider, is correct because OpenShift Container Platform natively supports OpenID Connect (OIDC) as an identity provider type, allowing integration with OIDC-compliant providers such as Keycloak or Google. Option D, LDAPPasswordIdentityProvider, is correct because OCP natively supports LDAP-based authentication via the LDAPPasswordIdentityProvider, which validates credentials against an LDAP directory using a bind operation. Option E, HTPasswdPasswordIdentityProvider, is correct because OCP natively supports the HTPasswdPasswordIdentityProvider, which validates usernames and passwords against a flat file generated by htpasswd.

Option A, ActiveDirectoryDirectIdentityProvider, is not a valid native provider type; Active Directory is integrated through the LDAP identity provider rather than a dedicated Active Directory provider. Option B, LocalDatabaseIdentityProvider, is not a valid native provider type; OCP does not provide a built-in local user database identity provider.

Exam trap

EX280 often tests whether candidates can distinguish real OpenShift identity provider type names from plausible-sounding fabrications like 'ActiveDirectoryDirectIdentityProvider' or 'LocalDatabaseIdentityProvider' that do not exist in the API schema.

Practice this question →
53
MCQeasy

An administrator wants to prevent developers from accidentally deploying containers that request excessive CPU resources in the 'analytics' namespace. Which object should the administrator create in that namespace?

A.ResourceQuota
B.ClusterRoleBinding
C.SecurityContextConstraints
D.LimitRange
AnswerD

A LimitRange enforces per-container minimum and maximum CPU and memory requests and limits at admission time within a namespace. Creating one in 'analytics' rejects any pod whose CPU request exceeds the configured ceiling, directly preventing developers from accidentally deploying over-resourced containers.

Why this answer

A LimitRange constrains per-pod or per-container resource requests and limits within a namespace, which is exactly what prevents a developer from submitting a pod that requests excessive CPU. It can set default, min, and max values for CPU/memory per container or pod, and the API server rejects any pod spec that violates those bounds. This is the correct object for per-object resource guardrails.

Exam trap

EX280 often tests the distinction between LimitRange (per-pod/container bounds) and ResourceQuota (namespace aggregate) — candidates pick ResourceQuota because it sounds like the resource-control object, but it does not stop a single oversized pod.

How to eliminate wrong answers

Option A is wrong because ResourceQuota caps aggregate namespace consumption (total CPU/memory across all pods), not the per-container request of a single pod — a single oversized pod could still be admitted if the namespace total is under quota. Option B is wrong because ClusterRoleBinding grants cluster-wide RBAC permissions and has nothing to do with resource sizing. Option C is wrong because SecurityContextConstraints govern pod security (SELinux, runAsUser, capabilities, volumes), not CPU/memory limits.

Practice this question →
54
Multi-Selecthard

Which TWO of the following steps are required when configuring an HTPasswd identity provider in OpenShift? (Choose TWO)

Select 2 answers
A.Create a ClusterRoleBinding for all users in the htpasswd file.
B.Place the htpasswd file directly on every control plane node at '/etc/origin/master/'.
C.Restart the kube-apiserver static pods manually across all masters.
D.Create a Secret containing the htpasswd file in the 'openshift-config' namespace.
E.Update the cluster OAuth configuration resource to reference the HTPasswd identity provider and Secret.
AnswersD, E

Creating the htpasswd Secret in the `openshift-config` namespace satisfies OpenShift's requirement that OAuth identity provider secrets reside there for the cluster OAuth server to consume. The `oauth` resource references this Secret by name, so the file must exist in that namespace before the identity provider can authenticate users.

Why this answer

Option D is correct because OpenShift requires the htpasswd file to be stored as a Secret in the 'openshift-config' namespace, which the OAuth server mounts and reads; the file cannot be referenced from an arbitrary path on the nodes. Option E is correct because after creating the Secret you must edit the cluster-scoped OAuth custom resource (oc edit oauth cluster) to add an identityProviders entry of type HTPasswd that references that Secret by name, which triggers the OAuth server to reconfigure. Option A is not required: HTPasswd users are not automatically granted any cluster role, and creating a ClusterRoleBinding for all users is an optional authorization step, not part of identity provider configuration.

Option B is incorrect because the htpasswd file is not placed directly on control plane nodes at '/etc/origin/master/'; that legacy path is not how modern OpenShift consumes the file. Option C is incorrect because you do not manually restart kube-apiserver static pods; the OAuth server (an operator-managed deployment) redeploys automatically when the OAuth configuration changes.

Exam trap

EX280 often tests the misconception that OpenShift 4 still uses the OpenShift 3 file-based htpasswd path or requires manual pod restarts, when the correct approach is a Secret plus OAuth CR update.

Practice this question →
55
MCQhard

An administrator configured an LDAP identity provider in OpenShift, but users report authentication failures. Upon checking the cluster logs, you find errors indicating that the bind DN password secret is missing or incorrect. Where must this bind password be stored?

A.In the 'openshift-config' namespace as a Secret referenced by the OAuth configuration
B.On each worker node at '/etc/origin/master/ldap.pass'
C.As an environment variable on the oauth-openshift deployment
D.In the 'openshift-authentication' namespace as a ConfigMap
AnswerA

The LDAP bind password must live in a Secret within the openshift-config namespace and be referenced by name in the OAuth configuration's identity provider stanza. The authentication operator reads only that namespace, so a missing or misplaced Secret produces the bind DN errors observed.

Why this answer

When configuring an LDAP identity provider in OpenShift, the bind DN password must be stored as a Secret in the 'openshift-config' namespace and referenced in the OAuth configuration. This is the required location for sensitive credentials used by the OAuth server to authenticate against LDAP.

Exam trap

EX280 often tests the location of the LDAP bind password Secret; candidates may incorrectly choose a ConfigMap or a different namespace, confusing sensitive and non-sensitive configuration storage.

How to eliminate wrong answers

Option B is wrong because storing the password on worker nodes is insecure and not how OpenShift manages identity provider credentials. Option C is wrong because environment variables on the oauth-openshift deployment are not used for LDAP bind passwords; the OAuth configuration references a Secret. Option D is wrong because ConfigMaps are for non-sensitive configuration data, not secrets, and the 'openshift-authentication' namespace is not where the bind password Secret is stored.

Practice this question →
56
Multi-Selecthard

Which TWO of the following characteristics apply to OpenShift SecurityContextConstraints (SCCs)? (Choose TWO)

Select 2 answers
A.SCCs replace Kubernetes NetworkPolicies entirely.
B.SCCs evaluate and can mutate pod specifications during admission control.
C.SCCs can be created as namespaced resources using standard RoleBindings.
D.SCCs are cluster-scoped resources.
E.SCCs apply only to stateful workloads and daemonsets.
AnswersB, D

SCCs act at admission control, validating a pod's security context against allowed values and mutating the pod spec to apply defaults such as SELinux labels or runAsUser when fields are unset. This admission-time evaluation distinguishes them from purely declarative policy objects.

Why this answer

Option B is correct because SCCs are enforced by the OpenShift admission controller: when a pod is created, the SCC admission plugin evaluates the pod's security context (runAsUser, SELinux context, capabilities, volumes, etc.) against the SCCs available to the requesting service account, and can mutate the pod specification to apply defaults such as allowed UID ranges or SELinux labels. Option D is correct because SecurityContextConstraints are cluster-scoped API resources (like ClusterRoles), defined once for the whole cluster rather than within a namespace, and are bound to users, groups, or service accounts via cluster-scoped RBAC (ClusterRole/ClusterRoleBinding or the scc-specific user/group fields). Option A is wrong because SCCs govern pod security context and admission, not network traffic; NetworkPolicies are a separate Kubernetes mechanism and SCCs do not replace them.

Option C is wrong because SCCs are not namespaced resources and cannot be granted through ordinary namespaced RoleBindings; access is granted via cluster-scoped bindings or the SCC's users/groups fields. Option E is wrong because SCCs apply to all pods regardless of workload type, including Deployments, Jobs, and standalone pods, not only stateful workloads or DaemonSets.

Exam trap

EX280 often tests the misconception that SCCs are namespaced or that they replace NetworkPolicies — candidates must remember SCCs are cluster-scoped admission controllers focused on pod security context, not network traffic.

Practice this question →
57
MCQhard

An administrator needs to configure resource requests and limits such that any pod created without explicit CPU requests in the 'web-tier' namespace automatically gets assigned a default CPU request of 200m and a default CPU limit of 500m. Which object achieves this?

A.ResourceQuota
B.PodPreset
C.LimitRange with default and defaultRequest parameters
D.ClusterResourceQuota
AnswerC

A LimitRange with default and defaultRequest keys applies admission-time defaults to containers lacking explicit values, so pods in web-tier receive a 200m CPU request and 500m limit automatically. ResourceQuota instead caps aggregate namespace consumption and cannot inject per-container defaults.

Why this answer

A LimitRange object with default and defaultRequest parameters is specifically designed to set default resource requests and limits for containers in a namespace. When a pod is created without explicit CPU requests, the LimitRange's defaultRequest value (200m) is applied as the request, and the default value (500m) is applied as the limit. This ensures consistent resource allocation and prevents pods from being created without any resource constraints.

Exam trap

EX280 often tests the distinction between ResourceQuota and LimitRange, where candidates mistakenly believe ResourceQuota can set default requests/limits, but it only enforces aggregate limits.

How to eliminate wrong answers

Option A is wrong because ResourceQuota enforces aggregate resource consumption limits for a namespace (e.g., total CPU or memory across all pods) but does not set default requests or limits for individual containers. Option B is wrong because PodPreset was an alpha feature that injected additional information into pods at creation time, but it was removed in Kubernetes 1.20 and never provided default resource requests/limits; it also required specific label selectors. Option D is wrong because ClusterResourceQuota is an OpenShift-specific object that manages quota across multiple namespaces based on label selectors, not a mechanism to assign default resource values to pods.

Practice this question →
58
Multi-Selectmedium

An administrator is configuring a ResourceQuota named 'quota-dev' in the 'development' namespace. Which TWO of the following resource types can be directly tracked and limited by this ResourceQuota? (Choose TWO)

Select 2 answers
A.persistentvolumeclaims
B.clusterroles
C.pods
D.namespaces
E.nodes
AnswersA, C

ResourceQuota directly limits persistentvolumeclaims by counting their quantity within the namespace, satisfying the 'development' namespace constraint. Unlike CPU or memory requests, which apply to pods, PVC quotas cap storage claims independently, allowing administrators to restrict how many volumes teams can provision without touching cluster-wide storage classes.

Why this answer

Option A (persistentvolumeclaims) is correct because Kubernetes ResourceQuota objects support the persistentvolumeclaims field, which limits the number of PVCs that can exist in the namespace, as well as requests.storage to cap total storage requested. Option C (pods) is correct because ResourceQuota natively supports the pods field, allowing the administrator to limit the total number of Pods created in the 'development' namespace. Options B (clusterroles), D (namespaces), and E (nodes) are incorrect because they are cluster-scoped resources, not namespaced resources; ResourceQuota only applies to namespaced objects within the namespace where the quota is defined, so it cannot track or limit ClusterRoles, Namespaces, or Nodes.

Exam trap

EX280 often tests the scope of ResourceQuota, and candidates may incorrectly include cluster-scoped resources like clusterroles or nodes, which are not namespaced and thus cannot be limited by ResourceQuota.

Practice this question →
59
Multi-Selecteasy

Which TWO of the following commands can an administrator use to verify the identity and permissions of the currently logged-in user? (Choose TWO)

Select 2 answers
A.oc whoami
B.oc get user --current
C.oc auth can-i --list
D.oc adm who-can-i
E.oc describe authentication
AnswersA, C

Running oc whoami returns the authenticated username bound to the current session token, directly confirming the identity half of the verification requirement. It queries the OpenShift API server, which validates the OAuth access token and reports the mapped user, satisfying the stem's need to establish who is logged in.

Why this answer

Option A, `oc whoami`, is correct because it queries the OpenShift API server and returns the username of the identity associated with the current session's credentials, directly verifying who the logged-in user is. Option C, `oc auth can-i --list`, is correct because it performs a SelfSubjectRulesReview against the API server and prints the full list of verbs and resources the current user is permitted to perform, thereby verifying the user's permissions. Option B, `oc get user --current`, is not a valid command—`oc get user` lists User objects but has no `--current` flag to identify the logged-in user.

Option D, `oc adm who-can-i`, is not a real subcommand; the actual command is `oc adm policy who-can <verb> <resource>`, which checks which users can perform an action, not the current user's identity. Option E, `oc describe authentication`, is not valid because `authentication` is a cluster-scoped configuration resource (operator.openshift.io) and describing it shows cluster auth configuration, not the current user's identity or permissions.

Exam trap

EX280 often tests the difference between `oc whoami` (identity) and `oc auth can-i` (authorization), causing candidates to pick invalid commands like `oc get user --current`.

Practice this question →

Ready to test yourself?

Try a timed practice session using only User And RBAC Management questions.

Start 20-question session