EX280 Networking And Network Policies — 10 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>