Your SOC monitors a Kubernetes application where pods are created and destroyed every few minutes. A service mesh routes east-west API traffic, and traditional host logs miss many inter-pod calls. Which telemetry should the analyst prioritize to detect anomalous workload behavior?
Select an answer to reveal the explanation.
Short Explanation
Think of short-lived pods like taxis: the same street signs won't tell you who rode where. You need the meters and route logs—sidecar and CNI telemetry—to see east-west traffic. Host firewall logs can miss what never touches a traditional boundary.
Full Explanation
Ephemeral container and service-mesh architectures change where visibility lives. Pods are created, destroyed, and rescheduled frequently, so host-centric monitoring can miss short-lived identities and east-west API calls that never traverse a traditional perimeter. Service mesh sidecars and CNI flow logs provide per-workload telemetry: source and destination identities, namespaces, labels, mesh routing, mTLS status, and microsegmented flows, which lets the analyst detect lateral movement or anomalous API behavior inside the cluster. Traditional host-based firewall logs from worker nodes are too coarse: they may record node-to-node traffic but can omit intra-node pod traffic and lack workload identity. NetFlow from a physical router describes packet flows between network segments, not the service-level relationships or pod lifecycle needed for ephemeral workloads. A static inventory of pod names and namespaces is an asset record, not activity telemetry, and it becomes stale as containers churn. Exam caveat: match the telemetry source to the architecture; dynamic workloads require identity-aware, east-west visibility. Operational check: generate a test pod-to-pod request and confirm the log contains namespace, pod label or mesh identity, destination service, and timing.