AlpinaShop has a solid infrastructure and absolutely nobody can use it. The shop is served from a numeric IP address, with no name and no certificate: typing https://34.120.x.x into a browser produces a red security warning, and no customer enters their card details after seeing that. All the work of the module's previous six sections depends on the missing piece: a name and a certificate.

This lesson closes module 3 by putting in place what the customer actually sees. You are going to create the public DNS zone for alpinashop.example, point the domain at the global IP alpinashop-lb-ip, delegate from the registrar and verify it; provision a Google-managed certificate and understand why it gets stuck in PROVISIONING when something is wrong; harden the connection with an SSL policy; add the security headers the Flask application should emit; and verify the result end to end with curl and openssl. We will finish with a checklist covering everything built in the module, from the VPC to the certificate.

Warning. TLS and security header configuration has permanent effects that are hard to reverse — HSTS is the canonical example — and compliance implications if payments are processed. Before applying this configuration to a real production domain, review it with a security professional. And a practical note: alpinashop.example uses the .example domain, reserved for documentation; in a real case you would be working with a genuinely registered domain.

1. A functional DNS refresher: just enough to operate
2. Cloud DNS: managed zones
3. AlpinaShop's public zone, record by record
4. Delegation from the registrar and verification with dig
5. Private zones for internal resolution
6. DNSSEC: what it protects and what it does not
7. Google-managed certificates
8. Why a certificate gets stuck in PROVISIONING
9. Certificate Manager: many domains and wildcards
10. Your own certificates and when they make sense
11. SSL policies: minimum version and cipher suites
12. Security headers emitted by the application
13. End-to-end verification
14. Module 3 secure publishing checklist

DNS translates names into addresses. Its model is an inverted tree in which each level delegates to the next: the root delegates to .example, which delegates to alpinashop.example, whose authoritative servers answer for everything below it.

This is the complete journey of what happens when a customer types the domain into the browser, and it is worth having in front of you because every piece of the lesson appears in it:

Note two points that correspond to two sections of this lesson: the delegation returned by the .example servers (section 4) and the SNI the browser sends, which is what lets one load balancer serve several domains with several certificates (sections 7 and 9).

The record types you need to know:

Three rules that cause most of the problems and are worth keeping in mind:

1. There cannot be a CNAME at the zone apex. alpinashop.example cannot be a CNAME; it has to be an A or AAAA record. It is a restriction of the protocol itself, because the apex already has SOA and NS records and a CNAME cannot coexist with other records. That is why we reserved a static global IP in 03-01: it is exactly what is needed at the apex.
2. The TTL governs propagation. When a resolver caches an answer, it keeps it for as long as the TTL says. If the TTL is 24 hours and you change the IP, some clients will keep going to the old one for 24 hours. Before a migration, lower the TTL to 60-300 seconds days in advance, and raise it again once everything is stable. It is the most valuable piece of advice in the whole section.
3. Absolute names end with a dot. alpinashop.example. with a trailing dot is an absolute name; without it, some tools append the local search domain. Cloud DNS is strict: it requires the dot.

Cloud DNS is Google's authoritative DNS service, with global anycast, very low latency and a 100 % availability service level agreement. Its units are managed zones:

Mind the distinction between registering a domain and hosting its DNS: they are different things. The registrar is where you buy the domain (Cloud Domains, or any other); Cloud DNS is where its records are hosted. You can perfectly well have the domain with one registrar and the DNS at Google, and in fact that is the most common case.

That last command returns something like ns-cloud-b1.googledomains.com. and three more. Note them down: they are the piece that goes into the registrar.

Now the records. Remember the global IP reserved in 03-01:

Design decisions that deserve an explanation:

• imagenes.alpinashop.example points at the same IP. No second load balancer is needed: the URL map routes by Host and by path. One load balancer, one certificate, one place to apply Cloud Armor. A subdomain does not imply new infrastructure.
• www is a CNAME to the apex, so an IP change is made in a single record.
• A TTL of 300 seconds on what can change (the apex, www) and 3600 on what is stable (MX, TXT). Before a migration, lower it to 60.
• The CAA record is a cheap lock: it stops another certificate authority issuing a certificate for your domain, even if it manages to fool somebody. If you later use Let's Encrypt, you will have to add 0 issue "letsencrypt.org".

For several atomic changes, Cloud DNS offers transactions:

Creating the zone in Cloud DNS does nothing by itself. The internet carries on asking whichever servers the registrar names. Delegation consists of going to the registrar's dashboard and replacing the name servers with Cloud DNS's four.

