EX280 Networking And Network Policies Practice Test 3 — 15 Questions

Question 1

An administrator needs to create a passthrough Route that preserves client certificates and forwards encrypted traffic directly to the backend pod. Which spec configuration is required?

Accepted Answer

spec:
  tls:
    termination: passthrough. A passthrough Route uses 'spec.tls.termination: passthrough', which tells the HAProxy router to forward the encrypted TLS connection directly to the backend pod without decrypting it. This preserves client certificates end-to-end and is required when the backend must handle TLS itself.

Answer

spec:
  tls:
    termination: reencrypt

Answer

spec:
  tls:
    termination: edge

Answer

spec:
  tls:
    insecureEdgeTerminationPolicy: Allow

Question 2

An administrator wants to configure a NetworkPolicy that allows incoming traffic only from pods with the label 'role=frontend' residing in any namespace, provided those namespaces have the label 'environment=production'. How should the namespaceSelector and podSelector be combined?

Accepted Answer

In the same ingress 'from' array item, combining namespaceSelector and podSelector. In Kubernetes NetworkPolicy, when you specify a single ingress rule with a 'from' array item that contains both namespaceSelector and podSelector, the two selectors are ANDed together. This means traffic is allowed only from pods that match the podSelector AND reside in namespaces that match the namespaceSelector. This exactly meets the requirement: pods with label 'role=frontend' in any namespace labeled 'environment=production'.

Answer

By referencing an external ClusterRole binding with label selectors

Answer

Using a peerSelector object that nests both labels

Answer

In separate ingress rules, where one rule has namespaceSelector and another has podSelector

Question 3

An administrator wants to test network connectivity from a pod named 'app-pod-1' to a service port on 'backend-service' using TCP. Which tool is commonly available and ideal for testing TCP port connectivity inside a container?

Accepted Answer

nc. 'nc' (netcat) is the standard tool for testing TCP/UDP port connectivity from inside a container because it can open a raw TCP connection to a specific host and port, e.g., 'nc -zv backend-service 8080'. It is included in many base images and is the go-to utility for verifying that a Service port is reachable and that network policies or firewalls are not blocking traffic.

Answer

ifconfig

Answer

traceroute

Answer

ping

Question 4

An administrator creates a NetworkPolicy that restricts egress traffic from a namespace. However, DNS resolution for external services immediately stops working. What is the cause of this behavior?

Accepted Answer

The NetworkPolicy blocks outbound traffic to port 53 on the cluster DNS service.. When a NetworkPolicy selects pods for egress, it becomes default-deny for all egress traffic from those pods except what is explicitly allowed. If the policy does not include a rule permitting UDP/TCP port 53 to the cluster DNS service (usually openshift-dns in openshift-dns namespace), DNS resolution fails immediately. The fix is to add an egress rule allowing port 53 to the DNS pods or namespace.

Answer

NetworkPolicies automatically disable the OpenShift SDN controller.

Answer

CoreDNS pods do not have valid security context constraints.

Answer

External DNS servers reject requests originating from OpenShift node IPs.

Question 5

An administrator needs to configure a custom default certificate for all routes created in the cluster without specifying a certificate on every individual Route object. Where should this wildcard certificate be configured?

Accepted Answer

In the IngressController resource named 'default' in openshift-ingress-operator. The wildcard default certificate for all routes is configured in the IngressController resource named 'default' in the `openshift-ingress-operator` namespace, specifically in `spec.defaultCertificate` with a Secret reference. This tells the OpenShift ingress operator to use that certificate as the fallback for any Route that does not specify its own TLS certificate. It is the cluster-wide default for edge/re-encrypt routes.

Answer

In a ConfigMap named 'router-certs' in the default namespace

Answer

In the apiserver.config.openshift.io cluster object

Answer

In the DNS cluster operator configuration

Question 6

An administrator needs to list all Services across all namespaces in the OpenShift cluster. Which command should be used?

Accepted Answer

oc get svc -A. The `-A` flag (short for `--all-namespaces`) is the standard OpenShift/Kubernetes flag that makes `oc get` query every namespace in the cluster. Running `oc get svc -A` returns all Services across all projects in a single table, which is exactly what the administrator needs. This flag is consistent across resource types and is the idiomatic way to perform cluster-wide listing.

Answer

oc get services --cluster

Answer

oc describe service --all

Answer

oc adm top services

Question 7

An OpenShift administrator needs to inspect how OVN-Kubernetes handles network flows and packet drops on a specific node. Which debugging utility installed in the OVN node container is most effective for viewing OpenFlow rules?

Accepted Answer

ovs-ofctl. OVN-Kubernetes uses Open vSwitch (OVS) as its data plane, and ovs-ofctl is the standard utility for inspecting and managing OpenFlow rules in the OVS bridge. It allows administrators to dump flows, view packet counters, and debug how traffic is being handled on a specific node. This makes it the most effective tool for viewing OpenFlow rules in the OVN node container.

Answer

nmcli connection show

Answer

ethtool -S

Answer

ovn-trace

Question 8

An administrator notices that client source IP addresses are lost when traffic hits a Service of type NodePort, appearing instead as a node IP. Which field in the Service specification should be changed to 'Local' to preserve client source IPs?

Accepted Answer

