Introduction

Scenario: Your multi-program enrollment now holds a mission roster dataset that carries Controlled Unclassified Information, and not everyone with a Project role is cleared to see it. As the security owner, you must apply a mandatory Marking to that resource, grant marking access only to the cleared mission team, and prove who can — and cannot — view the marked data.

Unit 4 introduces Markings, Foundry's mandatory access control. In the previous units you carved mission work into Projects and granted Owner, Editor, Viewer, and Discoverer roles to groups. Those roles are discretionary: a Project Owner can hand them out. Markings sit above that layer. A Marking is a mandatory, conjunctive (AND) control — to open a marked resource a user must satisfy every Marking applied to it, no matter what Project role they hold. This is the mechanism that lets a CUI dataset live inside a shared mission Project while remaining invisible to teammates who are not cleared for it.

This matters because in a defense org the Project boundary alone is too coarse. A program team needs to collaborate in one Project, but a roster tagged CUI must only reach members who carry that authorization. Markings attach to resources two ways: through the file hierarchy, where a Marking on a folder or Project cascades to everything contained inside it, and through data dependency, where a Marking propagates downstream to datasets derived from a marked source. Because the control is conjunctive, layering markings only ever narrows access — adding a second Marking can never widen who gets in. Together with Organizations, Markings form the mandatory baseline that always overrides discretionary roles, and they are the conceptual building block for the classified CBAC controls you will model in the next unit.

By the end of the unit you will have a mandatory Marking applied to a mission resource, marking access granted to the cleared group, and a documented marking-management role assignment so the right administrators can curate membership. You will also confirm each piece the way an auditor would: resolving the Marking and its category, reading the resource's access requirements to prove it is actually marked, listing the marking members to prove only the cleared group can view it, and verifying who holds authority to manage the Marking. Some of these reads are privileged, and you will learn exactly where the platform refuses to answer without elevated scope.

Capability focus: Mandatory conjunctive Markings; marking access grants; marking-management role assignment. · Artifact: A mandatory Marking applied to a mission resource with access granted to the cleared group.

Key concepts

Companion video

1. 1

   Confirm the Marking exists

   Start by proving the mandatory Marking actually exists in the enrollment and is the kind of control you intend. A Marking is the conceptual unit of mandatory access: it sits above Project roles and is conjunctive, so any resource it touches can only be opened by users who satisfy it. Create the CUI Marking in Control Panel (or confirm it was provisioned), then resolve it with the Admin API's Get Marking / List Markings read, which returns the Marking's rid, name, and category. The check confirms the Marking resolves; it also compares the category against the expected convention for a plain mandatory Marking (this course's sandbox uses MANDATORY, distinct from the classification-level and releasability categories you will meet in CBAC). Because the literal category strings are an environment convention to confirm rather than a documented Foundry enum, a Marking that resolves with a different category string is reported as blocked — verify the value with your instructor — never a silent pass.

   not startedinstance check

   Run check

   Confirms the mandatory Marking resolves with the expected category.

2. 2

   Confirm a resource carries the Marking as an access requirement

   Now prove the Marking is genuinely attached to the mission roster, not merely defined in the abstract. Apply the CUI Marking to the roster resource — either directly, or by marking a parent folder/Project so it cascades down the hierarchy, or by letting it propagate via data dependency from a marked upstream source. Then read the resource's access requirements with Filesystem Get Access Requirements, which returns the resource's Markings (conjunctive, AND) together with its Organizations (disjunctive, OR). The check confirms the CUI Marking appears in the resource's markings list and that the mission Organization appears among its organizations — the full mandatory envelope around the data. Note that Get Access Requirements is a preview endpoint: against a live instance the check may come back as blocked rather than passing silently if that preview surface is unavailable, and a blocked result is an honest signal to confirm by hand, not a pass.

   not startedinstance check

   Run check

   Confirms the mission resource is actually marked (the mandatory Marking appears in its access requirements, with the disjunctive Organization).

3. 3

   Confirm who can view the marked resource

   With the Marking applied, prove that only the cleared mission team can actually view the marked roster. Access to marked resources flows from marking membership, not Project roles, so grant marking access to the cleared GROUP rather than to individual users — membership then resolves transitively through any nested groups beneath it. List the marking members with the Admin API's List Marking Members read using transitive=true; the check confirms the cleared group is returned among the principals able to view the marked resource. Be aware this is a privileged read: only marking administrators are permitted to see who can view a Marking, so List Marking Members requires the api:admin-write scope. Against a live instance a read-only runner will return blocked here — that is expected and honest, signaling the elevated scope is required, never a silent pass.

   not startedinstance check

   Run check

   Confirms the cleared group is a marking member able to view marked resources (live: needs api:admin-write → blocked).

4. 4

   Confirm marking management role assignment

   Finally, confirm that the right administrators hold authority to manage this Marking going forward — to curate its membership and metadata as clearances change. This authority is a granted marking-management role assignment, distinct from membership in the Marking itself. Grant the marking-administration role to your security-admin group, then read the Marking's role assignments with the Admin API's List Marking Role Assignments. The check confirms the security-admins group holds the Marking Administrator role on the CUI Marking. Because Foundry role reads return role IDs rather than display names, the check applies a roleId-to-label crosswalk so a returned role ID resolves to 'Marking Administrator'; confirm the assignment is to the group (not an individual) so management authority stays auditable and survives staff turnover.

   not startedinstance check

   Run check

   Confirms a principal is granted authority to manage the Marking and its members.