And here is the most frequent mistake: changing name servers takes time. The delegation at the level above has its own TTL, typically 24 to 48 hours. During that time, some resolvers around the world will see the new configuration and others the old one, so the shop will work "sometimes". That is not a fault: it is how DNS works.

Verification, in this order:

Reading these commands is what turns an hour of frustration into a one-minute diagnosis:

• If (2) works and (3) does not, the configuration is correct and only propagation is missing. Wait.
• If (2) does not work, the record is wrong in Cloud DNS. Fix it yourself.
• If (1) returns the old servers, the delegation has not been done or has not propagated yet.

Inside alpinashop-vpc, Google already resolves the VMs' internal names automatically. But it is far better for the application to connect to pedidos.interna.alpinashop.example than to 10.10.1.5: the day the IP changes — a replica promoted, a migration — there is no code to touch.

Properties of private zones:

• They only resolve from the authorised VPCs. From the internet, pedidos.interna.alpinashop.example does not exist. You leak nothing about your internal topology.
• A low TTL (60 s) on purpose: these are names designed precisely to change without drama.
• The same zone can be defined in several VPCs. Sharing it between projects moves into the territory of Shared VPC and peering, which is covered in 07-03.

DNSSEC cryptographically signs DNS answers, so that a resolver can verify that the answer is genuine and has not been fabricated by an attacker. It protects against DNS cache poisoning: somebody making your resolver believe that alpinashop.example is at the attacker's IP.

The step almost everybody forgets is the second one: enabling DNSSEC in Cloud DNS is not enough. You have to take the DS record to the registrar so that the level above signs the delegation. Without that step, you have signed your zone but nobody can verify the signature, and it is useless.

What DNSSEC does not protect, so as not to confuse layers:

• It encrypts nothing: DNS queries are still visible. That is solved by DoH and DoT, which are a client matter.
• It does not protect the website's content: that is TLS.
• It does not stop anybody registering alpinashop-tienda.example for phishing.

And a serious operational warning: badly configured DNSSEC makes the domain invisible, not merely insecure. If the registrar's DS record does not match the zone's keys, validating resolvers reject the answer and your domain disappears for part of the internet. Change it carefully and always verify afterwards.

A TLS certificate certifies that the server answering for alpinashop.example really is who it says it is, and it allows the connection to be encrypted. Google issues and renews them free and automatically.

The managed.domainStatus field gives the state per domain, which is what you need in order to debug:

How Google validates the domain, which is the key to understanding the failures: it checks that the name resolves to the IP of the load balancer the certificate is attached to. In other words, the correct order is DNS first, certificate afterwards. If you create the certificate before the A record has propagated, it will sit there waiting.

Advantages and limits of managed certificates:

This deserves its own section because it is, by a distance, the most frequent problem when publishing on Google Cloud. The list of causes, ordered by likelihood:

1. The A record does not exist or points at a different IP. By far the most common error.
2. DNS has not propagated yet. Correct but recent; you have to wait.
3. The load balancer has no forwarding rule on 443. Google validates through the load balancer itself; if 443 is not published, it cannot.
4. A CAA record blocks Google. If you had a CAA from another authority, you have to add pki.goog.
5. The certificate is not attached to the HTTPS proxy. With no attachment, validation is never triggered.
6. It has been deleted and recreated many times, hitting a rate limit. Patience is the solution.

Diagnosis in the right order:

And the advice that saves half a day: when you change the DNS to fix it, do not delete the certificate. Google retries validation periodically on its own. Deleting and recreating resets the clock and brings you closer to the rate limit.

When classic certificates fall short — wildcards, hundreds of domains, deployment across several regions — the tool is Certificate Manager. Its validation mechanism is different: it does not require the domain to point at the load balancer already, but validates through an authorisation DNS record. That allows the certificate to be issued before the traffic is migrated, which is exactly what you want in a real migration.

For AlpinaShop, the classic certificate with three names is enough. If tomorrow every partner brand had its own subdomain, Certificate Manager's wildcard would be the answer.

You can also upload a certificate issued by another authority:

Legitimate cases: extended validation (EV) certificates, certificates issued by the corporate authority, or specific contractual requirements. In exchange you take on three things: looking after the private key (Secret Manager, 03-06), renewing before it expires — the classic 3 a.m. incident — and being warned before expiry. If there is no specific reason, the managed certificate is the better decision, precisely because it removes those three responsibilities.

By default, the load balancer accepts old TLS versions so as not to leave anybody out. For a shop processing payments, that is not acceptable: PCI DSS requires TLS 1.2 as a minimum.

