Trust and security in the cloud

Study guide for Cloud Digital Leader, Unit 5 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Discuss fundamental cloud security concepts.

Objectives, quoted from the exam guide:

1. Describe today’s top cybersecurity threats and business implications.
2. Differentiate between cloud security and traditional on-premises security.
3. Describe the importance of control, compliance, confidentiality, integrity, and availability in a cloud security model.
4. Define key security terms and concepts.

Trust and security in the cloud

What threatens you, what changes in the cloud, and the words for both

The threats — the old ones the cloud shares and the five it adds. The difference — the cloud is no more or less secure; what changes is where security lives. The five words — control, compliance, confidentiality, integrity, availability. The vocabulary — zero trust, least privilege, defense in depth and the rest, each as Google defines it.

Unit five opens with the concepts every later security topic uses, and the guide's summary is short: discuss fundamental cloud security concepts. Google defines cloud security as the set of cybersecurity measures used to protect cloud-based applications, data and infrastructure, and this topic's four objectives are four questions about it. What threatens an organization today, and what does a successful attack cost the business? What actually differs between securing the cloud and securing a data center of your own? What do the guide's five words — control, compliance, confidentiality, integrity and availability — each protect? And what do the core security terms mean, as Google uses them? One thing you already know from Unit one, Topic three, and will not be re-taught here: Google describes the provider as always responsible for the cloud and its core infrastructure, and the customer as responsible for securing anything that runs in the cloud. Everything in this topic sits on top of that split. Topics two and three of this unit then look at Google's own infrastructure and its compliance programme in detail.

The threats: old ones, and five the cloud adds

The cloud keeps the familiar risks and adds its own

Worked example (synthetic). A team moves a file store to the cloud and keeps the vendor's default password. No new attacker was needed — the misconfiguration was the vulnerability.

The first objective asks for today's top cybersecurity threats. Google's own definition of cloud security already names three: it exists to secure cloud environments against unauthorized access, online attacks and insider threats. Its fuller answer has two halves. The first half is continuity: cloud suffers from similar security risks that you might encounter in traditional environments, such as insider threats, data breaches and data loss, phishing, malware, distributed denial-of-service (DDoS) attacks, and vulnerable application programming interfaces (APIs). Moving to the cloud does not retire any of those. The second half is what the cloud adds, and Google names five challenges. Misconfiguration comes first because it matters most: misconfigured cloud security settings are one of the leading causes of data breaches in cloud environments, and Google's examples are ordinary — leaving default passwords in place, failing to activate data encryption, or mismanaging permission controls. Access management is next: because cloud deployments are reachable from the public internet, attackers can more easily reach resources with compromised credentials. Lack of visibility follows, since traditional network visibility tools are not suitable for cloud environments. Dynamic workloads defeat legacy tools that cannot enforce policy on workloads added or removed in seconds. And compliance is the odd one out, because it can fail without an attacker at all.

What the threats mean for the business

Attackers follow the shortcuts; strategy limits the damage

Figure. Three cards on the business implications of cyber threats: why cloud targets attract attackers when security is an afterthought, what a well-designed security strategy buys without guaranteeing prevention, and why understanding the threat landscape comes first.

Worked example (synthetic). A retailer rushes a new cloud storefront live before its security review. Google's pages describe exactly that trade — faster transformation, best practices skipped — as what attackers look for.

The second half of the first objective is business implications, and Google frames them in three moves. First, why the cloud attracts attackers: many organizations treat security as an afterthought and may forgo best practices in favor of chasing faster digital transformation, and as a result attackers see cloud-based targets as a potentially easy path to big gains. The implication is uncomfortable — the speed that made the move valuable can be what exposes it. Second, what a strategy buys. Google is careful here: cloud security can never guarantee complete prevention of attacks, but a well-designed strategy can go a long way toward preventing breaches or mitigating damage, improving compliance, and building stronger customer trust. Notice that three of those four outcomes are business outcomes, not technical ones. Third, where to begin. Google's framework says understanding the threat landscape — the most likely attackers, their tactics, techniques and procedures, and the potential impact — is critical to prioritizing actions, and that threat intelligence provides that knowledge about threat actors. You cannot defend against everything equally; you defend against what is most likely to hurt you.

