AlpinaShop's security has been built in pieces. In 03-01 the firewall was closed. In 03-04 IAM was designed with groups, custom roles and keyless service accounts. In 03-05 Cloud Armor was put in front. In 03-06 Secret Manager and customer-managed keys arrived. In 03-07 it was published with TLS. In 06-02 the main branch was protected. In 07-03 a perimeter was raised around the data.

Every piece was decided well at the time. And nobody has ever looked at the whole.

That is the difference between having security controls and having security. An attacker does not attack the firewall: they attack the weakest link in a chain you have never walked end to end. And in a forty-person company with three technical people, that link is almost never the one you imagine — it is not an exotic kernel vulnerability, it is a two-year-old JSON key still sitting on the laptop of an intern who no longer works here.

This lesson is the complete review. It walks the architecture layer by layer, applies the principles that make the layers hold together, reviews the software supply chain — today the fastest-growing attack vector — closes the data lifecycle, sets up detection and response, clarifies which part of compliance is Google's and which is yours, and finishes with two things that rarely appear in courses: a hardening checklist you can actually execute, and the honest list of the security debt AlpinaShop still carries, prioritised.

A warning, and it is meant seriously. This lesson is training, not an audit. The model presented is sound and applicable, but any architecture handling personal, payment or health data must be reviewed by a security and compliance professional before going to production, and as often as the sector requires. No course, no checklist and no automated tool replaces that work.

1. Defence in depth applied to AlpinaShop
2. The six principles that hold up everything else
3. Zero trust and BeyondCorp, with IAP as the practical implementation
4. Identity: a complete review of the IAM design
5. Temporary privilege elevation and federation
6. The software supply chain
7. Data: classification, encryption, pseudonymisation and deletion
8. Detection: Security Command Center and the audit logs
9. Response: the first two hours of an incident
10. Compliance: what Google gives you and what remains yours
11. Hardening checklist
12. AlpinaShop's security debt, prioritised

Defence in depth means no control is the only one. If one fails, another behind it limits the damage. It is not about stacking up tools: it is about designing so that the failure of any single layer is not catastrophic.

The way to check whether defence in depth is real is to ask the single-failure question at every layer:

The rows with a doubtful answer are debt, and they go to section 12. That is the real value of the exercise: not confirming what is fine, but finding what is not.

Tools change; principles do not. These six explain why every decision in the course was the right one.

Every identity has exactly the permissions it needs for its function, and not one more.

Applying it honestly hurts a little: it means that when somebody asks "give me Editor so I can test something", the answer is no and you have to spend fifteen minutes working out which permission they actually need. The shortcut of saying yes is what has filled the world with projects where everybody is an editor.

The tool that makes it bearable is the IAM Recommender (03-04), which compares granted permissions against permissions used over 90 days:

Whoever builds does not deploy alone; whoever deploys does not approve alone; whoever administers does not audit.

At AlpinaShop: Dani writes the code, Cloud Build builds it, Marta approves production, and the audit logs are kept by a project neither of them can write to (07-07). No single person can, on their own, put code into production and erase the evidence.

What is not explicitly allowed is forbidden.

It has been applied systematically: the 03-01 firewall with its implicit deny; Cloud Run with --no-allow-unauthenticated; ingress restricted to the balancer; the VPC-SC perimeter; the organization policies in 07-07. The alternative — allow by default and block the known bad — is a race you always lose.

When something is compromised — not if — how far does it reach?

This is the principle that justifies separating into projects, giving each workload a different service account, and never reusing credentials. The operational question: if this credential leaks today, what can whoever holds it do? If the answer is long, the design is wrong.

Being inside the VPC is not a credential.

The classic model — hard perimeter, soft interior — fails because the moment somebody gets in, they have everything. It is developed in section 3.

Design as if they were already inside.

It changes the priorities: you invest as much in detecting and limiting as in preventing. It is what justifies immutable audit logs, anomalous-behaviour alerts and rehearsing incident response.

BeyondCorp is the security model Google adopted internally after the attack known as Operation Aurora in 2009, and which gave rise to the term zero trust.

