Knowledge + Practice

CCNA Networking And Network Policies Questions

57 questions · Networking And Network Policies · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

A service of type NodePort has been created in OpenShift. Within what default port range are NodePort services typically allocated on the worker nodes?

A.30000-32767

B.50000-60000

C.1024-65535

D.80-443

AnswerA

OpenShift allocates NodePort services from the 30000-32767 range by default, exposing each service on every worker node's IP at that port. This range is configurable via the service-node-port-range parameter, but 30000-32767 remains the standard default.

Why this answer

By default, Kubernetes and OpenShift allocate NodePort services from the range 30000-32767. This range is configurable at the cluster level, but the default is standardized. NodePort services expose the service on each node's IP at that port, allowing external access.

Exam trap

EX280 often tests the default NodePort range, and candidates may confuse it with the ephemeral port range or the full non-privileged port range.

How to eliminate wrong answers

Option B is wrong because 50000-60000 is not the default NodePort range; it might be used for other purposes but not standard. Option C is wrong because 1024-65535 is the entire range of non-privileged ports, not the specific default for NodePort. Option D is wrong because 80-443 are privileged ports used for HTTP/HTTPS, not NodePort allocations.

Practice this question →

2

MCQmedium

An administrator needs to restrict ingress traffic to pods in the 'frontend' namespace so that only pods labeled role=api in the 'backend' namespace can connect on TCP port 8080. All other traffic must be denied. Which NetworkPolicy configuration achieves this?

A.A NetworkPolicy in the frontend namespace with podSelector matching app=web, ingress from namespaceSelector matching name=backend and podSelector matching role=api, and ports TCP 8080.

B.A NetworkPolicy in the frontend namespace with podSelector matching app=web and ingress from ipBlock 10.0.0.0/8 on TCP 8080.

C.A NetworkPolicy in the backend namespace with podSelector matching role=api and egress to namespaceSelector matching name=frontend and port TCP 8080.

D.A NetworkPolicy in the frontend namespace with podSelector matching app=web and ingress from namespaceSelector matching name=backend without specifying ports.

AnswerA

This policy selects the target pods via podSelector, allows ingress only from pods in the backend namespace that also have the role=api label, and restricts to TCP 8080. Because NetworkPolicy is additive and any pod selected by at least one policy has all non-allowed traffic denied, this correctly enforces the restriction.

Why this answer

A NetworkPolicy must be created in the namespace of the pods it protects (frontend) and use podSelector to select those pods. The ingress rule must combine namespaceSelector and podSelector to allow only pods in backend with role=api, and specify the port TCP 8080. Once any policy selects the frontend pods, all other ingress is denied by default.

Exam trap

The trap here is placing the policy in the source namespace or using ipBlock instead of label selectors, which fails to restrict traffic based on pod identity.

Practice this question →

3

MCQhard

An OpenShift administrator needs to restrict external access to a specific application Route by limiting access to a predefined list of allowed client IP addresses. How can this be accomplished?

A.Configure spec.clientIP in the Service object definition.

B.Create a NetworkPolicy with spec.ingress.ipBlock restricting the router pod.

C.Add the annotation 'haproxy.router.openshift.io/ip_whitelist' to the Route object.

D.Update the IngressController CR with a global clientIP blacklist.

AnswerC

The haproxy.router.openshift.io/ip_whitelist annotation is read by the HAProxy router and enforces an allow-list of client source IPs at the edge, rejecting all others before traffic reaches the application. This directly satisfies the requirement to restrict external Route access to a predefined set of addresses.

Why this answer

The annotation 'haproxy.router.openshift.io/ip_whitelist' on a Route object instructs the HAProxy router to allow only the specified client IP addresses (or CIDR ranges) to access that route. This is the standard OpenShift method for per-route IP whitelisting without affecting other routes or the entire router. The annotation is processed by the router's HAProxy configuration, which adds ACL rules to enforce the whitelist.

Exam trap

EX280 often tests the difference between Route annotations and NetworkPolicy for access control, and candidates may incorrectly choose NetworkPolicy because it is a Kubernetes-native construct, but NetworkPolicy operates at the pod level and cannot easily target per-route client IPs.

How to eliminate wrong answers

Option A is wrong because Service objects do not have a spec.clientIP field; Kubernetes Services use spec.loadBalancerSourceRanges for load balancer IP restrictions, but that is not applicable to OpenShift Routes and does not restrict client IPs at the router level. Option B is wrong because NetworkPolicy with spec.ingress.ipBlock is not a valid field; NetworkPolicy uses ipBlock under ingress.from, but applying it to the router pod would restrict traffic to the router itself, not per-route client IPs, and would require complex pod selectors. Option D is wrong because the IngressController CR does not support a global clientIP blacklist; it manages router deployment settings, not per-route access control.

Practice this question →

4

MCQhard

An administrator must configure a NetworkPolicy in the 'secure-zone' namespace to explicitly deny all ingress traffic except for TCP traffic coming from pods labeled 'tier=frontend' in the 'frontend-zone' namespace. Which NetworkPolicy specification achieves this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 10.128.0.0/14 ports: - protocol: TCP

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend-zone ports: - protocol: TCP

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend-zone podSelector: matchLabels: tier: frontend ports: - protocol: TCP

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: frontend matchExpressions: - key: namespace operator: In values: [frontend-zone] ports: - protocol: TCP

AnswerC

An empty podSelector selects all pods in secure-zone, and policyTypes Ingress makes the policy default-deny. The single ingress rule permits TCP only from pods labelled tier=frontend in the frontend-zone namespace, satisfying the explicit allowlist constraint.

Why this answer

Option C is correct because it uses a single ingress rule with both a namespaceSelector matching the 'frontend-zone' namespace (via the automatic label kubernetes.io/metadata.name) and a podSelector matching pods with label tier=frontend. In Kubernetes NetworkPolicy, when multiple selectors are specified within the same 'from' element, they are ANDed together, meaning only pods that satisfy both conditions are allowed. The policy also sets podSelector: {} to apply to all pods in the secure-zone namespace, and policyTypes: [Ingress] to enforce the rule, effectively denying all other ingress traffic.

Exam trap

EX280 often tests the distinction between namespaceSelector and podSelector, and the fact that they must be combined in the same 'from' element to achieve an AND condition; candidates frequently mistakenly use only one selector or incorrectly try to match namespace labels with podSelector.

How to eliminate wrong answers

Option A is wrong because it uses an ipBlock with CIDR 10.128.0.0/14, which allows traffic from any pod in that IP range regardless of labels or namespace, not specifically from pods labeled tier=frontend in frontend-zone. Option B is wrong because it only uses a namespaceSelector for frontend-zone, which allows all pods in that namespace, not just those with the tier=frontend label. Option D is wrong because it attempts to use a podSelector with matchExpressions on a 'namespace' key, but podSelector only matches pod labels, not namespace labels; the namespace field is not a valid pod label, so this would not correctly select pods from the frontend-zone namespace.

Practice this question →

5

MCQhard

An administrator troubleshoots a failing NetworkPolicy and wants to verify if the OpenShift SDN or OVN-Kubernetes controller has successfully applied the rules. Where are the controller operator logs examined?

A.In the openshift-apiserver namespace

B.In the openshift-network-operator or openshift-ovn-kubernetes namespaces

C.In the kube-system namespace under core-dns logs

D.In the openshift-ingress namespace under router pods

AnswerB

The network operator and OVN-Kubernetes controller run as pods within the openshift-network-operator and openshift-ovn-kubernetes namespaces respectively, so their logs reveal whether NetworkPolicy rules were successfully applied. Examining these namespaces satisfies the stem's requirement to verify controller application of rules.

Why this answer

In OpenShift, the network controller components that apply NetworkPolicy rules run in specific namespaces: the network operator itself runs in openshift-network-operator, and the OVN-Kubernetes control plane runs in openshift-ovn-kubernetes. To verify if the controller has successfully applied NetworkPolicy rules, you must examine the logs of the operator and the ovn-kubernetes pods in these namespaces. The openshift-network-operator manages the overall network configuration, while the ovn-kubernetes pods (like ovnkube-master and ovnkube-node) handle the actual implementation of network policies.

Exam trap

EX280 often tests the misconception that network policy controllers run in kube-system or openshift-apiserver, but in OpenShift they are specifically in openshift-network-operator and openshift-ovn-kubernetes namespaces.

How to eliminate wrong answers

Option A is wrong because the openshift-apiserver namespace contains the API server pods, which handle API requests but do not apply NetworkPolicy rules. Option C is wrong because kube-system namespace and core-dns logs are related to DNS services, not network policy enforcement; OpenShift SDN/OVN-Kubernetes controllers are not in kube-system. Option D is wrong because the openshift-ingress namespace contains router pods that handle ingress traffic, not the network policy controller.

Practice this question →

6

MCQeasy

A developer wants to expose an application using a secure Route that terminates TLS on the pod itself, avoiding decryption at the router layer. Which TLS termination type should be selected?

A.reencrypt

B.edge

C.none

D.passthrough

AnswerD

Passthrough forwards encrypted traffic straight to the pod, so the router never holds TLS keys and decryption occurs only inside the application container. This satisfies the requirement to terminate TLS on the pod itself, unlike edge or re-encrypt termination.

Why this answer

Passthrough termination allows the router to forward encrypted traffic directly to the pod without decrypting it, so TLS is terminated at the pod itself. This meets the requirement of avoiding decryption at the router layer. Edge and reencrypt both involve decryption at the router, while 'none' means no TLS termination at all.

Exam trap

EX280 often tests the distinction between passthrough and reencrypt, where candidates might think reencrypt avoids router decryption, but only passthrough keeps the router from decrypting.

How to eliminate wrong answers

Option A is wrong because reencrypt decrypts at the router and then re-encrypts to the backend, so the router still handles decryption. Option B is wrong because edge termination decrypts at the router and sends plain HTTP to the pod. Option C is wrong because 'none' is not a valid termination type for secure Routes; it would mean no TLS, which does not meet the requirement.

Practice this question →

7

MCQeasy

An administrator needs to expose an internal application running on port 8080 via an OpenShift Route using edge termination. Which object configuration correctly defines this Route?

A.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: edge

B.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: passthrough

C.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080

D.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: reencrypt

AnswerA

Edge termination requires the tls stanza with termination set to edge, so TLS is decrypted at the router before forwarding plain HTTP to the Service. The spec.to reference and targetPort 8080 correctly direct traffic to the internal application, satisfying the exposure requirement.

Why this answer

The correct Route configuration for edge termination includes the tls stanza with termination: edge, which instructs the router to terminate TLS at the router and forward plain HTTP to the backend service on port 8080. The other options either use incorrect termination types or omit TLS entirely, which would not provide edge termination.

Exam trap

EX280 often tests the details of Route YAML, and candidates might mistakenly choose passthrough or reencrypt when edge is required, or forget to include the tls stanza altogether.

How to eliminate wrong answers

Option B is wrong because termination: passthrough expects the backend to handle TLS, and the router does not decrypt, which contradicts edge termination. Option C is wrong because it lacks any tls stanza, resulting in an unsecured Route (no TLS termination). Option D is wrong because termination: reencrypt requires additional certificate configuration and is used when the router re-encrypts to the backend, not for edge termination.

