ExamFinch.com My Study

Study guide

6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

Practice this exam

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

Key Takeaways Explain This Topic AI

SSM Patch Manager enforces operating system compliance using Patch Baselines with auto-approval delays, explicit approved/rejected patch lists, and compliance severity thresholds.

Patch Groups map instances to distinct patch baselines using the exact tag key 'Patch Group', enabling phased deployment schedules across development, staging, and production fleets.

Maintenance Windows orchestrate patching operations with defined Schedule, Duration, and Cutoff parameters, preventing new tasks from initiating as the window nears completion.

Parameter Store and AWS Secrets Manager serve distinct architectural roles: Secrets Manager provides native, Lambda-driven automated credential rotation and resource-based cross-account policies, while Parameter Store provides hierarchical, low-cost configuration storage.

AWS AppConfig safely deploys dynamic application configurations at runtime, incorporating JSON Schema and Lambda validators, gradual deployment strategies (linear and canary), bake times, and automatic CloudWatch alarm-driven rollbacks.

Last updated: September 2026

SSM Patch Manager: Automated Fleet Patching & Compliance

Maintaining current security patches across heterogeneous operating system fleets is essential for regulatory compliance and vulnerability management. AWS Systems Manager Patch Manager automates the process of scanning, approving, and installing operating system and security patches across Amazon EC2 and hybrid instances at scale.

Patch Baselines: Rules, Approval Delays, and Overrides

A Patch Baseline defines which patches are approved for installation on your managed instances. Systems Manager provides predefined AWS baselines (e.g., AWS-AmazonLinux2DefaultPatchBaseline , AWS-UbuntuDefaultPatchBaseline , AWS-WindowsDefaultPatchBaseline ), but enterprise governance typically requires Custom Patch Baselines .

A custom patch baseline consists of four core elements:

Approval Rules : Define criteria for automatic patch approval based on:

Product : Operating system release (e.g., Amazon Linux 2023, Ubuntu 22.04, Windows Server 2022).

Classification : Patch category (e.g., Security , Bugfix , Enhancement , Recommended ).

Severity : Vendor severity rating (e.g., Critical , Important , Medium , Low ).

Auto-Approval Delay : The number of days to wait after a vendor publishes a patch before it becomes automatically approved (e.g., 7 days ). This buffer allows DevOps teams to test patches in development and staging environments before automated production rollout.

Explicit Approved Patches List : Patches explicitly approved regardless of approval rules. Used for emergency zero-day CVE remediation to bypass the 7-day delay.

Explicit Rejected Patches List : Patches explicitly prohibited from installation, even if they match approval rules. Essential for blocking known buggy packages, breaking kernel revisions (e.g., kernel-5.15* ), or unvalidated dependencies. [ Patch Release from Vendor ]

  • │
  • ├──> Is patch in Rejected List? ───────> YES ──> DO NOT INSTALL (Blocked)
  • │ │ (NO)
  • ├──> Is patch in Approved List? ───────> YES ──> APPROVE IMMEDIATELY (Zero-Day)
  • │ │ (NO)

└──> Matches Classification & Severity?

  • │ (YES)
  • └──> Has Auto-Approval Delay Elapsed? (e.g., 7 Days)
  • ├── YES ──> APPROVED
  • └── NO ──> PENDING (Wait for delay)
  • Patch Groups: Associating Instances with Baselines

To apply different patch policies to different environments (e.g., approving patches with a 0-day delay in Development, but a 10-day delay in Production), use Patch Groups :

Instances are assigned to a patch group by attaching an EC2 tag with the exact key Patch Group (case-sensitive!). The tag value represents the patch group name (e.g., Web-Production , Database-Staging ).

In Patch Manager, the patch baseline is registered to that specific patch group name.

Cardinality Rule : An instance can belong to only one patch group . A patch baseline can be associated with multiple patch groups , but a patch group can only be registered to one patch baseline per operating system type .

Maintenance Windows: Duration vs. Cutoff Mechanics

