A security operations center built around network taps and endpoint agents in the company's own data centers must now cover new IaaS and PaaS workloads, where it has no access to the provider's physical network. What should the SOC manager prioritize?
Select an answer to reveal the explanation.
Short Explanation
In the cloud you can't clip a tap onto the provider's switch, so you swap packets for telemetry. Your eyes become the management plane audit trail, flow logs and service logs, and your SIEM needs rules written for cloud attacks. Don't fall for the idea that the provider's SOC watches your workloads for you.
Full Explanation
Cloud consumers lose physical network visibility, so a SOC extends coverage by collecting the telemetry the provider exposes: management plane audit logs that record every API call and console action, virtual network flow logs, load balancer and web application firewall logs, identity provider events and logs from platform services. Feeding these into the SIEM and writing detection use cases for cloud-specific threats such as credential misuse, permission changes, public exposure of storage and unusual resource creation is what makes the SOC effective in IaaS and PaaS. Asking to install physical taps in a multi-tenant facility is not feasible; the provider will not grant access to shared hardware that carries other tenants' traffic. Relying on the provider's SOC misreads shared responsibility: the provider monitors its own infrastructure, while detection inside customer workloads, identities and configurations stays with the customer. Watching only the on-premises perimeter misses traffic that never crosses the corporate firewall, such as internet users reaching cloud applications or service-to-service calls inside the provider. Exam caveat: some telemetry must be explicitly enabled and retained by the customer. Operational check: confirm audit and flow logging is on in every account and region and that each source arrives in the SIEM with alerts mapped to it.