Practice this question →

8

MCQeasy

An administrator needs to create a service that exposes an application externally via an IP address allocated from an external cloud provider load balancer. Which service type must be used?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerB

The LoadBalancer service type provisions an external load balancer from the underlying cloud provider and assigns it a public IP address, exposing the application externally. NodePort and ClusterIP do not allocate provider-managed IPs, so they cannot satisfy the external cloud load balancer requirement.

Why this answer

A Service of type LoadBalancer instructs the cloud provider's controller (or OpenShift's cloud provider integration) to provision an external load balancer with a public or private IP address, and the Service is exposed through that IP. This is the standard way to expose an application externally via a cloud LB in OpenShift/Kubernetes. The LoadBalancer type builds on NodePort and ClusterIP, adding the external IP allocation.

Exam trap

EX280 often tests whether candidates confuse NodePort (node IP + static port) with LoadBalancer (cloud-allocated external IP), so pick LoadBalancer whenever the question mentions an IP from an external cloud provider load balancer.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the service on a static port on every node's IP, not via a cloud provider-allocated load balancer IP. Option C is wrong because ClusterIP only provides an internal virtual IP reachable within the cluster, with no external exposure. Option D is wrong because ExternalName maps a service to a DNS CNAME (e.g., an external database), not to a cloud load balancer IP.

Practice this question →

9

MCQhard

An administrator needs to modify the default Ingress controller configuration to change its replica count and adjust the router deployment parameters. Which resource should the administrator edit?

A.ingresscontroller.operator.openshift.io named 'default'

B.deployment named router-default in openshift-ingress namespace

C.configmap named router-config in openshift-ingress-operator

D.service named router-default-http in openshift-ingress

AnswerA

The IngressController operator resource is the cluster-scoped configuration object that the ingress operator reconciles; editing its spec changes replica count and router deployment parameters, which the operator then applies. Editing the router deployment directly would be overwritten, since the operator enforces the declared state.

Why this answer

The Ingress controller configuration in OpenShift is managed by the IngressController operator resource named 'default' in the openshift-ingress-operator namespace. To change replica count and router deployment parameters, the administrator edits this ingresscontroller.operator.openshift.io custom resource. The operator then reconciles the changes into the router Deployment.

Exam trap

EX280 often tests the operator pattern — candidates may choose to edit the router Deployment directly, not realizing that the IngressController CR is the supported and persistent way to change replica count and router parameters.

How to eliminate wrong answers

Option B is wrong because editing the router-default Deployment directly is not supported; the operator will revert manual changes, and the Deployment is a generated resource. Option C is wrong because there is no configmap named router-config in openshift-ingress-operator that controls replica count; configuration is via the IngressController CR. Option D is wrong because a Service named router-default-http exposes the router but does not define replica count or deployment parameters.

Practice this question →

10

Multi-Selecteasy

Which TWO components are core parts of the OpenShift DNS architecture for cluster resolution? (Choose TWO)

Select 2 answers

A.CoreDNS

B.Cluster DNS Operator

C.BIND9

D.HAProxy DNS module

E.Keepalived DNS plugin

AnswersA, B

CoreDNS runs as the cluster DNS operator's managed component, resolving service names and pod FQDNs for internal cluster traffic. It satisfies the stem's requirement for a core OpenShift DNS component, operating alongside the node resolver to handle the cluster domain's forward and reverse lookups.

Why this answer

CoreDNS (A) is correct because OpenShift uses CoreDNS as the actual DNS server that runs in the cluster and resolves names for services, pods, and internal cluster resources. The Cluster DNS Operator (B) is correct because it is the OpenShift operator responsible for deploying, configuring, and managing the CoreDNS instances and their DNS configuration across the cluster. BIND9 (C) is not part of the core OpenShift DNS architecture; it is a general-purpose DNS server not used as the cluster's internal resolver.

HAProxy DNS module (D) is incorrect because HAProxy is used for routing/load balancing, not as a core DNS resolution component in OpenShift. Keepalived DNS plugin (E) is incorrect because Keepalived provides VRRP-based high availability and is not a DNS resolution component of OpenShift.

Exam trap

EX280 often tests the confusion between general DNS servers (BIND9) and OpenShift-specific components (CoreDNS and DNS Operator), leading candidates to pick familiar but incorrect tools.

Practice this question →

11

MCQmedium

An application pod in OpenShift needs to determine its own IP address and the cluster DNS servers dynamically. Where does CoreDNS look or how are pods configured to resolve cluster DNS?

A.By querying the OpenShift API server directly on port 6443 for DNS records

B.Through an environment variable named CLUSTER_DNS injected into every container

C.By parsing the /etc/hosts file updated dynamically by the OpenShift SDN controller

D.Via the /etc/resolv.conf file automatically managed inside the pod container

AnswerD

The kubelet writes the pod's /etc/resolv.conf at creation, pointing nameserver at the CoreDNS ClusterIP service and setting search domains and ndots. Applications read this file to obtain cluster DNS resolution, so no manual configuration or API query is needed.

Why this answer

Every pod in OpenShift has its /etc/resolv.conf automatically populated by the kubelet with the cluster DNS service IP (typically 172.30.0.10) and search domains. CoreDNS listens on that service IP and answers queries for cluster-internal names like service.namespace.svc.cluster.local. The pod does not query the API server directly; it simply uses the resolver configuration injected at container start.

Exam trap

The trap here is assuming pods get DNS via environment variables or API calls; candidates must remember that Kubernetes/OpenShift DNS is delivered through the standard /etc/resolv.conf mechanism managed by the kubelet.

How to eliminate wrong answers

Option A is wrong because pods do not query the API server on 6443 for DNS; CoreDNS is the resolver, and the API server is not a DNS endpoint. Option B is wrong because there is no CLUSTER_DNS environment variable injected into containers by default; DNS is configured via resolv.conf, not env vars. Option C is wrong because /etc/hosts is not dynamically updated by the SDN controller for DNS resolution; it only contains static entries like the pod's own hostname.

Practice this question →

12

MCQeasy

An administrator needs to test DNS resolution from inside a running pod. Which command run inside a container uses the standard Linux DNS lookup utility?

A.nslookup backend.production.svc.cluster.local

B.route lookup backend

C.oc get dns

D.ping -dns backend.production.svc.cluster.local

AnswerA

nslookup is the standard Linux DNS lookup utility available inside the container image, querying the cluster DNS service for the fully qualified service name. It resolves backend.production.svc.cluster.local directly, confirming whether cluster DNS resolution works from the pod's network namespace.

Why this answer

nslookup is the standard Linux DNS lookup utility and can be run inside a container to query DNS resolution for a service FQDN such as backend.production.svc.cluster.local. Running it inside the pod tests the actual DNS path the application would use, including the cluster DNS service and any search domain configuration. This directly answers the requirement to test DNS resolution from inside a running pod.

Exam trap

EX280 often tests whether candidates know the standard in-container DNS utility (nslookup) versus cluster-level CLI commands (oc get dns) — candidates pick the oc command because it sounds authoritative, but it does not test resolution from inside the pod.

How to eliminate wrong answers

Option B is wrong because `route lookup` is not a standard Linux command for DNS resolution — route is a networking utility for the routing table, and there is no `route lookup` subcommand for DNS. Option C is wrong because `oc get dns` is an OpenShift CLI command that reads the cluster DNS operator configuration from outside the pod; it does not test resolution from inside a container. Option D is wrong because `ping -dns` is not a valid ping option — ping does not have a -dns flag, and while ping can resolve names, it is not the standard DNS lookup utility and may be blocked by ICMP policies.

Practice this question →

13

Multi-Selectmedium

Which TWO options describe characteristics of OVN-Kubernetes compared to the legacy OpenShift SDN? (Choose TWO)

Select 2 answers

A.It provides native support for EgressIP and EgressFirewall custom resources.

B.It relies exclusively on traditional Linux iptables rules without OVS flow tables.

C.It requires the flannel CNI plugin to function.

D.It uses Open Virtual Network (OVN) with OVS for routing and switching.

E.It does not support NetworkPolicies.

AnswersA, D

OVN-Kubernetes implements EgressIP and EgressFirewall as native custom resources through its OVN northbound database, satisfying the stem's requirement for characteristics distinguishing it from OpenShift SDN. The legacy plugin relied on different mechanisms, such as iptables-based egress router pods, so native CRD support is a genuine architectural difference.

Why this answer

Option A is correct because OVN-Kubernetes natively implements EgressIP and EgressFirewall as custom resources managed through its OVN northbound database, giving cluster administrators first-class APIs for controlling egress traffic that the legacy OpenShift SDN handled differently or with limited functionality. Option D is correct because OVN-Kubernetes is built on Open Virtual Network (OVN) and Open vSwitch (OVS), using OVS flows and OVN logical flows for distributed routing and switching across nodes, which is the architectural foundation that distinguishes it from OpenShift SDN. Option B is incorrect because OVN-Kubernetes does not rely exclusively on iptables; it uses OVS flow tables and OVN logical flows for most dataplane forwarding, with iptables only for limited host-level functions.

Option C is incorrect because OVN-Kubernetes does not require the flannel CNI plugin; it is a self-contained CNI implementation. Option E is incorrect because OVN-Kubernetes fully supports Kubernetes NetworkPolicy objects, translating them into OVN ACLs.

Exam trap

EX280 often tests the confusion between OVN-Kubernetes and OpenShift SDN features, such as whether EgressIP is supported natively or whether iptables is the primary mechanism.

Practice this question →

14

MCQeasy

An application pod needs to discover other pods behind the same headless service. What characteristic defines a headless service?

A.It automatically creates an external Route resource.

B.It has spec.clusterIP set to None.

C.It does not have any selector defined in its specification.

D.It disables internal container DNS resolution entirely.

AnswerB

Setting spec.clusterIP to None tells Kubernetes not to allocate a virtual IP or load-balance, so DNS returns individual pod IPs directly. Clients then discover every backing pod themselves, which is precisely the discovery behaviour the application requires behind the headless service.

Why this answer

A headless service is defined by setting `spec.clusterIP` to `None`, which tells Kubernetes not to allocate a virtual IP. Instead, DNS returns the individual pod IPs associated with the service, allowing direct pod discovery. This is commonly used for stateful applications where clients need to connect to specific pods.

Exam trap

EX280 often tests the definition of a headless service, and candidates may incorrectly think it requires no selector or that it disables DNS, rather than focusing on the `clusterIP: None` setting.

How to eliminate wrong answers

Option A is wrong because headless services do not create external Routes; Routes are an OpenShift resource for exposing services externally. Option C is wrong because a headless service can still have a selector; the key characteristic is the `clusterIP: None`, not the absence of a selector. Option D is wrong because headless services do not disable DNS resolution; they change the DNS response to return pod IPs instead of a single service IP.

Practice this question →

15

MCQeasy

An administrator wants to expose a Deployment via a NodePort service. What is the default port range allocated for NodePort services in OpenShift if not explicitly configured otherwise?

A.1024-65535

B.80-443

C.30000-32767

D.8000-9000

AnswerC

