Infrastructure and Policy as Code

What it is

Infrastructure as code (IaC) describes accounts, networks and services in files that a tool deploys the same way every time. Policy as code describes the rules those files must follow, and checks them automatically instead of in a review meeting.

At professional level the questions are about scale. You must choose the right authoring style, block non-compliant resources before they exist, keep secrets out of source control and roll the same baseline into hundreds of accounts.

How it works

Declarative and imperative IaC

AWS CloudFormation is declarative: a YAML or JSON template states the end result and the service works out the order. The AWS CDK is imperative in style: you write TypeScript, Python, Java, C# or Go, use loops and classes, and the CDK synthesizes a CloudFormation template.

Both end up as CloudFormation stacks, so change sets, rollback, drift detection and StackSets apply to both. CDK L2 and L3 constructs bake in sensible defaults, which cuts the code a team must write and review.

Policy as code: prevent, enforce, detect

Strong designs layer three kinds of control, from earliest to latest.

CloudFormation Hooks can run Guard rules or a Lambda function against resources, stacks or change sets. A hook in fail mode stops the operation, and warn mode only reports, which is a safe way to roll out a new rule. AWS Control Tower proactive controls are implemented as CloudFormation Hooks.

SCPs set the maximum permissions for member accounts. They never grant permissions, and they do not affect the management account, so keep workloads out of it.

AWS Config rules are mainly detective. A remediation action runs a Systems Manager Automation runbook, either manually or automatically, to fix a non-compliant resource. Deploy rules and conformance packs across the organization from a delegated administrator account.

CloudFormation drift detection reports resources changed outside the stack. It does not fix them, so pair it with Config remediation or a redeploy from the pipeline.

Secrets in infrastructure code

Never put a password in a template, a CDK app or a parameter default. Store it once and reference it.

CloudFormation dynamic references such as {{resolve:secretsmanager:prod/db:SecretString:password}} and {{resolve:ssm-secure:...}} fetch the value at deploy time, so it never appears in the template. For Amazon RDS and Aurora, the ManageMasterUserPassword property lets RDS create and rotate the master password in Secrets Manager with no secret in code at all.

In the CDK, reference a secret with Secret.fromSecretNameV2 or generate one, and let the construct pass only the ARN to the database.

StackSets for many accounts and Regions

CloudFormation StackSets deploys one template as stack instances in many accounts and Regions.

• Service-managed permissions use AWS Organizations, target OUs and support automatic deployment to accounts that join an OU later. They can be run from a delegated administrator account.
• Self-managed permissions need an administration role and execution roles that you create, for accounts outside an organization.
• Operation preferences set maximum concurrent accounts, failure tolerance and Region order, so a bad template stops early instead of hitting every account.

Service-managed StackSets do not deploy to the management account, even if it sits in a target OU.

How the exam asks about this

• "Block any stack that creates an unencrypted EBS volume, in every account, before resources exist" -> a CloudFormation Hook (or Control Tower proactive control), not only a Config rule.
• "New accounts must receive the logging and IAM baseline with no manual step" -> StackSets with service-managed permissions and automatic deployment to the OU.
• "Developers want loops and unit tests for 40 similar microservice stacks" -> the AWS CDK with shared constructs and aspects.