Skip to content
Quizra

EX282 Red Hat Certified Specialist in OpenShift Networking exam Practice Questions

Prepare for EX282 with more than an answer.

150 questions in the full set12 sample questionsUpdated Oct 3, 2026
Study as flashcards
Time limit
240 minutes
Level
Specialist (Level 4)
Valid for
3 years
Domains covered on the exam 8
  1. Manage core networking in Red Hat OpenShift Container Platform14%
  2. Implement and manage user-defined networks in Red Hat OpenShift Container Platform14%
  3. Manage DNS in Red Hat OpenShift Container Platform11%
  4. Manage ingress traffic in Red Hat OpenShift Container Platform8%
  5. Manage egress traffic in Red Hat OpenShift Container Platform11%
  6. Implement native BGP routing in Red Hat OpenShift Container Platform11%
  7. Configure node networking for provider integration11%
  8. Enable network observability20%
  1. 1

    A cluster administrator needs to configure DNS query forwarding for an internal corporate domain corp.internal.example.com using the OpenShift DNS Operator. Queries must be forwarded sequentially across two corporate nameservers (10.100.0.10 and 10.100.0.11). If the primary nameserver does not answer, the secondary nameserver must be queried. Which configuration snippet under spec.servers in the dns.operator/default resource achieves this requirement?

    Show answer details

    Correct answer: D

    Under spec.servers in dns.operator/default, custom forwarding zones are configured via forwardPlugin. The policy field determines upstream server selection order; Sequential queries the upstream nameservers in the exact order listed, falling back to subsequent entries upon failure or timeout. Random (the default) randomly distributes queries, and RoundRobin cycles sequentially without prioritizing the primary nameserver. Specifying policy: Failover or placing upstreams outside forwardPlugin violates the OpenShift DNS API schema.

  2. 2

    A security mandate requires an OpenShift cluster to forward all DNS queries for partner.api.net exclusively over DNS-over-TLS (DoT) to external resolvers at 198.51.100.53:853. The upstream servers present a certificate signed by an enterprise internal CA. Which TWO parameters are required within spec.servers[].forwardPlugin.transportConfig in the dns.operator/default configuration to enable and validate TLS connections to the upstream nameservers? (Select TWO)

    Show answer details

    Correct answer: A, E

    When configuring TLS transport in the DNS Operator, tls.serverName specifies the SNI server name used to validate the upstream server's TLS certificate. This parameter, along with tls.caBundle.name, ensures trusted verification of upstream DoT endpoints.

    Under spec.servers[].forwardPlugin.transportConfig, setting transport: TLS instructs CoreDNS to establish an encrypted TLS tunnel for queries sent to upstream resolvers. Furthermore, when connecting to private CAs or validating upstream identity, tls.caBundle.name (referencing a ConfigMap in openshift-dns) and tls.serverName (specifying the expected SNI hostname on the server's certificate) are used. protocol: TCP is not part of transportConfig, and insecureSkipVerify is not a valid parameter in this OpenShift API stanza.

  3. 3

    When an administrator updates forwarding configurations in the dns.operator/default custom resource, the DNS Operator reconciles and automatically renders the Corefile directives into a ConfigMap named _____ in namespace openshift-dns.

    Show answer details

    Correct answer: B

    The OpenShift DNS Operator manages CoreDNS via the dns.operator/default resource. When modifications are made, the operator renders the Corefile into the dns-default ConfigMap in the openshift-dns namespace, which is mounted by the CoreDNS DaemonSet pods (dns-default-*). Direct manual modifications to this ConfigMap are overwritten by the operator.

  4. 4

    A platform administrator configures MetalLB on an on-premises bare-metal OpenShift cluster. An IPAddressPool named external-lb-pool is created with address range 198.51.100.20-198.51.100.30. A service with type: LoadBalancer is deployed and successfully receives an external IP (198.51.100.21). However, external clients on the local network cannot communicate with the service, and ARP requests for 198.51.100.21 go unanswered. What is the root cause of this failure?

    Show answer details

    Correct answer: C

    MetalLB decouples IP address allocation from advertisement. An IPAddressPool defines available IPs, and the MetalLB controller assigns them to services of type LoadBalancer. However, the speaker DaemonSet will not announce those IPs via ARP (Layer 2) or BGP until a corresponding L2Advertisement or BGPAdvertisement custom resource is created that matches the pool.

  5. 5

    A network engineer needs to configure a secondary network attachment for high-throughput container workloads on OpenShift Container Platform 4.20. The pods require direct Layer 2 connectivity to an external physical subnet connected to worker node interface eth2. Communication between pods scheduled on the same worker node over this secondary network must be switched internally within the node kernel without requiring frames to traverse an external physical switch, while each pod retains an independent MAC address. Which CNI plugin type and operating mode must be specified in the NetworkAttachmentDefinition?

    Show answer details

    Correct answer: A

    The macvlan CNI plugin in bridge mode creates sub-interfaces on the parent physical device (eth2), each with a unique MAC address. In bridge mode, traffic between endpoints on the same host interface is switched directly within the Linux kernel, preventing packets from looping out to an external physical switch. In contrast, private mode drops inter-endpoint traffic on the same host, vepa requires an external switch supporting IEEE 802.1Qbg Hairpin mode, and passthru dedicates the physical interface entirely to a single container.

  6. 6

    A quantitative trading firm runs latency-critical algorithmic applications on OpenShift Container Platform 4.20 bare-metal worker nodes. The network infrastructure team requires secondary interfaces on pods to connect directly to an external low-latency market data network attached to ens2f1.

    The upstream switch fabric enforces strict Port Security policies: each switchport is restricted to the single MAC address of the physical server NIC. Any incoming packet presenting an untrusted or newly generated MAC address causes an immediate port shutdown. Furthermore, the application team requires Layer 3 routing handled entirely in the host kernel stack, with pod IP addresses assigned from non-overlapping subnets without bridging overhead.

    Which secondary network configuration satisfies the upstream switch port security constraint while routing traffic via the host network stack?

    graph LR subgraph WorkerNode["Worker Node (Bare Metal)"] subgraph PodNS["Pod Network Namespace"] net1["Interface: net1 IP: 192.168.50.15/24"] end HostStack["Linux Host IP Routing Stack"] PhysicalNIC["Parent NIC: ens2f1 HWaddr: 52:54:00:ab:cd:ef"] net1 -->|Shares Parent MAC| HostStack HostStack --> PhysicalNIC end PhysicalNIC --> SwitchPort["ToR Switch Port (Port Security: 1 MAC)"]
    Show answer details

    Correct answer: A

    The ipvlan plugin creates virtual network interfaces that share the exact physical MAC address of the master interface (ens2f1), satisfying upstream port security rules that permit only one MAC address. In mode: "l3", all Layer 2 broadcast and ARP processing is eliminated; the host networking stack routes packets directly at Layer 3 between the pod namespace and the physical interface. In contrast, macvlan creates distinct virtual MAC addresses for each pod, triggering port shutdown on the switch. ipvlan in l2 mode still acts as an L2 bridge (sharing the MAC), but does not route via the host kernel routing table. A Linux bridge with macspoofchk: true still exposes multiple MACs or drops frames.

Create an account to continue.

Create accountSign in

Keep going

Related exams