OpenShift's default NodePort allocation is 30000-32767, inherited from Kubernetes' service-node-port-range. Unless the administrator edits that range in the kubelet or apiserver configuration, every NodePort service receives a port within these bounds, so this range is the correct default.

Why this answer

OpenShift (like Kubernetes) allocates NodePort services from the default range 30000–32767 unless the cluster is explicitly configured otherwise. This range is defined by the `service-node-port-range` parameter in the kube-apiserver configuration. When you create a NodePort service without specifying a nodePort, the controller picks a free port from this range.

Exam trap

EX280 often tests memorization of the default NodePort range — candidates confuse it with the ephemeral port range or the full non-privileged range (1024–65535).

How to eliminate wrong answers

Option A is wrong because 1024–65535 is the full range of non-privileged ports, not the NodePort allocation range — NodePorts are deliberately restricted to a high range to avoid collisions with system services. Option B is wrong because 80–443 are standard HTTP/HTTPS ports used by the router or application containers, not NodePort allocations. Option D is wrong because 8000–9000 is an arbitrary application port range with no special meaning in Kubernetes/OpenShift NodePort allocation.

Practice this question →

16

MCQmedium

A developer deploys a headless service (ClusterIP set to None) in OpenShift. What is the primary characteristic of a headless service?

A.It prevents any external routes from binding to the service.

B.It routes traffic exclusively via NodePort across worker nodes.

C.It does not allocate a ClusterIP, and DNS returns the individual pod IPs directly.

D.It provisions an external cloud load balancer automatically.

AnswerC

With clusterIP: None, no virtual IP is allocated, so the service's DNS A records resolve straight to each backing pod's IP rather than a single load-balanced address. This satisfies the headless requirement, letting clients address individual pods directly for stateful or peer-discovery workloads.

Why this answer

A headless service in OpenShift/Kubernetes is defined by setting clusterIP: None, which means no virtual IP is allocated. Instead, DNS resolution for the service returns the individual pod IPs directly (A/AAAA records), allowing clients to connect to specific pods — commonly used for StatefulSets where each pod needs a stable identity.

Exam trap

EX280 often tests the confusion between headless services (clusterIP: None, DNS returns pod IPs) and NodePort/LoadBalancer services, causing candidates to incorrectly associate headless services with external exposure or NodePort routing.

How to eliminate wrong answers

Option A is wrong because headless services do not inherently prevent external routes from binding; Routes can still target the service, though headless services are typically used for internal discovery. Option B is wrong because headless services do not route traffic via NodePort — that is a separate service type (NodePort), and headless services bypass kube-proxy load balancing entirely. Option D is wrong because headless services do not provision cloud load balancers — that is the LoadBalancer service type, which is mutually exclusive with clusterIP: None.

Practice this question →

17

Multi-Selecteasy

Which TWO of the following are valid OpenShift Service types? (Choose TWO)

Select 2 answers

A.NetworkPort

B.ClusterIP

C.RouteIP

D.ContainerPort

E.NodePort

AnswersB, E

ClusterIP allocates a virtual IP reachable only from inside the cluster, making it the default Service type. It satisfies the stem because it is a native Kubernetes Service type, unlike Route or Ingress, which are OpenShift API objects rather than Services.

Why this answer

Option B, ClusterIP, is a valid OpenShift/Kubernetes Service type: it exposes the Service on an internal cluster IP reachable only from within the cluster, and it is in fact the default Service type. Option E, NodePort, is also a valid Service type: it allocates a static port on each node's IP (default range 30000-32767) so the Service is reachable from outside the cluster via <NodeIP>:<NodePort>. The other options are not Service types: NetworkPort is not a Kubernetes/OpenShift Service type, RouteIP is not a Service type (OpenShift Routes are separate API objects that expose Services externally), and ContainerPort is a field within a Pod's container spec that declares the port the container listens on, not a Service type.

Exam trap

EX280 often tests whether candidates can distinguish valid Service types from similarly named Kubernetes fields (ContainerPort) or OpenShift resources (Route) — the trap is picking terms that sound plausible but are not Service types.

Practice this question →

18

MCQeasy

An administrator needs to list all Services across all namespaces in the OpenShift cluster. Which command should be used?

A.oc get services --cluster

B.oc get svc -A

C.oc describe service --all

D.oc adm top services

AnswerB

The -A flag (equivalent to --all-namespaces) instructs oc to query Services cluster-wide rather than only within the current project, which is the constraint the administrator faces when needing a complete cross-namespace listing in one command.

Why this answer

The `-A` flag (short for `--all-namespaces`) is the standard OpenShift/Kubernetes flag that makes `oc get` query every namespace in the cluster. Running `oc get svc -A` returns all Services across all projects in a single table, which is exactly what the administrator needs. This flag is consistent across resource types and is the idiomatic way to perform cluster-wide listing.

Exam trap

EX280 often tests whether candidates invent non-existent flags like `--cluster` or `--all` for `oc get` instead of using the correct `-A` / `--all-namespaces` flag.

How to eliminate wrong answers

Option A is wrong because `--cluster` is not a valid flag for `oc get services`; there is no such option in the oc CLI, so the command would error out. Option C is wrong because `oc describe service --all` is not valid syntax — `describe` requires a specific resource name, and `--all` is not a supported flag for describe operations. Option D is wrong because `oc adm top services` is not a real command; `oc adm top` supports nodes and pods for metrics, not services, and it would not list Services at all.

Practice this question →

19

Multi-Selecthard

Which TWO statements are true regarding OpenShift Services of type LoadBalancer? (Choose TWO)

Select 2 answers

A.They interact with cloud provider APIs or MetalLB to provision an external IP address.

B.They are restricted to internal cluster communication only.

C.They replace the need for Ingress controllers completely.

D.They can only be created when running on bare-metal hardware without external integrations.

E.They automatically allocate a NodePort on every worker node to route traffic into the cluster.

AnswersA, E

LoadBalancer Services delegate external IP allocation to an infrastructure provider: on cloud platforms, the cloud controller calls the provider's API to create a load balancer; on bare metal, MetalLB assigns addresses from a configured pool. This satisfies the stem's requirement for provisioning an external IP without manual intervention.

Why this answer

Option A is correct because a Service of type LoadBalancer triggers OpenShift's cloud-provider integration (or the MetalLB operator on bare metal) to call the provider's API and provision an external load balancer with a routable external IP that forwards traffic to the service. Option E is correct because LoadBalancer builds on NodePort: OpenShift automatically allocates a NodePort (in the 30000-32767 range by default) on every node, and the external load balancer targets that NodePort to reach the backing pods. Option B is wrong because LoadBalancer services are specifically for external access, not internal-only communication (that is ClusterIP).

Option C is wrong because Ingress controllers and Routes provide HTTP/HTTPS host- and path-based routing that a LoadBalancer service does not replace. Option D is wrong because LoadBalancer services are supported on cloud platforms via provider APIs as well as on bare metal via MetalLB, so they are not limited to bare metal without integrations.

Exam trap

EX280 often tests the misconception that LoadBalancer Services replace Ingress or are internal-only, when in fact they are L4 external Services that complement L7 Ingress/Route objects.

Practice this question →

20

MCQmedium

An administrator is troubleshooting why a Pod in namespace `app-a` cannot reach a Pod in namespace `app-b` on TCP port 3306, even though both Pods are Running and the Services resolve correctly. A NetworkPolicy in `app-b` allows ingress only from Pods labeled `tier: frontend` in `app-a`. The source Pod in `app-a` has the label `tier: backend`. What is the most likely cause?

A.The cluster's DNS service is not resolving the destination Service name.

B.The source Pod's label does not match the NetworkPolicy's allowed source selector, so ingress is denied.

C.The destination Pod is not listening on port 3306, so the connection is refused.

D.The source namespace `app-a` lacks a matching egress NetworkPolicy allowing traffic to `app-b`.

AnswerB

The NetworkPolicy in `app-b` permits ingress only from Pods labeled `tier: frontend` in `app-a`. The source Pod carries `tier: backend`, so it does not match the allowed source selector. Since the policy explicitly restricts ingress, any traffic not matching an allow rule is dropped, making the label mismatch the direct cause of the connectivity failure.

Why this answer

NetworkPolicy ingress rules can restrict allowed sources by namespace and Pod label selectors. When a source Pod's labels do not match the allowed selector, its traffic is dropped even if the Pod is healthy and the destination Service resolves. In this case, the source Pod labeled `tier: backend` fails to match the policy's requirement for `tier: frontend`, so the ingress is denied by policy rather than by application or DNS failure.

Exam trap

The trap here is focusing on DNS or application port issues when the scenario already provides a NetworkPolicy whose source label selector clearly excludes the source Pod.

Practice this question →

21

MCQhard

An OpenShift administrator needs to inspect how OVN-Kubernetes handles network flows and packet drops on a specific node. Which debugging utility installed in the OVN node container is most effective for viewing OpenFlow rules?

A.nmcli connection show

B.ethtool -S

C.ovs-ofctl

D.ovn-trace

AnswerC

ovs-ofctl queries and dumps OpenFlow flow tables from the Open vSwitch bridge that OVN-Kubernetes programs. Running it inside the OVN node container shows the exact match-action rules and drop counters for flows on that node.

Why this answer

OVN-Kubernetes uses Open vSwitch (OVS) as its data plane, and ovs-ofctl is the standard utility for inspecting and managing OpenFlow rules in the OVS bridge. It allows administrators to dump flows, view packet counters, and debug how traffic is being handled on a specific node. This makes it the most effective tool for viewing OpenFlow rules in the OVN node container.

Exam trap

EX280 often tests the distinction between OVN logical flow tracing (ovn-trace) and OpenFlow rule inspection (ovs-ofctl), so candidates must pick the tool that directly shows OpenFlow rules when asked about packet drops on a node.

How to eliminate wrong answers

Option A is wrong because nmcli is a NetworkManager CLI for managing host network connections, not OpenFlow rules. Option B is wrong because ethtool -S displays NIC statistics, not OpenFlow flows. Option D is wrong because ovn-trace simulates packet traversal through OVN logical flows, which is useful for logical debugging but does not display the OpenFlow rules installed in OVS.

Practice this question →

22

MCQeasy

An administrator needs to delete a Service named 'old-service' in the 'test' namespace. Which command accomplishes this?

A.oc remove svc old-service --namespace=test

B.oc prune service old-service -n test

C.oc destroy service old-service -n test

D.oc delete service old-service -n test

AnswerD

The oc delete command removes a named resource, with -n test scoping the operation to the test namespace. Specifying service old-service targets the correct resource type and name, satisfying the requirement to delete that Service in that namespace.

Why this answer

The correct command is `oc delete service old-service -n test` because `oc delete` is the standard OpenShift/Kubernetes verb for removing resources. It accepts the resource type (service, or its abbreviation svc) and the resource name, with the `-n` flag specifying the namespace. This directly deletes the Service object from the 'test' namespace.

Exam trap

EX280 often tests whether candidates confuse `oc delete` with non-existent verbs like `remove`, `destroy`, or `prune`, which are not part of the standard oc CLI for deleting specific resources.

How to eliminate wrong answers

