EX280 Networking And Network Policies Practice Test 2 — 15 Questions

Question 1

An administrator needs to test internal cluster DNS resolution from a temporary troubleshooting pod. Which command creates a temporary pod with the 'dig' utility installed for DNS debugging?

Accepted Answer

oc run dns-test --rm -it --image=registry.redhat.io/rhel9/support-tools --command -- bash. The command 'oc run dns-test --rm -it --image=registry.redhat.io/rhel9/support-tools --command -- bash' creates a temporary pod using the RHEL support-tools image, which includes dig, nslookup, and other networking utilities. The --rm flag deletes the pod on exit, and -it provides an interactive shell for running dig against cluster DNS.

Answer

oc test dns --cluster

Answer

oc adm diagnose network-dns

Answer

oc debug node/worker-1 --image=registry.redhat.io/rhel9/support-tools:latest

Question 2

When troubleshooting network policies or container connectivity in an OVN-Kubernetes environment, which THREE tools or logs are useful for diagnosing packet drops and flow issues? (Choose THREE)

Accepted Answer

Querying the OVN southbound database using ovn-sbctl. Option A is correct because ovn-sbctl queries the OVN Southbound database, which holds the logical flow tables and port bindings that determine how packets are forwarded or dropped in OVN-Kubernetes, making it essential for tracing ACL and network policy drops. Option C is correct because the ovn-controller pods in the openshift-ovn-kubernetes namespace run on each node and their logs reveal flow programming errors, tunnel/encap issues, and failures translating logical flows to OpenFlow rules. Option E is correct because the network operator and its network policy controller logs record reconciliation errors, policy application failures, and status conditions that explain why a NetworkPolicy may not be enforced as expected. Option B is not appropriate because restarting firewalld on all workers simultaneously disrupts node networking and is unrelated to OVN-Kubernetes flow debugging. Option D is not appropriate because editing /etc/hosts on the master to map pod IPs does not diagnose OVN logical flows or packet drops and can cause resolution inconsistencies.

Answer

Running systemctl restart firewalld on all worker nodes simultaneously

Answer

Editing the master /etc/hosts file to add custom pod IP mappings

Question 3

An administrator is configuring an egress router pod in redirect mode to send traffic from a specific namespace to an external legacy system with a fixed source IP. The egress router pod must be deployed on a node with a specific label, and the external system expects traffic on TCP port 8443. Which configuration is required?

Accepted Answer

Create an EgressRouter custom resource with mode Redirect, network interface with an IP address, and a nodeSelector matching the node label; then create a NetworkPolicy that allows egress to the egress router pod's IP.. The EgressRouter custom resource in redirect mode creates a pod that acts as a gateway, redirecting traffic to a specified destination. It requires a nodeSelector to schedule the pod on a node with the desired label, and a NetworkPolicy to permit traffic from the application pods to the egress router pod. This provides a fixed source IP for external systems.

Answer

Create an EgressNetworkPolicy that allows egress to the external system's IP and port, and annotate the namespace with the desired source IP.

Answer

Create an EgressIP object and assign it to the namespace, ensuring the EgressIP is on the same subnet as the external system.

Answer

Create a Route with a custom hostname and use the router's external IP as the source address for all outbound traffic from the namespace.

Question 4

An administrator must ensure that only Pods labeled `role: db` in the `backend` namespace can receive ingress traffic on TCP port 5432, while all other ingress traffic to Pods in that namespace is denied. Which NetworkPolicy configuration accomplishes this?

Accepted Answer

Two NetworkPolicies: one with an empty podSelector and policyTypes Ingress (deny all), and one with podSelector matching `role: db` allowing ingress from Pods labeled `role: db` on port 5432.. NetworkPolicies are additive: a Pod is allowed traffic if any policy selecting it permits that traffic. To deny all ingress except a specific allowed flow, you need a default-deny policy (empty podSelector with Ingress and no rules) plus a targeted allow policy. The allow policy must select the database Pods and permit ingress from the intended source labels on the correct port. Only the combination of default-deny and a precise allow rule satisfies both the restriction and the exception.

Answer

A NetworkPolicy with an empty podSelector, policyTypes including Ingress, and an ingress rule allowing from Pods labeled `role: db` on port 5432.

Answer

A NetworkPolicy with podSelector matching `role: db`, policyTypes including Ingress, and an ingress rule allowing from all sources on port 5432.

Answer

A NetworkPolicy with podSelector matching `role: db`, policyTypes including Ingress, and an ingress rule allowing from a namespaceSelector for `backend` on port 5432.

Question 5

An administrator needs to expose an application running in the 'web' namespace to external clients using a hostname 'www.example.com'. The application listens on port 8080 and expects HTTP traffic. The administrator wants to use the default Ingress controller and ensure the Route uses the correct service. Which command creates the Route correctly?

