Select Two (Multi-Select) Questions

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

Why it fails: Deleting an OpenShift User object only removes the cluster-side record; the external LDAP or OIDC directory is never contacted, so provider entries persist. It tempts because identity providers do hold the authoritative credentials, but synchronising deletions back to them is not part of 'oc delete user'.

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

Why it fails: Namespaces are independent resources with their own lifecycle; removing a User object leaves every project and namespace it created intact. The temptation is that ownership implies cascade, yet OpenShift performs no such garbage collection, so an administrator must delete namespaces explicitly.

All RoleBindings and ClusterRoleBindings referencing the user are automatically deleted.

Why it fails: RoleBindings and ClusterRoleBindings persist after the User object is removed, leaving orphaned subjects that still match a recreated username. It tempts because bindings reference the user by name, but OpenShift does not cascade-delete RBAC objects; they must be cleaned up manually.

Htpasswd file path

Why it fails: OIDC authenticates against an external issuer using client ID, client secret and issuer URL, so no local htpasswd file is referenced. An htpasswd file path is required only when configuring the htpasswd identity provider, which validates credentials stored in a local file rather than through OIDC token exchange.

LDAP bind password

Why it fails: OIDC delegates authentication to an external identity provider via tokens and a client secret, so no LDAP bind password is collected. The bind password belongs to LDAP identity provider configuration, where OpenShift queries a directory server directly; it would be correct only if the stem specified LDAP rather than OIDC.

PeriodicTrigger

Why it fails: PeriodicTrigger is not a native rollout trigger type.

WebhookTrigger

Why it fails: Webhook triggers are used in BuildConfigs, not DeploymentConfigs.

GitTrigger

Why it fails: GitTrigger is not a valid native trigger type for DeploymentConfigs.

oc scale deployment/cluster-version-operator --replicas=3

Why it fails: Scaling the cluster-version-operator changes its replica count; it neither reveals why a MachineConfigPool is degraded nor repairs node configuration drift. It is tempting because the operator orchestrates upgrades, but diagnosis requires inspecting MachineConfigPool status, node conditions, and machine-config daemon logs instead.

oc adm upgrade cancel

Why it fails: Cancelling the upgrade aborts the in-progress rollout; it removes the symptom rather than exposing why the MachineConfigPool degraded. It is tempting because a stalled upgrade invites rollback, but diagnosis needs MachineConfigPool conditions, node status, and machine-config daemon logs, not cancellation.

containerRuntime

Why it fails: containerRuntime belongs to the ContainerRuntimeConfig or KubeletConfig resource, not StorageClass, which accepts provisioner, parameters, reclaimPolicy, volumeBindingMode and allowedTopologies. It is tempting because runtime settings do govern how pods execute, but that configuration is applied to nodes, not to dynamic provisioning of persistent volumes.

nodeSelector

Why it fails: nodeSelector is a Pod spec field controlling scheduling, not a StorageClass parameter; StorageClass uses allowedTopologies to constrain where volumes provision. It is tempting because both restrict placement, yet nodeSelector targets pod scheduling while allowedTopologies filters topology zones during dynamic provisioning.

oc get routes

Why it fails: Routes expose ingress hostnames, not operator installation state; OLM failures surface in the Subscription, ClusterServiceVersion and InstallPlan resources. Route inspection is tempting because operators with webhooks or console plugins publish routes, so it fits connectivity debugging once the operator is already running.

oc get pv

Why it fails: PersistentVolumeClaims are storage resources unrelated to OLM reconciliation of an operator installation. It is tempting because failing operators sometimes stall on storage, but OLM diagnostics require the Subscription, ClusterServiceVersion, and InstallPlan or operator pod, which expose the actual installation state.

The cluster must have exactly three worker nodes.

Why it fails: Worker node count is irrelevant to NetworkPolicy enforcement; policies apply per pod selector within the cluster regardless of how many nodes exist. It is tempting because cluster topology feels foundational, but the actual conditions concern pod and namespace selectors, policyTypes and whether the namespace is selected by the policy.

The physical switch port on the top-of-rack switch must be configured in trunk mode.

Why it fails: NetworkPolicy operates at layer 3/4 within the cluster's software-defined network, so physical switch trunk configuration has no bearing on whether traffic is allowed. It is tempting because trunking matters for VLAN-tagged traffic generally, but OpenShift SDN or OVN-Kubernetes handles pod traffic independently of top-of-rack switch port modes.

The cluster image registry configuration

Why it fails: The cluster image registry configuration governs image pull and push behaviour, not PersistentVolumeClaim binding or attachment, so describing it exposes registry storage settings rather than the failing volume's events. It is tempting because registry storage itself uses PVCs, and would be correct when diagnosing registry pod storage or image pull failures.

The OAuth client credentials secret

