EX280 Networking And Network Policies — 40 Questions

Question 1

An OVN-Kubernetes clustered environment requires configuring egress IP functionality for a specific namespace so that all outgoing traffic from pods in that namespace appears to originate from a designated external IP address. Which custom resource must be configured?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

EgressIP. The EgressIP custom resource is the correct answer because in OVN-Kubernetes, egress IP functionality is configured by creating an EgressIP object that specifies the desired external IP address(es). This resource is then associated with one or more namespaces via namespace labels or annotations, causing all outgoing traffic from pods in those namespaces to be SNAT'd to the designated egress IP. The EgressIP resource is specific to the OVN-Kubernetes CNI and is the standard way to achieve this behavior in OpenShift.

Answer

ClusterNetwork

Answer

HostSubnet

Answer

EgressRouter

Question 2

An administrator needs to create a Service of type ClusterIP that exposes an application running on port 8080 inside the container, mapping it to port 80 on the Service. Which command should the administrator use?

Accepted Answer

oc expose pod frontend --port=80 --target-port=8080 --type=ClusterIP. The oc expose service or oc create service command correctly maps the targetPort inside the container to the service port using the syntax --port=80 --target-port=8080.

Answer

oc create service clusterip frontend --tcp=80:8080

Answer

oc create service clusterip frontend --port=80 --port=8080

Answer

oc expose deployment frontend --port=8080 --target-port=80

Question 3

An OpenShift administrator needs to expose an internal web application securely using a Route that terminates TLS at the router. Which Route type and configuration requires the administrator to provide the certificate, private key, and CA certificate?

Accepted Answer

Edge TLS termination. For an Edge TLS termination Route, the router terminates TLS, and the administrator must provide the certificate, private key, and CA certificate in the Route specification. The router decrypts incoming traffic and forwards plain HTTP to the backend pods. This matches the requirement of terminating TLS at the router and providing the certificate materials.

Answer

Re-encrypt TLS termination

Answer

Unsecured Route with an external proxy

Answer

Insecure plain HTTP route

Answer

Passthrough TLS termination

Question 4

An OpenShift administrator needs to restrict access so that pods in namespace 'dev' cannot initiate any outbound connections to pods in namespace 'secure-db'. Which resource should be created in namespace 'secure-db' to achieve this?

Accepted Answer

A NetworkPolicy with an empty ingress rule set in namespace 'secure-db'. To prevent pods in namespace 'dev' from initiating connections to pods in namespace 'secure-db', the administrator should create a NetworkPolicy in namespace 'secure-db' that selects the target pods and has an empty ingress rule set (i.e., no allowed ingress). In OpenShift, NetworkPolicies are namespace-scoped and apply to pods in that namespace; an empty ingress rule denies all inbound traffic to the selected pods, effectively blocking connections from 'dev'.

Answer

A NetworkPolicy blocking egress in namespace 'dev'

Answer

A ClusterNetwork policy blocking all cross-namespace traffic cluster-wide

Answer

An EgressFirewall object in namespace 'dev'

Question 5

A cluster uses OVN-Kubernetes as its CNI network provider. An administrator needs to inspect the logical switches and routers created by OVN within a node. Which command-line tool inside the ovn-node pod should be used?

Accepted Answer

ovn-nbctl. ovn-nbctl is the command-line utility that talks to the OVN Northbound database, which holds the logical switch and logical router definitions. Inspecting logical switches and routers created by OVN-Kubernetes requires querying that northbound database, so ovn-nbctl is the correct tool. It is available inside the ovn-node pod where OVN components run.

Answer

ip route show

Answer

iptables-save

Answer

ovs-vsctl

Question 6

An administrator notices that Ingress controller logs show frequent health check failures for backend pods. Where can the administrator check or configure the liveness and readiness probes that dictate pod health for service endpoints?

Accepted Answer

In the IngressController custom resource spec. Liveness and readiness probes are defined at the container level within a pod's specification. In OpenShift, these are typically set in the Deployment (or other workload controller) pod template under the containers' livenessProbe and readinessProbe fields. The IngressController custom resource can also configure health checks for the router itself, but for backend pods, the probes are in the pod template. Thus, both A and B are correct locations depending on whether the administrator is checking the router's health checks or the backend pods' probes.

