Technical explanation

Layer 7 protocol visibility redirects traffic matching the relevant L7 rules to Cilium’s node-local proxy, which is Envoy. Envoy parses supported application protocols and supplies the resulting request or response metadata to Cilium’s observability pipeline. Therefore, C correctly identifies the architectural consequence of enabling this visibility.

The feature requires L7 proxy support and an appropriate CiliumNetworkPolicy containing Layer 7 rules. A standard Kubernetes NetworkPolicy is limited to Layer 3 and Layer 4 concepts and cannot express Cilium’s HTTP, DNS, or generic application-protocol rules, so B is incorrect.

A is also incorrect. DNS policy and visibility are commonly applied to pod egress queries, and Cilium’s model is not restricted to ingress-only DNS visibility. D overstates protocol coverage. Cilium supports defined L7 parsers and policy types—most prominently HTTP, DNS, Kafka, and supported generic Envoy-based protocols—but it does not promise arbitrary visibility for every application protocol. SSH, Telnet, and FTP cannot simply be assumed to receive native semantic parsing.

An operational caveat is that L7 visibility rules also affect policy enforcement: they are not merely passive packet logging instructions.

Official references

Layer 7 Protocol Visibility , Cilium Envoy

Study Guide topic: L7 proxy redirection, CiliumNetworkPolicy, protocol parsing, and Hubble visibility.