AWS Configuration Management & Systems Administration

This study guide focuses on the tools and strategies required for maintaining operational excellence and security through configuration management in complex, multi-account AWS environments, specifically aligned with the SAP-C02 exam.

Learning Objectives

• Design comprehensive configuration management strategies using AWS Systems Manager and AWS Config.
• Evaluate when to use AWS OpsWorks (Chef/Puppet) versus AWS Systems Manager for application-level configuration.
• Implement automated patching and remediation workflows to maintain compliance.
• Architect multi-account change management processes that include automated approval flows and templates.
• Differentiate between standard, normal, and emergency change types within an enterprise context.

Key Terms & Glossary

• Configuration Drift: The phenomenon where the running state of a resource deviates from its intended or initial configuration.
• SSM Document: A JSON or YAML file that defines the actions that Systems Manager performs on your managed instances.
• Feature Flag: A technique that allows you to enable or disable features in a runtime environment without redeploying code (supported by SSM AppConfig).
• State Manager: An SSM capability that automates the process of keeping managed instances in a defined state (e.g., ensuring specific software is always installed).
• Managed Node: Any machine (EC2, on-premises server, or VM) that has been configured for use with AWS Systems Manager.

The "Big Idea"

[!IMPORTANT] Configuration management in AWS is about transitioning from Snowflake Servers (manually configured, unique, and fragile) to Immutable or Automated Infrastructure. The goal is to ensure that every change is recorded, every state is enforceable, and manual intervention is replaced by automated, auditable workflows.

Formula / Concept Box

Hierarchical Outline

1. AWS Systems Manager (SSM) Ecosystem
   • Node Management: Patch Manager (baselines), Inventory, and State Manager.
   • Change Management: Change Manager (approvals) and Maintenance Windows.
   • Application Management: AppConfig (runtime shifts) and Parameter Store (secrets/config).
2. Compliance & Governance
   • AWS Config: Continuous monitoring, recording configuration history, and "Aggregators" for multi-account views.
   • Remediation: Using Systems Manager Automation documents to fix non-compliant resources identified by AWS Config.
3. Third-Party Integration (OpsWorks)
   • Managed Chef Automate/Puppet Enterprise: Full server management without the overhead of patching the Chef/Puppet server.
   • OpsWorks Stacks: Legacy stack-based management using Chef Solo.
4. Operational Change Flows
   • Standard: Pre-approved, low-risk changes.
   • Normal: Requires full review and approval.
   • Emergency: High-priority, bypasses standard timelines but requires post-mortem.

Visual Anchors

Automated Remediation Flow

This diagram illustrates how AWS Config and SSM work together to maintain compliance.

Systems Manager Architecture

A simplified view of how the SSM Agent interacts with the AWS Cloud.

\begin{tikzpicture} [node distance=2cm, box/.style={rectangle, draw, minimum width=3cm, minimum height=1cm, text centered}] \node (cloud) [box] {AWS Systems Manager}; \node (agent) [box, below of=cloud] {SSM Agent}; \node (ec2) [box, below of=agent] {EC2 Instance / On-Prem};

\end{tikzpicture}

Definition-Example Pairs

• Parameter Store: A secure, hierarchical storage for configuration data and secrets.
  • Example: Storing a database connection string as a "SecureString" that an EC2 instance fetches at runtime using its IAM role.
• Patch Baseline: A set of rules that define which patches are approved for installation on your instances.
  • Example: A baseline that auto-approves all "Critical" security updates for Amazon Linux 2 exactly 7 days after release.
• Config Aggregator: A resource type that collects AWS Config data from multiple accounts and regions into a single account.
  • Example: A central Security account using an aggregator to view the compliance status of S3 buckets across 50 different sub-accounts in an AWS Organization.

Worked Example: Automating a Patch Window

Scenario: You need to ensure all Production Web Servers are patched every Saturday at 2 AM without manual intervention.

1. Tagging: Ensure all target instances have the tag Environment: Production and Role: WebServer.
2. Create Patch Baseline: Define a baseline that approves security patches for your specific OS.
3. Define Maintenance Window:
   • Schedule: cron(0 2 ? * SAT *).
   • Targets: Use the tags defined in step 1.
   • Task: Assign the AWS-RunPatchBaseline task to this window.
4. Execution: At 2 AM, SSM automatically identifies the instances, locks them for maintenance (if configured), applies patches, and reboots if necessary.

Checkpoint Questions

1. What is the main difference between AWS Systems Manager Parameter Store and AWS Secrets Manager? (Answer: Secrets Manager supports built-in rotation for RDS; Parameter Store is more general-purpose and cost-effective for non-rotating data).
2. How does AWS Config handle "Auto-Remediation"? (Answer: Through integration with SSM Automation documents).
3. Which service would you choose to manage a legacy environment using existing Chef recipes? (Answer: AWS OpsWorks for Chef Automate or OpsWorks Stacks).
4. What SSM feature allows you to manage changes across multiple accounts/regions with approval steps? (Answer: SSM Change Manager).

Muddy Points & Cross-Refs

• SSM vs. Config: This is the most common confusion. Think: SSM is for Doing (patching, running commands, updating), while Config is for Watching (auditing history, checking compliance). They are often used together.
• OpsWorks Stacks vs. Chef Automate: Stacks is the legacy, "built-in" AWS way to use Chef Solo. Chef Automate is a managed version of the actual Chef Enterprise server. For SAP-C02, assume Chef Automate/Puppet Enterprise for modern requirements.
• Blue/Green Deployment: While SSM can facilitate this, also cross-reference AWS CodeDeploy, which is the primary service for deployment orchestration.

Comparison Tables

Configuration Management Tool Comparison