EX280 Networking And Network Policies Practice Test 5 — 15 Questions

Question 1

A developer reports that pods in the namespace 'project-a' cannot resolve services located in the namespace 'project-b' using standard internal DNS names. What is the correct way to query 'project-b' service 'backend' from 'project-a'?

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

Accepted Answer

backend.project-b.svc.cluster.local. The fully qualified domain name (FQDN) for a Kubernetes/OpenShift Service follows the pattern ..svc.cluster.local. Therefore, to reach the 'backend' service in namespace 'project-b' from any other namespace, the correct DNS name is backend.project-b.svc.cluster.local. This FQDN resolves via the cluster's internal DNS to the Service's ClusterIP.

Answer

backend.project-b.pod.cluster.local

Answer

backend.project-b.svc

Answer

backend.project-b.internal

Question 2

An administrator must configure a NetworkPolicy in the 'secure-zone' namespace to explicitly deny all ingress traffic except for TCP traffic coming from pods labeled 'tier=frontend' in the 'frontend-zone' namespace. Which NetworkPolicy specification achieves this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend-zone
      podSelector:
        matchLabels:
          tier: frontend
    ports:
    - protocol: TCP. It uses a single ingress rule with both a namespaceSelector matching the 'frontend-zone' namespace (via the automatic label kubernetes.io/metadata.name) and a podSelector matching pods with label tier=frontend. In Kubernetes NetworkPolicy, when multiple selectors are specified within the same 'from' element, they are ANDed together, meaning only pods that satisfy both conditions are allowed. The policy also sets podSelector: {} to apply to all pods in the secure-zone namespace, and policyTypes: [Ingress] to enforce the rule, effectively denying all other ingress traffic.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.128.0.0/14
    ports:
    - protocol: TCP

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend-zone
    ports:
    - protocol: TCP

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: secure-zone
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          tier: frontend
        matchExpressions:
          - key: namespace
            operator: In
            values: [frontend-zone]
    ports:
    - protocol: TCP

Question 3

An administrator needs to create a service that exposes an application externally via an IP address allocated from an external cloud provider load balancer. Which service type must be used?

Accepted Answer

LoadBalancer. A Service of type LoadBalancer instructs the cloud provider's controller (or OpenShift's cloud provider integration) to provision an external load balancer with a public or private IP address, and the Service is exposed through that IP. This is the standard way to expose an application externally via a cloud LB in OpenShift/Kubernetes. The LoadBalancer type builds on NodePort and ClusterIP, adding the external IP allocation.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 4

A cluster administrator needs to inspect the current default CNI network provider configured in an OpenShift 4.14 cluster. Which command or resource should the administrator check?

Accepted Answer

oc get networks.config/cluster -o jsonpath='{.spec.networkType}'. In OpenShift 4.x, the cluster-wide network configuration is stored in the networks.config.openshift.io/cluster resource, and the CNI plugin in use is exposed in the spec.networkType field. Running `oc get networks.config/cluster -o jsonpath='{.spec.networkType}'` returns the configured network plugin, typically OpenShiftSDN or OVNKubernetes. This is the authoritative place to inspect the default CNI provider.

Answer

oc get dns cluster -o jsonpath='{.spec.baseDomain}'

Answer

oc get proxy cluster -o jsonpath='{.spec.httpProxy}'

Answer

oc get clusterversion version -o jsonpath='{.status.capabilities}'

Question 5

An application pod needs to discover other pods behind the same headless service. What characteristic defines a headless service?

Accepted Answer

It has spec.clusterIP set to None.. A headless service is defined by setting `spec.clusterIP` to `None`, which tells Kubernetes not to allocate a virtual IP. Instead, DNS returns the individual pod IPs associated with the service, allowing direct pod discovery. This is commonly used for stateful applications where clients need to connect to specific pods.

Answer

It automatically creates an external Route resource.

Answer

It does not have any selector defined in its specification.

Answer

It disables internal container DNS resolution entirely.

Question 6

