A global Sentinel policy set restricts compute instance types to an approved list. The machine learning team, whose workspaces all sit in their own HCP Terraform project, has an approved business need for GPU instance types that the list excludes. How should the platform team accommodate them?
Select an answer to reveal the explanation.
Short Explanation
When one team needs a different rule, you give that team its own rule; you don't loosen it for everybody. Excluding their project from the global set and scoping a tailored set to it keeps the guardrail tight everywhere else.
Full Explanation
Policy sets can exclude specific projects, workspaces, Stacks or tags, and a separate set can be scoped to a single project. Excluding the ML project from the global set and attaching a project-scoped set that carries the same instance-type rule with the approved GPU additions keeps enforcement for the ML team while documenting the exception as code, and every other project continues to receive the original, unchanged rule. Downgrading the global policy to advisory removes enforcement for every workspace in the organization to satisfy one team. Routine overrides convert a standing, approved exception into a manual step on every run, generate noise in the audit trail, and depend on someone with override rights being available each time. The ignore_changes lifecycle argument only tells Terraform to disregard differences in an attribute when planning updates; policy evaluation still sees the planned instance type, so it neither avoids the policy nor matches the intent. Exam caveat: keep the shared rule logic in one module or library imported by both sets so the variants do not drift apart. Operational check: queue a plan in an ML workspace and confirm only the project-scoped set evaluates, then queue one in another project and confirm a GPU type still fails the global set.