Networking And Network Policies practice questions

ClusterNetwork

Why it fails: ClusterNetwork defines the global SDN cluster network parameters, not specific egress IP routing.

HostSubnet

Why it fails: HostSubnet defines node subnets in the legacy OpenShift SDN architecture.

EgressRouter

Why it fails: EgressRouter is a legacy OpenShift SDN feature, whereas OVN-Kubernetes uses EgressIP and EgressFirewall.

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

Why it fails: This command syntax does not properly establish a standard targetPort mapping for arbitrary container ports without a predefined generator.

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

Why it fails: Defining multiple --port flags without targetPort specification results in misconfigured port mapping.

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

Why it fails: The ports are inverted; service port should be 80 and targetPort should be 8080.

Re-encrypt TLS termination

Why it fails: While re-encrypt uses certificates, it is typically used when the backend pod also requires encryption, whereas standard edge termination is the direct answer for router termination.

Unsecured Route with an external proxy

Why it fails: Unsecured routes do not utilize TLS certificates at the OpenShift route level.

Insecure plain HTTP route

Why it fails: Plain HTTP routes do not require TLS certificates.

Passthrough TLS termination

Why it fails: Passthrough routes pass encrypted traffic directly to the pod without decrypting at the router, hence no certificates are supplied on the route.

A NetworkPolicy blocking egress in namespace 'dev'

Why it fails: While egress can be blocked in 'dev', the question asks for a policy protecting 'secure-db' or standard ingress control.

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

Why it fails: ClusterNetwork does not handle fine-grained namespace-to-namespace traffic isolation like NetworkPolicy.

An EgressFirewall object in namespace 'dev'

Why it fails: EgressFirewall controls traffic leaving a namespace to external CIDRs or other namespaces, but NetworkPolicy is the standard namespaced resource for ingress/egress rules.

ip route show

Why it fails: Linux routing tables do not display OVN logical topologies.

iptables-save

Why it fails: iptables is used for packet filtering and NAT, not OVN logical databases.

ovs-vsctl

Why it fails: ovs-vsctl manages Open vSwitch bridges and ports, but OVN logical abstractions are managed via ovn-nbctl/ovn-sbctl.

In the Service specification under healthCheckNodePort

Why it fails: healthCheckNodePort is only used for external load balancer health checks, not container readiness/liveness.

In the DNS operator configuration

Why it fails: DNS operator has no visibility into pod probes.

network.operator.openshift.io named 'default'

Why it fails: The network operator manages the cluster network operator status, but user specifications are defined in networks.config.openshift.io.

cluster-network.openshift.io

Why it fails: This is not a valid OpenShift config API resource.

sdn.openshift.io/config

Why it fails: This API does not exist in OpenShift 4.

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

Why it fails: TargetPort refers to pod ports, not Ingress controller IPs.

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

Why it fails: Ingress controllers can be configured with route selectors to shard traffic.

Routes cannot be assigned to specific Ingress controllers.

Why it fails: Ingress controllers support scoping routes via label selectors.

spec.ingress

Why it fails: Ingress rules are optional; an empty spec with an empty podSelector isolates a namespace entirely.

spec.egress.to.ipBlock

Why it fails: egress rules are optional in a network policy.

metadata.namespace

Why it fails: Namespace is specified at creation time or metadata, but podSelector is the core spec requirement.

oc top route

Why it fails: oc top does not support routes.

oc logs route/<route-name>

Why it fails: Routes are configuration objects and do not generate logs.

The physical MTU size of the cluster worker node network interfaces

Why it fails: MTU is configured in the Network operator, not DNS.

The default HAProxy router replica count

Why it fails: Router replicas are configured via the IngressController resource.

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

Why it fails: Ingress hostnames use the cluster's base domain or any valid DNS name configured.

Ingress objects require a ServiceMeshControlPlane to function properly in OpenShift.

Why it fails: ServiceMesh is optional and not required for standard Ingress operation.

OpenShift completely ignores Ingress resources and only processes Route objects.

Why it fails: OpenShift does support Ingress resources, which are translated into internal Route objects by the ingress operator.

iptables-save

Why it fails: iptables-save is used for traditional Linux packet filtering rules, not OVN native flow tables.

nft