In Google Cloud, the practical implementation is IAP (Identity-Aware Proxy), already used in 03-04 and worth looking at here as an architectural piece.

What IAP does, and why it is worth it:

• The application never sees unauthenticated traffic. The rejection happens at Google's edge.
• There is no VPN to maintain, no concentrator that falls over, no client to install.
• It works the same from the office and from home, which removes the incentive to work around the control.
• It combines with context-based access levels: verified corporate device, encrypted disk, screen lock, allowed country.

And its honest limit: IAP protects access to HTTP applications and to SSH/RDP over a tunnel. It is not a substitute for network segmentation or for IAM: it is one more layer.

Applied to AlpinaShop, it solves the problem from the 07-03 exercise — Lucía working from home — better than any IP list:

It reads like this: whoever uses a company-owned machine, encrypted, with a screen lock, with an up-to-date operating system, from Spain, France or Portugal, may come in. The IP has stopped mattering, which is exactly the point.

Identity is the new perimeter. In a well-built cloud, the vast majority of serious incidents start with a credential, not with an open port.

Owner, Editor and Viewer have existed since before IAM had granular roles and should never be used in production:

An immediate audit:

What you have to find, and why:

The default Compute account deserves its own paragraph because it is, by a distance, the most widespread failing in Google Cloud. It exists in every project, historically it came with Editor, and any VM, function or service that does not specify another account inherits it. A vulnerability in your web application goes from "read a database" to "administer the entire project". The organization policy automaticIamGrantsForDefaultServiceAccounts (07-07) prevents it in new projects; in existing ones it has to be fixed by hand.

Nobody is Owner of production. It is the 03-04 decision that generates the most argument and delivers the most value: if nobody can bypass the controls, the controls are real. For emergencies there is the break-glass access procedure in section 5, which is audited and temporary.

The rule, already established in 03-04 and closed out here:

A downloaded service account JSON key is a permanent password with no expiry that anyone can copy.

Alternatives, in order of preference:

Searching for existing keys across the whole organization:

--managed-by=user is the crux of the command: it filters the downloadable keys and discards the ones Google manages internally, which are harmless and would fill the output with noise.

Marta needs compute.securityAdmin to touch the firewall. She uses it once a month. The rest of the time, that permission only adds risk: if her session is stolen on any given Tuesday, the attacker can open the firewall.

Privileged Access Manager (PAM) solves this with permissions that are requested, justified, approved and expire by themselves.

What changes:

And the important nuance for a small business: if the approver is the only person who can approve and they are on holiday, the process blocks an emergency. There has to be a break-glass path: an entitlement with automatic approval, a one-hour duration, and an immediate alert to the security channel when it is used. You do not prevent it; you make it noisy. It is the same philosophy as the Terraform emergency procedure in 06-07: when there can be no preventive control, there has to be a detective one.

Workload Identity Federation lets an external identity — GitHub Actions, a cluster in another cloud, an OIDC provider — obtain short-lived Google Cloud credentials with no key at all. AlpinaShop has been using it since 06-02.

The security point almost everybody configures badly is the attribute condition:

That condition looks restrictive and is less so than it seems: if somebody creates a GitHub organization called alpinashop, they are in. And even if that were not so, any branch or pull request in the repository could deploy to production.

repository_id is numeric and immutable: it cannot be impersonated by renaming. This is the detail that separates a secure federation from one that only looks secure.

It is the vector that has grown most in recent years, and the one that gets the least attention in small businesses. There is no need to attack your application if you can attack a library your application installs.

And the step that turns scanning into a control: failing the build when there are critical vulnerabilities with a patch available.

The fixedVersion nuance is not a technicality: blocking on vulnerabilities with no patch available paralyses development without improving security, because there is nothing to be done except change dependency. You block what can be fixed; the rest is recorded, the risk is assessed and a decision is taken.

With no shell, an attacker who achieves code execution cannot launch sh, or curl, or wget. It is not invulnerable, but most post-exploitation tooling stops working.

And reproducibility, which is what makes all of the above verifiable:

The three lines that matter: a digest instead of a tag, --require-hashes so that a tampered dependency makes the install fail, and USER 1000 so as not to run as root.

