Cloud Security Fundamentals: Threats, Shared Responsibility, Zero Trust, Encryption and IAM (Cloud Digital Leader)
Fundamental cloud security concepts are the shared vocabulary leaders use to reason about risk in the cloud: the threats an organization faces, who is responsible for which part of security, and the controls that protect data and access. This lesson covers task 5.1 of the Google Cloud Digital Leader exam guide, from threats and their business impact to shared responsibility, the core security terms, encryption, identity and access, and security operations.
On this page10 sections
- Cybersecurity threats and their business impact
- Limiting the damage: backups, revocation and more than one location
- LLM attacks: prompt injection versus data poisoning
- Cloud security versus on-premises security
- Control, compliance, confidentiality, integrity and availability
- Key security terms: least privilege, privileged access, zero trust and more
- Zero trust versus perimeter security
- Encryption at rest, in transit and in use
- Authentication, authorization and auditing
- Security operations terms: posture, threat intelligence and threat response
- Recognise common cybersecurity threats, including DDoS, ransomware, viruses, phishing, cryptomining, misconfiguration, unsecured third-party systems, physical damage and LLM attacks, and describe the business impact of each
- Differentiate cloud security from on-premises security using shared responsibility and shared fate
- Explain control, compliance, confidentiality, integrity and availability, and identify which one a scenario puts at risk
- Define least privilege, privileged access, zero-trust architecture, data loss prevention, security by default, cyber resilience and firewalls
- Explain how encryption protects data at rest, in transit and in use, and what encryption does not protect against
- Differentiate authentication (including MFA and 2SV), authorization (IAM) and auditing
- Define the security operations terms security posture, threat intelligence and threat response
Cybersecurity threats and their business impact
A cybersecurity threat is anything that can harm an organization's systems or data, and leaders judge each one by its business impact: lost revenue, downtime, stolen or altered data, unexpected cost, regulatory penalties and damaged trust. The exam guide names the threats below. Each has a recognisable signature, so learn what each one does rather than only its name.
| Threat | What it does | Typical business impact |
|---|---|---|
| Distributed denial of service (DDoS) | Floods a service with traffic from many sources, often thousands of hijacked devices, until real users cannot reach it | Lost availability: missed sales, broken service levels, damaged reputation. No data needs to be stolen. |
| Malware | The family name for any software written to harm a system | Depends on the kind: data theft, disruption, cost |
| Virus | Malware that attaches itself to legitimate files and spreads when they are opened or shared | Infection spreads across devices and shared files |
| Ransomware | Malware that encrypts or locks data and demands payment for the key | Operations stop until data is restored; possible data loss and extortion |
| Cryptomining | Runs cryptocurrency-mining software on the victim's compute, usually after stealing credentials | Unexpected compute bills and slower systems; the attacker wants to stay hidden |
| Phishing | Messages that impersonate a trusted sender to trick people into revealing credentials or opening malicious content | Stolen accounts, often the first step of a larger attack |
| Misconfiguration | A setting the organization itself chose, such as a publicly readable storage bucket or an overly broad permission | Data exposure with no break-in; one of the most common causes of cloud data leaks |
| Unsecured third-party systems | A supplier's or partner's poorly protected system that is connected to yours becomes the way in | Your security is only as strong as the weakest system you connect to |
| Physical damage | Fire, flood, power loss or broken hardware in one location | Lost availability, and lost data if it existed only in that place |
| LLM attacks | Manipulating a large language model or the data it learns from (see below) | Leaked data, harmful or wrong decisions by AI systems |
Several threats often appear in one incident. Phishing may steal the password, the attacker then installs ransomware or runs cryptominers. When you classify an incident, name it by what the attack actually did to the business: data locked and a ransom demanded is ransomware, a surprise compute bill from unknown busy machines is cryptomining, a site knocked offline by a flood with no breach is DDoS.
Limiting the damage: backups, revocation and more than one location
Prevention keeps threats out; recovery planning limits the damage when one gets through, and each threat has a recovery measure that matches what it harms.
- Ransomware: regular backups kept separate from production, with restores that have been tested, let the organization rebuild without paying. Preventive controls lower the chance of infection, but once files are locked only a clean, separate copy brings them back.
- Cryptomining: the first response is to cut off the attacker's access, typically by revoking the leaked credential, and then remove the resources the attacker created. Noticing the cost is detection, not containment: while the credential still works, the attacker can keep spending.
- DDoS: the harm is an outage, so the measures are about absorbing or filtering traffic at the edge and keeping the service reachable. Google Cloud's edge protection products are covered in the task 5.2 lesson.
- Physical damage: a disaster hits a place, so resilience means running in more than one place. Anything that lives in the affected location, extra capacity and copies alike, goes down with it. Geographic separation, with data replicated between distant sites, is what lets service continue.
- Misconfiguration: case-by-case clean-up treats symptoms. Organization-wide guardrails, such as a policy that blocks public sharing in every project, prevent the mistake before it happens. Google Cloud now applies some of these guardrails by default to new organizations, for example preventing public access to Cloud Storage buckets.
LLM attacks: prompt injection versus data poisoning
LLM attacks target generative AI systems, and two common LLM attacks differ by when the attacker interferes: prompt injection manipulates the model at the moment it is used, data poisoning corrupts what it learns from before it is built.
| Prompt injection | Data poisoning | |
|---|---|---|
| When | At run time, through the input the model receives | Before or during training, through the training or tuning data |
| How | Instructions hidden in a user message or in content the model reads (a web page, a document) override the model's intended rules, for example "ignore your earlier instructions" | Falsified or malicious records are slipped into the data the model learns from |
| Result | The model reveals data it should protect or takes actions it should not | The trained model itself behaves the way the attacker wants, for example approving a fraud pattern |
Neither is phishing (which deceives a person) or malware (which installs software): the target is the AI model, and the weapon is text or data. Google Cloud's protections for AI systems, such as Model Armor, belong to task 5.2.
Cloud security versus on-premises security
In the cloud, security becomes a shared job: Google secures the underlying infrastructure, and the customer still secures its data, its users and how it configures access. On premises, the organization owns every layer itself, from the building's locks to the application's passwords.
| Layer | On premises | In Google Cloud |
|---|---|---|
| Data centre buildings, physical access, power | The organization | |
| Servers, network hardware, patching the physical infrastructure | The organization | |
| Encryption of stored data | The organization must set it up | On by default for customer data at rest; the customer can choose to manage its own keys |
| Who can access which data (identities, IAM roles, sharing settings) | The organization | The customer |
| The customer's data and how it is classified and used | The organization | The customer |
The exact split depends on the service: the more managed the service (SaaS, serverless), the more Google handles; with virtual machines the customer still patches the operating system it runs. What never moves to Google is the customer's control over its own data and access. Access decisions are the customer's to make, and the platform carries out whatever settings the customer chooses, including risky ones, so the risk of a misconfiguration stays with the customer.
Google describes its approach as shared fate rather than only shared responsibility: beyond securing its own layers, it gives customers secure defaults, blueprints and tools to help them get their part right. The help is real, but the responsibility for the customer's configuration still sits with the customer.
Control, compliance, confidentiality, integrity and availability
These five ideas describe what a cloud security model is trying to achieve, and a scenario usually puts one of them at risk more than the others. Confidentiality, integrity and availability are the classic CIA triad; control and compliance are the customer's authority over its data and its obligations to outside rules.
| Principle | Means | Lost when… |
|---|---|---|
| Confidentiality | Only authorized people can see the data | Data is read or exposed to the wrong people |
| Integrity | Data stays accurate and is changed only by those allowed to change it | Data is altered without permission, such as tampered prices |
| Availability | Authorized users can reach systems and data when they need them | A service is offline or unreachable, such as during a DDoS attack |
| Control | The customer decides who can access its data, where it is stored and who holds the encryption keys | Those decisions are left to someone else |
| Compliance | Meeting the laws, regulations and standards that apply to the business, and proving it to auditors and regulators | The business cannot meet or demonstrate an external requirement, such as data residency |
The near-twins are control and compliance. Control is the organization's own choice to make the decisions; compliance is an external rule it must meet and prove. A bank that must show auditors its data never leaves approved countries has a compliance need; a company that simply wants to choose its data locations and hold its own keys wants control. To read an incident against the triad, ask what happened to the data: seen by the wrong people (confidentiality), changed (integrity) or unreachable (availability).
Key security terms: least privilege, privileged access, zero trust and more
The exam guide lists a set of core security terms; each names one specific idea, and distractors usually swap in a neighbouring term.
- Least privilege: every user and service gets only the access its job needs, and nothing more. An analyst who only views billing reports should not be able to delete projects. Least privilege covers time as well as scope: powerful rights should exist only while they are needed.
- Privileged access: permissions powerful enough to change security settings, manage identities or destroy resources, typically held by administrators. Because misuse is so damaging, privileged access is kept small and temporary, for example granted on request for a few hours, approved and logged (Google Cloud offers this just-in-time model through Privileged Access Manager). Standing powerful rights are a standing target, and rights that several people use under one identity break accountability.
- Zero-trust architecture: no request is trusted because of where it comes from. Every request is verified on the user's identity and context, such as the device's state, and access is granted app by app. It replaces perimeter-based security, where anything inside the network boundary is trusted (see the next section).
- Data loss prevention (DLP): discovering, classifying and protecting sensitive data, such as card or national ID numbers, so it does not leak outside approved systems.
- Security by default: protections are built in and switched on from the start, with nothing for the customer to configure, such as Google Cloud encrypting stored data automatically.
- Cyber resilience: the ability to keep critical services running during an attack and recover quickly afterwards, accepting that not every attack can be prevented. Backups, tested restores and multi-region designs are resilience measures.
- Firewall: a control that allows or blocks network traffic using rules on source, destination, port and protocol, for example allowing web traffic on standard web ports and blocking every other incoming connection.
- Security posture: the overall strength and readiness of the organization's defences (covered with the SecOps terms below).
Zero trust versus perimeter security
Zero trust removes the trusted inside of the network: being on the corporate network or the VPN no longer grants access, and each application checks every request on identity and device before allowing it. Perimeter security works like a castle wall: once you are past the firewall or connected to the VPN, you can reach most internal systems.
The weakness of the perimeter model shows when one device is compromised. An intruder with a stolen laptop that is connected to the VPN can move from system to system, because the network itself is trusted. Hardening the boundary itself does not change that: whatever gets past it is still trusted. Zero trust limits the damage because each app decides on its own, using verified identity and device checks, so one compromised device does not open the whole network.
Zero trust and least privilege work together but are different ideas: zero trust is about how each request is checked, least privilege is about how much access is granted once it is. Google's own model is BeyondCorp, and Identity-Aware Proxy, which applies it to applications on Google Cloud, is covered in the task 5.2 lesson.
Encryption at rest, in transit and in use
Encryption turns readable data into scrambled data that only a holder of the right key can turn back (decryption), and it protects data in three states: at rest (stored), in transit (moving across a network) and in use (in memory while being processed).
| State | Where the data is | Protects against | In Google Cloud |
|---|---|---|---|
| At rest | On disks, in databases and storage | Someone obtaining the storage itself, such as a drive removed from a data centre | On by default for customer data; customers can use customer-managed keys for more control |
| In transit | Travelling between users, services and data centres | Someone intercepting traffic on the network | Traffic to Google is protected with TLS, and Google encrypts data moving between its facilities |
| In use | In memory while an application processes it | Data being read from memory during processing | Confidential Computing, which encrypts data in memory while it is processed |
At rest and in transit together still leave one gap: data being processed. Encryption in use closes it, which matters to organizations handling highly sensitive data such as health or financial records.
What encryption does not protect against
Encryption protects data from people without access, not from people using access the system accepts. A service decrypts data automatically for every request it authorizes. If an attacker steals an employee's valid sign-in, their requests look authorized and they see readable records. Whichever state is protected and whoever holds the keys, an authorized request still receives readable data. The same applies to misconfiguration: once a bucket is public, the service decrypts its files for anyone who asks. That is why encryption is paired with strong authentication, least-privilege authorization and auditing.
Security operations terms: posture, threat intelligence and threat response
Security operations (SecOps) is the ongoing work of protecting an organization, and three terms describe its main activities: improving security posture, gathering threat intelligence and carrying out threat response.
| Term | Meaning | Example |
|---|---|---|
| Security posture | The overall strength and readiness of the organization's own defences, improved by finding and fixing weaknesses | Clearing a backlog of unpatched servers; turning on stronger default settings across projects |
| Threat intelligence | Evidence-based knowledge about attackers, their methods, tools and indicators, used to anticipate attacks | Subscribing to a feed of indicators of compromise, such as known malicious IP addresses, and checking systems against it |
| Threat response | Acting on a detected, active threat: containing it, investigating it and recovering | Isolating a virtual machine found running malware, then investigating how it was infected |
The way to tell them apart is the presence of an attack. A weakness with no attack detected is a posture issue. Knowledge about attackers who have not struck you yet is intelligence. Only a live, detected threat calls for response. Google Cloud's products for these activities, such as Security Command Center, Google Threat Intelligence and Google Security Operations, are covered in the task 5.2 lesson.
Tip. Questions on this topic are short business scenarios that describe an incident, a goal or a worry and ask which threat, principle, term or control it matches, or what business impact to expect. Many options are near-neighbour terms from the same list (confidentiality vs integrity vs availability, control vs compliance, least privilege vs zero trust, threat intelligence vs threat response, authentication vs authorization vs auditing), so the deciding detail is usually one fact in the stem: whether data was read, changed or unreachable, whether an attack has been detected yet, or whether the requirement comes from an outside rule. Harder items ask why a control such as encryption does not stop an attack, who owns a mistake under shared responsibility, or which measure limits the damage after an attack gets through. Expect a few Select TWO items.
- Name a threat by what it did: data locked for ransom is ransomware, a surprise compute bill is cryptomining, an outage from a traffic flood is DDoS, data exposed by your own settings is misconfiguration.
- Malware is the family; a virus is the kind that spreads by infecting files.
- Prompt injection manipulates a model through its input at run time; data poisoning corrupts its training data beforehand.
- Isolated, tested backups limit ransomware damage; a physical disaster hits one place, so resilience means more than one region.
- In Google Cloud, Google secures the infrastructure; the customer secures its data, identities and access configuration, so misconfiguration stays the customer's to prevent.
- Confidentiality = not seen by the wrong people; integrity = not changed; availability = reachable. Control is deciding for yourself; compliance is meeting and proving external rules.
- Least privilege limits access in scope and in time; privileged access is kept small, temporary, approved and logged.
- Zero trust verifies every request on identity and device; a stronger perimeter is still perimeter security.
- Encryption protects data at rest, in transit and in use, but it does not stop someone using stolen valid credentials.
- Authentication (2SV, MFA) proves who you are, authorization (IAM) decides what you may do, auditing records what you did.
Frequently asked questions
What is the difference between ransomware, a virus and malware?
Malware is any software written to harm a system. A virus is a type of malware that attaches itself to legitimate files and spreads when they are opened or shared. Ransomware is a type of malware that encrypts or locks an organization's data and demands payment for the key. The best defence against ransomware's business impact is isolated backups with tested restores.
Who is responsible for security in Google Cloud?
Security in Google Cloud is shared. Google secures the infrastructure: its data centres, hardware, network and core services, and it encrypts customer data at rest by default. The customer remains responsible for its data, its users and identities, and how it configures access, such as IAM roles and sharing settings. Google calls its approach shared fate because it also provides secure defaults and tools to help customers get their part right.
What is the difference between prompt injection and data poisoning?
Prompt injection attacks a large language model at run time by hiding instructions in the input it receives, so it overrides its intended rules, for example revealing data it should protect. Data poisoning corrupts the data a model is trained or tuned on, so the finished model itself behaves the way the attacker wants. One manipulates what the model is told; the other manipulates what it learns from.
What is zero-trust architecture?
Zero-trust architecture is a security model in which no request is trusted because of its network location. Every request is verified on the user's identity and context, such as the state of the device, and access is granted application by application. Unlike perimeter security, where anything inside the network or VPN is trusted, zero trust stops one compromised device from giving an intruder access across the network.
What are the three states of data encryption?
Data is encrypted at rest when it is stored on disks and in databases, in transit when it travels across a network, and in use when it is in memory while being processed. Google Cloud encrypts customer data at rest by default, protects data in transit, and offers Confidential Computing to encrypt data in use. Encryption does not stop someone who signs in with stolen valid credentials, because the service decrypts data for authorized requests.
What is the difference between authentication, authorization and auditing?
Authentication confirms who someone is, for example with a password plus multi-factor authentication or two-step verification (2SV). Authorization decides what an authenticated identity may do on which resources, which Google Cloud handles with IAM roles. Auditing records who did what, where and when, so actions can be investigated afterwards. Each answers a different question, so security goals often need more than one of them.
What is the difference between least privilege and privileged access?
Privileged access means permissions powerful enough to change security settings, manage identities or delete resources. Least privilege is the principle that every user gets only the access their job needs. Applied to privileged access, least privilege means keeping powerful rights to few people and granting them only for as long as needed, ideally on request, approved and logged.
What is the difference between security posture, threat intelligence and threat response?
Security posture is the overall strength of an organization's own defences, improved by fixing weaknesses such as unpatched systems. Threat intelligence is knowledge about attackers, their methods and tools, used to prepare before they strike. Threat response is the action taken against a detected, active threat: containing it, investigating it and recovering.
Source
This lesson covers the "Trust and Security with Google Cloud" domain of the official CDL exam guide. Vendors revise their guides — check the source for the current version.
- Google Cloud Digital Leader certification and exam guide — Google Cloud
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.