Accepted Answer

oc expose service web-service --name=web-route --hostname=www.example.com. The 'oc expose service' command creates a Route for a service. Without additional flags, it creates an unsecured HTTP route. The --hostname flag sets the external hostname. The service must already be configured with the correct target port. This is the simplest way to expose a service over HTTP.

Answer

oc create route edge web-route --service=web-service --hostname=www.example.com --port=8080

Answer

oc expose service web-service --name=web-route --hostname=www.example.com --port=8080

Answer

oc create route passthrough web-route --service=web-service --hostname=www.example.com

Question 6

An administrator needs to expose an application running in the `frontend` namespace to external users over HTTP on a hostname managed by the cluster's default Ingress controller. The application Service is named `web-svc` and listens on port 8080. Which command creates the appropriate OpenShift Route?

Accepted Answer

oc expose service web-svc -n frontend. The `oc expose service` command is the canonical way to create a Route from an existing Service in OpenShift. It automatically uses the default Ingress controller and generates a hostname, requiring no manual TLS or path configuration for a basic HTTP application. Because the Service already targets the Pod's port, the Route inherits that mapping, making this the fastest correct method to expose the application externally.

Answer

oc create route passthrough web-svc --service=web-svc -n frontend

Answer

oc create ingress web-svc --rule=frontend.example.com/*=web-svc:8080 -n frontend

Answer

oc expose deployment frontend -n frontend

Question 7

An administrator is configuring a NetworkPolicy to allow ingress traffic to pods labeled app=db in the 'database' namespace from pods labeled app=api in the 'api' namespace on TCP port 5432. The administrator also wants to allow ingress from pods in the 'monitoring' namespace on TCP port 9090 for metrics scraping. Which two NetworkPolicy rules should be included in the policy? (Choose two.)

Accepted Answer

An ingress rule with from: namespaceSelector: matchLabels: name: monitoring, and ports: protocol: TCP, port: 9090.. The policy must include two ingress rules: one for API pods from the 'api' namespace with label app=api on port 5432, and one for any pod in the 'monitoring' namespace on port 9090. The first rule requires both namespaceSelector and podSelector, while the second requires only namespaceSelector.

Answer

An ingress rule with from: namespaceSelector: matchLabels: name: monitoring, podSelector: matchLabels: app: prometheus, and ports: protocol: TCP, port: 9090.

Answer

An ingress rule with from: ipBlock: cidr: 10.0.0.0/8, and ports: protocol: TCP, port: 5432.

Answer

An ingress rule with from: podSelector: matchLabels: app: api, and ports: protocol: TCP, port: 5432.

Question 8

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?

Accepted Answer

A custom label defined in the namespaceSelector of the NetworkPolicy spec. 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.

Answer

openshift.io/cluster-monitoring=true

Answer

security.openshift.io/scc=restricted

Answer

kubernetes.io/metadata.name matching the namespace name

Question 9

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?

Accepted Answer

Via the /etc/resolv.conf file automatically managed inside the pod container. 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.

Answer

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

Answer

Through an environment variable named CLUSTER_DNS injected into every container

Answer

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

Question 10

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?

Accepted Answer

30000-32767. 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.

Answer

1024-65535

Answer

80-443

Answer

8000-9000

Question 11

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?

Accepted Answer

backend.production.svc.cluster.local. In OpenShift/Kubernetes, the fully qualified domain name (FQDN) for a Service follows the pattern ..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.

Answer

backend.production.pod.cluster.local

Answer

backend.production.router.default.svc

Answer

svc.production.backend.cluster.local

Question 12

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?

Accepted Answer

The Service selector labels do not match any active Pod labels.. 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.

Answer

The Route YAML has an invalid TLS certificate format.

Answer

The Ingress controller pods have crashed across all worker nodes.

Answer

The cluster DNS operator is degraded.

Question 13

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?

Accepted Answer

oc get route webapp -o jsonpath='{.spec.host}'. 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.

Answer

oc get route webapp --show-url

Answer

oc describe route webapp --url

Answer

oc extract route/webapp --field=host

Question 14

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?

Accepted Answer

ingresscontroller.operator.openshift.io named 'default'. 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.

Answer

deployment named router-default in openshift-ingress namespace

Answer

configmap named router-config in openshift-ingress-operator

Answer

service named router-default-http in openshift-ingress

Question 15

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?

Accepted Answer

The cloud controller manager or cloud credentials operator is not configured to provision external load balancers.. 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.

Answer

The cluster is missing a valid Ingress controller deployment.

Answer

The NetworkPolicy is blocking cloud provider traffic.

Answer

The NodePort range is exhausted.