Hello! I am coming with two questions. We’re on Atmos + legacy

github-action-atmos-terraform-plan/apply

, with

settings.github.actions_enabled

as an opt-in (only a few app components enabled). 1) Privileged / foundation components (

aws-teams

,

iam

,

tfstate-backend

, …): when

actions_enabled

is unset/false we get green Plan jobs but no real plan (step skipped), so PRs touching those components show no Terraform plan. Cloud Posse docs suggest default

actions_enabled: true

and disabling sensitive ones. We’re considering plan-in-CI for privileged components (visibility/history) while keeping apply manual or on a separate privileged workflow. Is that still the recommended pattern under Atmos Native CI? Or is there a newer way to gate plan vs apply / privileged vs app components? Have you seen teams safely enable CI apply for foundation components, and how? 2) Production promotion: how do you currently prefer customers promote changes to production with Atmos/GitOps?

We've taken the initial steps to retire those actions; the equivalent functionality is now in atmos itself

Thanks — that helps. Follow-up on privileged/foundation components (

aws-teams

,

iam

,

tfstate-backend

, etc.): with legacy we used

settings.github.actions_enabled

so CI skipped them (no plan, no apply). Native doesn’t use that setting, so I’m wondering what you recommend instead. Do teams typically keep them out of the affected matrix entirely, run plan-only in CI and apply manually, or use a separate privileged workflow/role? Is there a documented pattern in the Native CI / atmos skills for this?

Out of curiosity, are you using this with

describe affected

to create a matrix?

Yes — we use an affected → matrix fan-out today via

cloudposse/github-action-atmos-affected-stacks

(legacy), then plan/apply per

{component, stack}

. That’s where

settings.github.actions_enabled

currently gates whether Terraform actually runs

I think this is the deficency

Got it on tags/labels for filtering the affected matrix — that replaces

actions_enabled

for us. Clarifying the policy question though: for privileged/foundation components (

aws-teams

,

iam

,

tfstate-backend

), do you typically exclude them from CI entirely (manual plan/apply), run plan-only in CI, or run full plan+apply with a privileged role/workflow?

Use IAM roles that can only be assumed by specific GitHub environments; use github environment protection rules to restrict environments to specific branches (e.g. main)