SLSA (Supply-chain Levels for Software Artifacts) is a framework with assurance levels about how an artefact was built. Cloud Build generates verifiable provenance natively:

Provenance answers, with a cryptographic signature: which exact commit, which build instructions, which machine, which moment. It serves what during an incident is a question worth hours: was this image running in production built from our code, or did somebody publish it by hand?

It was already introduced in 07-01. Here is where it fits: it is the control that stops an image which did not go through the process reaching production.

And it applies to Cloud Run, not just to GKE, which makes it directly relevant to AlpinaShop after 07-02:

Assured Open Source Software is a service through which Google distributes the open source packages it uses itself: it builds them on its own infrastructure, scans them, signs them and gives them SLSA provenance.

Its value is bounded and it is worth saying so: it covers a catalogue of popular Java and Python packages, not everything you install. For AlpinaShop, with a dozen common dependencies, most would be covered. It is not a silver bullet; it is reducing the surface where you have to trust blindly.

You cannot protect what you do not know the nature of. AlpinaShop's classification:

The fourth row is the best security decision in the whole course, and it is not technical: data you do not keep cannot leak. AlpinaShop does not store card numbers because the gateway returns a token. That removes the entire scope of PCI-DSS from its infrastructure at a stroke.

In 04-07 DLP — today Sensitive Data Protection — was introduced for data governance. Here it is used as a security control: finding personal data where it should not be.

Two decisions in that file:

• includeQuote: false: do not store the fragment that was found. Storing the detected card number in the findings table would create a second copy of the problem. A real and frequent mistake.
• SPAIN_DNI_NUMBER: there are country-specific detectors. Using only the generic ones leaves out what matters most in Spain.

What always turns up, and AlpinaShop was no exception: email addresses in free-text comment fields, phone numbers in the "order notes" field, and full addresses in application logs from months ago. None of it was intentional. All three are personal data for GDPR purposes.

Google encrypts everything at rest by default, with nothing to configure. CMEK (03-06) adds that you control the key yourself in Cloud KMS:

The "red button" CMEK gives you. If an intrusion is detected in progress, disabling the key makes the data encrypted with it unreadable within seconds, even for somebody holding read permissions. It is a containment capability that does not exist without CMEK.

With its counterpart, which has to be said plainly: if you lose the key, you lose the data. Permanently. That is why KMS prevents immediate deletion and imposes a scheduled destruction period.

For Lucía to analyse purchasing behaviour she does not need to know who each customer is:

Three techniques in five lines: a salted hash so that the same customer is the same cliente_id without it being reversible; generalisation of the postcode to its first two digits, which gives the province without pinpointing the neighbourhood; and omission of name, address and phone number, which add nothing to the analysis.

And the honest warning: pseudonymisation is not anonymisation. With the salt, the data is still re-identifiable and therefore still personal data for GDPR purposes. It reduces the risk; it does not remove the obligation.

The GDPR requires you not to keep personal data longer than necessary, and to be able to delete it at the data subject's request.

And deletion on request, which is where most companies discover that their architecture never accounted for it:

Note point 1: the orders are not deleted, they are anonymised, because tax regulations require invoices to be kept. The right to erasure is not absolute and it collides with other legal obligations; resolving that collision is not a technical decision and must be documented with legal advice.

SCC is Google Cloud's security centre. It detects insecure configurations, vulnerabilities and active threats.

What the free tier really detects, which is the one a small business will use:

Premium adds Event Threat Detection, which analyses the logs in real time looking for behaviour — not configuration: cryptocurrency mining on a VM, data exfiltration from BigQuery, credential use from an impossible geography, a service account being created and immediately followed by a permission grant.

The honest criterion for AlpinaShop: start with the free tier and actually deal with its findings, which is already more than most people do. Premium is justified when there is something to watch actively, a compliance requirement that demands it, or somebody with time to respond to what it detects. Buying detection nobody looks at is worse than not buying it, because it creates the feeling of being protected.

They are covered in depth in 07-07. Here, the bare minimum:

The fact that "data access" is disabled by default has a consequence that must be accepted consciously: without enabling it, you cannot know who read your customers' data. For AlpinaShop, enabling it in alpinashop-datos and in the buckets holding personal data is not optional if it wants to be able to answer a breach.

Three queries to have written before you need them:

The third deserves a permanent alert: in an organization that federates identities and uses impersonation, creating a JSON key is an exceptional event that must always be looked at.

Here is what almost no course includes and what really makes the difference. A realistic script for a team of three.

Scenario: it is 23:40 on a Thursday in October, in the middle of the campaign. An SCC alert arrives: "Anomalous IAM grant: the account sa-informes-nocturnos has granted roles/owner to an external account".

Nothing is touched yet. The first impulse — delete the account, cut off access — destroys evidence and sometimes warns the attacker. The first thing is to answer three questions:

1. Is it real or a false positive? Is there a scheduled change tonight? Is somebody working?
2. Is it ongoing? Is there still activity from that identity right now?
3. What is the scope? What can that credential touch?

If it is real, cut without destroying. The order matters:

Step 3 is the one that is always forgotten. Disabling an account does not invalidate the access tokens already issued, which live for up to an hour. During that hour the attacker is still inside even though the console says the account is disabled.

The questions, in this order:

The search for persistence is the most neglected part and the one that makes an incident repeat itself the following week:

The GDPR's 72 hours for notifying the supervisory authority are not negotiable and the clock starts when you become aware, not when you finish the investigation. It is the number one reason to call the legal adviser within the first hour, even if the scope is not yet known.

An incident is no time to improvise. The folder that has to be written today:

• Phone numbers: internal, management, legal adviser, insurer, Google Cloud support.
• The containment command already written, tested and with permissions verified.
• An evidence bucket with locked retention, created outside the project that may be compromised.
• An alternative communication channel — if corporate email is compromised, you cannot coordinate by email.
• Emergency access tested: that Marta can get in even if her usual account is locked.
• One drill a year. Half an hour in a room, over a written scenario. It uncovers more holes than any configuration audit.

The split from 01-05, revisited now with the full context:

Google's certifications — ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI-DSS as a provider, ENS in Spain, sector-specific schemes — accredit its infrastructure. They are downloaded from the Compliance Reports Manager.

And here is the most expensive misunderstanding about compliance in the cloud:

Google being certified to ISO 27001 does not certify your company. Its infrastructure being fit for PCI-DSS does not make your shop compliant. What you get is that the layer underneath is already audited, which reduces your scope considerably — but your configuration, your code, your processes and your people are still yours and are still auditable.

For AlpinaShop, as a Spanish online shop:

The documentation you have to have, and which an inspection asks for before any technical configuration:

1. Record of processing activities (GDPR art. 30).
2. Data processor agreement with Google Cloud.
3. Impact assessment (DPIA) if there is high-risk processing.
4. Information security policy, even if it is four pages.
5. Breach response procedure, with the deadlines from section 9.
6. Record of access to personal data — which is exactly what the data access logs give you.
7. Analysis of international transfers and the safeguards applied.

It bears repeating because it matters: this table is indicative and educational. A compliance professional must validate what applies to your specific case, especially regarding the GDPR, international transfers and PCI-DSS scope.

Actionable over everything built in the course. The status column is AlpinaShop's today.

Result: 20 ✅, 11 ⚠️, 12 ❌. Not bad for a forty-person company. And not enough.

No company is at 100 %. What distinguishes a mature organization is not having no debt, but knowing which debt it has, having prioritised it and paying it off. Prioritisation by risk (probability × impact) against effort.

The four together add up to less than two days of work and are what reduces risk the most. Starting here is not a matter of opinion.

And this is part of maturity too: deciding not to do something, in writing, with a reason.

An accepted, documented risk is not a security failure: it is a management decision. A risk nobody has looked at is.