Cloud security against on-premises security

Not more secure or less — secured differently

• Google: cloud is no more or less secure than on-premises security
• On-premises trusted the perimeter; zero trust verifies every request
• Providers build layered security into the platform and automate it at scale
• You lose complete control of the data center, and gain central visibility

Worked example (synthetic). A bank's security lead argues that its own data center is safer because it is physically theirs. Google's answer is that location is not the variable — what matters is how the controls are built and run.

The second objective asks how cloud security differs from traditional on-premises security, and it is easy to answer with a slogan in either direction. Google declines both slogans: cloud security has often been framed as a barrier to adoption, but the reality is that cloud is no more or less secure than on-premises security. What changes is where security lives and how it is run. Traditional information technology (IT) security, in Google's description, focused on defending access at the network perimeter and assumed everything inside could be trusted. The cloud's model is different: the top providers have secure-by-design infrastructure and layered security built directly into the platform — from zero-trust network architecture to identity and access management (IAM), multi-factor authentication (MFA), encryption, and continuous logging and monitoring — and the cloud lets you automate and manage security at an enormous scale. There is a genuine trade, and Google states it too. On-premises, you have complete control over your data and how it is accessed; in the cloud it is much harder to identify every asset and control and map it to requirements. In return, an integrated cloud security stack gives centralized visibility, and you no longer pay for dedicated security hardware or spend your own staff on security updates. Google also describes where the relationship is heading: under a shared fate model, the provider gives more comprehensive guidance, resources and tools to help customers sustain secure use of the cloud, rather than leaving them to navigate the risk alone.

Five differences, side by side

Each row is a trade, not a verdict

Worked example (synthetic). An auditor asks the same question of two teams: show me every place customer data lives. The on-premises team knows its racks; the cloud team needs its provider's central inventory to answer at all.

Laid side by side, the second objective becomes five trades. Where is trust placed? On-premises, at the perimeter, with everything inside assumed trustworthy; in the cloud, on every identity and every request. Who secures what? On-premises, the organization secures everything; in the cloud, the provider is responsible for the cloud and its core infrastructure and you secure what runs in it — the split you met in Unit one. How much control over the data? Google is candid that on-premises offers complete control over your data and how it is accessed, and that in the cloud it is much harder to consistently identify all assets and controls. How much can you see? Traditional tools see the corporate network, while an integrated cloud-based security stack provides centralized visibility of cloud resources and data. And who buys and updates the security tooling? On-premises, you do; in the cloud, you no longer pay for dedicated hardware to upgrade your security, and much of it is automated at scale. Read the table as trades. A question that asks which environment is simply more secure is a question Google's own page refuses to answer that way.

The perimeter moves to the user

Access is checked at identity and context, not network location

Figure. A zero-trust access path. An employee on any network signs in to an identity provider with strong authentication. Each request then goes to Identity-Aware Proxy, which verifies identity and context every time before forwarding it, with least privilege, to the application inside a boundary of only the granted resources, which reads its data. The callout states that no request is trusted for being inside the network.

Worked example (synthetic). An employee's laptop is on the office network, but its session fails the context check. Under zero trust the request is refused anyway — being inside the building earns nothing.

This figure is the reason the comparison is not a matter of taste. On-premises security drew one line, the perimeter, and trusted everything inside it. Google's own model, BeyondCorp, uses tools such as single sign-on, Access Context Manager and Identity-Aware Proxy to push the perimeter from the network to individual devices and users. Follow the path. The employee, on any network, first proves who they are to an identity provider — Google's framework says you must implement strong identity verification measures, such as multi-factor authentication (MFA). Then every request goes to Identity-Aware Proxy, which checks identity and context before anything reaches the application. Google describes the approach as authenticating and authorizing every user and device, validating their context such as location and device posture, and granting least privilege access to only the necessary resources. That is why the boundary is labelled only the resources granted. Nothing on this path asks where the request came from, and that is the whole point.