Option A is wrong because `oc remove` is not a valid subcommand in the oc CLI; the correct verb is `delete`. Option B is wrong because `oc prune` is used to remove older resources based on criteria (e.g., builds, deployments) and does not target a specific named Service. Option C is wrong because `oc destroy` is not a valid subcommand; it might be confused with `oc delete` or `oc destroy` from other tools, but it does not exist in oc.

Practice this question →

23

Multi-Selecteasy

Which TWO options are valid methods to check service endpoints in OpenShift? (Choose TWO)

Select 2 answers

A.oc adm inspect endpoints

B.oc get routes --show-endpoints

C.oc get pods --endpoints

D.oc get endpoints

E.oc describe service <service-name>

AnswersD, E

'oc get endpoints' queries the Endpoints API object directly, listing the pod IP addresses and ports backing each service. This satisfies the requirement to verify which pods a service currently routes to, exposing the actual endpoint set.

Why this answer

Option D, `oc get endpoints`, is correct because Endpoints objects are the native Kubernetes/OpenShift resource that lists the actual IP:port pairs backing a Service, so querying them directly shows whether the service has healthy endpoint addresses. Option E, `oc describe service <service-name>`, is correct because the describe output includes an `Endpoints:` field (e.g., `10.128.0.5:8080`) that reveals the currently selected pod endpoints for that Service. Option A is invalid because `oc adm inspect` is a must-gather/diagnostic command that collects cluster resources into a directory; it does not take `endpoints` as a subcommand to display them.

Option B is invalid because `oc get routes` has no `--show-endpoints` flag, and Routes are OpenShift ingress objects, not the Service endpoint mechanism. Option C is invalid because `oc get pods` has no `--endpoints` flag and pods do not expose endpoint lists in that manner.

Exam trap

EX280 often tests the correct CLI syntax for inspecting endpoints — candidates pick plausible-sounding but non-existent flags like --show-endpoints or --endpoints, when the valid commands are `oc get endpoints` and `oc describe service`.

Practice this question →

24

MCQhard

An administrator configures an EgressFirewall in a namespace to deny all external traffic except for a specific CIDR block. In what order are the rules in an EgressFirewall evaluated?

A.Allow rules are evaluated first, followed by deny rules.

B.Deny rules always take precedence over allow rules regardless of order.

C.In sequential order (top to bottom), stopping at the first matching rule.

D.Alphabetically by rule description.

AnswerC

EgressFirewall rules are evaluated sequentially from top to bottom, with evaluation halting at the first rule that matches the traffic. This deterministic first-match behaviour satisfies the scenario's requirement to deny all external traffic except the specified CIDR block, so the allow rule for that block must precede any broader deny rule.

Why this answer

EgressFirewall rules are evaluated in sequential order from top to bottom, and the first rule that matches the traffic is applied. Once a match is found, no further rules are evaluated. This is similar to firewall rule processing in traditional firewalls.

Therefore, the order of rules is critical for achieving the desired allow/deny behavior.

Exam trap

EX280 often tests the evaluation order of EgressFirewall rules, and candidates may assume that deny rules always win or that allow rules are processed first, leading to incorrect rule placement.

How to eliminate wrong answers

Option A is wrong because there is no implicit priority for allow rules; evaluation is strictly by order. Option B is wrong because deny rules do not automatically take precedence; a deny rule only takes effect if it is encountered before any matching allow rule. Option D is wrong because rules are not evaluated alphabetically by description; descriptions are for human readability only.

Practice this question →

25

Multi-Selecteasy

Which TWO commands are used to check the health and status of the cluster networking operator? (Choose TWO)

Select 2 answers

A.oc get routes --all-nodes

B.oc describe clusteroperator network

C.oc adm network status

D.oc get clusteroperators

E.oc top network

AnswersB, D

`oc describe clusteroperator network` reports the network operator's conditions, versions and reconciliation messages, directly satisfying the stem's requirement to check health and status. Unlike `oc get`, it exposes the detailed condition reasons and last transition times needed to diagnose a degraded cluster networking operator.

Why this answer

Option B, `oc describe clusteroperator network`, is correct because it shows the detailed status of the network ClusterOperator, including its conditions (Available, Progressing, Degraded), related messages, and version, which directly reflects the health of the cluster networking operator. Option D, `oc get clusteroperators`, is correct because it lists all ClusterOperators with their AVAILABLE, PROGRESSING, and DEGRADED columns, letting you quickly verify whether the network operator is healthy. Option A, `oc get routes --all-nodes`, is invalid since `--all-nodes` is not a valid flag for `oc get routes` and routes are not the operator's status object.

Option C, `oc adm network status`, is not a real OpenShift command for checking the network operator. Option E, `oc top network`, is not a valid subcommand of `oc top`, which supports resources like pods and nodes, not network operator health.

Exam trap

EX280 often tests whether candidates know the correct oc subcommands for operator health — fabricated commands like 'oc adm network status' or 'oc top network' look plausible but do not exist, so candidates must recognize the real ClusterOperator inspection commands.

Practice this question →

26

MCQeasy

An administrator needs to expose an existing deployment using a quick command without writing a YAML manifest. Which command exposes port 8080 of a deployment named 'my-app' as a Service?

A.oc expose deployment my-app --port=8080

B.oc expose pod my-app --port=8080

C.oc service create my-app --port=8080

D.oc create service my-app --port=8080

AnswerA

The oc expose command generates a Service object directly from an existing resource, with --port specifying the container port to expose. Naming the deployment my-app and port 8080 satisfies the stem's requirement to avoid writing a YAML manifest.

Why this answer

The 'oc expose' command creates a Service from an existing resource. Using 'oc expose deployment my-app --port=8080' generates a Service that targets the deployment's pods on port 8080, without requiring a YAML manifest. This is the standard imperative approach.

Exam trap

The trap is mixing up 'oc expose' with 'oc create service' — candidates forget that 'oc expose' is the imperative shortcut specifically designed for this use case.

How to eliminate wrong answers

Option B is wrong because 'oc expose pod' exposes a single pod, not a deployment, and would not provide the load-balanced Service behavior expected for a deployment. Option C is wrong because 'oc service create' is not a valid oc subcommand. Option D is wrong because 'oc create service' requires a manifest file or explicit parameters and is not the quick expose syntax; 'oc expose' is the correct imperative command.

Practice this question →

27

Multi-Selectmedium

When configuring a NetworkPolicy in OpenShift, which THREE options represent valid components or fields within a NetworkPolicy specification? (Choose THREE)

Select 3 answers

A.podSelector

B.routeSelector

C.clusterIP

D.ingress

E.policyTypes

AnswersA, D, E

podSelector is a required field in the NetworkPolicy spec, defining which pods in the namespace the policy applies to via label matching. It satisfies the stem's requirement for a valid specification component, sitting alongside ingress/egress rules and policyTypes to scope enforcement.

Why this answer

Option A (podSelector) is correct because it is a core field of the Kubernetes/OpenShift NetworkPolicy spec that selects the pods to which the policy applies, using label selectors. Option D (ingress) is correct because ingress is a valid rule block that defines which inbound traffic is allowed to the selected pods, including from, ports, and protocol details. Option E (policyTypes) is correct because it explicitly lists which policy types the NetworkPolicy covers, valid values being Ingress, Egress, or both.

Option B (routeSelector) is not a NetworkPolicy field; routes are OpenShift Route objects and are not selected by NetworkPolicy. Option C (clusterIP) is not a NetworkPolicy field; it is a Service attribute assigned to a Service's virtual IP, not part of the NetworkPolicy specification.

Exam trap

EX280 often tests whether candidates confuse NetworkPolicy fields with Service or Route fields — clusterIP and routeSelector are deliberately planted as plausible-sounding but API-invalid options.

Practice this question →

28

MCQeasy

An administrator wants to view the public URL assigned to an existing Route named 'webapp'. Which oc command is best suited to extract only the host URL value?

A.oc get route webapp --show-url

B.oc describe route webapp --url

C.oc extract route/webapp --field=host

D.oc get route webapp -o jsonpath='{.spec.host}'

AnswerD

The jsonpath output flag extracts only the host field from the Route object, returning the bare URL without headers or extra fields. This satisfies the requirement to isolate the host value rather than dumping the full YAML or JSON definition.

Why this answer

The `oc get route webapp -o jsonpath='{.spec.host}'` command uses JSONPath to extract exactly the value of the `spec.host` field from the Route object, which is the public URL assigned to the Route. This is the most precise and script-friendly way to retrieve only the host value without any additional formatting or metadata. The `-o jsonpath` output option is a standard Kubernetes/OpenShift mechanism for field-level extraction.

Exam trap

EX280 often tests the difference between `oc get` with output formatting (like `-o jsonpath`) and `oc describe`, as well as invalid flags that seem plausible but are not supported.

How to eliminate wrong answers

Option A is wrong because `--show-url` is not a valid flag for `oc get route`; the command would fail with an unknown flag error. Option B is wrong because `oc describe route` does not support a `--url` flag and would output the full human-readable description, not just the URL. Option C is wrong because `oc extract` is used to extract files from a container image or a ConfigMap/Secret, not to retrieve a single field from a Route resource; the `--field` flag is not valid for this purpose.

Practice this question →

29

MCQeasy

An administrator wants to test network connectivity from a pod named 'app-pod-1' to a service port on 'backend-service' using TCP. Which tool is commonly available and ideal for testing TCP port connectivity inside a container?

A.ifconfig

B.traceroute

C.nc

D.ping

AnswerC

nc (netcat) opens a raw TCP connection to a host and port, so it directly verifies whether the service port accepts connections from inside the container. It is present in most images and needs no cluster-level tooling, unlike curl or ping.

Why this answer

'nc' (netcat) is the standard tool for testing TCP/UDP port connectivity from inside a container because it can open a raw TCP connection to a specific host and port, e.g., 'nc -zv backend-service 8080'. It is included in many base images and is the go-to utility for verifying that a Service port is reachable and that network policies or firewalls are not blocking traffic.

Exam trap

EX280 often tests the difference between ICMP-based tools (ping, traceroute) and TCP-based tools (nc, curl) — candidates pick ping because it's familiar, but ping cannot verify TCP port connectivity.

How to eliminate wrong answers

Option A (ifconfig) is wrong because it only displays network interface configuration (IP addresses, MTU, etc.) and cannot test connectivity to a remote port. Option B (traceroute) is wrong because it traces the network path hop-by-hop using ICMP/UDP and does not verify TCP port reachability — it also often fails in containers due to missing privileges. Option D (ping) is wrong because it uses ICMP echo requests, which test host reachability, not TCP port availability, and ICMP is frequently blocked in Kubernetes environments.

Practice this question →

30

MCQhard

An administrator observes that pods in a specific namespace are unable to resolve external domain names (e.g., www.redhat.com) while internal service resolution works perfectly. What is the most likely cause of this issue in CoreDNS configuration?

A.The API server service is missing endpoint IPs.

B.NodePort range exhaustion prevents external DNS packets from traversing worker nodes.

C.The cluster ingress controller is blocking external UDP port 53.

D.The Corefile in the cluster DNS operator configuration has incorrect or missing forward plugins for external resolvers.

AnswerD

Internal names resolve because CoreDNS serves cluster zones locally, but external lookups require the forward plugin pointing to upstream resolvers. A missing or incorrect forward directive in the Corefile means external queries have no upstream, so only cluster-internal resolution succeeds.