Patch installation should not occur during peak traffic hours. Maintenance Windows define scheduled blocks of time during which disruptive tasks (such as package updates and reboots) can execute. A Maintenance Window consists of four structural parameters:

Parameter Definition Typical Value

Schedule A cron or rate expression defining when the window opens (supports time zones). cron(0 2 ? * SUN *) (Sundays at 02:00 UTC)

Duration The total duration of the maintenance window in hours. 4 hours

Cutoff The number of hours before the end of the window when Systems Manager stops scheduling new task invocations. 1 hour

Registered Targets & Tasks The target instances (by Patch Group tag or Resource Group) and the registered task (e.g., AWS-RunPatchBaseline ). Task: Operation=Install , RebootOption=RebootIfNeeded

Important

The Duration vs. Cutoff Rule : If a maintenance window has a Duration of 4 hours and a Cutoff of 1 hour, tasks can only initiate during the first 3 hours (02:00 to 05:00). At the 3-hour mark (05:00), the cutoff begins; Systems Manager will not dispatch any new tasks. Currently running tasks are permitted to complete during the final hour until the window closes at 06:00.

Scanning vs. Installing: Compliance Reporting

The AWS-RunPatchBaseline command document accepts an Operation parameter with two modes:

Scan : Inspects the instance against the assigned baseline, generates a compliance inventory of installed, missing, and failed patches, and publishes the results to Systems Manager Compliance and AWS Config without modifying installed packages.

Install : Resolves approved patches, downloads and installs them, and performs a reboot if RebootOption is set to RebootIfNeeded .

Loading diagram... AWS AppConfig Deployment, Validation & Automated Rollback Architecture

Systems Manager Parameter Store vs. AWS Secrets Manager

Managing application configuration and sensitive credentials requires choosing between two core AWS services: AWS Systems Manager Parameter Store and AWS Secrets Manager . On the AWS DevOps Professional exam, selecting the correct service depends on specific functional requirements, including automated rotation, cross-account sharing, value size limits, and cost profile.

Comprehensive Decision Matrix

Architectural Dimension SSM Parameter Store (Standard Tier) SSM Parameter Store (Advanced Tier) AWS Secrets Manager

Primary Purpose Hierarchical application configuration and simple secrets High-throughput application configuration with TTL policies Sensitive secrets, database credentials, API keys with rotation

  • Storage Cost Free (no storage charge) $0.05 per parameter per month $0.40 per secret per month
  • API Request Cost Standard throughput is free $0.05 per 10,000 API requests $0.05 per 10,000 API requests
  • Max Value Size 4 KB 8 KB 64 KB
  • Max Parameters / Secrets Up to 10,000 per region/account Up to 100,000 per region/account Unlimited secrets

Automated Secret Rotation No native rotation engine (requires custom EventBridge + Lambda) No native rotation engine (requires custom EventBridge + Lambda) Native out-of-the-box rotation via managed Lambda templates

Cross-Account Sharing No resource-based policies; requires IAM role assumption Supports sharing via AWS RAM, but no resource-based policies Supports resource-based policies attached directly to secrets

Parameter Policies / TTL Not supported Supported : Expiration , ExpirationNotification , NoChangeNotification Rotation intervals natively managed

KMS Encryption Plaintext ( String , StringList ) or KMS SecureString Plaintext or KMS SecureString Always encrypted via AWS KMS CMK or default key

Automated Rotation Lifecycle in Secrets Manager

The fundamental differentiator between Parameter Store and Secrets Manager is Secrets Manager's native automated rotation engine. When configured (e.g., every 30 days), Secrets Manager invokes a dedicated AWS Lambda rotation function that coordinates a 4-step rotation protocol :

createSecret : The Lambda function generates a new random password and stores it in Secrets Manager under the staging label AWSPENDING . The current production secret remains untouched under AWSCURRENT .

setSecret : The Lambda function connects to the target database (e.g., Amazon RDS Aurora PostgreSQL) using existing superuser credentials and alters the target user's password to match the AWSPENDING credential.