Why it fails: OAuth client credentials secrets authenticate API service accounts, not storage volumes, so 'oc describe' on them reveals token metadata rather than PersistentVolumeClaim binding events or attachment errors. It is tempting because secrets are inspectable resources, and would be the right target when debugging authentication failures for an operator or OAuth-protected route.

The source namespace must disable its LimitRange objects.

Why it fails: LimitRange objects cap per-pod or per-container resource requests and limits; they have no bearing on cross-namespace API authorisation. It is tempting because LimitRange is a namespace-scoped policy object, and would matter if the question concerned resource quota enforcement.

An administrative override annotation must be placed on the target namespace.

Why it fails: Kubernetes RBAC has no override annotation mechanism; authorisation is evaluated solely through Roles, ClusterRoles and their bindings. It is tempting because annotations do configure other namespace behaviours, such as scheduling or sidecar injection, but no annotation bypasses the RBAC authorisation chain for a ServiceAccount.

The ServiceAccount must be granted cluster-admin rights cluster-wide.

Why it fails: Cluster-admin grants full cluster-wide access, far exceeding the namespace-scoped RoleBinding or ClusterRoleBinding plus Role required here. It is tempting because cluster-admin genuinely solves cross-namespace access, but by granting every permission everywhere rather than the specific API resources in namespace-b.

Chart version

Why it fails: A chart version selects which release of a chart to install and is supplied at install time, not when registering the repository. It is tempting because version pinning matters for reproducible deployments, but the repository definition itself needs only a name and the index URL, so version is irrelevant here.

Username

Why it fails: A username is only needed for a private repository that requires authentication, so it is not required to define a repository in general. It is tempting because authenticated Helm repos do prompt for credentials, but the mandatory pair for any repository definition is the name and its index URL.

Namespace

Why it fails: A namespace is chosen when installing a chart into a cluster, not when defining the repository that hosts it. It is tempting because Helm commands frequently include --namespace, but repository registration stores only a name and URL; the namespace belongs to the release, not the repo.

oc logs -n openshift-ingress-operator deployment/ingress-operator

Why it fails: The ingress operator manages router deployment and certificate plumbing, not the OAuth token exchange between the OAuth server and identity provider. It tempts administrators because ingress failures can break authentication routes, but token-exchange diagnostics live in oauth-openshift pod logs, the authentication clusteroperator status and oauthclient resources.

oc get namespaces

Why it fails: Listing namespaces returns project names and their status, revealing nothing about OAuth token exchange failures. It tempts administrators checking whether the openshift-authentication project exists, but the relevant sources are oauth-openshift pod logs, the authentication clusteroperator conditions and OAuth client or identity provider configuration.

Object

Why it fails: Object is not a PersistentVolume access mode; the valid modes are ReadWriteOnce, ReadOnlyMany, ReadWriteMany and ReadWriteOncePod, describing how many nodes may mount the volume. Object is tempting because object storage is a real backend, but it is a storage type, not a PV access mode.

Database

Why it fails: Database is not a PersistentVolume access mode; valid modes are ReadWriteOnce, ReadOnlyMany, ReadWriteMany and ReadWriteOncePod, which describe concurrent mount semantics. Database is tempting because stateful workloads commonly use PVCs, but it names a workload, not an access mode.

Stream

Why it fails: Stream is not a PersistentVolume access mode; OpenShift supports ReadWriteOnce, ReadOnlyMany, ReadWriteMany and ReadWriteOncePod, which govern concurrent node access. Stream is tempting because streaming volume types exist for media workloads, but that describes a storage class or workload pattern, not a PV access mode.

BIND9

Why it fails: BIND9 is an external DNS server; OpenShift's cluster DNS runs on CoreDNS, which resolves internal service and pod names. It tempts because BIND9 is a legitimate DNS implementation, and it would be correct for external DNS zones that delegate to the cluster.

HAProxy DNS module

Why it fails: HAProxy is OpenShift's ingress router, load-balancing HTTP and TLS traffic to services; it holds no DNS module and plays no part in cluster name resolution. It tempts because HAProxy is a core OpenShift component, and it would be correct for a question about ingress routing.

Keepalived DNS plugin

Why it fails: Keepalived provides VRRP-based virtual IP failover for API and ingress endpoints, not cluster DNS resolution. It tempts because Keepalived genuinely appears in OpenShift control-plane high-availability designs, and it would be the right answer for a question about API server endpoint failover.

NFS network shares

Why it fails: NFS shares are network-attached persistent storage backed by an external server; their lifecycle is independent of the pod, so data survives pod restarts. Ephemeral volumes such as emptyDir and configMap are created and deleted with the pod. NFS would be right when data must persist beyond the pod's lifetime.

PersistentVolumeClaim

Why it fails: A PersistentVolumeClaim requests durable storage from a provisioner; the resulting volume persists independently of the pod, so it is not ephemeral. Ephemeral patterns such as emptyDir exist only for the pod's lifetime. A PVC would be correct when data must survive pod deletion and rescheduling.