Control, compliance, confidentiality, integrity, availability

Five words, five different things to protect

• Control: where data is stored, how it's accessed and how it's processed
• Compliance: meeting regulatory requirements — which can fail without a breach
• Confidentiality: only authorized parties can see the data
• Integrity: data cannot be changed unnoticed; availability: it is there when needed

Worked example (synthetic). A payments firm's regulator asks three things: who can read card data, whether a record can be altered without detection, and whether the service survives an outage. Those are confidentiality, integrity and availability — asked in that order.

The third objective lists five words, and three of them travel together. Google names them as a set more than once: its framework says the zero-trust model helps ensure confidentiality, integrity and availability of data and resources in the cloud, and its security overview describes an incident-management process for any security event that might affect the confidentiality, integrity or availability of systems or data. Confidentiality is about who can see: Google's Confidential Computing, for example, performs computation in cryptographic isolation to help ensure confidentiality in a multi-tenant cloud. Integrity is about who can change: encryption, Google says, not only keeps unauthorized people from seeing data but safeguards it so malicious actors cannot change important documents. Availability is about whether it is there, and Google ties it to control — software sovereignty assures you that you can control the availability of your workloads and run them wherever you want. The other two words sit around the triad, and Google's definition of cloud security names both: it focuses on ensuring data protection, supporting regulatory compliance, and providing control over privacy, access and authentication. Control is Google's promise about your data: to help you meet data residency requirements, Google Cloud lets you control where your data is stored, how it is accessed and how it is processed. And compliance is meeting the rules, which Google's providers pursue through independent verification — and which, as the first objective showed, can be violated with no breach at all.

Each word, the question it answers, and a Google mechanism

Name the question in the scenario, then the word

Worked example (synthetic). A hospital must keep patient records inside one country. The word is control — a question about where data lives — even though the rule behind it is a compliance rule.

The exam will describe a worry and expect you to name the word, so rehearse the question each word answers. Control answers where is my data and who decides — Google Cloud lets you control where your data is stored, how it is accessed and how it is processed, and data sovereignty gives you a mechanism to prevent Google from accessing your data. Compliance answers are we meeting the rules — and providers pursue it with rigorous independent verification of their security, privacy and compliance controls. Confidentiality answers who can see it. Integrity answers can it be changed without anyone noticing. Availability answers is it there when it is needed. Two pairs are easy to confuse. Control and compliance often appear in the same scenario, because a rule, such as data residency, is usually met by exercising a control; the word the question wants is the one about what is being asked for. And confidentiality and integrity are both served by encryption, which is why the mechanism alone does not tell you the word — the question does.

Key terms: who gets in, and how much

Access vocabulary, in Google's own definitions

Worked example (synthetic). A contractor needs to read one reporting dataset. Least privilege says grant the narrowest predefined role on that dataset — not a basic role on the whole project.

The fourth objective asks for key security terms without listing them, so this deck teaches the ones Google's own security pages lean on, each in Google's words. Zero trust is a security model based on the idea that no person or device should be trusted by default, even if they are already inside an organization's network; it removes implicit trust by enforcing strict authentication and authorization throughout the network, not just at a perimeter. Identity and access management (IAM) is, in Google's plainest sentence, a way to control who can do what on which resources — you give a principal permission by granting it a role on a resource. Least privilege is the discipline applied to that grant: Google's framework says to minimize the risk of unauthorized access by enforcing least privilege and separation of duties, and its IAM guidance is concrete — in production, do not grant basic roles unless there is no alternative, and grant the most limited predefined or custom roles instead. Multi-factor authentication (MFA) is the strong identity verification that zero trust requires. And defense in depth means layered security measures that offer redundancy and backup security should one measure fail. Google's framework recommends applying it at each layer of the application and infrastructure stack.

Key terms: protecting the data, and watching for threats