• Confusing having tools with having security. SCC enabled and nobody looking at the findings is worse than not having it: it creates false confidence.
• Leaving the default Compute account with Editor. It is the most widespread failing in Google Cloud and it turns any vulnerability into a total compromise of the project.
• Creating JSON keys "just to test". They are never deleted. Hunt for them periodically with --managed-by=user.
• Federating identity without a strict attribute condition. Without repository_id and ref, any branch or repository with the same organization name can deploy to production.
• Deleting the compromised account during an incident. It destroys evidence. You disable it.
• Forgetting that live tokens survive disabling for up to an hour.
• Storing the fragment detected by DLP. Creating a table with the card numbers you found duplicates the problem, it does not solve it.
• Believing that pseudonymisation is anonymisation. With the salt, it is still personal data for GDPR purposes.
• Thinking Google's certifications certify your company. They certify the layer underneath. Your configuration is yours.
• Blocking builds on vulnerabilities with no patch available. It paralyses the team without improving anything. You block what can be fixed.
• Enabling all the controls at once. VPC-SC, Binary Authorization and organization policies on the same day is a guaranteed outage. One at a time, in dry-run mode first.
• Leaving the response plan until it is needed. The incident is the worst moment to write it.
• Tip: ask the single-failure question at every layer. It takes half an hour and finds more than any scanner.
• Tip: the best security measure is the data you do not keep. Before protecting a piece of data, ask whether it needs storing at all.
• Tip: a half-hour drill once a year uncovers more real holes than a configuration audit.
• Tip: write down the accepted debt. It turns a hole into a decision, and it makes sure it gets revisited.

Write an audit script that, across AlpinaShop's five projects, detects and reports:

1. Any binding with basic roles (owner, editor, viewer).
2. Bindings with allUsers or allAuthenticatedUsers on projects and on buckets.
3. Service accounts with user-managed keys, and their age.
4. Service accounts unused for 90 days.
5. Service accounts with administrator roles.

For each finding, state the severity and the recommended action. Also explain why point 4 matters more than it looks.

Scenario. On a Monday morning, an external developer posts on a public forum that they have found an AlpinaShop GitHub repository with a credenciales.json file in the commit history. The file is a key for sa-dataflow-pedidos, deleted from the repository eight months ago but present in the history. That account has roles/bigquery.dataViewer on alpinashop_analitica and roles/storage.objectAdmin on alpinashop-datalake.

Write the complete response plan with timestamps: what is done in the first 10 minutes, in the first 30, in the first hour and in the first 24 hours. Include the commands, the communication decisions (with whom and when), how you determine whether there was improper access, and what structural changes are made afterwards so that it does not happen again.

AlpinaShop's management approves 10 days of Marta's time and €3,000 for security this quarter. There is no more.

From the debt list in section 12, choose what gets done and what does not, justifying each decision on risk against effort. Draw up a plan by weeks and, most importantly, write what you tell management about what is left undone, in language a managing director understands.

Solution 1 — Identity audit

Table of findings, severity and action:

Why point 4 matters more than it looks. An unused service account is a silent target: nobody watches its activity, nobody would notice anomalous use, and because it is not used, nobody remembers why it exists or what permissions it has. Beyond removing attack surface, the clean-up brings something more valuable: every account removed reduces the noise in the audit, and a list of twenty accounts of which all twenty are understood is infinitely safer than one of sixty of which twenty are understood.

The correct technique is to disable before deleting (gcloud iam service-accounts disable): if something breaks, it is reactivated in a second; if it was deleted, you have to recreate it and rebuild all its permissions. Thirty days of waiting is a reasonable period, because it captures the monthly processes.

Solution 2 — Designing the response to a specific incident

T+0 to T+10 min — Assess without acting.

The first decision: this is already public. Unlike an internal detection, here the potential attacker does not merely exist: an entire forum knows about the key. Urgency is at a maximum and stealth no longer buys anything, which changes the calculation compared with section 9.

You are looking for one thing only: requests from IPs that are not Dataflow's. If any appear, the incident goes from "exposed credential" to "confirmed access", with immediate legal implications.

T+10 to T+30 min — Contain.

The hard decision in these twenty minutes: disabling the account breaks the orders pipeline into BigQuery. You do it anyway. Faced with a public credential that has access to the data lake, the analytics can wait a few hours. And it is exactly the decision you should have thought through beforehand, not in the heat of the moment.