Answer

In the Service specification under healthCheckNodePort

Answer

In the DNS operator configuration

Question 7

An OpenShift cluster is configured with a custom Cluster Network CIDR. An administrator needs to verify the cluster network subnet settings and host subnet assignments. Which operator status or configuration resource contains this cluster-wide network configuration?

Accepted Answer

networks.config.openshift.io named 'cluster'. The cluster-wide network configuration in OpenShift is stored in the networks.config.openshift.io custom resource named 'cluster'. This resource defines the Cluster Network CIDR, Service Network CIDR, and host subnet prefix length used by the SDN/OVN-Kubernetes. Administrators inspect it with 'oc get networks.config.openshift.io cluster -o yaml' to verify subnet assignments.

Answer

network.operator.openshift.io named 'default'

Answer

cluster-network.openshift.io

Answer

sdn.openshift.io/config

Question 8

An administrator creates a Route with a specific hostname, but multiple Ingress controllers exist in the cluster. How does the Route know which Ingress controller should serve it?

Accepted Answer

By specifying the corresponding label selector in the Route spec under 'wildcardPolicy' or router selection annotations.. In OpenShift, a Route can be bound to a specific Ingress controller (router shard) by setting the `routerName` field in the Route spec or by adding the `router.openshift.io/<router-name>` annotation. The router shard's Ingress controller is configured with a matching label selector (e.g., `router=shard`), and only routers whose labels match the Route's `routerName` will admit and serve that Route. This allows administrators to partition traffic across multiple Ingress controllers for isolation, performance, or multi-tenancy.

Answer

By adding the Ingress controller IP directly to the Route spec targetPort.

Answer

All routes are automatically served by every Ingress controller without exception.

Answer

Routes cannot be assigned to specific Ingress controllers.

Question 9

Which TWO fields are mandatory when defining a standard Kubernetes NetworkPolicy object? (Choose TWO)

Accepted Answer

metadata. Option B (metadata) is mandatory because every Kubernetes object, including a NetworkPolicy, requires the standard ObjectMeta fields (at minimum a name, and a namespace when created via kubectl in a namespaced context) to be identified and stored in the API server. Option E (spec.podSelector) is mandatory because a NetworkPolicy's spec must declare which pods the policy applies to; the podSelector field is required in the spec (an empty selector {} selects all pods in the namespace), and omitting it makes the manifest invalid. Option A (spec.ingress) is not required because a policy may define only egress rules, or use an empty podSelector with no rules to deny all traffic; ingress is optional. Option C (spec.egress.to.ipBlock) is not required because it is a nested field used only when writing specific egress rules to CIDR ranges, and egress itself is optional. Option D (metadata.namespace) is not a mandatory field of the object definition itself, since the namespace is typically supplied by the client context or defaults to the current namespace rather than being a required manifest field.

Answer

spec.ingress

Answer

spec.egress.to.ipBlock

Answer

metadata.namespace

Question 10

Which THREE commands can an administrator use to inspect existing routes in an OpenShift cluster? (Choose THREE)

Accepted Answer

oc get routes. Option A, `oc get routes`, is correct because it lists all Route objects in the current project, showing their names, hosts, and other summary information, which is the standard way to inspect existing routes. Option B, `oc explain route`, is correct because it retrieves the documentation and schema for the Route resource type, including its fields and descriptions, which helps an administrator understand how routes are defined and inspected. Option E, `oc describe route `, is correct because it provides detailed information about a specific route, including its host, path, TLS settings, and the service it points to. Option C, `oc top route`, is not a valid command since `oc top` only supports resources like pods and nodes, not routes. Option D, `oc logs route/`, is not valid because routes do not produce logs; logs are associated with pods or build configurations, not Route objects.

Answer

oc top route

Answer

oc logs route/<route-name>

Question 11

Which THREE parameters can be configured within the cluster DNS operator resource (dns.operator/default)? (Choose THREE)

Accepted Answer