The available profiles:

How to decide without breaking anything: MODERN with a TLS 1.2 minimum leaves out genuinely old browsers (Internet Explorer on Windows earlier than 7, Android 4.x). For a mountaineering gear shop in 2026, that traffic is residual and probably not even human. If it worries you, measure first: the load balancer log records the TLS version negotiated, so you can know exactly how many real customers it would affect.

Two more proxy adjustments, while we are here:

And remember that the HTTP to HTTPS redirect was already done in 03-02, with a separate URL map on port 80 returning a permanent 301. Without that redirect, the HSTS header from the next section would never reach the customers who type the domain with no protocol.

The load balancer encrypts the connection, but there are protections only the application can enable, because they are instructions for the browser.

HSTS deserves a paragraph of its own. Start with max-age=300 for a few days, raise it to a day, then to a year, and only then consider preload. The reason: once a browser has seen the header, it will refuse to connect over HTTP to your domain for the whole max-age, even if you want it to. And preload goes further still: it puts your domain in a list compiled into the browsers themselves, which takes months to get out of. If you enable includeSubDomains and it then turns out that an internal subdomain has no certificate, that subdomain becomes unreachable.

In the same way, CSP is deployed in Content-Security-Policy-Report-Only first, the violation reports are collected for weeks and the policy is adjusted until there are no false positives left. It is exactly the same discipline as Cloud Armor's preview mode in 03-05: measure before enforcing.

What each one should produce:

Complementary external tools, useful for the report to management: SSL Labs for an overall grade on the TLS configuration, and Security Headers for the headers. Neither replaces checking it yourself, but they produce a presentable document.

This is the operational summary of everything built. Use it before every publication of a new service.

Network (03-01)

• [ ] VPC in custom mode, with planned subnets and no CIDR overlaps.
• [ ] No VM with a public IP unless explicitly justified; egress through Cloud NAT.
• [ ] SSH only from the IAP range 35.235.240.0/20; never 0.0.0.0/0 on port 22.
• [ ] A rule allowing 130.211.0.0/22 and 35.191.0.0/16 towards the application's port.
• [ ] An explicit denial at the end, with logging enabled.
• [ ] Cloud SQL on a private IP, through private services access.
• [ ] Private Google Access enabled on the subnets with no internet egress.

Load balancing (03-02)

• [ ] A static global IP reserved.
• [ ] A shallow health check that does not query the database.
• [ ] Named port declared on the instance group.
• [ ] Connection draining configured.
• [ ] max-rate-per-instance measured with a load test, not picked by eye.
• [ ] Load balancer logging enabled.
• [ ] HTTP to HTTPS redirect.

Caching (03-03)

• [ ] CDN enabled on the backend bucket and on the backend service.
• [ ] An appropriate cache mode; never FORCE_CACHE_ALL over user content.
• [ ] utm_*, gclid and fbclid parameters excluded from the cache key.
• [ ] Immutable object names with a long TTL; HTML with a short TTL.
• [ ] Negative caching with the 5xx at 0.
• [ ] serve-while-stale enabled.

Identity (03-04)

• [ ] No basic role (Owner, Editor) in production.
• [ ] Permissions granted to groups, not to people.
• [ ] One service account per workload; never the default Compute one.
• [ ] Zero downloaded JSON keys.
• [ ] Exceptional access with an expiry condition.
• [ ] IAP with tunnelResourceAccessor for SSH and httpsResourceAccessor for internal things.

WAF (03-05)

• [ ] Security policy attached to the backend service.
• [ ] Office IP exemption at the lowest priority.
• [ ] OWASP rules at sensitivity 1, after at least a week in preview.
• [ ] Rate limiting on the sign-in form and on the search box.
• [ ] VERBOSE logging and an alert on the volume of denied requests.

Secrets and encryption (03-06)

• [ ] No secret in metadata, in Git, in container images or in logs.
• [ ] Secrets in Secret Manager, with permissions at secret level.
• [ ] A written rotation procedure; disable before destroying.
• [ ] CMEK where compliance requires it, with permission for the service agent.

DNS and TLS (03-07)

• [ ] Public zone in Cloud DNS, with delegation verified with dig.
• [ ] Apex A record pointing at the load balancer's IP.
• [ ] DNSSEC enabled and the DS record declared at the registrar.
• [ ] CAA record restricting who can issue certificates.
• [ ] Managed certificate in the ACTIVE state, attached to the HTTPS proxy.
• [ ] SSL policy with a TLS 1.2 minimum and the MODERN profile.
• [ ] HSTS, CSP, X-Content-Type-Options and Referrer-Policy in the responses.
• [ ] End-to-end verification with curl and openssl passed.