Point 4 deserves attention: had the perimeter been enforced instead of in dry-run mode (debt #7), the leaked key could not have taken a single byte out of the organization. The incident illustrates why a half-finished control is not half a control.

T+30 min to T+1 h — Determine whether there was access.

And here appears the problem that makes this exercise the best demonstration of why debt #5 matters: the data access logs are disabled. AlpinaShop has the admin activity logs — it will know if somebody changed permissions — but it cannot know whether somebody read the orders table.

The practical consequence, and it is serious: being unable to demonstrate that there was no access, legally the case has to be treated as if there could have been. You go from "exposed credential with no evidence of use" to "possible personal data breach whose scope cannot be bounded". That completely changes the notification to the AEPD.

Alternative avenues of evidence, all worse:

T+1 to T+2 h — Communicate.

T+2 to T+24 h — Scope and eradication.

T+24 to T+72 h — Notification. If the legal adviser determines there is a risk to data subjects' rights, notification to the AEPD within 72 hours. Since access cannot be ruled out, notification is most likely required. The notification describes: what happened, what data could be affected, what measures have been taken, and why the scope cannot be bounded — which, said plainly, is in itself an unfavourable finding about the organization.

Structural changes afterwards:

The final reflection of the exercise. The key was pushed eight months ago, it was deleted from the repository, and everybody thought the problem was solved. Deleting a file from Git does not delete its history: anybody with access to the repository — or to the public repository, or to a fork — could recover it with git log -p. It is such a widespread misunderstanding that it deserves a rule of its own:

A secret that has been in a repository, even for a minute, is compromised. The only correct answer is to rotate it. Deleting it from the history is tidying up, not remediation.

Solution 3 — Prioritising on a limited budget

Constraints: 10 days of Marta's time, €3,000, one quarter. And a premise that has to be respected: Marta also has to operate the platform, so 10 days of security are 10 real days, not elastic ones.

What gets done:

That leaves €2,100 spare. And here comes the proposal that delivers the most value per euro:

Buy a half-day external security review (~€1,500-2,000) at the end of the quarter, over the already-hardened architecture.

The reasoning: Marta built this platform and has the blind spots of the person who built it. An outside look at an already tidy system finds different things from what it would find on a messy one — and that is why it is bought after paying off the priority 1 and 2 debt, not before. It also brings something you cannot manufacture internally: a report signed by a third party, which is what a corporate customer, an insurer or an inspection asks for.

What is NOT done, and why:

What management is told — and this is the part that costs the most effort and matters the most:

"With these ten days we close the four holes that expose us most today: a permanent password we lost more than a year ago and that still works, an internal account that grants permission to delete anything, an automated system that can touch everything, and the absence of any warning when somebody changes permissions.

On top of that we do two things we do not have today and that are either a legal obligation or common sense: knowing who accesses our customers' data — today we could not answer that question if the Spanish Data Protection Agency asked, and not being able to answer it is itself a problem — and checking that our backups can really be restored, which we have never verified. And we rehearse what we would do if something happens tomorrow, because the day of the incident is the worst day to improvise.

What is left undone, and I want it on the record: we are not going to have active threat monitoring — if somebody gets in quietly, we would find out late; we are not going to technically prevent unapproved software from being deployed; administrative permissions will remain permanent rather than temporary; and we are not going to buy a professional simulated attack. Each of those four is a budget decision, not an oversight, and we review them next quarter.

With what we are doing we move from a risk I would call high to a medium one. Getting to low requires a person dedicated to security or a managed service, and that is a different conversation, best had when we are sixty people or when a large customer requires it of us by contract."

The three elements that make this communication good, and that can be reused in any company: it talks about business risks and not about product names; it says explicitly what is left uncovered instead of letting management assume everything is solved; and it sets when it gets reviewed, which turns a budget cut into a conscious decision with a date instead of into silence.

AlpinaShop has gone from having security controls to having reviewed security, and — more usefully — to knowing exactly what it is missing.

You have applied defence in depth layer by layer — edge, identity, network, workload, data, detection — and above all you have learnt the single-failure question, which is the cheapest and most effective tool in the whole lesson: for each layer, if this fails, what contains it? The doubtful answers are the debt.

You have the six principles that explain every decision in the course: least privilege with the Recommender that makes it bearable, separation of duties — Dani writes, Cloud Build builds, Marta approves, and nobody can deploy and erase the evidence — deny by default, limited blast radius with its operational question, do not trust the network, and assume breach.

You understand zero trust and BeyondCorp with IAP as the practical implementation, and you have seen that an access level based on the device — corporate, encrypted, locked, up to date, from an allowed region — solves remote working far better than any IP list, because it makes the IP stop mattering.

You have reviewed identity thoroughly: removing the basic roles, the script that finds them, and the three findings that always turn up — a person with Owner, Cloud Build with Editor and, above all, the default Compute account with Editor, which is the most widespread failing in Google Cloud and the one that turns any application vulnerability into a total compromise. You know the keyless alternatives for each situation and the command with --managed-by=user that finds the ones still around. You know how to set up temporary elevation with PAM — with the break-glass path that does not prevent but makes noise — and identity federation with the attribute condition on repository_id and ref that separates a secure federation from one that only looks secure.

You have mastered the supply chain: scanning that blocks only what has a patch, minimal base images — with the table that runs from python:3.12 to distroless — pinned by digest and with --require-hashes, USER 1000 instead of root, SLSA provenance that answers "did this image come out of our code?", Binary Authorization — which also applies to Cloud Run — and Assured Open Source with its honest scope.

You have closed the data lifecycle: classification into four levels with the best security decision in the course — not storing cards, because data you do not keep does not leak — discovery with Sensitive Data Protection and Spanish detectors, includeQuote: false so as not to duplicate the problem, CMEK with its "red button" of disabling the key and its irreversible counterpart, pseudonymisation with a salted hash and generalisation — which is not anonymisation — and retention with the erasure procedure that anonymises the orders instead of deleting them because the tax obligation rules.

You know how to detect: Security Command Center with its three tiers, what the free one really finds, and the honest criterion that buying detection nobody looks at is worse than not buying it. And you have the four types of audit log with the fact that changes everything — data access is disabled by default, and without it you cannot know who read your customers' data — along with the three queries to have written before you need them.

You have a realistic response script: ten minutes to assess without touching anything, twenty to contain without destroying evidence — disable, do not delete, and revoke the live tokens that survive for an hour — half an hour for the scope including the search for persistence, and communication with the GDPR's 72 hours counting from awareness and not from conclusion. Plus the folder that has to be prepared today, including the alternative communication channel and the annual drill.

You know what compliance Google gives you and what remains yours, with the most expensive misunderstanding cleared up: its certifications accredit the layer underneath, not your company. And you have the list of seven documents that are asked for before any technical configuration.

And you take away two things worth more than any theoretical section: the checklist of 43 controls with AlpinaShop's real status — 20 ✅, 11 ⚠️, 12 ❌ — and the prioritised debt in three blocks, with four priority 1 tasks that add up to less than two days and remove the most risk. Plus the list of consciously accepted debt, because a documented risk is a management decision and a risk nobody has looked at is a hole.

The leaked key exercise has left the most uncomfortable lesson of all, and it is worth taking away verbatim: a secret that has been in a repository, even for a minute, is compromised; deleting it from the history is tidying up, not remediation.

And the budget exercise has left the other one: a small business's security is not decided with a list of the ideal, but by choosing ten well-spent days and telling management, in writing and in their language, what is left uncovered.

Two threads from this lesson are left explicitly open. One points to 07-06: the backup restore has never been tested, and it appears as a critical risk both in the checklist and in the prioritisation. The other points to 07-07: organization policies, immutable audit logs in a separate project and periodic access review are governance, and that is where they are resolved.

But first there is a conversation that has been deferred for seven modules. Every lesson has added services; none has closed the bill. This very lesson has proposed enabling data access logs — which cost money — has ruled out SCC Premium on price, and has allocated €3,000 as if it were a lot of money, which for a forty-person company it is. None of those three decisions can be taken well without understanding where every euro of AlpinaShop's bill comes from. The next lesson opens the whole bill, line by line, and explains it.