Why it fails: nftables is an alternative packet filtering framework, but OVN translates flows to OpenFlow/OVS rules.

firewall-cmd

Why it fails: firewall-cmd manages firewalld zones and rules on Red Hat Enterprise Linux nodes.

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

Why it fails: Node resolv.conf files are managed by systemd-resolved/NetworkManager and will be overwritten.

Create a custom Route with DNS forwarding annotations.

Why it fails: Routes deal with HTTP/HTTPS traffic ingress, not core cluster DNS server forwarding.

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

Why it fails: Manually editing the Corefile in kube-system is overwritten by the cluster DNS operator.

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

Why it fails: Egressrouter is a legacy method and not the native OVN-Kubernetes EgressIP feature.

Configure a SNAT rule inside the default NodePort service definition.

Why it fails: NodePort services do not handle namespace-level egress IP assignment.

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

Why it fails: Annotations are not used for OVN-Kubernetes egress IP assignment; an EgressIP CR is required.

oc test dns --cluster

Why it fails: There is no 'oc test dns' subcommand in the OpenShift CLI.

oc adm diagnose network-dns

Why it fails: `oc adm diagnose network-dns` runs a cluster-wide diagnostic that inspects existing DNS configuration and reports problems; it does not create a pod or provide an interactive `dig` shell. It is tempting because it genuinely targets DNS troubleshooting, and would suit verifying cluster DNS health after a suspected misconfiguration, but the scenario requires launching a temporary debugging pod.

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

Why it fails: oc debug node runs on the host namespace, which does not test cluster internal pod DNS resolution directly in the same manner as a cluster pod.

Running systemctl restart firewalld on all worker nodes simultaneously

Why it fails: Restarting firewalld disrupts node networking and is not a standard troubleshooting tool for OVN flows.

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

Why it fails: Static /etc/hosts edits do not resolve dynamic pod network routing or policy drops.

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

Why it fails: EgressNetworkPolicy is used to block or allow egress traffic based on CIDR, but it cannot perform source NAT or redirect traffic through a specific pod. It also does not provide a fixed source IP for external systems. This approach would not meet the requirement of a specific source IP.

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

Why it fails: EgressIP assigns a specific source IP to traffic from a namespace, but it is a cluster-wide feature that requires the IP to be available on the node's network. It does not redirect traffic to a specific destination or port, and it does not use an egress router pod. The scenario specifically requires redirect mode with a nodeSelector.

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.

Why it fails: Routes are for ingress traffic to services, not for controlling egress source IP. The router's IP is not used as the source for outbound traffic from pods. This does not provide a fixed source IP for the external system and is unrelated to egress router functionality.

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

Why it fails: An empty podSelector selects all Pods in the namespace, and the ingress rule allows traffic from Pods labeled `role: db`. This inverts the intent: it permits the database Pods to initiate traffic to everything, rather than restricting who can reach the database. It also does not limit the allowed port to 5432 for other Pods, so the scenario's goal is not achieved.

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

Why it fails: Selecting the `role: db` Pods and allowing ingress on port 5432 from all sources does restrict traffic to those Pods on that port, but it does not deny all other ingress traffic to the rest of the namespace. Pods without the `role: db` label would remain unaffected and continue accepting any traffic, so the requirement to deny all other ingress is not met.

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

Why it fails: This allows ingress to the database Pods from any Pod in the `backend` namespace on port 5432, which is broader than intended because it does not restrict the source to Pods labeled `role: db`. Additionally, it does not deny ingress to other Pods in the namespace, so the isolation requirement is only partially satisfied and the source restriction is incorrect.

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

Why it fails: The 'oc create route edge' command creates an edge-terminated route, which terminates TLS at the router. The scenario expects HTTP traffic, not HTTPS. Also, the --port flag specifies the service port, not the target port. This would not create a plain HTTP route as required.

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

Why it fails: The 'oc expose service' command does not have a --port flag to specify the target port; it uses the service's port. The --hostname flag is valid, but the port must be defined in the service. This command would fail because --port is not a recognized flag for oc expose service.

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

Why it fails: A passthrough route forwards encrypted traffic directly to the pod without termination, which is used when the pod handles TLS. The scenario expects HTTP traffic, so passthrough is incorrect. Also, the service port is not specified, and the route would not decrypt traffic.