Why this answer

CoreDNS handles all DNS resolution in OpenShift, and its behavior is driven by the Corefile managed by the DNS Operator. Internal service names resolve via the kubernetes plugin, but external names like www.redhat.com require the forward plugin pointing to upstream resolvers (e.g., /etc/resolv.conf or explicit IPs). If the forward plugin is missing or misconfigured, internal resolution still works while external lookups fail with SERVFAIL or NXDOMAIN.

Exam trap

EX280 often tests the misconception that DNS failures are always network or firewall issues, when in OpenShift the Corefile's forward plugin configuration is the usual culprit for selective external resolution failures.

How to eliminate wrong answers

Option A is wrong because missing API server endpoints would break cluster API access and internal service discovery, not selectively break external DNS resolution. Option B is wrong because NodePort range exhaustion affects Service exposure on nodes, not outbound UDP/53 traffic from pods to CoreDNS or upstream resolvers. Option C is wrong because the ingress controller handles HTTP/HTTPS ingress traffic, not pod DNS queries, which are resolved by CoreDNS via the cluster DNS service IP.

Practice this question →

31

MCQhard

An administrator wants to configure a NetworkPolicy that allows incoming traffic only from pods with the label 'role=frontend' residing in any namespace, provided those namespaces have the label 'environment=production'. How should the namespaceSelector and podSelector be combined?

A.By referencing an external ClusterRole binding with label selectors

B.In the same ingress 'from' array item, combining namespaceSelector and podSelector

C.Using a peerSelector object that nests both labels

D.In separate ingress rules, where one rule has namespaceSelector and another has podSelector

AnswerB

Placing namespaceSelector and podSelector in the same from array item ANDs them, so traffic must originate from a pod labelled role=frontend within a namespace labelled environment=production. Separate array items would OR the conditions, breaking the requirement.

Why this answer

In Kubernetes NetworkPolicy, when you specify a single ingress rule with a 'from' array item that contains both namespaceSelector and podSelector, the two selectors are ANDed together. This means traffic is allowed only from pods that match the podSelector AND reside in namespaces that match the namespaceSelector. This exactly meets the requirement: pods with label 'role=frontend' in any namespace labeled 'environment=production'.

Exam trap

EX280 often tests the difference between AND and OR semantics in NetworkPolicy selectors, trapping candidates who assume that separate rules combine with AND instead of OR.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy does not reference ClusterRole bindings; that is an RBAC concept, not a network policy selector. Option C is wrong because there is no 'peerSelector' object in the NetworkPolicy API; the correct fields are 'namespaceSelector' and 'podSelector' within a NetworkPolicyPeer. Option D is wrong because placing namespaceSelector and podSelector in separate ingress rules creates an OR condition, allowing traffic from any pod in the selected namespaces OR from pods with the label in any namespace, which is broader than intended.

Practice this question →

32

MCQmedium

An administrator notices that pods on different worker nodes cannot communicate with each other. Upon checking the cluster network operator, it appears the MTU settings between the underlying physical network and the cluster overlay network mismatch. Which OpenShift command checks the cluster network operator status?

A.oc get cni cluster

B.oc describe networkconfig

C.oc get nodes --show-mtu

D.oc get clusteroperator network

AnswerD

The Cluster Network Operator reports overlay health, including MTU mismatches between the physical underlay and the cluster network. Querying the network ClusterOperator object surfaces its status conditions, letting the administrator confirm the operator's degraded state before adjusting the MTU.

Why this answer

The Cluster Network Operator (CNO) status is exposed as a clusteroperator resource named 'network'. Running 'oc get clusteroperator network' shows the operator's availability, progress, and any degraded conditions, which is the standard way to check network operator health. This command directly queries the operator's status.

Exam trap

EX280 often tests the correct resource name for the network operator ('clusteroperator network') versus fictitious resources like 'cni cluster' or 'networkconfig', so candidates must know the exact oc command syntax.

How to eliminate wrong answers

Option A is wrong because 'oc get cni cluster' is not a valid resource/command combination in OpenShift. Option B is wrong because 'oc describe networkconfig' is not a valid resource; the correct resource is 'network.config.openshift.io'. Option C is wrong because 'oc get nodes --show-mtu' is not a real flag; MTU is not displayed via that option.

Practice this question →

33

Multi-Selectmedium

Which THREE actions can be performed using the IngressController custom resource? (Choose THREE)

Select 3 answers

A.Modifying the core Kubernetes API server port.

B.Defining the container security context constraints for worker nodes.

C.Scaling the number of router replicas.

D.Setting the endpoint publishing strategy (e.g., LoadBalancer, HostNetwork).

E.Configuring a default wildcard TLS certificate for routes.

AnswersC, D, E

The IngressController custom resource includes a `replicas` field that directly controls how many router pods the OpenShift ingress operator deploys, satisfying the requirement to scale router capacity. Setting this value triggers the operator to reconcile the deployment, adjusting replica count without manual intervention.

Why this answer

Option C is correct because the IngressController custom resource includes a replicas field that controls the number of router pods deployed by the OpenShift ingress operator, allowing administrators to scale router replicas declaratively. Option D is correct because the IngressController CR exposes the endpointPublishingStrategy field, which lets you choose how the router is exposed, such as LoadBalancerService, HostNetwork, NodePortService, or Private. Option E is correct because the IngressController CR supports the defaultCertificate field, which references a TLS secret used as the wildcard certificate for routes that do not specify their own certificate.

Option A is not correct because the core Kubernetes API server port is configured on the kube-apiserver static pod or API server arguments, not through the IngressController CR. Option B is not correct because security context constraints for worker nodes are managed via SCC objects and node configuration, not through the IngressController custom resource.

Exam trap

EX280 often tests whether candidates attribute unrelated cluster settings (API server port, node SCCs) to the IngressController CR, so pick only the router-scaling, publishing-strategy, and default-certificate options.

Practice this question →

34

Multi-Selectmedium

Which THREE of the following components are part of the standard OpenShift Ingress architecture? (Choose THREE)

Select 3 answers

A.IngressController Custom Resource

B.HAProxy-based router pods

C.ClusterNetwork operator

D.Ingress Operator

E.EgressFirewall controller

AnswersA, B, D

The IngressController Custom Resource defines and configures the ingress operator's managed router deployment, specifying replicas, node placement and endpoint publishing strategy. It is a core declarative component of the standard OpenShift Ingress architecture, satisfying the stem's requirement for an architectural element rather than a client or workload object.

Why this answer

Option A (IngressController Custom Resource) is correct because the Ingress Operator manages one or more IngressController custom resources that define how the OpenShift router is deployed and configured, including replicas, node placement, and endpoint publishing strategy. Option B (HAProxy-based router pods) is correct because the default OpenShift ingress data plane is implemented by router pods running HAProxy, which terminate and route external HTTP/HTTPS traffic to Services based on Routes and Ingress objects. Option D (Ingress Operator) is correct because it is the cluster operator responsible for deploying, configuring, and reconciling the IngressController resources and their backing router deployments.

Option C (ClusterNetwork operator) does not belong because it manages the cluster's pod network (OVN-Kubernetes/CNI, network plugin configuration), not the ingress routing layer. Option E (EgressFirewall controller) does not belong because it enforces egress traffic policies for namespaces, which is unrelated to the standard ingress architecture.

Exam trap

The trap is including network-related operators like ClusterNetwork or EgressFirewall because they sound infrastructure-related, but ingress architecture is specifically about the IngressController, router pods, and Ingress Operator.

Practice this question →

35

Multi-Selecteasy

Which TWO tools or protocols can an administrator use to verify internal cluster DNS resolution from a pod? (Choose TWO)

Select 2 answers

A.ping

B.nslookup

C.ifconfig

D.top

E.dig

AnswersB, E

Running nslookup inside a pod queries the cluster DNS service directly, confirming that CoreDNS resolves internal service names to ClusterIP addresses. It satisfies the stem's requirement to verify internal cluster DNS resolution from a pod, testing the pod's configured resolver path end to end.

Why this answer

nslookup (B) is correct because it is a DNS query utility that can be run from inside a pod to resolve cluster service names against the cluster DNS server (CoreDNS/kube-dns) and confirm the returned A/AAAA records. dig (E) is also correct because it performs direct DNS lookups and shows detailed query/response data, including the resolver used and answer records, making it ideal for verifying internal cluster DNS resolution. ping (A) only tests ICMP reachability and name-to-address resolution incidentally, so it does not specifically validate DNS query behavior. ifconfig (C) merely displays network interface configuration and addresses, and top (D) shows process/resource usage, neither of which queries DNS.

Exam trap

EX280 often tests whether candidates confuse network troubleshooting tools (ping, ifconfig) with DNS-specific query tools (dig, nslookup), so the trap is selecting ping because it 'tests connectivity' when the question specifically asks about DNS resolution verification.

Practice this question →

36

MCQmedium

An administrator created a Route but external clients receive a 503 Service Unavailable error when attempting to access it. Upon checking the endpoints of the Service referenced by the Route, the administrator discovers there are zero endpoints listed. What is the most likely cause?

A.The Route YAML has an invalid TLS certificate format.

B.The Ingress controller pods have crashed across all worker nodes.

C.The cluster DNS operator is degraded.

D.The Service selector labels do not match any active Pod labels.

AnswerD

A Service with zero endpoints means its selector matches no running Pod labels, so the router has no backend to forward to and returns 503; correcting the selector or Pod labels restores endpoints and traffic.

Why this answer

A Service with zero endpoints means its label selector matched no running Pods. The Service's Endpoints object is populated by the endpoints controller, which continuously watches for Pods whose labels match the Service's spec.selector. If the selector labels don't match any active Pod labels, the endpoint list stays empty, and the router/Ingress controller has no backend to forward traffic to, returning 503 Service Unavailable.

Exam trap

EX280 often tests the distinction between Route-level failures (TLS, hostname) and Service-level failures (selector mismatch, readiness), so candidates must trace the 503 back to the empty Endpoints object rather than blaming the router or DNS.

How to eliminate wrong answers

Option A is wrong because an invalid TLS certificate on the Route would cause TLS handshake failures or certificate warnings, not a 503 with zero Service endpoints. Option B is wrong because crashed Ingress controller pods would affect all Routes cluster-wide and would not explain a Service with zero endpoints. Option C is wrong because a degraded DNS operator would cause name resolution failures, not empty Service endpoints.

Practice this question →

37

MCQeasy

An administrator wants to check the status of all cluster operators, specifically verifying that the Network and DNS operators are healthy. Which command should be run?

A.oc get clusteroperators

B.oc get operators --cluster

C.oc describe operators

D.oc adm check health

AnswerA

oc get clusteroperators lists every cluster operator with its availability, progress and degraded status columns, letting the administrator confirm whether the Network and DNS operators report healthy. It queries the operator state directly without needing per-operator inspection commands.

Why this answer

The `oc get clusteroperators` command lists all ClusterOperators in an OpenShift cluster, showing their AVAILABLE, PROGRESSING, DEGRADED, and other status conditions. This is the standard way to verify the health of core operators like the Network operator (network.operator.openshift.io) and DNS operator (dns.operator/default). Administrators use this command to quickly assess whether any operator is degraded or unavailable.