An administrator needs to modify the timeout values for the default OpenShift Ingress Controller (Router). Where should this change be applied?

Accepted Answer

Edit the ingresscontroller instance named 'default' in the 'openshift-ingress-operator' namespace.. The OpenShift Ingress Controller (Router) is managed by the Ingress Operator. To change timeout values, you must modify the IngressController custom resource named 'default' in the 'openshift-ingress-operator' namespace. This is the supported method because the Operator reconciles the router deployment and its configuration based on this resource. Directly editing the router's configmap or deployment is not persistent and will be overwritten by the Operator.

Answer

Edit the proxy resource named 'cluster'.

Answer

Edit the endpoints resource in the 'openshift-ingress' namespace.

Answer

Modify the kube-apiserver configmap.

Question 7

A developer wants to expose an application using a secure Route that terminates TLS on the pod itself, avoiding decryption at the router layer. Which TLS termination type should be selected?

Accepted Answer

passthrough. Passthrough termination allows the router to forward encrypted traffic directly to the pod without decrypting it, so TLS is terminated at the pod itself. This meets the requirement of avoiding decryption at the router layer. Edge and reencrypt both involve decryption at the router, while 'none' means no TLS termination at all.

Answer

reencrypt

Answer

edge

Answer

none

Question 8

An OpenShift administrator needs to restrict external access to a specific application Route by limiting access to a predefined list of allowed client IP addresses. How can this be accomplished?

Accepted Answer

Add the annotation 'haproxy.router.openshift.io/ip_whitelist' to the Route object.. The annotation 'haproxy.router.openshift.io/ip_whitelist' on a Route object instructs the HAProxy router to allow only the specified client IP addresses (or CIDR ranges) to access that route. This is the standard OpenShift method for per-route IP whitelisting without affecting other routes or the entire router. The annotation is processed by the router's HAProxy configuration, which adds ACL rules to enforce the whitelist.

Answer

Configure spec.clientIP in the Service object definition.

Answer

Create a NetworkPolicy with spec.ingress.ipBlock restricting the router pod.

Answer

Update the IngressController CR with a global clientIP blacklist.

Question 9

An administrator notices that pods on different worker nodes cannot communicate with each other. Upon checking the cluster network operator, it appears the MTU settings between the underlying physical network and the cluster overlay network mismatch. Which OpenShift command checks the cluster network operator status?

Accepted Answer

oc get clusteroperator network. The Cluster Network Operator (CNO) status is exposed as a clusteroperator resource named 'network'. Running 'oc get clusteroperator network' shows the operator's availability, progress, and any degraded conditions, which is the standard way to check network operator health. This command directly queries the operator's status.

Answer

oc get cni cluster

Answer

oc describe networkconfig

Answer

oc get nodes --show-mtu

Question 10

A service of type NodePort has been created in OpenShift. Within what default port range are NodePort services typically allocated on the worker nodes?

Accepted Answer

30000-32767. By default, Kubernetes and OpenShift allocate NodePort services from the range 30000-32767. This range is configurable at the cluster level, but the default is standardized. NodePort services expose the service on each node's IP at that port, allowing external access.

Answer

50000-60000

Answer

1024-65535

Answer

80-443

Question 11

Which TWO of the following are valid OpenShift Service types? (Choose TWO)

Accepted Answer

ClusterIP. Option B, ClusterIP, is a valid OpenShift/Kubernetes Service type: it exposes the Service on an internal cluster IP reachable only from within the cluster, and it is in fact the default Service type. Option E, NodePort, is also a valid Service type: it allocates a static port on each node's IP (default range 30000-32767) so the Service is reachable from outside the cluster via :. The other options are not Service types: NetworkPort is not a Kubernetes/OpenShift Service type, RouteIP is not a Service type (OpenShift Routes are separate API objects that expose Services externally), and ContainerPort is a field within a Pod's container spec that declares the port the container listens on, not a Service type.

Answer

NetworkPort

Answer

RouteIP

Answer

ContainerPort

Question 12

Which THREE actions can be performed when managing Route objects in OpenShift? (Choose THREE)

