Cloud Security Concepts
The CIA triad: the goals of all security
Hand someone a security incident, a leaked customer database, an altered invoice, a site knocked offline, and ask which goal it broke: there are only three possible answers. Security professionals call them the CIA triad, three properties that together define what "secure" means. (CIA here is confidentiality, integrity, availability, unrelated to the intelligence agency.) Every control exists to protect at least one of them, so the triad is the mental model the rest of this page hangs on, and it lines up with the goals Google's own security guidance[1] is built to serve.
- Confidentiality: only authorized people and systems can read the data. Encryption, access management, and authentication all serve confidentiality. The failure mode is disclosure: a leaked customer database, an email sent to the wrong person, a stolen laptop.
- Integrity: data and systems are accurate, complete, and have not been altered by anyone unauthorized. Checksums, digital signatures, and audit logs serve integrity. The failure mode is tampering: a payment amount silently changed, a record deleted, malware modifying a file.
- Availability: the data and services are accessible when authorized users need them. Redundancy, backups, and DDoS protection serve availability. The failure mode is denial: a ransomware lockout, a hardware failure with no backup, an attack that floods a site offline.
The Cloud Digital Leader exam tests the triad as a classification skill, not a configuration skill. When a question describes a problem, the conceptual answer is usually the property that was violated. "A competitor obtained our unreleased pricing" → confidentiality. "Invoices were altered after approval" → integrity. "Customers could not reach the store during the sale" → availability. The same incident can hit more than one property. Ransomware that both steals and encrypts data breaks confidentiality and availability, so read the scenario for what actually happened to the data.
The triad also explains why the controls in the rest of this guide exist. When the trusted-infrastructure subtopic describes encryption, authentication, and DDoS defense, each maps back to one of these three goals. That is the throughline to carry forward.
Top cybersecurity threats and their business impact
This section explains the threats a leader is expected to recognize and, more importantly, why they matter to the business, not how to defend against each one technically. The leadership framing comes first: security is a business risk to be managed, and the most common way in is a person, not a flaw in the hardware. Keep that lens while reading the threats below.
The threats the exam expects you to know are the common, high-impact ones:
- Phishing and social engineering: tricking a person into revealing credentials or clicking a malicious link, usually by impersonating a trusted party. This is the single most common entry point because it targets human judgment rather than a technical weakness.
- Malware and ransomware: malicious software that steals, corrupts, or (for ransomware) encrypts data and demands payment to release it. Ransomware attacks both confidentiality and availability from the CIA triad above.
- Insider threats: misuse of legitimate access by an employee or partner, whether malicious or accidental. No perimeter defense helps here, which is why the zero-trust idea in the next section verifies every access regardless of who is asking.
- Distributed denial-of-service (DDoS): flooding a service with traffic so legitimate users cannot reach it; a direct attack on availability.
What the exam actually rewards is naming the business impact, because that is how a Cloud Digital Leader frames risk to the rest of the organization. The figure below shows that translation: each technical threat lands as one or more of these business consequences.
| Impact | What it looks like |
|---|---|
| Financial loss | Theft, fraud, ransom payments, and the cost of incident response and recovery |
| Regulatory penalties | Fines and legal liability when a breach violates GDPR, HIPAA, or similar rules |
| Operational downtime | Lost productivity and sales while systems are offline or being restored |
| Reputational damage | Eroded customer trust and churn that often outlasts and outweighs the direct loss |
The through-line: the costliest consequence is frequently the reputational and trust damage, not the immediate financial hit, and the most common attack vector is human. That is why leaders treat security awareness, least-privilege access (granting only the minimum access a task needs, defined fully in the last section), and a culture of verification as business investments, and why "buy one more firewall" is rarely the complete answer.
Cloud vs. on-premises security and shared responsibility
Security in the cloud is a shared responsibility: the provider secures the cloud itself, and the customer secures what they run in it. Building on the CIA goals from the first section, that one model decides who is responsible for a given security task and why the cloud can be more secure than a typical on-premises setup. Everything below is a delta from it.
On-premises, you own the whole stack. The organization is responsible for the physical building and power, the hardware, the network, the operating system, the applications, and the data. Every security control, and the cost and staff to run it, is theirs. That is the baseline the cloud changes.
In the cloud, the responsibility splits. Google describes the shared responsibility model[2] as the set of security tasks that differ between you and the cloud provider. Google secures the infrastructure: the data centers, the purpose-built servers, the global private network, and hardware disposal. The customer secures their own layer: their data, who can access it, and how they configure their services. Google extends this with shared fate, which it frames as an "ongoing partnership to improve security": rather than handing the customer a checklist at the door, Google provides secure defaults, vetted blueprints, and guidance so the customer's side is easier to get right. Where the dividing line sits depends on the service model and shifts toward the provider as you move from IaaS to PaaS to SaaS. The dedicated service-models-shared-responsibility subtopic covers that shift; here, the takeaway is simply that the line exists and the customer is always responsible for their data and access.
Why the cloud can be more secure, not less. A frequent misconception is that moving off-premises is inherently riskier. In practice a hyperscale provider affords controls a single organization usually cannot, and turns many on by default:
- Encryption at rest by default: Google states it encrypts "all Google customer content at rest, without any action required by you,"[3] using AES-256. On-premises, encryption is something you must design and enable yourself.
- Encryption in transit: data moving across Google's network is encrypted[4] by default to protect it from interception.
- Zero trust: Google operates a never trust, always verify[1] model, granting access based on continuous verification rather than trusting any device just because it is inside the network perimeter. This is the structural answer to the insider and phishing threats from the previous section, which defeat perimeter trust.
The reconciling point, secure-by-default does not make the cloud automatically safe, belongs right here next to the claim: the customer still owns their side of the line, and most real-world cloud incidents trace to customer misconfiguration (an over-permissive access rule, a publicly exposed bucket), not to a breach of Google's infrastructure. The cloud raises the floor; the customer still has to stand on their part of it.
Control, compliance, and key security terms
This section closes the loop: having seen the goals (CIA), the threats, and who is responsible, you will be able to distinguish being secure from proving it, and recognize the security vocabulary the exam drops into questions. It opens with the distinction the exam most often tests in this area.
A security control is a safeguard that reduces risk; compliance is demonstrating to an outside party that the required controls are in place and working. Controls are what you do to be secure; compliance is how you prove it. The two are easy to conflate, so keep them apart: a system can have strong controls and not yet be certified, and (the trap) passing an audit proves controls existed on paper but does not by itself guarantee the system is secure in practice. Compliance is necessary evidence, not a substitute for the controls.
Controls come in three families, and a question may ask you to recognize which kind something is. The figure below groups each family with its typical examples:
- Technical (or logical) controls are enforced by technology: encryption, access management, firewalls, logging.
- Administrative controls are policies and process: security training, access-review procedures, an incident-response plan.
- Physical controls protect the premises: data-center badge access, cameras, guards.
Compliance standards are the published rulebooks an organization is measured against. The exam expects recognition, not mastery: ISO 27001 (an international information-security management standard), SOC 2 (a report on a service provider's security controls), GDPR (EU data-protection regulation), and HIPAA (US health-information privacy). The cloud advantage here is inheritance: because Google's infrastructure regularly undergoes independent verification[5] and is certified against many of these standards, the customer inherits that coverage for the provider's layer and only has to demonstrate compliance for their own layer, narrowing the scope and cost of an audit. The trust-principles-compliance subtopic goes deeper on how Google publishes and shares this evidence.
Finally, the key security terms the exam uses as building blocks, each defined once for reference:
| Term | Meaning |
|---|---|
| Authentication | Verifying who a user or system is (proving identity) |
| Authorization | Determining what an authenticated identity is allowed to do |
| Least privilege | Granting only the minimum access needed for a task, nothing more |
| Zero trust | Never trust, always verify: authenticate and authorize every access regardless of network location |
| Encryption | Encoding data so only an authorized party with the key can read it |
These terms recur throughout the trust-security domain; recognizing them and the control-vs-compliance distinction is the core of what "cloud security concepts" tests at Cloud Digital Leader level.
Securing on-premises vs. securing in the cloud
| Dimension | On-premises | Cloud (shared responsibility) |
|---|---|---|
| Who secures the physical layer | You: building, power, hardware, disposal | Google: data centers, servers, global network |
| Who secures data, access, config | You | You (the customer's side of the line) |
| Spending model for security | CapEx: buy and staff your own controls | OpEx: inherit provider controls, pay as used |
| Encryption posture | Optional: you must design and enable it | On by default: at rest (AES-256) and in transit |
| Trust model | Often perimeter trust (trusted internal network) | Zero trust: verify every access, no implied trust |
| Compliance evidence | You build and prove every certification yourself | Inherit Google's independently audited certifications |
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Map every security goal to the CIA triad
The CIA triad names the three goals all security serves: confidentiality (only authorized parties can read data), integrity (data is accurate and untampered), and availability (data and services are reachable when needed). On the exam, classifying an incident by the property it violated is usually the answer: leaked data is confidentiality, altered records are integrity, an outage is availability.
- Confidentiality is about disclosure, not change or uptime
Confidentiality fails when data is disclosed to someone unauthorized: a leaked customer list, a misdirected email, a stolen laptop. It is protected by encryption, access management, and authentication. Keep it distinct from integrity (which is about unauthorized change) so you pick the right CIA property when a scenario describes exposed data.
Trap Calling a silent data alteration a confidentiality breach: changing data without disclosing it is an integrity failure, not confidentiality.
- Integrity is about unauthorized change, detected by signatures and logs
Integrity means data and systems are accurate and have not been altered by anyone unauthorized; the failure mode is tampering, such as a payment amount silently changed or a record deleted. It is protected by checksums, digital signatures, and audit logs that reveal whether something was modified. Read the scenario for whether data was changed (integrity) versus merely seen (confidentiality).
- Availability is about access when needed, the target of DDoS and ransomware
Availability means authorized users can reach the data and services when they need them; the failure mode is denial, whether from a DDoS flood, a hardware failure with no backup, or a ransomware lockout. It is protected by redundancy, backups, and DDoS defense. An attack that knocks a site offline during a sale is an availability incident, even if no data was stolen.
3 questions test this
- An online retailer needs to guarantee that its customer-facing services stay accessible even during hardware failures or traffic spikes.…
- A streaming media platform must remain accessible and fully operational for its viewers even during periods of unusually high demand. Which…
- A financial services company experiences a distributed denial-of-service attack. What is the most significant business implication if the…
- One incident can break more than one CIA property
The CIA properties are not mutually exclusive: ransomware that both exfiltrates and encrypts data breaks confidentiality and availability at once. When classifying an incident, read what actually happened to the data rather than assuming exactly one property applies.
- The most common attack vector is a person, not a firewall gap
Phishing and social engineering (tricking someone into revealing credentials or clicking a malicious link by impersonating a trusted party) are the single most common entry point, because they target human judgment rather than a technical weakness. The leadership consequence is that security awareness and least-privilege access matter as much as technical controls, since buying more perimeter hardware does not address the human vector.
Trap Treating phishing as a purely technical problem solved by firewalls: it exploits human judgment, so awareness training and least privilege are the real mitigations.
- Know the common threats: phishing, malware/ransomware, insiders, DDoS
The threats the exam expects you to recognize are phishing/social engineering, malware and ransomware (which steal or encrypt data for payment), insider threats (misuse of legitimate access, malicious or accidental), and DDoS (flooding a service so users can't reach it). Each maps back to the CIA triad: ransomware hits confidentiality and availability, DDoS hits availability, an insider can hit any of the three.
- Frame a breach by its business impact, not just the technical event
A Cloud Digital Leader describes security risk in business terms: financial loss (theft, fraud, ransom, recovery cost), regulatory penalties (fines for violating GDPR, HIPAA, and similar), operational downtime (lost productivity and sales), and reputational damage (eroded customer trust and churn). The reputational and trust damage is frequently the costliest and longest-lasting consequence, often outweighing the immediate financial hit.
Trap Assuming the direct financial loss is always the biggest cost: reputational and customer-trust damage often outlasts and outweighs it.
The shared responsibility model splits security tasks between provider and customer: Google secures the infrastructure (data centers, hardware, the global network) while the customer secures what they run on it (their data, access, and configuration). It does not make security less important: it changes who is responsible for which part. On-premises, by contrast, the organization owns the entire stack and every control.
Trap Reading shared responsibility as outsourcing all security to the provider: the customer is always responsible for their own data, access, and configuration.
7 questions test this
- Under the Google Cloud shared responsibility model, which security task remains the responsibility of the customer rather than Google?
- An organization wants a cloud provider that goes beyond dividing responsibilities and actively helps it achieve a secure posture through…
- An organization wants to clarify its obligations versus those of Google Cloud under the cloud shared responsibility model. Which statement…
- A company is moving from a traditional on-premises data center to Google Cloud and wants to understand how security obligations change.…
- An organization plans to run its Security Operations (SecOps) on Google's trusted infrastructure. How does this align with the shared…
- An organization assumes that because Google Cloud holds many compliance certifications, it has no further compliance obligations of its own…
- Under the cloud shared responsibility model, which task always remains the customer's responsibility regardless of whether they adopt IaaS,…
- The responsibility line moves toward the provider from IaaS to PaaS to SaaS
Where the shared-responsibility dividing line sits depends on the service model: in IaaS the bulk of security tasks are the customer's, and the provider's share grows through PaaS until, in SaaS, the provider owns most of it and the customer mainly secures their access and the data they choose to store. The customer is responsible for their data and access in every model: only the rest of the line shifts.
Google frames shared fate as an ongoing partnership to improve security: rather than handing the customer a checklist of their responsibilities and stepping back, Google provides secure defaults, vetted blueprints, and guidance so the customer's side of the line is easier to get right. It is the cooperative complement to the shared responsibility model, which only divides the tasks.
- Cloud can be more secure than on-prem because controls are on by default
Moving to the cloud is not inherently riskier; a hyperscale provider affords controls most organizations cannot and enables many by default. Google encrypts all customer data at rest automatically with AES-256 and no action required, encrypts data in transit, and runs zero trust, whereas on-premises those protections are something the organization must design, fund, and enable itself.
Trap Assuming on-premises is automatically safer because the data is physically in-house: providers turn on encryption and zero trust by default that most on-prem estates lack.
- Most cloud incidents come from customer misconfiguration, not provider breach
Secure-by-default does not make the cloud automatically safe, because the customer still owns their side of the shared-responsibility line. The majority of real-world cloud security incidents trace to customer misconfiguration (an over-permissive access rule, a publicly exposed storage bucket) rather than a breach of the provider's infrastructure. The cloud raises the security floor, but the customer still has to configure their part correctly.
- Zero trust means never trust, always verify: no implied network trust
Zero trust grants access based on continuous verification of identity and context rather than trusting a device just because it sits inside the network perimeter. It is the structural answer to insider and phishing threats, which defeat perimeter-based trust by operating from inside or with stolen credentials. Every access is authenticated and authorized regardless of where it originates.
Trap Believing a trusted internal network removes the need to verify internal traffic: zero trust verifies every access precisely because insiders and stolen credentials bypass the perimeter.
- A control reduces risk; compliance proves the controls exist
A security control is a safeguard that reduces risk; compliance is demonstrating to an outside party (regulator, auditor, customer) that the required controls are in place and working against a standard. Controls are what you do to be secure; compliance is how you prove it. The two are distinct: a system can have strong controls before it is certified, and certification alone does not guarantee real-world security.
Trap Treating passing an audit as proof the system is actually secure: compliance shows controls exist on paper but is evidence, not a substitute for the controls working.
- Controls come in three families: technical, administrative, physical
Security controls fall into three categories the exam may ask you to recognize: technical (or logical) controls enforced by technology such as encryption, access management, and logging; administrative controls that are policy and process such as training and access-review procedures; and physical controls that protect the premises such as badge access and cameras. A complete security posture uses all three, not just technical tools.
- In the cloud you inherit the provider's audited compliance for its layer
Because Google's infrastructure is independently audited and certified against standards like ISO 27001, SOC 2, GDPR, and HIPAA, the customer inherits that coverage for the provider's layer and only has to demonstrate compliance for their own layer. This narrows the scope and cost of an audit compared with proving every certification yourself on-premises: a concrete business benefit of the cloud.
- Authentication proves who you are; authorization decides what you can do
Authentication verifies identity (proving who a user or system is) while authorization determines what that authenticated identity is permitted to do. They run in that order: you authenticate first, then the system authorizes specific actions. Confusing the two is a common error, so anchor on who (authentication) versus what (authorization).
Trap Using authentication and authorization interchangeably: verifying identity is separate from granting permissions, and a valid login still needs authorization for each action.
4 questions test this
- After a user has successfully signed in to Google Cloud, the system determines which actions that user is permitted to perform on a…
- A new engineer asks how authentication differs from authorization within Google Cloud's access control model. Which statement correctly…
- An organization needs to confirm that every user is who they claim to be before they are allowed to sign in to its Google Cloud…
- A retailer is mapping their Google Cloud controls to the three pillars of access management: authentication, authorization, and auditing.…
- Least privilege grants only the minimum access a task needs
Least privilege means granting an identity only the access required to do its job and nothing more, which limits the blast radius if an account is compromised or misused. It is a core defense against both insider threats and stolen-credential attacks, since a tightly scoped account can do far less damage than an over-permissive one.
6 questions test this
- An organization needs to grant a team of developers access to Cloud Storage resources without giving them broader permissions they do not…
- An organization wants its employees to have only the minimum permissions they need to perform their jobs, and nothing more. Which approach…
- An organization has a unique job function that needs a specific set of permissions, but no predefined IAM role matches that set without…
- A security administrator wants to ensure that principals in the organization have only the minimum permissions necessary to perform their…
- A bank must ensure that only authorized analysts can access sensitive customer datasets in its serverless data warehouse, in line with data…
- A security architect explains that Google Cloud's defense-in-depth model relies on granting each identity only the permissions required for…
- Encryption protects confidentiality at rest and in transit
Encryption encodes data so only a party holding the key can read it, protecting confidentiality both at rest (stored data) and in transit (data crossing a network). In Google Cloud both are provided by default, so even a stolen disk or intercepted packet yields unreadable data without the key, which is why encryption is a primary confidentiality control.
3 questions test this
- An organization is concerned that data exchanged between its users and Google Cloud services could be intercepted while it moves across the…
- An organization wants to ensure that data moving between its users and Google Cloud services cannot be read if it is intercepted on the…
- An organization is deploying a new application on Google Cloud and wants to ensure their data stored in Cloud Storage is encrypted. What…