Upstream DNS forwarders. The cluster DNS operator resource (dns.operator/default) exposes a spec that lets administrators tune CoreDNS behavior. Option B is correct because spec.upstreamResolvers allows configuring upstream DNS forwarders (including their protocol and policy) that CoreDNS uses to resolve external names. Option C is correct because spec.servers lets you define custom server zones and their bindings, including per-zone upstream forwarders and plugins. Option D is correct because spec.logLevel controls the CoreDNS log verbosity, and the operator also exposes CoreDNS handler logging configuration. Option A is not part of the DNS operator spec; MTU is configured at the network/CNI layer, not in dns.operator/default. Option E is not part of the DNS operator spec; the HAProxy router replica count is managed by the IngressController resource.

Answer

The physical MTU size of the cluster worker node network interfaces

Answer

The default HAProxy router replica count

Question 12

An administrator configures an Ingress resource in the 'web-apps' namespace to route traffic using the default OpenShift Ingress controller. The Ingress creation succeeds, but traffic to the hostname returns a 404 error. What is a common reason for this behavior in OpenShift?

Accepted Answer

The Ingress resource is missing the spec.ingressClassName set to the default OpenShift ingress class name.. OpenShift natively uses Route objects. While Ingress is supported, the Ingress controller watches Ingress objects, but custom annotations or missing paths/backend configurations or default controller sharding often require ensuring the Ingress class or annotations match the default router configuration. Alternatively, Ingress controllers in OpenShift require the ingress class name to be specified correctly (e.g., 'openshift-default').

Answer

Ingress hostnames must end with the exact string '.internal.cloudapp.net'.

Answer

Ingress objects require a ServiceMeshControlPlane to function properly in OpenShift.

Answer

OpenShift completely ignores Ingress resources and only processes Route objects.

Question 13

An OVN-Kubernetes clustered OpenShift environment requires troubleshooting packet flows between namespaces. Which tool is installed on the cluster nodes that allows administrators to inspect OVN database contents and flow tables?

Accepted Answer

ovn-sbctl. ovn-sbctl is the command-line utility for the OVN Southbound database, which stores logical flows, logical ports, and binding information for the OVN-Kubernetes CNI. Administrators use it on cluster nodes to inspect flow tables and trace how packets are handled between namespaces. It is installed as part of the OVN tooling on OpenShift nodes.

Answer

iptables-save

Answer

nft

Answer

firewall-cmd

Question 14

An administrator needs to configure cluster-wide DNS forwarding for a specific custom domain (e.g., 'corp.local') to point to internal corporate DNS servers. Where is this configured in OpenShift 4.14?

Accepted Answer

Edit the DNS resource named 'cluster' and add a spec.servers block with forwardPlugin rules.. In OpenShift 4.x, cluster-wide DNS forwarding is configured by editing the DNS Operator's 'cluster' DNS custom resource (oc edit dns.operator.openshift.io/default or the 'cluster' DNS object) and adding a spec.servers block with a forwardPlugin that lists the upstream corporate DNS servers for the custom zone. The DNS Operator then regenerates the CoreDNS configuration automatically. This is the supported, declarative method in 4.14.

Answer

Modify the /etc/resolv.conf file on every worker node.

Answer

Create a custom Route with DNS forwarding annotations.

Answer

Edit the Corefile ConfigMap directly in the 'kube-system' namespace.

Question 15

An administrator needs to configure an egress IP for a specific namespace in an OVN-Kubernetes enabled OpenShift cluster so that all egress traffic originating from that namespace appears to come from a specific dedicated external IP. How is this configured?

Accepted Answer

Create an EgressIP custom resource specifying the target namespace and the designated egress IP address.. In an OVN-Kubernetes cluster, egress IPs are configured by creating an EgressIP custom resource (egressips.k8s.ovn.org) that specifies the desired egress IP address and the namespace or pod selector it applies to. OVN-Kubernetes then assigns that IP to a node and programs OVN flows so traffic from the selected namespace is SNATed to the designated egress IP. This is the supported, declarative mechanism for namespace-level egress IPs.

Answer

Modify the egressrouter pod template in the openshift-infra namespace.

Answer

Configure a SNAT rule inside the default NodePort service definition.

Answer

Add an egress annotation directly to the namespace metadata named 'openshift.io/origin-egress-ip'.

Question 16

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 17

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 18

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 19

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 20

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