This list is a solid starting point, not a certificate of conformity. Before publishing a service that handles personal data or payments, the final review is done by a security and compliance professional. Security best practices are picked up again cross-cuttingly in 07-04 and governance at scale in 07-07.

• Trying a CNAME at the zone apex. The protocol does not allow it. An A record to the static global IP.
• Not lowering the TTL before a migration. With a 24-hour TTL, the change takes a day to be seen. Lower it to 60 in advance.
• Forgetting the trailing dot in Cloud DNS names.
• Creating the certificate before the DNS record. It gets stuck in PROVISIONING. DNS first, certificate afterwards.
• Deleting and recreating the certificate out of impatience. It resets the clock and brings the rate limit closer. Google retries on its own.
• Enabling DNSSEC without declaring the DS record at the registrar. It is useless; and if the DS does not match, the domain disappears.
• Setting a CAA without including pki.goog. The managed certificate will never be issued.
• Expecting a wildcard from a classic managed certificate. It does not support them: that is Certificate Manager.
• Enabling HSTS with preload from day one. It is practically irreversible. Raise the max-age in phases.
• Deploying CSP without Report-Only. It breaks the site. The same discipline as Cloud Armor's preview mode.
• Testing only from the browser. It caches DNS and certificates aggressively. Use dig and openssl s_client.
• Uploading your own certificate and forgetting the renewal. It is the classic middle-of-the-night incident. If there is no real reason, use the managed one.
• Tip: use a staging subdomain (pre.alpinashop.example) pointing at a pre-production load balancer. Rehearsing the whole publication there costs little and avoids surprises.
• Tip: set a certificate expiry alert in Cloud Monitoring (06-04), even for managed ones. A renewal can fail if the DNS changed.
• Tip: manage the DNS zone as code with Terraform (06-07). A record added by hand and left undocumented is a guaranteed mystery.

AlpinaShop launches a blog at blog.alpinashop.example, served by a new backend service bs-blog that already exists. Write all the necessary steps, in order, from DNS through to verification, including what has to be touched from the module's previous lessons.

alpinashop.example is today on traditional hosting, with the DNS at the registrar and a TTL of 86,400 seconds. It has to be migrated to Google Cloud without the shop stopping working for a single minute and without losing any email. Write the plan with its timeline.

Marta has followed the lesson and https://alpinashop.example gives ERR_SSL_PROTOCOL_ERROR in the browser. She gathers this data:

• dig A alpinashop.example +short → 34.120.10.5.
• gcloud compute addresses describe alpinashop-lb-ip --global → 34.120.10.5.
• gcloud compute ssl-certificates describe alpinashop-cert --global → managed.status: ACTIVE.
• curl -I http://alpinashop.example/ → a correct 301 towards HTTPS.
• gcloud compute forwarding-rules list --global shows only one rule, on port 80.

Identify the cause and write the commands that fix it.

Solution 1

What else has to be touched from the previous lessons:

• 03-05: rule 2300 rejects requests with a Host that is not in the list. You have to add blog.alpinashop.example to that expression, or the blog will return 404 from the WAF and nobody will know why.
• 03-03: decide bs-blog's cache policy. A blog is almost static content: CACHE_ALL_STATIC with an s-maxage of several minutes is a big improvement.
• 03-01: if bs-blog points at new instances, they need the network tag that allows the health checks.
• 03-04: whoever publishes on the blog needs permissions, and those permissions go to a group.

The key step is number 4: attaching both certificates to the proxy simultaneously. The load balancer supports several and picks by SNI, so the site keeps working while the new one is validated. Replacing the certificate outright would leave the shop with no valid certificate during provisioning.

Solution 2

T-7 days — Prepare and lower the TTL.

All the existing records are inventoried: A, MX, TXT (SPF, DKIM, DMARC, third-party service verifications), CNAME. Losing a verification TXT breaks services silently; losing the MX records loses email, which is unrecoverable.

T-3 days — Build the zone in Cloud DNS.

At this point the new zone is a faithful copy, but nobody is using it yet. The A record still points at the old hosting: that is deliberate.

T-1 day — The certificate in advance. With Certificate Manager and a DNS authorisation the certificate can be issued before the domain points at Google. It is exactly the scenario that validation exists for, and it avoids the window in which the domain already points at the load balancer but there is still no certificate.

