Policy as Code

Policy as Code treats governance requirements as software artifacts rather than relying only on documents and manual reviews. Engineers express requirements in a rule language or general-purpose code, store them in version control, test their behavior, and run them through automated evaluation. Examples include requiring encryption for storage, prohibiting unrestricted administrative network access, and requiring ownership tags. Policies should produce actionable results that identify the resource, violated requirement, and expected correction.

Infrastructure as code and Policy as Code serve different purposes. Infrastructure as code describes resources to create or modify; Policy as Code evaluates whether those definitions or their resulting resources satisfy requirements. A reusable infrastructure template can contain secure defaults, but those defaults are not an enforcement boundary if callers can override them or deploy through another path. A practical design combines approved templates with independent policy checks and appropriately restricted deployment permissions.

In a deployment pipeline, validate the infrastructure definition before provisioning. For AWS CloudFormation, cfn-lint checks templates against resource specifications and other validation rules, helping detect invalid properties and configuration mistakes. AWS CloudFormation Guard evaluates structured data against explicitly authored policy rules, such as requiring an encryption property or restricting allowed resource configurations. Passing cfn-lint does not establish compliance with an organization's security requirements, and Guard does not enforce rules merely because a rule file exists. The pipeline must execute the checks and stop deployment when required checks fail.

For example, a pull request that introduces an unencrypted database should fail a policy test before deployment. The same repository can include passing and failing fixtures to verify that the rule detects missing encryption settings without rejecting approved configurations. Third-party infrastructure tools can use comparable workflows, such as evaluating Terraform plan JSON with Open Policy Agent. Evaluate the artifact that will actually be deployed, and account for unresolved values: static checks cannot always determine properties that become known only during deployment.

Across accounts and Regions, CloudFormation StackSets can distribute approved baseline templates and updates consistently. StackSets provide deployment orchestration, not a general-purpose security policy evaluator. Validate templates before distributing them, control deployment roles, and use staged rollouts to limit the impact of mistakes. Where appropriate, CloudFormation Hooks can add provisioning-time checks, while organization-level permission controls can restrict prohibited actions through other deployment paths.

Predeployment checks do not replace assessment of running resources. Console changes, alternative automation, and changing dependencies can introduce noncompliance after a successful deployment. Runtime evaluations, such as AWS Config rules, complement pipeline checks; detection and remediation are separate capabilities and must be configured deliberately. Drift detection identifies differences from declared infrastructure but does not independently prove security compliance.

The main trade-offs are policy maintenance, incomplete evaluation context, false positives, and the disruption caused by incorrect blocking rules. Begin new rules in reporting mode when appropriate, test them against representative workloads, and promote them to enforcement after review. Exceptions should have an owner, justification, scope, and expiration. Protect policy repositories and pipeline configuration as carefully as deployment credentials, because an actor who can weaken checks or bypass the pipeline can undermine the control.