Outcome
By the end of this lesson, you will be able to predict when a remediation waits for approval, act on an approval request as an admin, and set up your org’s roles so destructive changes get a second look without stalling.
| Prerequisites | M2.3.L1 · M2.3.L2 |
| Time | 9 minutes |
1. Concept
The approval gate is a pause. Before a change reaches your cloud, an admin says yes or no.
What decides whether the pause happens is not the rule, the tag or the cost of the resource. It is who clicked Remediate.
THE GATE PATTERN:
ADMIN clicks Remediate: precondition → action → validate No approval step. The admin's click is the approval.
EDITOR clicks Remediate: precondition → AWAITING ADMIN APPROVAL → action → validate The workflow pauses until an admin decides.
VIEWER: Cannot start a remediation at all.The right balance comes from role assignment, not per-rule configuration.
When the approval step is added
The step is planned into the workflow when the job is created. Which actions add it for an editor:
ACTION TYPE EDITOR CLICK ADMIN CLICK───────────────────────────────────────────────────────────────────────Delete (orphan snapshot, disk, IP) Approval step added No approvalResize Approval step added No approvalPause (Synapse, Data Factory, ...) Approval step added No approvalK8s manifest edit (1 -> 2 replicas) Approval step added No approvalGCP Dataproc pause Approval always No approval (deleting the cluster cannot be undone)For deletes and resizes the step is unconditional for a non-admin. For pause and K8s edits it follows the approval setting, which is on by default and is set for the whole ZopNight deployment rather than per org. There is no settings page where a team picks approval rules per rule, per tag or per cost band.
Who can approve
APPROVER: Any admin in the org EXCEPT the person who started the remediation (no self-approval, enforced on the server)
WHERE THEY SEE IT: Recommendations page banner: "N remediations awaiting your approval" Approve or Reject inline, or open the drawer Reject requires a reason
ONE STEP, ONE DECISION: A single "Awaiting admin approval" step One admin's approval is enoughThere is no two-person rule, no approver chain and no escalation to a backup approver. One admin decides.
How approvers find out
When the workflow reaches the approval step:
EMAIL (always on): Every org admin except the initiator gets the "[ZopNight] Remediation approval needed" email It links to the job in ZopNight Sent once per step; a replayed step does not re-send
CHANNELS (if your org subscribed one): A notification subscription to the "Remediation Approval Request" event delivers the same notice to that channel
THE DECISION ITSELF: Always made in ZopNight (or through the API) The email and channel notice carry no approve or reject buttonsThe notice tells the admin something is waiting. The approval happens where the evidence is.
Approval workflow timeline
T+0 Editor clicks Remediate Precondition passes Workflow reaches "Awaiting admin approval"
T+1 sec Job status: awaiting user Approval email sent to admins Resource state unchanged
[ human-bounded delay ]
T+3 hr Admin sees the banner on the Recommendations page Opens the drawer, reviews evidence Clicks Approve, then confirms
T+3 hr+1s Workflow advances to the action stepT+3 hr+15s Action complete Validate step confirms Workflow ends
OR (alternative path):
T+48 hr No decision within 48 hours (fixed)T+48 hr Hourly expiry sweep cancels the job: "Auto-cancelled: this remediation was not confirmed within 48 hours." Resource state unchanged Recommendation stays open; start it again when readyThe timing is human-bounded; approval is the slowest step.
The approval API and audit trail
Approve and reject are one state change on the step’s stable ID:
APPROVE: PATCH /orgs/{orgID}/workflows/{jobID}/steps-by-id/{stepID} Body: {"action":"approve"}
REJECT: PATCH /orgs/{orgID}/workflows/{jobID}/steps-by-id/{stepID} Body: {"action":"reject","reason":"Owner confirms the snapshot is still needed"}
MCP TOOLS: list_workflows pending approvals approve_workflow_step approve reject_workflow_step rejectApprove carries no comment field; reject carries the reason. Both land in Audit Logs as “Approved workflow step …” or “Rejected workflow step …”, with the user and time. The job’s own step timeline shows the same decision in context.
Rejected: what happens
REJECTED (admin clicks Reject and gives a reason): The job is cancelled The action never runs Resource state unchanged Recommendation stays open The reject is recorded in Audit Logs
NEXT: The editor reads the reason Fixes the concern or dismisses the recommendation Can start the remediation again laterReject is an intentional no, captured cleanly.
When approval becomes theatre
SIGNS THE GATE IS NOT DOING WORK: Admins approve every request within seconds Nobody opens the drawer before approving Rejects never happen
WHAT YOU CAN CHANGE (all through roles): Make the people who already own production change approval into admins, so their clicks run directly Keep everyone else as editors, so their destructive clicks get a real review Keep at least two admins, so a request does not wait on one person's calendar and the 48-hour window is rarely hitYou cannot narrow the gate per rule or per tag. You choose who is an admin.
Approval security
WHO CAN APPROVE: Org admins only Never the initiator
WHO SKIPS THE GATE: Admins, by design: their click already carries the authority an approval would grant
WHAT NOBODY CAN DO: Viewers cannot start a remediation An editor cannot approve their own (or anyone's) request
AUDIT IMPACT: Start, approve and reject are each recorded in Audit Logs with the user and timeThe gate is a documented decision point. Its strength is only as good as your role hygiene.
2. Demo
A 50-engineer SaaS team setting up its roles for remediation:
ROLES: 3 admins: the platform leads who already approve production changes 20 editors: service owners Everyone else: viewer
A TYPICAL WEEK:
Monday 10:02 Editor clicks Remediate on RC-021 (orphan EBS snapshot delete, guided) Types to confirm; precondition passes Workflow pauses: "Awaiting admin approval" All 3 admins get the approval email
Monday 11:15 Admin opens the Recommendations page Banner: "1 remediation awaiting your approval" Reviews the snapshot's source volume: gone Approves; the snapshot is deleted Audit Logs: "Approved workflow step ..."
Tuesday 14:40 Editor clicks Remediate on a resize Admin rejects: "Quarter-end batch runs on this host; resize after the 5th" Job cancelled; recommendation stays open
Thursday 09:00 Admin clicks Remediate on an unattached disk delete themselves No approval step; runs straight through
Friday One request from Wednesday is still waiting (all 3 admins were travelling) It will be cancelled at the 48-hour mark The editor will start it again next weekEvery gate in this week came from who clicked, not from per-rule settings.
3. Hands-on (5 min)
Check how the gate will behave in your org:
□ STEP 1: List your admins Count: _____ Each admin's Remediate click runs with no approval. Should every one of them have that? □ Yes □ No
□ STEP 2: List your editors Count: _____ Their deletes, resizes, pauses and K8s edits wait for an admin.
□ STEP 3: Check coverage Are there at least 2 admins who check ZopNight on a working day? □ Yes □ No If not, requests risk the 48-hour cancellation.
□ STEP 4: Find pending approvals As an admin, open the Recommendations page Banner present? □ Yes (count: ___) □ No
□ STEP 5: Review last month's decisions In Audit Logs, find the "Approved workflow step" and "Rejected workflow step" entries Approved: ___ Rejected: ___ Cancelled at 48h: ___A 15-minute check shows whether the gate is a real review or a rubber stamp.
4. Knowledge check
Q1
An editor clicks Remediate on an allowlisted orphan snapshot delete. Why does the workflow pause?
A. The rule is configured per org to require approval for every snapshot
B. Non-admin initiators go through an approval step; an admin must approve
C. Snapshot deletes always wait 48 hours before they are allowed to run
D. The safety gate demoted the recommendation and is now waiting on a re-check
Show answer
Correct: B. The approval step is planned from the initiator’s role. An editor’s delete always waits for an admin; the same click by an admin runs straight through. There is no per-rule or per-tag approval configuration.
Q2
An approval request times out (48 hours with no decision). What happens to the resource:
A. Action proceeds anyway (assumed approved)
B. Approval bypassed
C. Resource is deleted
D. Auto-cancel. Resource state unchanged
Show answer
Correct: D. The job is cancelled and the recommendation remains open, so the team can start it again. Timeout means no-go, and the 48-hour window is fixed rather than set per rule.
Q3
Your org has one admin, Priya. Priya clicks Remediate on a resize. What happens?
A. The workflow waits for a second admin, since an admin cannot approve their own request
B. The workflow waits for any editor on the team to approve it
C. It runs with no approval step, because an admin’s click is the approval
D. It is refused, because a single-admin org cannot run any remediation
Show answer
Correct: C. Admins are never gated. No-self-approval only matters when an admin is asked to approve a request; it never applies to an admin’s own click, because no approval step is planned for it.
5. Apply
Approval follows the initiator’s role: admins run directly, editors wait for an admin, viewers cannot start a remediation. Admins approve or reject from the banner on the Recommendations page, and Audit Logs records every decision.
For your team: review admin and editor assignments quarterly, and keep at least two admins who check ZopNight on working days.
Related lessons
- L1: 3-step workflow
- L2: Allowlisted, guided, advisory
- L4: Error classes (next)
- L5: Database denylist
- L6: Remediation notifications