testSecret : The Lambda function opens a fresh connection to the database using the new AWSPENDING credentials to verify that authentication succeeds.

finishSecret : The Lambda function moves the AWSCURRENT version staging label to the newly validated secret version. The previous version receives the label AWSPREVIOUS . This supports rotation without planned downtime when the application refreshes credentials and handles the transition correctly.

Rotation Strategies : Secrets Manager supports Single-User rotation (updating the secret in place, with a momentary authentication blip) and Multi-User rotation (alternating between two user accounts, e.g., user_a and user_b , ensuring 100% uninterrupted zero-downtime database access).

Hierarchical Organization & Dynamic References

Parameter Store uses forward slashes to organize configuration into trees (e.g., /ecommerce/production/database/endpoint ). Applications can retrieve entire configuration trees in a single API call using GetParametersByPath with --recursive .

CloudFormation templates can dynamically resolve parameters and secrets without hardcoding sensitive strings or passing parameters as plaintext: Resources:

AppDatabase:

Type: AWS::RDS::DBInstance

Properties:

  • MasterUsername: '{{resolve:ssm:/app/prod/db/user}}'
  • MasterUserPassword: '{{resolve:secretsmanager:app/prod/db/creds:SecretString:password}}'
  • AWS AppConfig: Runtime Configuration & Automated Rollbacks

Traditional application configuration changes (such as toggling feature flags, changing rate limits, or updating routing endpoints) frequently require re-deploying code artifacts or restarting container tasks. AWS AppConfig , a capability of AWS Systems Manager, enables runtime configuration deployment with zero application downtime, automated validation, and safety guardrails.

AppConfig Structural Hierarchy

Application : The logical boundary representing your application (e.g., PaymentService ).

Environment : A deployment environment (e.g., Development , Staging , Production ).

Configuration Profile : Defines the source and schema of the configuration data. Sources include AppConfig hosted store, SSM Parameter Store, Systems Manager Documents, Amazon S3, or AWS CodeCommit.

Dual-Layer Validation Gates

Before AppConfig deploys a new configuration version, it passes the data through mandatory validation gates to prevent syntax errors or invalid business states from entering production:

Syntactic Validators (JSON Schema / YAML Schema) : Validates structural formatting, required keys, integer ranges, and regex patterns (e.g., ensuring max_connections is an integer between 1 and 500).

Semantic Validators (AWS Lambda Function) : Executes programmatic business logic against the new configuration. For example, a Lambda validator can verify that an updated external payment gateway URL responds to health checks before approving the deployment.

Deployment Strategies & Bake Time

An AppConfig Deployment Strategy controls how rapidly the configuration is distributed across the target infrastructure:

Growth Type : Linear (distributes fixed percentage increments over time) or Exponential (canary ramp-up).

Step Percentage : The percentage of targets that receive the configuration at each interval (e.g., 20%).

Deployment Duration : The total time across which the step percentages are applied (e.g., 20 minutes).

Bake Time (Soak Time) : A mandatory observation period after 100% of the configuration has been deployed (e.g., 15 minutes). AppConfig monitors attached Amazon CloudWatch alarms throughout the entire deployment duration and the bake time.

Automated Rollback via CloudWatch Alarms

You can associate one or more Amazon CloudWatch Alarms (such as HTTP 5xx error rate, synthetic canary failure, or latency spikes) with an AppConfig Environment. If any associated alarm transitions into the ALARM state at any point during deployment or bake time, AppConfig immediately initiates an automated rollback , reverting all clients to the previous known good configuration version.

Client Caching & AWS AppConfig Agent

Applications retrieve configuration via the AWS AppConfig Agent (running as a local sidecar container in Amazon ECS/EKS or local daemon on EC2) or SDK extensions. The agent polls AppConfig periodically, caches configuration locally in memory, and serves data to the application over localhost HTTP with sub-millisecond latency . If the configuration has not changed, AppConfig returns an HTTP 304 Not Modified status, eliminating unnecessary data transfer costs and API throttling.