AWS EBS volumes

Why it fails: AWS EBS volumes are block storage provisioned through a CSI driver and bound by a PersistentVolume; they outlive the pod and are not native ephemeral patterns. Ephemeral volumes are tied to the pod's lifecycle. EBS would be correct when durable, reattachable block storage is required across pod restarts.

hardened

Why it fails: Kubernetes defines exactly three Pod Security Standard levels: privileged, baseline and restricted. 'Hardened' is not one of them, so it cannot be selected. It tempts administrators because hardening terminology appears throughout OpenShift security documentation, yet the PSS API only accepts the three defined labels.

secured

Why it fails: Kubernetes defines exactly three Pod Security Standard levels: privileged, baseline and restricted. "Secured" is not one of them, so it cannot be applied to a namespace label. It is tempting because the word sounds like a plausible security tier, and a similarly named level would be the answer if Kubernetes actually defined one.

isolated

Why it fails: Kubernetes defines exactly three Pod Security Standard levels: privileged, baseline and restricted. "Isolated" is not among them, so it cannot restrict pod creation via namespace labels. It is tempting because isolation describes a genuine security goal, and it would be relevant when discussing network policies or sandboxing rather than Pod Security Standards.

ActiveDirectoryDirectIdentityProvider

Why it fails: OpenShift supports LDAP identity providers, not an ActiveDirectoryDirectIdentityProvider type; Active Directory is integrated by configuring an LDAP identity provider against it. The name tempts because Active Directory is a common corporate directory, but no dedicated native provider type exists for it in OpenShift Container Platform.

LocalDatabaseIdentityProvider

Why it fails: OpenShift's native identity provider types are HTPasswd, Keystone, LDAP, BasicAuth, RequestHeader, GitHub, GitLab, Google and OpenID; LocalDatabaseIdentityProvider is not among them. It tempts because local user stores exist in other platforms, but OpenShift manages local users through HTPasswd identity providers instead.

Reinstall the entire cluster storage operator.

Why it fails: Reinstalling the storage operator addresses persistent volume provisioning, which is unrelated to whether a Route's hostname resolves or its backend service answers. It is tempting because reinstallation feels like a clean reset, but it would be correct when storage classes or volume claims are failing, not ingress routing.

Modify the cluster kube-apiserver certificates.

Why it fails: Route resolution depends on the ingress controller, router shards and DNS, not on API server serving certificates; regenerating those certificates would disrupt the control plane without fixing the Route. It is tempting because certificate errors do break TLS, and it would be correct when the API server's own serving certificate has expired.

A default ClusterRoleBinding for system:authenticated users

Why it fails: Snapshot operations are authorised through the CSI snapshot controller's own RBAC and the VolumeSnapshotClass, not a default binding granting every authenticated user cluster-wide snapshot rights. It is tempting because ClusterRoleBindings do govern API access generally, but no such default binding exists for snapshots, and granting one would violate least privilege.

NetworkPolicy resources restricting snapshot traffic

Why it fails: Snapshot traffic flows through the CSI driver and storage backend, not through Kubernetes NetworkPolicy objects, which filter pod ingress and egress. NetworkPolicy is tempting because it genuinely secures pod-level traffic in other contexts, but snapshot creation depends on VolumeSnapshotClass, CSI snapshotter, and VolumeSnapshot resources instead.

SCCs replace Kubernetes NetworkPolicies entirely.

Why it fails: SCCs govern pod security context such as UID, capabilities and volume types; NetworkPolicies control pod-to-pod traffic flow. The option tempts because both are cluster security controls, yet they operate on entirely different axes and neither replaces the other.

SCCs can be created as namespaced resources using standard RoleBindings.

Why it fails: SCCs are cluster-scoped objects, not namespaced, and are granted through User, Group or ServiceAccount subjects rather than RoleBindings. The option tempts because RoleBindings grant namespaced permissions for most resources, but SCC admission sits outside that RBAC namespace model.

SCCs apply only to stateful workloads and daemonsets.

Why it fails: SCCs govern pod admission for every workload type — Deployments, Jobs, ReplicaSets, and standalone pods — not just stateful workloads and daemonsets. The option is tempting because DaemonSets and StatefulSets often need elevated host access, so SCC tuning frequently centres on them, but the constraint object itself is workload-agnostic.

ClusterNetwork operator

Why it fails: The ClusterNetwork operator manages pod network configuration and IP address pools, not Ingress routing. It is tempting because it is a core OpenShift networking operator, but the Ingress architecture comprises the Ingress operator, Ingress Controller pods, and the router service, which handle external HTTP and TLS traffic.

EgressFirewall controller

Why it fails: The EgressFirewall controller governs outbound traffic filtering from namespaces, not inbound Ingress routing. It is tempting because it is a networking component within OpenShift, but the standard Ingress architecture consists of the Ingress operator, the Ingress Controller deployment, and the router service handling external requests.