Unit 2 Study Guide: Configuration Management and IaC

This guide covers Content Domain 2 of the AWS Certified DevOps Engineer - Professional (DOP-C02) exam, representing approximately 17% of the scored content. It focuses on the automation of infrastructure provisioning, configuration management, and multi-account governance.

Learning Objectives

By the end of this module, you should be able to:

• Evaluate various AWS IaC tools (CloudFormation, SAM, CDK) for specific use cases.
• Design multi-account and multi-region deployment strategies using CloudFormation StackSets.
• Implement automated configuration management and patching using AWS Systems Manager and AWS Config.
• Standardize account provisioning and governance using AWS Control Tower and AWS Organizations.

Key Terms & Glossary

• Infrastructure as Code (IaC): The practice of managing and provisioning infrastructure through machine-readable definition files, rather than manual hardware configuration or interactive configuration tools.
• StackSets: A CloudFormation feature that lets you create, update, or delete stacks across multiple accounts and regions with a single operation.
• Drift Detection: A feature in CloudFormation and AWS Config that identifies when a resource's actual configuration differs from its expected template configuration.
• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, acting as a guardrail for what actions accounts can perform.
• State Manager: A capability of AWS Systems Manager that automates the process of keeping managed instances in a defined state (e.g., ensuring a specific antivirus is running).

The "Big Idea"

The core philosophy of Unit 2 is treating infrastructure exactly like application code. By codifying your environment, you gain the ability to version control your data center, perform peer reviews on network changes, and instantly replicate complex architectures across the globe. This eliminates "snowflake servers" (unique, manually configured instances) and replaces them with consistent, disposable, and repeatable environments.

Formula / Concept Box

Hierarchical Outline

1. Infrastructure as Code (IaC) Foundations
   • Authoring Tools: CloudFormation (JSON/YAML), SAM (Serverless focus), and CDK (Higher-level constructs).
   • Reusable Components: Utilizing CloudFormation Modules and CDK Libraries to encapsulate security and compliance standards.
2. Multi-Account Strategy and Governance
   • Account Provisioning: Automating account creation via AWS Control Tower and AWS Organizations.
   • Cross-Account Deployment: Scaling deployments using StackSets for consistent global baselines.
   • Guardrails: Implementing SCPs and AWS Config Rules to enforce organizational compliance.
3. Configuration Management & Task Automation
   • Fleet Management: Using AWS Systems Manager (SSM) for inventory, patch management, and state enforcement.
   • Resource Tracking: AWS Config for auditing changes and remediating non-compliant resources.
   • Application Config: Using AWS AppConfig to manage dynamic application toggles without redeploying code.

Visual Anchors

Multi-Account Deployment Logic

This diagram illustrates how a Management account uses StackSets to distribute infrastructure to Member accounts across different regions.

CDK Synthesis Process

This TikZ diagram represents how the AWS CDK converts high-level programming code into a CloudFormation template.

Definition-Example Pairs

• Term: Remediation Action
  • Definition: An automated response triggered when a resource falls out of compliance.
  • Example: If AWS Config detects an S3 bucket is public, it triggers a Lambda function via Systems Manager Automation to immediately set the bucket to private.
• Term: Immutable Infrastructure
  • Definition: A strategy where servers are never patched in place; instead, they are replaced by new instances from a fresh image.
  • Example: Using EC2 Image Builder to create a new AMI and performing a Blue/Green deployment rather than running yum update on live production instances.

Worked Examples

Scenario: Enforcing a "No Public S3 Buckets" Policy Globally

Goal: Ensure that in a 50-account organization, no user can create a public S3 bucket.

1. Define the Guardrail: Create a Service Control Policy (SCP) at the Organization Root that explicitly denies the s3:PutBucketPublicAccessBlock or s3:PutAccountPublicAccessBlock if it's being disabled.
2. Continuous Monitoring: Deploy an AWS Config Managed Rule (s3-bucket-public-read-prohibited) via CloudFormation StackSets to all accounts.
3. Automated Response: Link a Systems Manager Automation document to the Config Rule as a remediation action.
4. Verification: Attempt to create a public bucket in a member account; the action should be blocked by the SCP, and any existing buckets should be flagged and remediated by Config.

Checkpoint Questions

1. Which tool is most appropriate for a developer who wants to use loops and logic to define 100 identical VPC subnets? (Ans: AWS CDK)
2. You need to run a shell script across 500 EC2 instances to check for a specific file. Which SSM capability do you use? (Ans: SSM Run Command)
3. What is the primary difference between a CloudFormation Template and a StackSet? (Ans: A template defines what to build; a StackSet defines where to build it across accounts/regions.)

Muddy Points & Cross-Refs

• SSM State Manager vs. OpsWorks: This is often confusing. Use State Manager for simple, lightweight OS-level configuration and patching. Use OpsWorks (Chef/Puppet) if the organization has an existing investment in those specific configuration DSLs or requires complex recipe-based orchestration.
• Config Rules vs. SCPs: Think of SCPs as the "Prevention" (stopping the action) and Config Rules as the "Detection" (finding and fixing the action after it happened or if it was done by a user with bypass permissions).

Comparison Tables

Configuration Management vs. Infrastructure as Code