EX280 Networking And Network Policies Practice Test 4 — 15 Questions

Question 1

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?

Accepted Answer

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

Answer

passthrough

Answer

edge

Answer

secure-tunnel

Question 2

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?

Accepted Answer

oc get clusteroperators. 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.

Answer

oc get operators --cluster

Answer

oc describe operators

Answer

oc adm check health

Question 3

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?

Accepted Answer

The Corefile in the cluster DNS operator configuration has incorrect or missing forward plugins for external resolvers.. 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.

Answer

The API server service is missing endpoint IPs.

Answer

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

Answer

The cluster ingress controller is blocking external UDP port 53.

Question 4

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

Accepted Answer

ClusterIP. 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 :. 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.

Answer

VirtualIP

Answer

IngressObject

Answer

Route

Question 5

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

Accepted Answer

IngressController Custom Resource. 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.

Answer

ClusterNetwork operator

Answer

EgressFirewall controller

Question 6

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

Accepted Answer

It provides native support for EgressIP and EgressFirewall custom resources.. 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.

Answer

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

Answer

It requires the flannel CNI plugin to function.

Answer

It does not support NetworkPolicies.

Question 7

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

Accepted Answer

Check that the Route hostname resolves correctly via DNS to the cluster router IP.. 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.

Answer

Reinstall the entire cluster storage operator.

Answer

Modify the cluster kube-apiserver certificates.

Question 8

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

Accepted Answer

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

Answer

ping

Answer

ifconfig

Answer

top

Question 9

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

Accepted Answer

oc describe clusteroperator network. 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.

Answer

oc get routes --all-nodes

Answer

oc adm network status

Answer

oc top network

Question 10

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

Accepted Answer

Scaling the number of router replicas.. 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.

Answer

Modifying the core Kubernetes API server port.

Answer

Defining the container security context constraints for worker nodes.

Question 11

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

Accepted Answer

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

Answer

ClusterNetwork

Answer

IngressController

Question 12

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

Accepted Answer

They interact with cloud provider APIs or MetalLB to provision an external IP address.. 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.

Answer

They are restricted to internal cluster communication only.

Answer

They replace the need for Ingress controllers completely.

Answer

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

Question 13

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

Accepted Answer

Verifying that the target service has valid endpoints pointing to running pods.. 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.

Answer

Restarting the cluster storage provider pods.

Answer

Deleting all persistent volume claims.

Answer

Modifying the global MachineConfig pool.

Question 14

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

Accepted Answer

If an ingress policy is present, the connection must be explicitly permitted by at least one rule.. 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.

Answer

The cluster must have exactly three worker nodes.

Answer

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

Question 15

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?

Accepted Answer

kind: Route
metadata:
  name: my-app
spec:
  to:
    kind: Service
    name: my-service
  port:
    targetPort: 8080
  tls:
    termination: edge. 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.

Answer

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

Answer

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

Answer

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