Skip to content
Agile Defense

Curriculum / Platform Administration & Security — Defense Edition

INTERMEDIATEUnit 8unit-08

Resource Protection and Branching for Production Integrity

not started~300 min
Protect production resources so changes flow through branch proposals and approvals, configuring a project approval policy in the Branch protection tab.

Introduction

Scenario: Your multi-program enrollment has a shared production pipeline that downstream mission dashboards depend on, and an analyst's accidental edit last sprint broke a coalition report mid-operation. You are asked to lock that production resource so every future change flows through a reviewed branch proposal under a project approval policy.

This unit teaches resource protection and branching, the control that turns a production dataset from something anyone with Editor access can change directly into something that can only be changed through a reviewed, approved proposal. For a defense org running multiple programs against a shared pipeline, this is the difference between a single careless edit silently breaking a coalition dashboard and that edit being caught, reviewed, and approved (or rejected) before it ever reaches main. You will identify the production resource to protect, confirm the Owner-level grant that authorizes someone to toggle protection and own approvals, and then document the project approval policy and the branch-and-approve change flow that protection enforces.

Protection is a mandatory change-management gate layered on top of the access model you built earlier in the course: Projects are still the primary security boundary, and Organizations plus Markings still decide who can see a resource at all. Protection does not change who can read the data; it changes how the data may be altered. A protected resource cannot be edited in place. Instead a contributor opens a branch, makes the change there, and submits it as a proposal; the change merges to main only after the configured number of eligible reviewers approve it. The Owner who holds protection authority is the same kind of group-scoped Owner grant you have been making throughout the course, which is why this unit leans on the role model rather than introducing a new permission system.

Two honesty constraints shape this unit. First, the protected (locked) state of a resource and the approval-policy configuration itself are set and read through the Foundry UI Branch protection tab and are not exposed by any documented read API, so the live checks here confirm only that the target resource exists and that the responsible group holds the Owner grant needed to manage protection; the policy and the open-proposal state are attested by you, not machine-verified. Second, the resource-roles check runs against a preview endpoint, so a live run may legitimately return 'blocked' rather than a silent pass. Both are expected limits, not failures, and you should record exactly what was confirmed versus what was attested.

Capability focus: Protected resources; branch-and-approve change flow; project approval policy (eligible reviewers, required approvals, self-approval). · Artifact: A protected production resource plus a configured project approval policy.

Key concepts

  • Protected resources: A resource whose Owner has toggled protection (shown by a lock icon) cannot be changed directly. All changes must be made on a branch and approved before they merge to main, which converts production edits from immediate writes into reviewed proposals. Protection governs how a resource changes, not who can see it — Organizations and Markings still control visibility.
  • Branch-and-approve change flow: To alter a protected resource a contributor creates a branch, makes the change there, and submits it as a proposal; the proposal merges to main only after the required approvals are recorded. This is the operational core of production integrity — no direct writes, every change reviewed against the policy first.
  • Project approval policy: Administrators configure the policy in the Branch protection tab, defining the eligible reviewers (who is allowed to approve), the number of approvals required before a proposal may merge, and whether a contributor may approve their own proposal. Tightening these settings (more approvals, no self-approval, a constrained reviewer set) raises the assurance bar for production changes.
  • Owner role as protection authority: Resource Owners toggle protection on and off and own the approval process; protection management rides on the same Project role model (Owner, Editor, Viewer, Discoverer) used elsewhere in the course, with the grant made to a responsible group rather than to individuals. Confirming the Owner grant confirms that an accountable principal exists to manage the lock and the policy.
  • Mandatory-over-discretionary layering: Protection sits alongside the broader Foundry control stack. Discretionary Project roles decide read/write capability, but mandatory controls (Organizations, Markings) always override role to prevent ineligible access, and protection adds a change-management gate on top — a user with Editor access still cannot edit a protected resource directly.
  • Read-API limits on protection state: The protected/locked state, the approval-policy configuration, and open proposal status are managed in the Foundry UI and are not surfaced by a documented Foundry read API. Existence of the target resource and the Owner role grant are API-confirmable; the policy itself and the workflow are documented, attested checkpoints rather than machine-assertable facts.

Companion video

Resource protection & branching walkthrough (placeholder) · open on YouTube

Hands-on activity

each step validates · the unit completes when all steps pass
  1. 1

    Confirm the production resource(s) targeted for protection exist

    Begin by confirming the production resource you intend to protect actually exists where you expect it in the mission Project, since the protection policy and approval gate are meaningless if they are pointed at the wrong target. The live check resolves the production pipeline dataset by its path in the Mission Program Project (Filesystem-v2 Get By Path / Get Resource), confirming the target of protection is present. Note that this is an existence check only: the protected (locked) state itself is set and read through the Foundry UI Branch protection tab and is not exposed by any documented read API, so resolving the resource confirms the target exists but does not by itself prove protection is on. Record the resource by name and RID so the rest of the policy work refers unambiguously to the same production resource the downstream dashboards depend on.

    not startedinstance check

    Confirms the production resource resolves (existence-only; the protected/locked state itself is not read-API-exposed).

  2. 2

    Confirm an Owner-level grant exists to toggle protection

    Next, confirm that a responsible group holds the Owner-level role grant on the production resource, because only an Owner can toggle protection (the lock) and own the approval process. The check uses Filesystem-v2 List Resource Roles to verify an Owner grant for the mission security administrators group, the accountable principal who will manage protection and approvals — consistent with the course practice of granting roles to groups rather than individuals. This runs against a preview endpoint, so a live run may legitimately return 'blocked' rather than passing silently; treat a 'blocked' result as an expected limit of the preview API, not as a missing grant, and re-confirm the Owner grant in the Foundry UI if needed. The point of this step is to establish that an accountable owner exists to manage the lock before you write the policy that depends on it.

    not startedinstance check

    Confirms an Owner grant for the responsible group (the principal who can Protect/Unprotect and own approvals).

  3. 3

    Document the project approval policy configuration

    Now document the project approval policy you configured in the Branch protection tab. This is an honest, self-attested checkpoint: the approval-policy configuration is set in the Foundry UI and is not exposed by any documented read API, so no live check can confirm it — you record what you set and the platform cannot machine-verify it here. Capture the three policy parameters explicitly: the eligible reviewers (which principals are allowed to approve proposals on this resource), the number of approvals required before a proposal may merge to main, and whether a contributor may approve their own proposal (self-approval). For a shared multi-program production pipeline, justify your choices — for example requiring multiple approvals from a constrained reviewer set and disallowing self-approval so that no single contributor can both author and merge a production change. State plainly that this step is documented and attested rather than API-confirmed.

    not startedself-attested

    Self-attested: the approval policy (eligible reviewers, approvals required, self-approval) set in the Branch protection tab.

  4. 4

    Document the branch-and-approve change flow

    Finally, document the branch-and-approve change flow that protection enforces, so reviewers understand the operational consequence of the lock you configured. This too is a self-attested checkpoint, not machine-assertable: open proposal state and the workflow itself are managed in the Foundry UI and have no documented read API. Record the flow in concrete terms: a protected resource (marked by the lock icon) cannot be edited directly; a contributor must create a branch, make the change there, and submit it as a proposal; the proposal merges to main only after the required approvals from eligible reviewers are recorded. Tie it back to the scenario — explain how this gate would have caught the accidental edit that broke the coalition dashboard, since the change would have surfaced as a reviewable proposal instead of an immediate write to production. Note explicitly that you are attesting to the documented workflow, not to a value the platform returned.

    not startedself-attested

    Self-attested: protected resources change only via branch proposals approved before merge to main.