Cloud Security
What this domain tests
Cloud Security tests the shared responsibility model, identity and access management, encryption, network controls, logging, and compliance. Scenario questions ask who secures which layer and which control prevents a specific risk.
Core rules
- Under the shared responsibility model, the provider secures the cloud infrastructure: facilities, physical security, hypervisor, and managed service foundations. The customer secures what it puts in the cloud: data, identities, access policies, configuration, and, for IaaS, the guest OS and application.
- The split changes by service model. In IaaS the customer patches the guest OS. In PaaS the provider patches the runtime and operating system; the customer secures applications and identities. In SaaS the provider secures the application; the customer manages users, access, and data sharing.
- Apply least privilege through roles and groups rather than individual long-lived credentials. Enforce multi-factor authentication for privileged access.
- Encrypt data in transit with TLS and at rest with provider or customer-managed keys. Key management determines who can decrypt; encryption without access control does not prevent data exposure.
- Enable centralized logging, monitoring, and alerting. Retain logs according to policy and test incident response.
- Compliance is shared but not fully inherited. The provider's certifications cover its infrastructure; the customer must still prove its own controls.
Worked example
A customer runs its own application on IaaS virtual machines containing regulated data. The provider is responsible for physical security, the hypervisor, and the underlying network. The customer is responsible for guest OS patching, application security, identity and access management, security group rules, encryption of data at rest, key policies, and log retention. If the same function moved to SaaS, the provider would patch the application, but the customer would still manage user provisioning, MFA, data classification, and external sharing settings. Reasoning: responsibility follows the layer the customer controls, not ownership of the data center.
Traps that cost marks
- Saying the provider secures everything in the cloud. The customer always owns data and identities.
- Assuming encryption alone is sufficient. Key access and identity controls still matter.
- Leaving security groups open to the internet because the application is behind a load balancer.
- Treating a provider's compliance certificate as covering the customer's application and configurations.
- Forgetting to monitor and alert on privileged actions and configuration changes.
Governance and Service Management
What this domain tests
Governance and Service Management tests how cloud use is controlled, measured, and operated: policies, guardrails, cost accountability, service catalogs, SLAs, change management, and exit planning. Questions ask you to choose preventive controls and distinguish governance from security alone.
Core rules
- Governance sets decision rights and policies for cloud use. It includes financial, security, operational, and compliance controls, not just security.
- Preventive controls stop non-compliant actions before they happen, such as policy-as-code that denies untagged resources. Detective controls find issues after the fact, such as configuration scans. Reactive controls respond after an incident.
- Tagging enables cost allocation, ownership, automation, and reporting. Common required tags include cost center, owner, environment, and data classification.
- Showback reports costs to teams; chargeback bills them. Both depend on accurate tagging and account or subscription structure.
- A service catalog defines approved services, options, owners, and prices. It reduces shadow IT and speeds compliant provisioning.
- SLAs state provider commitments, often with service credits. SLOs are internal objectives. An SLA does not guarantee business outcomes.
- Plan for vendor lock-in and exit: data export formats, API dependencies, identity integration, contract terms, and tested exit procedures.
Worked example
A company requires every cloud resource to carry CostCenter, Owner, and Environment tags. It enforces this with policy-as-code at provisioning time, so untagged resources are denied. It also runs a weekly detective scan for resources created before the policy, and publishes monthly showback reports by cost center. Exceptions require a documented approval with an expiry date. Reasoning: the preventive control stops most violations, the detective control finds drift, and showback creates accountability without waiting for a full chargeback model. The expiry date prevents permanent exceptions.
Traps that cost marks
- Treating governance as only security. Cost, service, and compliance controls are part of it.
- Relying on documentation without enforcement. A policy that cannot deny or remediate is only guidance.
- Confusing showback with chargeback. Showback informs; chargeback transfers cost.
- Assuming an SLA guarantees service. It usually defines commitments and credits, not business continuity.
- Ignoring exit strategy until renewal. Data gravity and proprietary APIs can make exit expensive.