EX280 User And RBAC Management Practice Test 5 — 15 Questions

Question 1

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

Accepted Answer

oc adm policy add-scc-to-user privileged system:serviceaccount:cicd:builder-sa. `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.

Answer

oc annotate serviceaccount builder-sa scc=privileged -n cicd

Answer

oc set scc privileged --serviceaccount=builder-sa -n cicd

Answer

oc create rolebinding privileged-binding --clusterrole=privileged --serviceaccount=cicd:builder-sa

Question 2

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?

Accepted Answer

In the LDAP identity provider specification under the 'attributes' mapping fields. 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.

Answer

In the kube-apiserver ConfigMap under LDAP settings

Answer

In the GroupSync CRD resource settings

Answer

In the project request template annotations

Question 3

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)

Accepted Answer

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

Answer

security-admin

Answer

node-admin

Answer

cluster-admin

Question 4

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

Accepted Answer

Create a Secret containing the htpasswd file in the 'openshift-config' namespace.. 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.

Answer

Create a ClusterRoleBinding for all users in the htpasswd file.

Answer

Place the htpasswd file directly on every control plane node at '/etc/origin/master/'.

Answer

Restart the kube-apiserver static pods manually across all masters.

Question 5

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

Accepted Answer

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

Answer

SecurityContextConstraints

Answer

NetworkPolicy

Question 6

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

Accepted Answer

oc adm policy add-role-to-user. 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`.

Answer

oc user modify-role

Answer

oc set policy-binding

Question 7

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

Accepted Answer

Every Project in OpenShift has a corresponding underlying Kubernetes Namespace.. 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.

Answer

A single namespace can contain multiple distinct OpenShift projects.

Answer

Namespaces created via 'oc create namespace' automatically instantiate project request templates.

Answer

Projects can be nested hierarchically within other projects.

Question 8

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

Accepted Answer

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

Answer

namespace

Answer

subjects

Question 9

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

Accepted Answer

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

Answer

ActiveDirectoryDirectIdentityProvider

Answer

LocalDatabaseIdentityProvider

Question 10

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

Accepted Answer

SCCs evaluate and can mutate pod specifications during admission control.. 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.

Answer

SCCs replace Kubernetes NetworkPolicies entirely.

Answer

SCCs can be created as namespaced resources using standard RoleBindings.

Answer

SCCs apply only to stateful workloads and daemonsets.

Question 11

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

Accepted Answer

View ConfigMaps. 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.

Answer

Delete PersistentVolumeClaims

Answer

Modify RoleBindings within the project

Question 12

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

Accepted Answer

oc whoami. 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 `, 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.

Answer

oc get user --current

Answer

oc adm who-can-i

Answer

oc describe authentication

Question 13

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

Accepted Answer

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

Answer

replicas

Answer

clusterWideAccess

Question 14

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

Accepted Answer

The User resource object is removed from the cluster database.. 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.

Answer

External identity provider records are automatically deleted from LDAP or OIDC servers.

Answer

All namespaces owned or created by the user are permanently deleted.

Answer

All RoleBindings and ClusterRoleBindings referencing the user are automatically deleted.

Question 15

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

Accepted Answer

Create, modify, and delete workloads and services within the project.. 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.

Answer

Modify cluster-wide ClusterRoles and ClusterRoleBindings.

Answer

Create new projects cluster-wide without restrictions.

Answer

Modify global SecurityContextConstraints.