Cloud Security Operations

Picture the moment a platform goes live: the architecture is signed off, the data-protection controls are in place, and now someone has to keep the thing safe every day, prove they are doing so, and act fast when it breaks. That daily running is the whole of this domain. It assumes you already know what a secure design looks like (the earlier domains covered that) and asks the next question, how do you operate it. The single mental model that holds all six subtopics together is an operations lifecycle in three movements: stand the platform up from a trusted, hardened baseline (build); keep it patched, monitored, governed, and available (run); and when an event happens, detect it, contain it, investigate it, and tell the right people (respond). Read every topic below as the answer to where in that build-run-respond arc this work lives. The classic exam trap the model defuses is treating any of these as a one-time project: a hardened build erodes without disciplined operations, and an incident-response plan is worthless if it was never exercised before the incident.

The six subtopics walk the lifecycle in order. Building Cloud Infrastructure is the clean-room moment: pin the trust root in hardware (a TPM measures and attests the boot chain, an HSM guards the keys), run a Type-1 hypervisor, and roll out hosts and golden images from a hardened baseline rather than vendor defaults. Operating Cloud Infrastructure is day-two work: reach hosts only through a bastion or managed session broker, keep them at baseline, treat infrastructure as immutable code so a patch is a redeploy, and engineer availability at the cluster. Operational Controls & Standards governs the run with service-management process, ISO/IEC 20000-1 as the certifiable standard and ITIL as the practice guidance, separating the look-alike pairs (incident versus problem, change versus release versus deployment). Then the respond arc begins: Security Operations Management is the live detection-and-response engine (the SOC team, the SIEM that correlates, the SOAR that automates, the NIST SP 800-61 incident lifecycle); Digital Forensics is the after-the-fact evidence work, collecting virtual artifacts by order of volatility while holding chain of custody across the provider boundary; and Communication with Relevant Parties is the obligation to notify vendors, customers, regulators, and partners on the legal clock once an incident is confirmed. Reach for each in roughly that sequence.

Operations is the domain where the exam most rewards process discipline over technical cleverness. The recurring instinct it tests: prefer the answer that names a recognized standard, a defined role, and a repeatable procedure over the one that quietly fixes the symptom. Restore service first with incident management, but raise a problem record so the root cause is removed and the outage stops recurring. Do not log into a server to patch it; change the immutable template and redeploy so every host stays identical and auditable. Do not power off a compromised instance; isolate it and snapshot it so volatile evidence survives. Do not wait for an incident to learn whom to notify; build the stakeholder map and assign each notification an owner with a RACI before the clock starts. Across all six subtopics the higher-scoring choice is the one that is provable after the fact, because cloud operations is judged by the audit trail it leaves, not by the cleverness of any single recovery.