AWS for DevOps — Configuration & Secrets Exercises

4 minute read

11.6 — Practice Exercises: Configuration & Secrets

Test your understanding of Parameter Store, Secrets Manager, Session Manager, AWS Config, and Run Command.

Exercise 1 — Organize Parameters

You have an application with three environments (dev, staging, production). Each environment needs: db_host, db_port, cache_host, and feature_new_ui. Design the Parameter Store hierarchy and create the production parameters.

Show Answer

Hierarchy design:

/myapp/
├── dev/
│   ├── db_host
│   ├── db_port
│   ├── cache_host
│   └── feature_new_ui
├── staging/
│   ├── db_host
│   ├── db_port
│   ├── cache_host
│   └── feature_new_ui
└── production/
    ├── db_host
    ├── db_port
    ├── cache_host
    └── feature_new_ui

Create production parameters:

$ aws ssm put-parameter --name "/myapp/production/db_host" \
    --value "prod-db.cluster-abc.rds.amazonaws.com" --type String

$ aws ssm put-parameter --name "/myapp/production/db_port" \
    --value "5432" --type String

$ aws ssm put-parameter --name "/myapp/production/cache_host" \
    --value "prod-redis.abc.cache.amazonaws.com" --type String

$ aws ssm put-parameter --name "/myapp/production/feature_new_ui" \
    --value "false" --type String

# Retrieve all production parameters at once
$ aws ssm get-parameters-by-path \
    --path "/myapp/production/" \
    --recursive

Key point: Your application only needs to know its environment name. It constructs the path prefix /myapp/{ENV}/ and fetches all parameters under it.

Exercise 2 — Store and Rotate a Secret

Store database credentials in Secrets Manager and explain how auto-rotation works. What happens to existing database connections when a secret rotates?

Show Answer 
# Create the secret
$ aws secretsmanager create-secret \
    --name myapp/production/db-creds \
    --secret-string '{
      "username": "app_user",
      "password": "S3cureP@ss!",
      "host": "prod-db.cluster-abc.rds.amazonaws.com",
      "port": 5432,
      "dbname": "myapp"
    }'

# Enable rotation
$ aws secretsmanager rotate-secret \
    --secret-id myapp/production/db-creds \
    --rotation-lambda-arn arn:aws:lambda:ap-south-1:123456789012:function:RotateDBCreds \
    --rotation-rules AutomaticallyAfterDays=30

What happens during rotation:

  1. createSecret — Lambda generates a new password, stores it as AWSPENDING
  2. setSecret — Lambda updates the database user’s password
  3. testSecret — Lambda connects to the database with the new password
  4. finishSecret — Lambda moves AWSPENDING → AWSCURRENT, old becomes AWSPREVIOUS

Impact on existing connections:

  • Existing connections using the old password continue to work (already authenticated)
  • New connections must use the new password
  • Applications should cache credentials briefly (5-15 minutes) and re-fetch on authentication failure

Exercise 3 — Replace SSH with Session Manager

Your team currently uses SSH with bastion hosts to access production instances. Describe the steps to migrate to Session Manager and the security benefits.

Show Answer

Migration steps:

  1. Attach IAM role to all EC2 instances with AmazonSSMManagedInstanceCore policy
  2. Verify SSM Agent is installed and running: 
    $ aws ssm describe-instance-information \
    --filters Key=PingStatus,Values=Online
  3. Enable session logging to S3 and CloudWatch
  4. Test Session Manager access on a few instances
  5. Remove SSH inbound rules from security groups (port 22)
  6. Decommission bastion hosts
  7. Revoke SSH key pairs and update documentation

Security benefits:

Before (SSH) After (Session Manager)
SSH keys to manage and rotate IAM authentication (no keys)
Port 22 open to bastion No inbound ports needed
Bastion host to maintain No bastion needed
No session logging Full session logging to S3/CloudWatch
No audit trail CloudTrail records all sessions
Key sharing risk Fine-grained IAM policies per user

Exercise 4 — Set Up Config Rules

Create three AWS Config rules for a production environment: (1) all S3 buckets must have versioning, (2) no public S3 buckets, and (3) all EBS volumes must be encrypted.

Show Answer 
# Rule 1: S3 versioning required
$ aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "s3-versioning-required",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "S3_BUCKET_VERSIONING_ENABLED"
      },
      "Scope": {
        "ComplianceResourceTypes": ["AWS::S3::Bucket"]
      }
    }'

# Rule 2: No public S3 buckets
$ aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "s3-no-public-read",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
      }
    }'

# Rule 3: EBS volumes encrypted
$ aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "ebs-encrypted",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "ENCRYPTED_VOLUMES"
      }
    }'

# Check compliance after evaluation
$ aws configservice get-compliance-summary-by-config-rule

Bonus: Add auto-remediation to enable S3 versioning automatically:

$ aws configservice put-remediation-configurations \
    --remediation-configurations '[{
      "ConfigRuleName": "s3-versioning-required",
      "TargetType": "SSM_DOCUMENT",
      "TargetId": "AWS-ConfigureS3BucketVersioning",
      "Parameters": {
        "BucketName": {"ResourceValue": {"Value": "RESOURCE_ID"}},
        "VersioningState": {"StaticValue": {"Values": ["Enabled"]}}
      },
      "Automatic": true,
      "MaximumAutomaticAttempts": 3,
      "RetryAttemptSeconds": 60
    }]'

Exercise 5 — Patch Instances with Run Command

You need to apply security patches to all production web servers (tagged Role=web-server, Environment=production). Describe how to do this safely with rate control.

Show Answer 
# Step 1: Check how many instances will be targeted
$ aws ssm describe-instance-information \
    --filters Key=tag:Role,Values=web-server Key=tag:Environment,Values=production \
    --query 'InstanceInformationList[].InstanceId'
# Output: ["i-0abc123", "i-0def456", "i-0ghi789", ...]

# Step 2: Apply patches with rate control
$ aws ssm send-command \
    --targets Key=tag:Role,Values=web-server Key=tag:Environment,Values=production \
    --document-name AWS-RunShellScript \
    --parameters 'commands=["yum update -y --security && echo PATCH_SUCCESS"]' \
    --comment "Security patches - March 2026" \
    --max-concurrency "2" \
    --max-errors "1" \
    --timeout-seconds 600

# Step 3: Monitor results
$ aws ssm list-command-invocations \
    --command-id cmd-abc123 \
    --details

Key safety measures:

  • --max-concurrency "2" — only 2 instances patched at a time (preserves capacity)
  • --max-errors "1" — stop if any instance fails (investigate before continuing)
  • --timeout-seconds 600 — kill the command if it takes more than 10 minutes
  • --comment — document why the command was run
  • Verify with echo PATCH_SUCCESS at the end of the command

Best practice: Run on staging first, then production.

Next Chapter → Advanced Networking

Updated:

You may also enjoy