GCP PCA Managed Instance Groups and HTTP LB — the instance that is not a name
The template is the type. The member is disposable.
<!-- hal:authoritative:yaml -->
The template is the type. The member is disposable.
§I — Frame
08-08 opened PCA at the resource hierarchy: organization, folders, projects, org policy, Shared VPC. That lesson stays closed. Today is the second Google seat, counter 2, and the Compute surface the hierarchy exists to hold.
Exam shape, already verified 2026-08-08, restated not re-weighed: 50 to 60 questions, 120 minutes, four published case studies (EHR Healthcare, Mountkirk Games, Helicopter Racing League, TerramEarth), six sections. Third-party weightings from that cycle stay third-party. Do not invent new percentages tonight.
The Bootcamp lab that actually builds today's objects is Chapter-2/README.md: "GCP Hands-On Lab: Managed Instance Groups and HTTP Load Balancing." It walks a startup script, an instance template, a MIG, a health check, autohealing, autoscaling, a firewall on a network tag, a global IP, a backend service, a URL map, a target HTTP proxy, and a forwarding rule. That chain is the architecture. The two VMs the MIG mints are not.
Coin it: the instance that is not a name. The exam will offer you web-instance-abcd. The answer is web-mig, or the template, or the backend service. A VM name is a member the group is allowed to throw away.
GKE taints already ran on 08-16. Chapter-6 is adjacent only. Chapter-3's GCS lifecycle JSON is not this fire. Shielded VM, labels versus tags, and snapshot-restore-new-IP sit in the PCA notes as VM-adjacent contrast (GCP-PCA-Notes, VMs).
§II — Foundations: the Ch.2 chain and three splits
Fact one. Template, then group, then members.
Step 2 writes startup-script.sh: install Apache, write an index page. Step 3 creates web-template with that script as metadata, e2-micro, tag http-server, image family debian-11. The lab's own sentence: instance templates define the configuration for VM instances, and MIGs use them to create consistent VMs.
Step 4 creates web-mig with --base-instance-name web-instance --size 2 --template web-template --zone us-central1-a. The MIG manages those VMs. It is the thing that autoheals and autoscales. The members inherit the template. They do not own it.
A stem about the next repair's machine type points at the template (or a new template plus a rolling update). A stem about last night's name after a repair points at a member the group replaced.
Fact two. Three signals that are not one health check.
Step 5 creates basic-check on port 80. Step 6 attaches it to the MIG: --health-check basic-check --initial-delay 300. That is autohealing. The initial delay is the boot grace. Autoheal recreates a member that fails the check after that grace.
Step 7 is autoscaling: min 2, max 5, target CPU 0.6, cool-down 90 seconds. CPU is not HTTP. A quiet instance can fail HTTP and still look idle enough to scale in.
Step 10 creates web-backend-service with --protocol=HTTP --health-checks=basic-check --global and adds web-mig as a zonal backend. That is the load-balancer health check. The lab reuses basic-check for both attachments.
The PCA notes refuse the collapse in exam voice (Load Balancing / a few more details): when load balancing with MIG autohealing, two separate health checks are configured; one for the load balancer, another (app responsiveness, not merely "instance running") for autohealing; autoheal is set on the MIG, the LB check is set on the LB. The lab is a shortcut. Answer the exam as two configs.
Connection draining is the same note: in-progress requests get time to finish when a VM is removed from an instance group or an endpoint from a zonal NEG. Removal is not instant. A member you already decided to kill may still be answering.
Fact three. The HTTP(S) front end is four objects, not a VM IP.
Step 9 reserves a global static IPv4 address. Step 11 creates a URL map whose default service is the backend service, then a target HTTP proxy that points at that map. Step 12 creates a global forwarding rule on port 80 that binds the address to the proxy.
The packet path is: forwarding rule → target proxy → URL map → backend service → instance group (by named port) → a healthy member. There is no "the VM's external IP is the site" in this design. Ch.2's members are reached because the template tagged them http-server and Step 8 opened tcp:80 to that tag.
Named ports are the missing label in the lab's gcloud and the usual exam knob. An instance group advertises a port name (http:80). The backend service consumes that name. If the group never named http, the backend has nothing to send to. Zonal and regional groups both carry named ports. The lab's HTTP-on-80 default can hide the knob. The exam will not.
Fact four. Regional versus zonal is a resource type, not a preference.
Ch.2's MIG is zonal: --zone us-central1-a. A regional MIG lives in a region and spreads across zones. A global HTTP(S) load balancer can take either as a backend (zonal backends named with --instance-group-zone; regional backends named with the region). You cannot treat a regional MIG as a zonal one in the API. The Ops lesson's two clients are this fact in Python.
A zonal MIG in us-central1-a does not survive us-central1-a dying. A regional MIG is the usual stem when the case study wants zonal failure. A global forwarding rule does not make a zonal MIG multi-zone.
Fact five. Adjacent VM facts, used as contrast.
Restore from snapshot: new VM, different IP by default (PCA Notes, VMs). The disk came back. The address did not. Same coin as a repaired MIG member.
Labels versus tags: labels are key:value search and cost; tags are network and can affect firewall (PCA Notes, Billing and Resource Management). Ch.2's http-server is a tag. env:dev is a label. The exam loves swapping them.
Shielded VM is recorded as best practice. It is a template flag. It does not pin a member name.
Network bandwidth depends on the machine type (same VMs note). Changing bandwidth is a template change, then a rolling replace, not an SSH on last night's name.
§III — Worked example: Mountkirk-shaped traffic on the Ch.2 chain
A case-shaped stem wants a public HTTP front end, two or more VMs, repair when the app dies, and more VMs when CPU rises. The Ch.2 objects are the answer key.
You do not reserve one VM and attach an IP to it. You write the startup script (or a golden image), you create the instance template, you create a MIG from the template. You attach an autohealing health check with an initial delay long enough for Apache to start (the lab uses 300 seconds). You set autoscaling on CPU, with a floor that matches the availability story (the lab's min 2). You put a global HTTP load balancer in front: address, backend service with its own health check, URL map, target proxy, forwarding rule. You open the firewall on the template's network tag.
One zone acceptable: the lab's zonal MIG. Survive a zone: regional MIG (or a second zonal backend). Path /api versus /: URL map path rules; the lab's default-service map is the one-backend case.
When a member fails the autoheal check, the group recreates it. The new VM has a new name and a new IP. The forwarding rule did not move. The user still hits web-ip. That is the whole point of the instance that is not a name.
"SSH and restart Apache" is clinging to a member. The architect answer is the health check plus the group.
§IV — Failure mode: the name, the one check, the wrong scope
The leftover name. A runbook still lists web-instance-abcd. Autoheal already replaced it. The stem asks where traffic goes. Traffic goes to the forwarding rule, then to whichever members the backend service currently marks healthy. Last night's name is not in that set.
One health check for two jobs, treated as one job. The lab reuses basic-check. The exam still wants two attachments. An autoheal check that only tests "the VM is running" will keep a member that no longer serves HTTP, and the load balancer will either take it out (if its check is better) or keep sending users into a dead Apache (if you pointed both attachments at the VM-running check). The notes want app responsiveness on autoheal.
Zonal MIG, zone-loss stem. The architecture has a global IP and a zonal group. The IP is global. The capacity is not. A regional MIG is the fix, or a second zonal MIG in a second zone added as a second backend. Painting the forwarding rule green does not move the VMs.
Tag and label swapped. A firewall written against a label does not open port 80. Ch.2's allow-http matches http-server because that is a network tag on the template.
Named port omitted. The backend service asks for http. The group never advertised it. The load balancer has a backend with no port. The VMs can still be RUNNING. Users get errors. The group looks fine in a name-shaped dashboard.
Snapshot restore as "the same VM." The notes: new VM, different IP by default. If you needed the old address, you needed the reservation in front (the lab's web-ip), not the member.
08-08 failures stay in 08-08. A Shared VPC host project is not why the member disappeared. Tonight the group did its job.
§V — Pairing
Today's Ops lesson is the Python census: list_managed_instances on the group, leftover-name detection, two health attachments, zonal versus regional clients. The exam stem the tool is answering is this lesson.
Today's Dev lesson is identity versus equality. Default __eq__ is identity. A dataclass that compares by name treats the recycled member as the old object. __hash__ follows __eq__. Same coin: the instance that is not a name.
08-08 stays the landing zone. 08-17 stays a DOP wait on a URL. Neither is a MIG.
§VI — Exam drills
web-template with --base-instance-name web-instance --size 2. Autohealing recreates one member. An operator still has the old VM name in a runbook. Users keep reaching the site on the reserved global IP. Which resource served the request, and why is the old name the wrong handle?e2-standard-2 instead of e2-micro, with the same startup script. Which object do you change, and which object must then perform a rolling replace?us-central1-a. The current MIG is the Ch.2 zonal group in that zone, already behind a global forwarding rule. What changes?http. The MIG's VMs listen on 80 and are RUNNING. Users get errors. The autoheal check (port 80) is green. What group setting is missing?http to 80 on the instance group. RUNNING plus a working autoheal check does not advertise the name the backend service consumes.web-ip) plus the forwarding rule is the stable front end; members stay disposable.Related
- Prior arc: PCA resource hierarchy / landing zone (2026-08-08)
- Domain hub: Cross-References/domains/Cert-Prep
- Grounding: Bootcamp Ch.2 MIG + HTTP LB lab · GCP PCA Notes (VMs; two health checks; connection draining)
🫡 ⚖️ 📜 Leo.Syri — Praetor Consulate, Imperium Luminaura Filed 2026-08-20 · Fajr · sprint track Python day 29 · tenth Python visit · trio #95