diff --git a/docs/changelog-20260724-caveman-disable.md b/docs/changelog-20260724-caveman-disable.md
index 5c7b1e9..e261786 100644
--- a/docs/changelog-20260724-caveman-disable.md
+++ b/docs/changelog-20260724-caveman-disable.md
@@ -155,3 +155,19 @@
 - **Revert:** `git revert <sha>` (removes the script, harness, D-135 amendment
   paragraph, and CURRENT-STATE split); if installed live, on the dc1 rack:
   `systemctl disable --now apt-cacher-ng; rm -f /etc/apt-cacher-ng/acng.conf.d/dc1-cache-proxy.conf`.
+
+## Item 6 -- phase-4 runbook: per-DC MAAS service-credential step (Step 2.0)
+
+- Operator-directed: the MAAS API key Juju needs is created by NO prior stage --
+  a standing DEPLOYMENT-TIME task, so it belongs in the runbook. Added **Step 2.0**
+  to `runbooks/dc-dc-phase4-juju-bundle-per-dc.md` (before the bootstrap MUTATION):
+  create a DEDICATED per-DC MAAS admin service user (`sudo maas createadmin`) +
+  issue its own API key (`sudo maas apikey --generate`) -- per-DC credential
+  isolation (SEC-012/-016; Roosevelt: per-DC cloud creds), never a cross-DC reuse.
+- **Creds location corrected (operator-directed):** the key stages in the JUMPHOST
+  per-site creds folder (`~/vr1-<dc>-creds/maas-api-key.txt` on vcloud, SEC-009
+  convention) -- NOT a new location on the region (voffice1) as the first
+  walkthrough had it. Generated FROM the jumphost so it transits ssh stdout with
+  no persistent copy on the region; never printed (SEC-006); consumed by Juju via
+  path/stdin, never argv. Each issued key = a per-DC SEC rotation row.
+- Revert: `git revert <sha>` (removes Step 2.0). No live/cloud state touched.
diff --git a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md
index 2f99bd7..a890b53 100644
--- a/runbooks/dc-dc-phase4-juju-bundle-per-dc.md
+++ b/runbooks/dc-dc-phase4-juju-bundle-per-dc.md
@@ -116,6 +116,31 @@
 model as VR0/DC0's original bootstrap -- a fresh `juju bootstrap` targeting
 THIS DC's MAAS cloud/region, not a reused controller.
 
+**Step 2.0 -- Per-DC MAAS service credential [DEPLOYMENT-TIME TASK; MUST precede bootstrap]**
+
+Juju authenticates to the MAAS region with an API key -- this is NOT created by
+any prior stage, so it is a standing deployment-time task per DC. Per the per-DC
+credential-isolation discipline (SEC-012/-016; Roosevelt analog: per-DC cloud
+credentials), issue a DEDICATED MAAS admin service user + its OWN key per DC --
+never reuse one key across DCs. On the MAAS region host (VR1: `voffice1`):
+```bash
+# service account -- Juju auths via the API key, not this password; use a random one
+sudo maas createadmin --username=juju-<dc> --email=juju-<dc>@<realm>
+```
+Generate the key so it lands ONLY in the JUMPHOST per-site creds folder
+(`~/vr1-<dc>-creds/maas-api-key.txt` on vcloud, SEC-009 convention -- NOT a new
+location on the region), never echoed to a terminal (a printed MAAS key is
+burned, SEC-006). Run the generate FROM the jumphost so the key transits ssh
+stdout straight into the vcloud file (no persistent copy on the region):
+```bash
+ssh <region> 'sudo maas apikey --username=juju-<dc> --generate' \
+  > ~/vr1-<dc>-creds/maas-api-key.txt
+chmod 600 ~/vr1-<dc>-creds/maas-api-key.txt
+awk -F: '{print "parts:", NF}' ~/vr1-<dc>-creds/maas-api-key.txt   # expect 3; do NOT cat
+```
+Register the MAAS cloud + this credential in Juju consuming the key BY PATH/stdin
+(never argv). Each key is a rotation obligation -- open a per-DC SEC row when issued.
+
 **CHECK (read-only) -- confirm the target MAAS cloud is registered to Juju**
 ```bash
 juju clouds --client | grep -i maas