What You Built in This Module

“It is live” is the claim a green deploy makes and the one most worth distrusting — a deploy reports success while the service is unreachable, ships an artifact you never tested, fails its first hour for entirely normal reasons, and bills you for weeks while idle. Every property you would be paged about is invisible at the moment the deploy goes green. What you can stand up now reaches the public at a real address, ships the artifact you actually verified, recovers from a bad release in one step, and costs what you said it would.

What you completed

Getting a 200 OK from a public URL came first; each lesson after it hardened a property that a successful-looking deploy quietly leaves unproven:

• A green deploy and a reachable service are different facts. A server bound to 127.0.0.1 answers only itself, so the platform reports success while every outside request times out — and the host expects you to bind the port it injects, not one you picked. Scoring a real record at the public URL is the only check that the two facts agree.
• A second docker build is a new artifact wearing the same Dockerfile. Rebuilding to deploy throws away the thing you tested and ships something that merely resembles it; promoting by content digest is what makes the box in production the box you verified. The baked-secret-survives-deletion rule returns here for a reason — what you promote is exactly what leaks if you got it wrong.
• The normal first hour reads as broken if you do not know the two clocks. DNS propagation bounded by TTL and a certificate gated on an ACME challenge run in series, so the domain fails for about an hour for reasons nothing is wrong with. Reading that as expected rather than as an outage is what keeps you from “fixing” a system that was already working.
• A deploy you cannot undo is a deploy you are afraid to make. Rollout strategy plus a readiness probe that means can-serve rather than is-alive is what lets a bad version come back out in one step under live traffic. The is-alive check passing while the service cannot actually serve is the exact failure the gate exists to catch.
• A scale-to-zero service idles near free or bills you for weeks, and you only find out which afterward. The billing model follows from where the service sits on the traffic curve, and the worst-case monthly figure is an unknown until you state it out loud. Bounding the cost in advance is the difference between a surprise and a number you already accepted.

Check your understanding

Work these without scrolling back up. Each one is a new service, not the loan-scoring deploy the lessons used — the point is to apply the judgment, not recall the case. Try to answer before opening the hint.

1. You deploy a photo-moderation service to a cloud host. The platform reports the deploy as successful, but every outside request to it times out. The container binds to 127.0.0.1 on a port you chose. Explain why a green deploy and a reachable service are different facts here, and the one check that confirms they agree.

   Hint

   A server bound to loopback answers only itself. Think about which interface the service has to bind to be reachable, which port the host expects it to use, and why scoring a real record at the public URL is the only proof the two facts agree.

2. To push a fix to the moderation service, a teammate runs docker build again on the deploy machine and ships the result. Explain why this is not the artifact that was tested, what promoting by content digest changes, and why the baked-secret rule from the packaging module is relevant to what you promote.

   Hint

   A second build is a new artifact wearing the same Dockerfile — it merely resembles what you verified. Think about promoting the exact box you tested by its digest, and why what you promote is also exactly what leaks if a secret got baked in.

3. You point a custom domain at the moderation service and for about an hour the domain fails to resolve and the certificate is not yet valid. A teammate wants to start changing configuration to fix it. Explain the two clocks running here and why the normal first hour reads as broken to someone who does not know them.

   Hint

   Two processes run in series — DNS propagation bounded by a TTL, and a certificate gated on a challenge that cannot complete until the domain resolves. Think about why reading this as expected, not as an outage, keeps you from breaking a system that was already working.

4. A new version of the moderation model ships and starts returning wrong labels under live traffic. The platform’s liveness check stays green the whole time. Explain why is-alive passing is not the same as can-serve, the probe that would have caught it, and the property that lets you pull the bad version back out in one step.

   Hint

   A deploy you cannot undo is one you are afraid to make. Think about a readiness probe that means can-serve rather than merely is-alive, and the rollout strategy that lets a bad version come back out under live traffic without a scramble.

5. The moderation service scales to zero between bursts of uploads. Before launch a stakeholder asks what it will cost per month, and nobody can answer. Explain why the billing model depends on where the service sits on the traffic curve, and what you would state out loud before shipping so the bill is a number you already accepted.

   Hint

   A scale-to-zero service idles near free or bills you for weeks, and you only learn which afterward. Think about the worst-case monthly figure being unknown until you compute it, and why bounding it in advance turns a surprise into an accepted number.

What it adds up to

Making the service answer once was the demo; making it answer safely, durably, and affordably to anyone was the job. The system you can now deploy reaches the public at a real address, ships the artifact you actually verified, recovers from a bad release in one step, and costs what you said it would. That is the difference between a model that works on your laptop and a model other people can depend on.

What comes next

You deployed this service by running the steps yourself — CLI commands and console settings, configured and pushed until it was right. That works once. The problem is not that you typed the commands; it is that the resulting infrastructure lives nowhere in code, so it cannot be rebuilt, reviewed, or recovered after someone changes it out from under you. The next module makes the infrastructure itself reproducible the way Docker made the application reproducible: declared in code, versioned, and reviewable — so the environment this service runs in can be rebuilt as reliably as the image that runs in it.