T-0 — Delegate. Change the name servers at the registrar to Cloud DNS's. For 24-48 hours the two configurations will coexist; since they are identical apart from whatever is changed later, the user notices nothing. Keep the old hosting switched on for that whole time.

T+2 days — Change the destination. With the delegation already propagated and the TTL at 300 seconds, the A record is updated to the load balancer's IP. The real traffic switch happens now, with a five-minute window and the ability to undo it in five minutes.

T+3 days — Stabilise. Verify that no traffic is still reaching the old hosting (its logs will tell you), raise the TTLs to normal values, enable DNSSEC with its DS record, and only then decommission the hosting.

The idea to hold on to: the change of who resolves (T-0) is separated from the change of where it points (T+2). If they are done at once and something fails, you do not know which of the two caused it and undoing it takes 48 hours.

Solution 3

The cause is in the last piece of data: there is only one forwarding rule, on port 80. The 443 rule is missing. The certificate is ACTIVE (Google validated over HTTP), the DNS is correct and the redirect works — hence the 301 — but when the browser follows that redirect to https://, there is nothing listening on 443. The ERR_SSL_PROTOCOL_ERROR error is exactly that: there is no TLS dialogue on the other side.

If step 1 revealed that the HTTPS proxy does not exist either, it would have to be created first:

The diagnostic lesson: a certificate in ACTIVE proves that Google was able to validate the domain, not that the site serves HTTPS. They are two different things and it is easy to confuse them. Faced with a publishing failure, walk the complete 03-02 chain from the outside in: forwarding rule → proxy → certificate → URL map → backend service → backend → health check. The broken link always turns up.

AlpinaShop is published. Customers type alpinashop.example into the browser, see the padlock and buy. Behind that trivial gesture lie seven lessons of work.

In this last one you have gone over DNS in just enough depth to operate it: the record types, the impossibility of a CNAME at the apex — which is the whole reason for the static global IP — the role of the TTL in any migration and the habit of lowering it in advance. You have created the alpinashop-publica public zone with the apex A record pointing at alpinashop-lb-ip, the www CNAME, the imagenes record to the same IP — because a subdomain does not imply new infrastructure when the URL map routes by Host — the MX records, the SPF and a CAA record restricting who can issue certificates. You have delegated from the registrar and you know how to diagnose with dig whether the problem is yours or is propagation. You have created the alpinashop-interna private zone so that the application stops knowing IP addresses by heart, and you have enabled DNSSEC without forgetting the step almost everybody forgets: the DS record at the registrar.

You have provisioned a Google-managed certificate and, above all, you know why it gets stuck in PROVISIONING and in which order to look at the six possible causes, starting with the one that explains most of them: the A record. You know the limits of managed certificates and you know that wildcards and zero-downtime migrations are Certificate Manager's territory, with its DNS authorisation validation that allows issuing before moving the traffic. You have hardened the connection with the pol-ssl-alpinashop policy (MODERN profile, TLS 1.2 minimum) and you have added the headers only the application can emit — HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — with the same discipline you already applied to the WAF: Report-Only first, measure, and only then enforce. And you have verified the result end to end with curl and openssl s_client, checking not only that HTTPS works, but that TLS 1.1 fails, that the images subdomain returns Age and that Cloud Armor is still blocking what it should.

With the final checklist, module 3 is closed as a unit: a segmented network with no public IPs, a global load balancer with healthy health checks, caching at the edge with a well-calculated key, minimal permissions by group and with no downloaded keys, a WAF calibrated with preview mode, secrets out of the code and keys managed where they need to be, and at last a name and a certificate. AlpinaShop is on the internet and it is protected.

And now another story begins. That working shop generates data every second: orders arriving in alpinashop-pedidos, visits recorded in the load balancer logs, clicks on product pages, searches that find nothing, images served from the CDN, shopping carts abandoned in Firestore. Right now, all of that piles up with nobody looking at it. Marta knows how many instances are running, but nobody knows which backpack sells best in Catalonia, or whether the autumn campaign worked, or why 30 % of shopping carts are abandoned at the shipping step. Lucía, who so far has only appeared to ask for permissions, becomes the protagonist.

In module 4, Data and Analytics, we will build the platform that answers those questions. We will start with 04-01, BigQuery, creating the alpinashop_analitica dataset in alpinashop-datos and loading the order history into it, to discover why an analytical warehouse is not just a bigger database, how you pay for what you query and why a badly written query can cost more than a whole instance. Then will come Pub/Sub to capture events at the moment they happen, Dataflow to transform them, and the rest of the pieces until we reach dashboards Lucía can use without having to ask anybody for anything.