Encryption, DLP, SIEM and threat intelligence

Figure. Four cards defining data and detection terms: encryption, which scrambles data so only a key unlocks it at rest, in transit or in processing; data loss prevention, which discovers, classifies and de-identifies regulated data; SIEM, which automates monitoring, detection and incident response; and threat intelligence, knowledge about threat actors and their tactics.

Worked example (synthetic). A clinic needs to find every document holding patient identifiers before an audit. That is a DLP job — discover and classify — not an encryption one.

The second group of terms protects data and watches for trouble. Encryption, in Google's words, protects data from being stolen, changed or compromised by scrambling it into a secret code that can only be unlocked with a unique digital key, and encrypted data can be protected at rest, in transit between computers, or while being processed. On Google Cloud one part of that is automatic: Google encrypts all customer content stored at rest, without any action from you. Data loss prevention (DLP) is about knowing what you hold: it can automatically discover, classify and de-identify regulated cloud data. Security information and event management (SIEM) combines security information and event management to offer automated monitoring, detection and incident response. And threat intelligence provides knowledge about threat actors, their tactics, and indicators of compromise. The exam distinction worth holding is between protecting and finding. Encryption protects data you already know about; data loss prevention finds the data you did not know you had. Monitoring tools watch for an attack as it happens; threat intelligence tells you which attacks to expect.

One grant, three parts

Who, what and which — and least privilege sizes the what

Figure: A flow chart of an IAM grant. A principal, who, and a role, what, combine in a grant on a resource, which. A dotted note on the role says least privilege means the most limited role that meets the need.

Worked example (synthetic). A new analyst is given a basic role on the whole project because it was quicker. The grant works — and gives thousands of permissions nobody needed, which is the failure least privilege names.

Identity and access management (IAM) and least privilege are easiest to hold as one picture. Google says IAM lets you control who can do what on which resources, and that to give a principal permission to access a resource, you grant them a role on the resource. So every grant has three parts: the principal is who, the role is what, and the resource is which. Least privilege does not add a fourth part; it is a rule about the size of the second. Google's guidance is to avoid basic roles in production unless there is no alternative, and to grant the most limited predefined or custom roles that meet your needs. Google applies the same rule to its own staff: access rights are based on an employee's job function and role, using the principles of least privilege and need-to-know. When an exam scenario asks how to give someone access safely, find the three parts, then ask whether the role is as small as the job.

What this topic actually tests

Four discriminations, four objectives

Old risk or new? misconfiguration, access, visibility, dynamic workloads and compliance are the cloud's own. More secure or secured differently? Google says neither more nor less. Which word? name the question — see, change, be there, decide, obey. Which term? zero trust places trust; least privilege sizes it; defense in depth layers it.

Close the topic on the four discriminations the exam leans on. First, old risk or new: phishing, malware, insider threats and denial-of-service attacks follow you to the cloud, while misconfiguration, access management, lack of visibility, dynamic workloads and compliance are the challenges the cloud adds — and misconfiguration is among the leading causes of cloud breaches. Second, more secure or secured differently: Google's answer is that the cloud is no more or less secure than on-premises, and what changes is that trust moves from the perimeter to every identity and request. Third, which of the five words: confidentiality is who can see, integrity is who can change, availability is whether it is there, control is where data lives and who decides, and compliance is whether you meet the rules. Fourth, which term: zero trust decides where trust is placed, least privilege decides how much is granted, and defense in depth makes sure one failed measure is not the end. Topic two turns to how Google builds those layers into its own infrastructure.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 5
• What is cloud security? — Google Cloud
• What is zero trust? — Google Cloud
• Well-Architected Framework — Implement zero trust
• Google security overview
• What is encryption? — Google Cloud
• Well-Architected Framework — Meet regulatory, compliance, and privacy needs
• IAM overview — Google Cloud
• Use IAM securely — Google Cloud
• Well-Architected Framework — Implement security by design
• Well-Architected Framework — Implement preemptive cyber defense
• Default encryption at rest — Google Cloud