Exam trap

EX280 often tests the exact resource name and command syntax for cluster-wide health checks, and candidates may confuse `oc get clusteroperators` with non-existent commands like `oc adm check health` or `oc get operators`.

How to eliminate wrong answers

Option B is wrong because `oc get operators --cluster` is not a valid oc command; the correct resource is `clusteroperators` (or `co`). Option C is wrong because `oc describe operators` targets a non-existent resource type and would fail; `oc describe clusteroperator <name>` is the correct form for detailed output. Option D is wrong because `oc adm check health` does not exist as a command in OpenShift; health checks are performed via `oc get clusteroperators` or `oc adm top` for resource usage.

Practice this question →

38

MCQmedium

An administrator needs to configure a Route that handles encrypted communication both from the client to the router AND from the router to the backend pod. Which termination type is required?

A.reencrypt

B.passthrough

C.edge

D.secure-tunnel

AnswerA

Reencrypt termination decrypts at the router, then re-encrypts traffic to the backend pod using a separate certificate, satisfying the requirement for encryption on both the client-to-router and router-to-backend legs. Edge and passthrough terminate only one leg, leaving the backend connection unencrypted.

Why this answer

The reencrypt termination type allows the router to decrypt incoming TLS traffic and then re-encrypt it before forwarding to the backend pod, enabling end-to-end encryption with separate certificates for the client-to-router and router-to-pod legs. This satisfies the requirement for encrypted communication both from client to router and router to backend. Edge termination only encrypts client-to-router, while passthrough does not decrypt at the router at all.

Exam trap

EX280 often tests the confusion between edge and reencrypt, where candidates might think edge encrypts both legs, but only reencrypt provides encryption from router to pod.

How to eliminate wrong answers

Option B is wrong because passthrough forwards encrypted traffic directly to the pod without decryption at the router, so the router cannot re-encrypt or manage certificates, and it does not provide separate encryption for the router-to-pod leg. Option C is wrong because edge termination decrypts at the router and sends plain HTTP to the backend, so the router-to-pod leg is not encrypted. Option D is wrong because 'secure-tunnel' is not a valid OpenShift Route termination type; the valid types are edge, passthrough, and reencrypt.

Practice this question →

39

Multi-Selecthard

Which THREE actions can be performed when managing Route objects in OpenShift? (Choose THREE)

Select 3 answers

A.Attaching a container storage volume directly inside the Route spec

B.Allocating a direct BGP peering session from the Route object

C.Specifying TLS termination as edge, passthrough, or reencrypt

D.Defining a custom hostname for external access

E.Configuring path-based routing under spec.path

AnswersC, D, E

The route's spec.tls.termination field accepts edge, passthrough, or reencrypt, controlling where TLS is decrypted. This satisfies the stem because termination mode selection is a genuine Route management action, determining whether the router or the pod handles encryption.

Why this answer

Option C is correct because a Route's spec.tls.termination field accepts exactly edge, passthrough, or reencrypt, controlling where TLS is decrypted (at the router for edge, not at all for passthrough, and at the router then re-encrypted to the backend for reencrypt). Option D is correct because spec.host lets you define the externally reachable hostname (e.g., app.example.com) that the router uses to match incoming requests. Option E is correct because spec.path allows path-based routing, so a single hostname can direct /api to one Service and /web to another.

Option A is wrong because storage volumes belong to Pods/Deployments via PersistentVolumeClaims, not to Route specs, which only handle HTTP(S) ingress. Option B is wrong because BGP peering is a networking concern handled by the cluster's SDN/OVN or MetalLB, not by Route objects, which are HAProxy-based ingress definitions.

Exam trap

EX280 often tests the specific capabilities of Route objects versus other OpenShift resources. Candidates might incorrectly assume Routes can manage storage or network peering, but Routes are strictly for HTTP/HTTPS ingress with TLS and path-based routing features.

Practice this question →

40

Multi-Selectmedium

Which TWO methods can an administrator use to troubleshoot why a pod cannot connect to a remote Service? (Choose TWO)

Select 2 answers

A.Verifying that the target service has valid endpoints pointing to running pods.

B.Using nc or curl from inside a debug pod to test connectivity to the service IP and port.

C.Restarting the cluster storage provider pods.

D.Deleting all persistent volume claims.

E.Modifying the global MachineConfig pool.

AnswersA, B

A Service without valid endpoints, caused by a mismatched selector or unready pods, silently drops traffic. Checking endpoints confirms whether the Service actually maps to running pod IPs, satisfying the requirement to verify the target before deeper network diagnosis.

Why this answer

Option A is correct because a Service only forwards traffic to pods that match its selector and are Ready, so checking that the Service has valid Endpoints (via kubectl get endpoints or kubectl describe svc) confirms whether the Service is actually backed by running pods and is essential to diagnosing connectivity failures. Option B is correct because running nc or curl from inside a debug pod directly tests L3/L4 reachability to the Service ClusterIP and port, helping isolate whether the problem is DNS, network policy, kube-proxy, or the application itself. Options C, D, and E are unrelated to Service connectivity troubleshooting: restarting storage provider pods addresses storage/CSI issues, deleting PVCs affects persistent volume binding, and modifying a MachineConfig pool changes node-level configuration, none of which diagnose why a pod cannot reach a remote Service.

Exam trap

EX280 often tests troubleshooting methodology, and candidates may choose actions that are unrelated to networking, like restarting storage pods or deleting PVCs, instead of focusing on Service endpoints and connectivity tests.

Practice this question →

41

MCQmedium

An administrator notices that client source IP addresses are lost when traffic hits a Service of type NodePort, appearing instead as a node IP. Which field in the Service specification should be changed to 'Local' to preserve client source IPs?

A.externalTrafficPolicy: Local

B.publishNotReadyAddresses: true

C.sessionAffinity: ClientIP

D.ipFamilyPolicy: RequireDualStack

AnswerA

Setting `externalTrafficPolicy: Local` stops kube-proxy from masquerading traffic to other nodes, so only pods on the receiving node answer and the original client source IP survives. The default `Cluster` policy forwards across nodes and rewrites the source to a node IP, which is exactly the loss described.

Why this answer

externalTrafficPolicy: Local preserves the client source IP by only routing traffic to pods on the same node that received the request, avoiding the SNAT that occurs when kube-proxy forwards to a pod on another node. With the default Cluster policy, traffic can be forwarded to any node's pod, causing the source IP to be rewritten to the node's IP. Setting it to Local ensures the original client IP is retained for the backend pod.

Exam trap

EX280 often tests the misconception that sessionAffinity or other Service fields can preserve source IPs, when only externalTrafficPolicy: Local achieves this by preventing SNAT.

How to eliminate wrong answers

Option B is wrong because publishNotReadyAddresses controls whether DNS records include not-ready endpoints, not source IP preservation. Option C is wrong because sessionAffinity: ClientIP only ensures that requests from the same client IP stick to the same pod; it does not prevent SNAT or preserve the original source IP. Option D is wrong because ipFamilyPolicy: RequireDualStack configures dual-stack IP families for the Service, unrelated to source IP preservation.

Practice this question →

42

MCQeasy

An administrator needs to create a passthrough Route that preserves client certificates and forwards encrypted traffic directly to the backend pod. Which spec configuration is required?

A.spec: tls: termination: passthrough

B.spec: tls: termination: reencrypt

C.spec: tls: termination: edge

D.spec: tls: insecureEdgeTerminationPolicy: Allow

AnswerA

Passthrough termination makes the router forward the TLS handshake untouched, so the backend pod terminates encryption and sees the client certificate directly. Edge or re-encrypt termination would decrypt at the router, breaking the requirement to preserve client certificates end to end.

Why this answer

A passthrough Route uses 'spec.tls.termination: passthrough', which tells the HAProxy router to forward the encrypted TLS connection directly to the backend pod without decrypting it. This preserves client certificates end-to-end and is required when the backend must handle TLS itself.

Exam trap

EX280 often tests whether candidates pick 'reencrypt' thinking it preserves client certs, when only 'passthrough' forwards the encrypted stream end-to-end without router termination.

How to eliminate wrong answers

Option B is wrong because 'reencrypt' terminates TLS at the router and re-encrypts to the backend, which breaks end-to-end client certificate preservation. Option C is wrong because 'edge' terminates TLS at the router and forwards plain HTTP to the backend, so client certificates never reach the pod. Option D is wrong because 'insecureEdgeTerminationPolicy' is a sub-field that controls HTTP fallback behavior for edge/reencrypt Routes, not a termination type, and it is meaningless for passthrough.

Practice this question →

43

MCQeasy

An administrator needs to check the internal DNS resolution of a service named 'backend' within the 'production' namespace from a debug pod. Which DNS name is fully qualified and valid within the cluster?

A.backend.production.pod.cluster.local

B.backend.production.router.default.svc

C.svc.production.backend.cluster.local

D.backend.production.svc.cluster.local

AnswerD

backend.production.svc.cluster.local follows Kubernetes' cluster DNS schema: service, namespace, "svc", then the cluster domain. It satisfies the stem's requirement for a fully qualified name resolving the 'backend' service in the 'production' namespace from any debug pod, without relying on search-domain expansion.

Why this answer

In OpenShift/Kubernetes, the fully qualified domain name (FQDN) for a Service follows the pattern <service>.<namespace>.svc.cluster.local. For the service 'backend' in the 'production' namespace, the correct FQDN is backend.production.svc.cluster.local. This DNS name resolves to the ClusterIP of the service, allowing internal cluster communication.

Exam trap

EX280 often tests the exact ordering of the DNS components, and candidates may mistakenly put the namespace before the service name or use 'pod' instead of 'svc', leading to incorrect answers.

How to eliminate wrong answers

Option A is wrong because it uses 'pod.cluster.local' instead of 'svc.cluster.local'; pod DNS names are typically of the form <pod-ip>.<namespace>.pod.cluster.local and are not used for service resolution. Option B is wrong because it includes 'router.default.svc', which is not part of the standard service DNS hierarchy and suggests a route or ingress, not a service. Option C is wrong because it reverses the order of service and namespace; the correct order is service first, then namespace, then 'svc', then 'cluster.local'.

Practice this question →

44

MCQmedium

A developer reports that a Service in the project `webapp` is not exposing the expected endpoints, even though the Deployment shows all replicas Running. The administrator inspects the Service and sees the selector is `app: web-frontend`. Which command should the administrator run to verify whether the Pods actually carry the labels the Service selector expects?

A.oc get endpoints webapp -n webapp

B.oc get networkpolicy -n webapp

C.oc describe deployment webapp -n webapp

D.oc get pods -n webapp --show-labels

AnswerD

This command lists every Pod in the `webapp` namespace together with its full label set, letting the administrator compare the Pod labels against the Service selector `app: web-frontend`. If the labels differ, the Service has no matching endpoints, which explains the empty endpoint list. It is the direct, namespace-scoped way to confirm label alignment.

Why this answer

A Service selects backend Pods purely by label matching against its selector. When a Deployment is healthy but the Service has no endpoints, the most common cause is a mismatch between the Service selector and the labels applied to the Pod template. Listing Pods with their labels exposes that mismatch directly, allowing the administrator to correct either the selector or the Pod labels.