externalTrafficPolicy: Local. externalTrafficPolicy: Local preserves the client source IP by only routing traffic to pods on the same node that received the request, avoiding the SNAT that occurs when kube-proxy forwards to a pod on another node. With the default Cluster policy, traffic can be forwarded to any node's pod, causing the source IP to be rewritten to the node's IP. Setting it to Local ensures the original client IP is retained for the backend pod.

Answer

publishNotReadyAddresses: true

Answer

sessionAffinity: ClientIP

Answer

ipFamilyPolicy: RequireDualStack

Question 9

An administrator needs to create a Route that handles multiple subdomains or redirects insecure HTTP traffic to HTTPS automatically. Where is the insecure traffic redirect configured?

Accepted Answer

insecureEdgeTerminationPolicy: Redirect. In OpenShift, a Route's TLS configuration includes the `insecureEdgeTerminationPolicy` field, which controls how non-TLS (HTTP) traffic is handled when the Route is configured for edge or re-encrypt termination. Setting it to `Redirect` makes the router automatically issue an HTTP 302 redirect to the HTTPS URL, ensuring all insecure traffic is upgraded. This is the standard, supported mechanism for enforcing HTTPS on a Route.

Answer

route.openshift.io/handling: insecure-redirect

Answer

tls.allowInsecure: true

Answer

spec.redirectHTTP: enabled

Question 10

A developer deploys a headless service (ClusterIP set to None) in OpenShift. What is the primary characteristic of a headless service?

Accepted Answer

It does not allocate a ClusterIP, and DNS returns the individual pod IPs directly.. A headless service in OpenShift/Kubernetes is defined by setting clusterIP: None, which means no virtual IP is allocated. Instead, DNS resolution for the service returns the individual pod IPs directly (A/AAAA records), allowing clients to connect to specific pods — commonly used for StatefulSets where each pod needs a stable identity.

Answer

It prevents any external routes from binding to the service.

Answer

It routes traffic exclusively via NodePort across worker nodes.

Answer

It provisions an external cloud load balancer automatically.

Question 11

An administrator configures an EgressFirewall in a namespace to deny all external traffic except for a specific CIDR block. In what order are the rules in an EgressFirewall evaluated?

Accepted Answer

In sequential order (top to bottom), stopping at the first matching rule.. EgressFirewall rules are evaluated in sequential order from top to bottom, and the first rule that matches the traffic is applied. Once a match is found, no further rules are evaluated. This is similar to firewall rule processing in traditional firewalls. Therefore, the order of rules is critical for achieving the desired allow/deny behavior.

Answer

Allow rules are evaluated first, followed by deny rules.

Answer

Deny rules always take precedence over allow rules regardless of order.

Answer

Alphabetically by rule description.

Question 12

An administrator needs to expose an existing deployment using a quick command without writing a YAML manifest. Which command exposes port 8080 of a deployment named 'my-app' as a Service?

Accepted Answer

oc expose deployment my-app --port=8080. The 'oc expose' command creates a Service from an existing resource. Using 'oc expose deployment my-app --port=8080' generates a Service that targets the deployment's pods on port 8080, without requiring a YAML manifest. This is the standard imperative approach.

Answer

oc expose pod my-app --port=8080

Answer

oc service create my-app --port=8080

Answer

oc create service my-app --port=8080

Question 13

An administrator needs to test DNS resolution from inside a running pod. Which command run inside a container uses the standard Linux DNS lookup utility?

Accepted Answer

nslookup backend.production.svc.cluster.local. nslookup is the standard Linux DNS lookup utility and can be run inside a container to query DNS resolution for a service FQDN such as backend.production.svc.cluster.local. Running it inside the pod tests the actual DNS path the application would use, including the cluster DNS service and any search domain configuration. This directly answers the requirement to test DNS resolution from inside a running pod.

Answer

route lookup backend

Answer

oc get dns

Answer

ping -dns backend.production.svc.cluster.local

Question 14

An administrator troubleshoots a failing NetworkPolicy and wants to verify if the OpenShift SDN or OVN-Kubernetes controller has successfully applied the rules. Where are the controller operator logs examined?

Accepted Answer

In the openshift-network-operator or openshift-ovn-kubernetes namespaces. In OpenShift, the network controller components that apply NetworkPolicy rules run in specific namespaces: the network operator itself runs in openshift-network-operator, and the OVN-Kubernetes control plane runs in openshift-ovn-kubernetes. To verify if the controller has successfully applied NetworkPolicy rules, you must examine the logs of the operator and the ovn-kubernetes pods in these namespaces. The openshift-network-operator manages the overall network configuration, while the ovn-kubernetes pods (like ovnkube-master and ovnkube-node) handle the actual implementation of network policies.

Answer

In the openshift-apiserver namespace

Answer

In the kube-system namespace under core-dns logs

Answer

In the openshift-ingress namespace under router pods

Question 15

An administrator needs to delete a Service named 'old-service' in the 'test' namespace. Which command accomplishes this?

Accepted Answer

oc delete service old-service -n test. The correct command is `oc delete service old-service -n test` because `oc delete` is the standard OpenShift/Kubernetes verb for removing resources. It accepts the resource type (service, or its abbreviation svc) and the resource name, with the `-n` flag specifying the namespace. This directly deletes the Service object from the 'test' namespace.

Answer

oc remove svc old-service --namespace=test

Answer

oc prune service old-service -n test

Answer

oc destroy service old-service -n test