Cloud & Containers Cilium-Associate Book

Technical explanation

The status output reports Operator: OK , followed by Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1 . This establishes that the Cilium Operator is deployed and healthy, making B the intended answer. Cilium uses Kubernetes CustomResourceDefinitions as its default mechanism for storing and propagating cluster state, while the operator performs cluster-wide duties that should be handled once centrally rather than independently on every node.

Option A is contradicted by the exhibit: both hubble-ui and hubble-relay appear as ready deployments and running containers. Option C is incorrect because the resource is explicitly identified as a Deployment ; the cilium agents, by contrast, are shown as a DaemonSet . Option D incorrectly treats the displayed desired replica count as a permanent restriction. A desired count of one describes this installation’s current configuration, not a universal maximum.

The exhibit also shows embedded Envoy mode and three healthy Cilium agent instances, but neither detail changes the operator conclusion.

Official references

Cilium Component Overview , Setting up Hubble Observability

Study Guide topic: Cilium components, Cilium Operator, CRD-backed state, and status interpretation.

Technical explanation

A Cluster Mesh can be created after assigning each cluster a unique name and numeric cluster ID. Cilium uses the cluster ID when constructing Cluster Mesh security identities, so duplicate values cannot safely identify endpoints from different clusters. The name must likewise be unique. These values can be changed after installation, although all existing workloads must then be restarted so their security identities are regenerated.

The other listed conditions are compatible. Both clusters use the same encapsulation datapath mode, their PodCIDRs are intended to be non-overlapping, and the nodes possess the required inter-cluster connectivity. Different Kubernetes patch or minor versions do not inherently prevent Cluster Mesh. Cilium versions may differ by one minor release, so versions 1.14 and 1.13 satisfy the documented compatibility rule.

Different certificate authorities are not an irreversible blocker under current documentation. Every cluster must trust certificates presented by the others. Operators may use a shared root CA or configure a CA bundle containing all trusted CA certificates. Consequently, B is too absolute. C is also false because changing the cluster identity is possible, subject to workload restarts. D is unnecessary because a one-minor Cilium difference is supported.

The source’s option A is truncated, but its intended corrective action is technically accurate.

Official references

Setting up Cluster Mesh .

Study Guide topic: Cluster Mesh.

Technical explanation

Policy Audit Mode allows administrators to evaluate the consequences of network policies before enforcing their deny decisions. Traffic that would ordinarily be rejected remains permitted, while Cilium records an audit verdict. These verdicts can be examined with Cilium monitoring tools and used to identify legitimate communications that are missing from the proposed policies.

This is especially valuable when introducing host policies or default-deny controls into an existing environment. An incomplete policy might otherwise block access to the Kubernetes API, node-management interfaces, DNS, monitoring systems, or other operational dependencies. The recommended workflow is to enable audit mode, observe traffic and policy verdicts, adjust the rules, confirm that all required communications receive allow verdicts, and then disable audit mode to begin enforcement.

DNS enforcement mode and HTTP audit mode are not the general Cilium configuration requested. “Policy enforcement mode” describes whether policies are normally enforced, but it does not provide the non-disruptive learning behavior in the question.

Audit mode should be treated as a temporary validation mechanism because it does not actually block disallowed traffic and does not persist across every agent-restart scenario.

Official references

Cilium Policy Audit Mode

Study Guide topic: Policy validation, audit verdicts, and safe policy rollout.

Technical explanation

The requirement is that traffic remain encrypted all the way from the external client to the backend Service . Therefore, TLS must not terminate at the Cilium Gateway/Envoy proxy .

With TLS Passthrough , Cilium forwards the encrypted TLS stream to the backend without decrypting the application traffic. Envoy can inspect the TLS ClientHello/SNI sufficiently to select the appropriate backend, but the TLS session itself continues to the Service. Cilium specifically supports TLS passthrough with the Gateway API TLSRoute resource .

By contrast, TLS Terminate + HTTPRoute decrypts the connection at the Gateway. Although a separate encrypted connection to the backend can be configured in some architectures, that is not the same as preserving the original end-to-end TLS session requested here. Cilium's HTTPS Gateway examples use TLS termination when the Gateway itself handles the certificate.

Study Guide topic: Service Mesh.