Exam trap

The trap here is assuming a healthy Deployment guarantees Service endpoints, when endpoint membership depends entirely on label selector agreement between the Service and the Pods.

Practice this question →

45

Multi-Selecteasy

Which THREE network-related objects are namespaced in OpenShift? (Choose THREE)

Select 3 answers

A.ClusterNetwork

B.IngressController

C.NetworkPolicy

D.Service

E.Route

AnswersC, D, E

NetworkPolicy objects are namespaced resources, scoped to a single project and applied only to pods within that namespace. This satisfies the question's requirement for namespaced network objects, unlike cluster-scoped resources such as nodes or ClusterNetwork.

Why this answer

NetworkPolicy (C) is namespaced because it is a Kubernetes resource scoped to a namespace, where its podSelector and ingress/egress rules apply only to pods within that namespace. Service (D) is namespaced since a Service is a namespaced Kubernetes object that provides a stable virtual IP and DNS name for pods in the same namespace. Route (E) is namespaced because OpenShift Routes are namespace-scoped resources that expose a Service from within that namespace to external clients.

ClusterNetwork (A) is cluster-scoped, as it defines the overall pod network CIDR configuration for the entire cluster. IngressController (B) is also cluster-scoped, since it configures the ingress controller operator for the whole OpenShift cluster rather than a single namespace.

Exam trap

EX280 often tests whether candidates can distinguish namespaced from cluster-scoped resources, so the trap is assuming that all network-related objects are namespaced and selecting ClusterNetwork or IngressController, which are actually cluster-scoped.

Practice this question →

46

Multi-Selectmedium

Which THREE conditions must be met for a NetworkPolicy to successfully allow traffic from another pod? (Choose THREE)

Select 3 answers

A.The cluster must have exactly three worker nodes.

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

C.If an ingress policy is present, the connection must be explicitly permitted by at least one rule.

D.The target port and protocol specified in the NetworkPolicy must match the traffic.

E.The source pod must match the podSelector or namespaceSelector specified in the ingress rule.

AnswersC, D, E

Kubernetes NetworkPolicy is default-deny once any policy selects the target pod. If an ingress policy exists, every inbound connection must be explicitly permitted by at least one ingress rule; unmatched traffic is dropped regardless of other conditions.

Why this answer

Option C is correct because Kubernetes NetworkPolicy is default-deny for ingress once any policy selects the pod: if an ingress policy exists, the connection must be explicitly allowed by at least one ingress rule, otherwise the traffic is dropped. Option D is correct because the policy's ports and protocol fields (e.g., port: 6379, protocol: TCP) must match the actual destination port and L4 protocol of the traffic for the rule to permit it. Option E is correct because the ingress rule's from selectors — podSelector and/or namespaceSelector — must match the source pod's labels and namespace for the connection to be allowed.

Option A is wrong because NetworkPolicy enforcement is independent of the number of worker nodes; it depends on a CNI plugin that implements NetworkPolicy (e.g., Calico, Cilium), not cluster size. Option B is wrong because NetworkPolicy operates at the pod/CNI layer inside the cluster and does not require any top-of-rack switch port trunk configuration.

Exam trap

The trap is overthinking the infrastructure layer — candidates may pick physical switch or node-count options, but NetworkPolicy is purely a logical Kubernetes construct with three specific matching conditions.

Practice this question →

47

MCQmedium

An administrator needs to modify the timeout values for the default OpenShift Ingress Controller (Router). Where should this change be applied?

A.Edit the proxy resource named 'cluster'.

B.Edit the ingresscontroller instance named 'default' in the 'openshift-ingress-operator' namespace.

C.Edit the endpoints resource in the 'openshift-ingress' namespace.

D.Modify the kube-apiserver configmap.

AnswerB

Editing the ingresscontroller custom resource named 'default' in the openshift-ingress-operator namespace is the supported method: the Ingress Operator reconciles this resource and propagates the timeout settings to the managed router deployment. Directly patching router pods or the router deployment would be overwritten, so the operator-managed CR satisfies the persistence constraint.

Why this answer

The OpenShift Ingress Controller (Router) is managed by the Ingress Operator. To change timeout values, you must modify the IngressController custom resource named 'default' in the 'openshift-ingress-operator' namespace. This is the supported method because the Operator reconciles the router deployment and its configuration based on this resource.

Directly editing the router's configmap or deployment is not persistent and will be overwritten by the Operator.

Exam trap

EX280 often tests the misconception that directly editing the router's configmap or deployment is the way to change router settings, but the correct approach is to modify the IngressController custom resource managed by the Operator.

How to eliminate wrong answers

Option A is wrong because the 'cluster' proxy resource is used to configure cluster-wide proxy settings for OpenShift components, not Ingress Controller timeouts. Option C is wrong because the endpoints resource in 'openshift-ingress' namespace lists the IP addresses of the router pods and does not control router configuration. Option D is wrong because the kube-apiserver configmap is used to configure the Kubernetes API server, not the Ingress Controller; modifying it would have no effect on router timeouts and could break the API server.

Practice this question →

48

MCQmedium

An administrator configures a LoadBalancer service on an OpenShift cluster running on a cloud provider. However, the EXTERNAL-IP remains in a <pending> state indefinitely. What is the most likely reason?

A.The cluster is missing a valid Ingress controller deployment.

B.The cloud controller manager or cloud credentials operator is not configured to provision external load balancers.

C.The NetworkPolicy is blocking cloud provider traffic.

D.The NodePort range is exhausted.

AnswerB

Without a functioning cloud controller manager or properly configured cloud credentials operator, OpenShift cannot call the cloud provider's API to provision the external load balancer, so the EXTERNAL-IP stays `<pending>`. This directly satisfies the stem's cloud-provider constraint: the LoadBalancer service requires cloud integration to allocate an external address.

Why this answer

When a LoadBalancer service on a cloud provider remains in <pending> for EXTERNAL-IP, the most common cause is that the cloud controller manager (or the cloud credentials operator in OpenShift) is not properly configured to provision external load balancers. Without valid cloud credentials and a functioning CCM, OpenShift cannot create the underlying cloud LB resource, leaving the service without an external IP.

Exam trap

EX280 often tests the misconception that Ingress controllers or NetworkPolicies affect LoadBalancer service provisioning, when the real dependency is the cloud controller manager and cloud credentials operator.

How to eliminate wrong answers

Option A is wrong because a missing Ingress controller affects Route/Ingress functionality, not the provisioning of a LoadBalancer service's external IP — LoadBalancer services are handled by the cloud controller manager, not the Ingress controller. Option C is wrong because NetworkPolicy governs pod-to-pod traffic within the cluster and does not block the cloud provider's control-plane API calls needed to provision a load balancer. Option D is wrong because NodePort range exhaustion would cause a different error (service creation failure or port allocation error), not a perpetually pending EXTERNAL-IP.

Practice this question →

49

MCQmedium

A cluster administrator needs to inspect the current default CNI network provider configured in an OpenShift 4.14 cluster. Which command or resource should the administrator check?

A.oc get dns cluster -o jsonpath='{.spec.baseDomain}'

B.oc get proxy cluster -o jsonpath='{.spec.httpProxy}'

C.oc get clusterversion version -o jsonpath='{.status.capabilities}'

D.oc get networks.config/cluster -o jsonpath='{.spec.networkType}'

AnswerD

The cluster network configuration object stores the active CNI plugin in its spec.networkType field, so querying networks.config/cluster returns the deployed provider directly. This satisfies the requirement to inspect the current default CNI on OpenShift 4.14 without inferring it from pod annotations or node state.

Why this answer

In OpenShift 4.x, the cluster-wide network configuration is stored in the networks.config.openshift.io/cluster resource, and the CNI plugin in use is exposed in the spec.networkType field. Running `oc get networks.config/cluster -o jsonpath='{.spec.networkType}'` returns the configured network plugin, typically OpenShiftSDN or OVNKubernetes. This is the authoritative place to inspect the default CNI provider.

Exam trap

EX280 often tests whether candidates know that the CNI provider lives in the networks.config.openshift.io/cluster object rather than in the dns, proxy, or clusterversion operator resources — the similar 'oc get <operator> cluster' syntax across these objects is the trap.

How to eliminate wrong answers

Option A is wrong because `oc get dns cluster` reads the cluster DNS operator configuration and its spec.baseDomain field returns the cluster's DNS base domain, not the CNI provider. Option B is wrong because `oc get proxy cluster` reads the cluster-wide proxy configuration and spec.httpProxy returns the HTTP proxy URL, which is unrelated to the CNI plugin. Option C is wrong because `oc get clusterversion version` reports the OpenShift version and its status.capabilities field lists optional cluster capabilities (like the ones that can be disabled), not the network provider.

Practice this question →

50

Multi-Selecthard

Which THREE troubleshooting steps should an administrator take when a newly created Route fails to resolve or connect? (Choose THREE)

Select 3 answers

A.Reinstall the entire cluster storage operator.

B.Check that the Route hostname resolves correctly via DNS to the cluster router IP.

C.Verify that the referenced Service has active endpoints.

D.Inspect the Ingress controller operator logs for routing errors.

E.Modify the cluster kube-apiserver certificates.

AnswersB, C, D

A Route only works if its hostname resolves to the router's external IP; verifying DNS resolution confirms whether the failure lies in name resolution rather than the Route or Service configuration, isolating the fault domain.

Why this answer

Option B is correct because a Route only works if its hostname resolves via DNS to the cluster's router (Ingress controller) IP; if DNS points elsewhere or does not resolve, clients cannot reach the route. Option C is correct because a Route forwards to a Service, and if that Service has no active endpoints (e.g., selector mismatch or unready pods), the router returns 503 and the route appears broken. Option D is correct because the Ingress controller operator/router logs record routing errors such as missing TLS secrets, invalid route admission, or backend failures, making them the primary diagnostic source.

Option A is wrong because reinstalling the entire cluster storage operator is unrelated to Route resolution and would not fix DNS, Service, or router issues. Option E is wrong because modifying kube-apiserver certificates is a destructive, unrelated action that does not affect Route hostname resolution or backend connectivity.

Exam trap

EX280 often tests the layered troubleshooting approach for Routes — candidates focus only on the Route object itself and forget to check DNS resolution, Service endpoints, and Ingress controller logs, which are the actual common failure points.

Practice this question →

51

MCQeasy

An administrator needs to create a Route that handles multiple subdomains or redirects insecure HTTP traffic to HTTPS automatically. Where is the insecure traffic redirect configured?

A.route.openshift.io/handling: insecure-redirect

B.tls.allowInsecure: true

C.insecureEdgeTerminationPolicy: Redirect

D.spec.redirectHTTP: enabled

AnswerC

Setting insecureEdgeTerminationPolicy to Redirect makes the OpenShift router answer plain HTTP on the route's host with a 301 to the HTTPS URL. This satisfies the automatic redirect requirement without a separate route or frontend configuration.

Why this answer