Accepted Answer

Specifying TLS termination as edge, passthrough, or reencrypt. Option C is correct because a Route's spec.tls.termination field accepts exactly edge, passthrough, or reencrypt, controlling where TLS is decrypted (at the router for edge, not at all for passthrough, and at the router then re-encrypted to the backend for reencrypt). Option D is correct because spec.host lets you define the externally reachable hostname (e.g., app.example.com) that the router uses to match incoming requests. Option E is correct because spec.path allows path-based routing, so a single hostname can direct /api to one Service and /web to another. Option A is wrong because storage volumes belong to Pods/Deployments via PersistentVolumeClaims, not to Route specs, which only handle HTTP(S) ingress. Option B is wrong because BGP peering is a networking concern handled by the cluster's SDN/OVN or MetalLB, not by Route objects, which are HAProxy-based ingress definitions.

Answer

Attaching a container storage volume directly inside the Route spec

Answer

Allocating a direct BGP peering session from the Route object

Question 13

Which TWO options are valid methods to check service endpoints in OpenShift? (Choose TWO)

Accepted Answer

oc get endpoints. Option D, `oc get endpoints`, is correct because Endpoints objects are the native Kubernetes/OpenShift resource that lists the actual IP:port pairs backing a Service, so querying them directly shows whether the service has healthy endpoint addresses. Option E, `oc describe service <service-name>`, is correct because the describe output includes an `Endpoints:` field (e.g., `10.128.0.5:8080`) that reveals the currently selected pod endpoints for that Service. Option A is invalid because `oc adm inspect` is a must-gather/diagnostic command that collects cluster resources into a directory; it does not take `endpoints` as a subcommand to display them. Option B is invalid because `oc get routes` has no `--show-endpoints` flag, and Routes are OpenShift ingress objects, not the Service endpoint mechanism. Option C is invalid because `oc get pods` has no `--endpoints` flag and pods do not expose endpoint lists in that manner.

Answer

oc adm inspect endpoints

Answer

oc get routes --show-endpoints

Answer

oc get pods --endpoints

Question 14

When configuring a NetworkPolicy in OpenShift, which THREE options represent valid components or fields within a NetworkPolicy specification? (Choose THREE)

Accepted Answer

podSelector. Option A (podSelector) is correct because it is a core field of the Kubernetes/OpenShift NetworkPolicy spec that selects the pods to which the policy applies, using label selectors. Option D (ingress) is correct because ingress is a valid rule block that defines which inbound traffic is allowed to the selected pods, including from, ports, and protocol details. Option E (policyTypes) is correct because it explicitly lists which policy types the NetworkPolicy covers, valid values being Ingress, Egress, or both. Option B (routeSelector) is not a NetworkPolicy field; routes are OpenShift Route objects and are not selected by NetworkPolicy. Option C (clusterIP) is not a NetworkPolicy field; it is a Service attribute assigned to a Service's virtual IP, not part of the NetworkPolicy specification.

Answer

routeSelector

Answer

clusterIP

Question 15

Which TWO components are core parts of the OpenShift DNS architecture for cluster resolution? (Choose TWO)

Accepted Answer

CoreDNS. CoreDNS (A) is correct because OpenShift uses CoreDNS as the actual DNS server that runs in the cluster and resolves names for services, pods, and internal cluster resources. The Cluster DNS Operator (B) is correct because it is the OpenShift operator responsible for deploying, configuring, and managing the CoreDNS instances and their DNS configuration across the cluster. BIND9 (C) is not part of the core OpenShift DNS architecture; it is a general-purpose DNS server not used as the cluster's internal resolver. HAProxy DNS module (D) is incorrect because HAProxy is used for routing/load balancing, not as a core DNS resolution component in OpenShift. Keepalived DNS plugin (E) is incorrect because Keepalived provides VRRP-based high availability and is not a DNS resolution component of OpenShift.

Answer

BIND9

Answer

HAProxy DNS module

Answer

Keepalived DNS plugin