In OpenShift, a Route's TLS configuration includes the `insecureEdgeTerminationPolicy` field, which controls how non-TLS (HTTP) traffic is handled when the Route is configured for edge or re-encrypt termination. Setting it to `Redirect` makes the router automatically issue an HTTP 302 redirect to the HTTPS URL, ensuring all insecure traffic is upgraded. This is the standard, supported mechanism for enforcing HTTPS on a Route.

Exam trap

EX280 often tests the exact field name and location for redirecting insecure traffic, and candidates may confuse it with non-existent annotations or assume a boolean flag like `allowInsecure` exists.

How to eliminate wrong answers

Option A is wrong because `route.openshift.io/handling` is not a valid annotation or field in OpenShift; there is no such handling directive. Option B is wrong because `tls.allowInsecure` is not a valid field in a Route spec; while `insecureEdgeTerminationPolicy` can be set to `Allow` to permit HTTP, there is no boolean `allowInsecure` property. Option D is wrong because `spec.redirectHTTP` does not exist in the Route API; redirection is controlled exclusively via `insecureEdgeTerminationPolicy`.

Practice this question →

52

MCQmedium

An administrator needs to configure a custom default certificate for all routes created in the cluster without specifying a certificate on every individual Route object. Where should this wildcard certificate be configured?

A.In a ConfigMap named 'router-certs' in the default namespace

B.In the IngressController resource named 'default' in openshift-ingress-operator

C.In the apiserver.config.openshift.io cluster object

D.In the DNS cluster operator configuration

AnswerB

The default IngressController in openshift-ingress-operator accepts a defaultCertificate field, which the ingress operator applies to every router-generated Route lacking its own certificate. Configuring it there satisfies the stem's constraint of a cluster-wide wildcard without editing individual Route objects.

Why this answer

The wildcard default certificate for all routes is configured in the IngressController resource named 'default' in the `openshift-ingress-operator` namespace, specifically in `spec.defaultCertificate` with a Secret reference. This tells the OpenShift ingress operator to use that certificate as the fallback for any Route that does not specify its own TLS certificate. It is the cluster-wide default for edge/re-encrypt routes.

Exam trap

EX280 often tests the difference between the IngressController resource (declarative, operator-managed) and the legacy router-certs secret — candidates pick the old secret location or confuse it with the apiserver config object.

How to eliminate wrong answers

Option A is wrong because although the router historically used a `router-certs` secret in the `openshift-ingress` namespace, manually editing it is not the supported declarative method and it is not in the `default` namespace — the operator manages this. Option C is wrong because the `apiserver.config.openshift.io` cluster object configures the API server's serving certificate and named certificates, not ingress route certificates. Option D is wrong because the DNS cluster operator manages cluster DNS records and forwarding, not TLS certificates for routes.

Practice this question →

53

Multi-Selectmedium

Which THREE statements are true regarding Ingress controllers in OpenShift? (Choose THREE)

Select 3 answers

A.Administrators can create additional custom IngressController instances.

B.They replace the internal Kubernetes kube-proxy component entirely.

C.They are implemented using HAProxy router pods by default.

D.They watch both Route and Ingress resources.

E.They require manual iptables rule updates on every worker node for every new route.

AnswersA, C, D

Administrators may deploy extra IngressController custom resources beyond the default `default` instance, each bound to distinct node selectors, namespaces or endpoint publishing strategies. This satisfies the stem's requirement for true statements, since OpenShift supports multiple concurrent ingress controllers, enabling workload isolation and separate routing domains within one cluster.

Why this answer

Option A is correct because OpenShift administrators can create additional custom IngressController instances (for example, in the openshift-ingress-operator namespace) to provide separate ingress endpoints with their own HAProxy router deployments, scaling, and node placement. Option C is correct because the default OpenShift Ingress controller is implemented by the OpenShift Router, which runs HAProxy in router pods managed by the Ingress Operator. Option D is correct because the OpenShift router watches both Route resources (the OpenShift-native API) and Ingress resources (the standard Kubernetes API), serving both through the same HAProxy-based data path.

Option B is not correct because kube-proxy is a separate Kubernetes component that programs service load balancing on nodes; Ingress controllers handle HTTP/HTTPS routing and do not replace kube-proxy. Option E is not correct because the router dynamically updates its HAProxy configuration as Routes and Ingresses change, so administrators do not manually edit iptables rules on worker nodes for each new route.

Exam trap

EX280 often tests the misconception that Ingress controllers replace kube-proxy or require manual iptables updates, confusing the roles of different networking components.

Practice this question →

54

MCQhard

An administrator creates a NetworkPolicy that restricts egress traffic from a namespace. However, DNS resolution for external services immediately stops working. What is the cause of this behavior?

A.NetworkPolicies automatically disable the OpenShift SDN controller.

B.The NetworkPolicy blocks outbound traffic to port 53 on the cluster DNS service.

C.CoreDNS pods do not have valid security context constraints.

D.External DNS servers reject requests originating from OpenShift node IPs.

AnswerB

Egress NetworkPolicies are default-deny once any pod is selected, so only explicitly permitted destinations pass. Cluster DNS listens on port 53, and omitting an egress rule for it silently drops all name resolution traffic from the namespace.

Why this answer

When a NetworkPolicy selects pods for egress, it becomes default-deny for all egress traffic from those pods except what is explicitly allowed. If the policy does not include a rule permitting UDP/TCP port 53 to the cluster DNS service (usually openshift-dns in openshift-dns namespace), DNS resolution fails immediately. The fix is to add an egress rule allowing port 53 to the DNS pods or namespace.

Exam trap

EX280 often tests the default-deny behavior of NetworkPolicies — candidates forget that once a pod is selected for egress, DNS (port 53) is blocked unless explicitly allowed.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are enforced by the CNI plugin (OVN-Kubernetes or OpenShift SDN) and do not disable the SDN controller — they simply filter traffic. Option C is wrong because CoreDNS pods run with appropriate SCCs by default; SCCs govern pod security, not network reachability, and DNS failures from NetworkPolicies are not SCC-related. Option D is wrong because external DNS servers do not reject OpenShift node IPs — the failure occurs before the packet leaves the cluster, at the NetworkPolicy enforcement point.

Practice this question →

55

MCQhard

A cluster administrator notices that a NetworkPolicy applied to the database namespace is dropping traffic from the frontend namespace. The policy uses namespaceSelector. Which label must be present on the frontend namespace for traffic to be successfully allowed?

A.openshift.io/cluster-monitoring=true

B.security.openshift.io/scc=restricted

C.A custom label defined in the namespaceSelector of the NetworkPolicy spec

D.kubernetes.io/metadata.name matching the namespace name

AnswerC

A namespaceSelector matches namespaces by their labels, so the frontend namespace must carry the exact custom label key and value declared in the policy's namespaceSelector. Without that label, the selector never matches and traffic stays dropped.

Why this answer

In a NetworkPolicy, the `namespaceSelector` matches namespaces based on their labels. For traffic from the `frontend` namespace to be allowed, the `frontend` namespace must have the exact label key-value pair specified in the `namespaceSelector` of the NetworkPolicy. This label is arbitrary and defined by the administrator; it does not have to be a default OpenShift label.

Exam trap

EX280 often tests the difference between automatic labels (like `kubernetes.io/metadata.name`) and custom labels, tricking candidates into choosing a default label instead of the one defined in the policy.

How to eliminate wrong answers

Option A is wrong because `openshift.io/cluster-monitoring=true` is a label used for monitoring, not for NetworkPolicy selection unless explicitly configured. Option B is wrong because `security.openshift.io/scc=restricted` is a label related to Security Context Constraints, not namespace selection for NetworkPolicy. Option D is wrong because `kubernetes.io/metadata.name` is a label automatically added to namespaces (since Kubernetes 1.21) that contains the namespace name, but it is not the label required unless the NetworkPolicy specifically uses it; the question states the policy uses `namespaceSelector`, which requires a custom label defined in the policy.

Practice this question →

56

Multi-Selecteasy

Which TWO of the following are valid Service types supported natively in OpenShift? (Choose TWO)

Select 2 answers

A.VirtualIP

B.ClusterIP

C.IngressObject

D.NodePort

E.Route

AnswersB, D

ClusterIP is a native Kubernetes Service type, exposing an internal virtual IP reachable only within the cluster. OpenShift supports it natively, satisfying the stem's requirement for valid built-in Service types. It provides stable east-west load balancing across selected pods without external exposure, unlike NodePort or LoadBalancer.

Why this answer

Option B (ClusterIP) is correct because ClusterIP is the default Kubernetes/OpenShift Service type that exposes the Service on an internal cluster IP reachable only from within the cluster. Option D (NodePort) is correct because NodePort is a natively supported Service type that exposes the Service on each node's IP at a static port (default range 30000–32767), allowing external access via <NodeIP>:<NodePort>. The other options are not Service types: VirtualIP (A) is not a Kubernetes/OpenShift Service type, IngressObject (C) is not a Service type (Ingress is a separate API resource for HTTP/HTTPS routing), and Route (E) is an OpenShift-specific resource that exposes Services externally but is not itself a Service type.

Exam trap

EX280 often tests the distinction between native Kubernetes Service types and OpenShift-specific resources like Routes, causing candidates to mistakenly select 'Route' as a Service type.

Practice this question →

57

MCQmedium

A developer reports that pods in the namespace 'project-a' cannot resolve services located in the namespace 'project-b' using standard internal DNS names. What is the correct way to query 'project-b' service 'backend' from 'project-a'?

A.backend.project-b.svc.cluster.local

B.backend.project-b.pod.cluster.local

C.backend.project-b.svc

D.backend.project-b.internal

AnswerA

Cross-namespace DNS resolution requires the fully qualified domain name, since the search list only covers the pod's own namespace. The FQDN `backend.project-b.svc.cluster.local` satisfies the stem's constraint: pods in `project-a` resolving a service in `project-b`. The `<service>.<namespace>.svc.cluster.local` format targets that namespace explicitly.

Why this answer

The fully qualified domain name (FQDN) for a Kubernetes/OpenShift Service follows the pattern <service>.<namespace>.svc.cluster.local. Therefore, to reach the 'backend' service in namespace 'project-b' from any other namespace, the correct DNS name is backend.project-b.svc.cluster.local. This FQDN resolves via the cluster's internal DNS to the Service's ClusterIP.

Exam trap

EX280 often tests whether candidates know the exact DNS suffix hierarchy (svc.cluster.local vs pod.cluster.local vs .internal), so the trap is choosing a plausible-looking but incorrect suffix like '.svc' or '.internal' instead of the full FQDN.

How to eliminate wrong answers

Option B (backend.project-b.pod.cluster.local) is wrong because the 'pod' subdomain is used for headless services or direct pod DNS records (e.g., <pod-ip>.<namespace>.pod.cluster.local), not for standard Service resolution — using it would fail to resolve the service name. Option C (backend.project-b.svc) is wrong because while it may work as a relative name within the same cluster domain due to search domains, it is not the fully qualified name and can fail depending on the pod's resolv.conf search list; the question asks for the correct way to query cross-namespace, which requires the FQDN. Option D (backend.project-b.internal) is wrong because '.internal' is not a valid Kubernetes DNS suffix — the cluster domain is 'cluster.local' by default, and 'internal' has no special meaning in cluster DNS.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Networking And Network Policies questions.

Start 20-question session