This chapter covers AWS AppConfig, a feature of AWS Systems Manager that enables you to create, manage, and deploy feature flags and application configurations independently of code deployments. For the DVA-C02 exam, AppConfig appears in Domain 3 (Deployment) under Objective 3.2: 'Deploy and manage feature flags and configuration data using AWS AppConfig.' While not a massive topic, it typically appears in 2-3 questions, often as part of a larger scenario involving safe deployments, rollback, or decoupling config from code. Understanding AppConfig's core mechanisms — configuration profiles, environments, hosted configuration versions, validators, and deployment strategies — is essential to answering these questions correctly.
Jump to a section
Imagine you are the captain of a massive cargo ship with hundreds of systems: engines, navigation, cargo cranes, ballast tanks, and communication arrays. Each system has dozens of configurable parameters — engine RPM limits, crane load thresholds, radio frequencies. You cannot afford to stop the ship and rewire everything every time you need to change a setting. Instead, the ship has a central control panel with switches, dials, and levers. You flip a switch to enable a new navigation algorithm, turn a dial to adjust engine timing, or pull a lever to activate emergency ballast pumps. The control panel is connected to each system via a dedicated signaling network that delivers the new settings instantly without requiring any system restart. Importantly, the control panel has a validation layer: if you try to set an engine RPM beyond safe limits, the panel refuses and alerts you. It also has a rollback mechanism: if a new setting causes a vibration, you can flip the switch back to the previous position and the old configuration is restored immediately. AWS AppConfig works exactly like this control panel for your software systems. You define configurations (feature flags, allowlists, tuning parameters) in a central location, deploy them to your applications without code changes or redeploys, validate them with checks like JSON schema or Lambda functions, and can roll back instantly if something goes wrong. The applications poll AppConfig or receive pushed updates, applying the new settings on the fly without restarting.
What is AWS AppConfig and Why Does It Exist?
AWS AppConfig is a managed service that decouples configuration from application code, allowing you to change application behavior at runtime without deploying new code or restarting the application. It is a feature of AWS Systems Manager, but it can be used independently. The primary use cases are: - Feature flags: Toggle features on/off for subsets of users (canary deployments, A/B testing). - Allow/block lists: Update IP allowlists or deny lists in real time. - Tuning parameters: Adjust database connection pool sizes, cache TTLs, or logging levels without a redeploy. - Safety mechanisms: Validate configuration before deployment, monitor for errors, and automatically roll back if problems are detected.
AppConfig is designed for production systems where configuration changes must be fast, safe, and auditable. It is not a general-purpose key-value store like Parameter Store or Secrets Manager; it is specifically for deploying configuration changes in a controlled, gradual manner with built-in validation and rollback.
How AppConfig Works Internally
AppConfig operates through a set of core resources:
- Application: A logical container for configurations. Each AppConfig application can have multiple configuration profiles and environments. - Configuration Profile: Defines the type of configuration (feature flag, freeform) and its source. Sources can be: - AppConfig Hosted Configuration: Store configuration directly in AppConfig as a versioned document (max 1 MB per version, 2 MB for feature flags). - AWS AppConfig Agent: A sidecar that polls AppConfig and caches configurations locally (for EC2, ECS, EKS, Lambda). - External sources: SSM Parameter Store, SSM Document, S3, or a Lambda function that returns configuration. - Environment: A logical deployment stage (e.g., Development, Testing, Production). Each environment can have its own deployment strategy and monitors. - Configuration Version: A specific revision of the configuration data. Every time you save a new configuration, AppConfig creates a new version. - Deployment Strategy: Defines how quickly the configuration is rolled out, including: - Growth Type: Linear, Exponential, or Canary. - Growth Factor: Percentage of targets to receive the new config per step (e.g., 10%, 25%). - Deployment Duration: Total time over which the deployment occurs (e.g., 15 minutes). - Final Bake Time: Time after full deployment before the deployment is considered complete (e.g., 5 minutes). - Validator: A check that runs before deployment. Two types: - JSON Schema: Validates the configuration payload against a JSON Schema definition. - AWS Lambda: A custom validator function that can perform any check (e.g., call an external API, verify format). - Monitor: An Amazon CloudWatch alarm that, if triggered during a deployment, causes an automatic rollback.
The Deployment Flow
Create or update a configuration version in the configuration profile.
Start a deployment specifying the configuration profile, environment, configuration version, and deployment strategy.
AppConfig validates the configuration (if validators are defined). If validation fails, the deployment is rejected immediately.
AppConfig deploys the configuration to the environment following the deployment strategy's growth type and timing. For example, a linear deployment with 10% growth factor and 10-minute duration would deploy to 10% of targets every minute.
Targets (applications) receive the new configuration either by polling AppConfig or via the AppConfig Agent, which pushes updates.
During deployment, AppConfig monitors the CloudWatch alarm specified as the monitor. If the alarm enters ALARM state, AppConfig automatically rolls back the deployment to the previous version.
After full deployment and final bake time, the deployment is marked as Completed.
Configuration Sources: Hosted vs. External
AppConfig Hosted Configuration: Configuration is stored as a versioned document within AppConfig. Max size: 1 MB for freeform config, 2 MB for feature flags. You can create up to 1,000 versions per configuration profile. This is the simplest source and often used for feature flags.
SSM Parameter Store: You can reference an SSM Parameter Store parameter as the source. The parameter can be of type String, StringList, or SecureString. AppConfig retrieves the parameter value when starting a deployment.
SSM Document: A Systems Manager document (e.g., JSON/YAML) can be used.
S3: An object in S3 (plain text or JSON) can be the source. AppConfig needs read access to the S3 bucket.
Lambda: A Lambda function returns the configuration as a JSON payload. This allows dynamic generation of configuration at deployment time.
Feature Flags vs. Freeform Configuration
When you create a configuration profile, you choose either: - Feature flag: A structured configuration where you define flags with a type (boolean, percentage, or string). AppConfig provides a UI to toggle flags and assign percentages to user cohorts. This is ideal for feature toggles and canary deployments. - Freeform: Any JSON or YAML document. This is for any other configuration (allowlists, tuning parameters).
AppConfig Agent
The AppConfig Agent is a sidecar process that runs alongside your application on EC2, ECS, EKS, or Lambda (via the Lambda extension). It:
Polls AppConfig every 30 seconds (configurable) for configuration updates.
Caches the latest configuration locally.
Provides a local HTTP endpoint (port 2772 by default) for your application to retrieve configuration.
Reduces latency and load on AppConfig API.
Supports automatic polling and caching of multiple configuration profiles.
IAM Permissions
To use AppConfig, you need specific IAM permissions:
- appconfig:* or more granular actions like appconfig:StartDeployment, appconfig:GetConfiguration, appconfig:CreateConfigurationProfile.
- For external sources: ssm:GetParameter, s3:GetObject, lambda:InvokeFunction.
- For monitors: cloudwatch:DescribeAlarms.
Pricing
AppConfig charges per configuration profile per environment per month, plus per deployment. As of 2025, pricing is $0.05 per configuration profile per environment per month, and $0.10 per deployment. The AppConfig Agent is free. There are no charges for hosted configuration storage or API calls (though standard data transfer rates apply).
Integration with Other Services
AWS Lambda: Use the AppConfig Lambda extension to retrieve configurations without polling. The extension runs as a separate Lambda layer.
Amazon ECS/EKS: Run the AppConfig Agent as a sidecar container.
AWS CloudFormation: You can define AppConfig resources in CloudFormation templates.
AWS CloudTrail: All AppConfig API calls are logged in CloudTrail for auditing.
Amazon CloudWatch: Monitor deployment health and set alarms for automatic rollback.
Common Commands
Using the AWS CLI:
# Create an application
aws appconfig create-application --name MyApp
# Create a configuration profile (hosted, feature flag)
aws appconfig create-configuration-profile \
--application-id <app-id> \
--name MyFeatureFlags \
--location-uri hosted \
--type AWS.AppConfig.FeatureFlags
# Create an environment
aws appconfig create-environment \
--application-id <app-id> \
--name Production \
--monitors "MonitorArn=arn:aws:cloudwatch:us-east-1:123456789012:alarm:MyAlarm,AlarmRoleArn=arn:aws:iam::123456789012:role/AppConfigMonitorRole"
# Create a deployment strategy
aws appconfig create-deployment-strategy \
--name LinearTenPercent \
--growth-type LINEAR \
--growth-factor 10 \
--deployment-duration-in-minutes 10 \
--final-bake-time-in-minutes 5
# Create a hosted configuration version
aws appconfig create-hosted-configuration-version \
--application-id <app-id> \
--configuration-profile-id <profile-id> \
--content-type application/json \
--content '{"feature_x": true}'
# Start a deployment
aws appconfig start-deployment \
--application-id <app-id> \
--environment-id <env-id> \
--configuration-profile-id <profile-id> \
--configuration-version <version-number> \
--deployment-strategy-id <strategy-id>
# Get configuration (from application)
aws appconfig get-configuration \
--application <app-name> \
--environment <env-name> \
--configuration <profile-name> \
--client-id <unique-client-id>Best Practices
Always use validators (JSON Schema or Lambda) to catch malformed configurations before deployment.
Use monitors with CloudWatch alarms to detect application errors after configuration changes.
Start with a canary deployment strategy to test changes on a small percentage of hosts first.
Use the AppConfig Agent to reduce latency and API calls in production.
Version your configurations and keep a history for auditing and rollback.
For feature flags, use percentage-based toggles to gradually expose new features to users.
Edge Cases and Limitations
Configuration size limit: 1 MB for freeform, 2 MB for feature flags (hosted). For larger configs, use an external source like S3.
Version limit: 1,000 versions per configuration profile. After that, you must delete old versions.
Deployment strategy growth factor must be between 1% and 100%.
Deployment duration can be from 0 to 1440 minutes (24 hours).
Final bake time can be from 0 to 1440 minutes.
If you use a Lambda validator, the Lambda function must complete within 30 seconds.
The AppConfig Agent polls every 30 seconds by default; you can configure it via environment variables.
AppConfig does not support real-time push; applications must poll or use the agent.
Define the Application and Configuration
Start by creating an AppConfig application to group related configurations. Then create a configuration profile within that application. Choose the source type: hosted (for simple configs stored in AppConfig) or external (SSM Parameter Store, S3, Lambda). For feature flags, select the type 'AWS.AppConfig.FeatureFlags'. Define the configuration data as a JSON document. For hosted config, use the create-hosted-configuration-version API call. The configuration is versioned automatically.
Create Environments and Deployment Strategy
Create one or more environments (e.g., Dev, Test, Prod) to represent deployment stages. Each environment can have its own monitors (CloudWatch alarms) for automatic rollback. Then define a deployment strategy that controls the rollout pace: linear (same percentage each step), exponential (percentage doubles each step), or canary (a small percentage first, then full rollout). Specify the growth factor (e.g., 10%), total duration (e.g., 15 minutes), and final bake time (e.g., 5 minutes).
Add Validators to Configuration Profile
To ensure configuration correctness, add validators to the configuration profile. You can use a JSON Schema validator to check the structure of the configuration document. Alternatively, use a Lambda function that performs custom validation (e.g., checking values against a database). Validators run at deployment start. If validation fails, the deployment is rejected and an error is returned. This prevents deploying broken configurations.
Start a Deployment
Initiate a deployment by calling StartDeployment with the application ID, environment ID, configuration profile ID, configuration version number, and deployment strategy ID. AppConfig validates the configuration (if validators are attached). If valid, it begins rolling out the configuration to the environment's targets following the deployment strategy. The deployment transitions through states: BOOTSTRAPPING, DEPLOYING, DEPLOYED, COMPLETE (or ROLLED_BACK).
Monitor Deployment and Rollback if Needed
During the deployment, AppConfig monitors the CloudWatch alarm(s) specified in the environment. If the alarm enters ALARM state, AppConfig automatically rolls back the deployment to the previous configuration version. You can also manually stop a deployment using StopDeployment. After the deployment reaches 100% and the final bake time elapses, it completes successfully. The new configuration is now active.
Retrieve Configuration in Application
Applications retrieve the configuration by calling GetConfiguration (for direct polling) or using the AppConfig Agent (recommended). The Agent polls AppConfig every 30 seconds and caches the latest configuration. The application queries the Agent's local HTTP endpoint (http://localhost:2772/applications/{app}/environments/{env}/configurations/{profile}) to get the current configuration. The Agent automatically returns the new configuration after a deployment completes.
Enterprise Scenario 1: E-Commerce Feature Flag for Checkout Flow
A large e-commerce company wants to test a new checkout flow with 5% of users before full rollout. They create an AppConfig feature flag named 'new_checkout' with type percentage. They define a configuration profile with a hosted configuration containing the flag. They set up three environments: Dev, Staging, and Production. For Production, they create a deployment strategy with a canary step: initially deploy to 5% of hosts, wait 10 minutes, then deploy to 100%. They add a monitor CloudWatch alarm that tracks checkout error rate. If the error rate spikes, the deployment auto-rolls back. The application polls the AppConfig Agent every 30 seconds. Once the deployment starts, 5% of instances receive the new flag value, enabling the new checkout. After 10 minutes with no alarm, the rest get the flag. This allows safe feature testing without redeploying code.
Enterprise Scenario 2: Dynamic IP Allowlist for a SaaS Platform
A SaaS platform needs to update IP allowlists frequently to block malicious traffic or add new client IPs. They store the allowlist as a freeform JSON document in AppConfig hosted configuration. They have a Lambda function that validates the IP format against CIDR notation. They deploy changes to Production using a linear strategy over 5 minutes. The application runs on ECS with the AppConfig Agent sidecar. When a new allowlist is deployed, the Agent picks it up and the application reloads the list without restarting. If a malformed IP is detected by the validator, the deployment is rejected before any instance gets the bad config. If a deployment causes a spike in blocked requests (monitored via CloudWatch), the alarm triggers an automatic rollback to the previous allowlist.
Common Pitfalls
Not using validators: Deploying a malformed config can break all instances. Validators catch this early.
Forgetting to set a monitor: Without a CloudWatch alarm, AppConfig cannot auto-rollback, leading to prolonged outages.
Using too large a growth factor: Deploying to 100% immediately defeats the purpose of gradual rollout. Start small.
Not using the AppConfig Agent: Direct polling increases latency and API costs. The agent reduces both.
Confusing AppConfig with Parameter Store: AppConfig is for deploying configuration changes with validation and rollback; Parameter Store is for storing static or dynamic configuration without deployment controls.
What DVA-C02 Tests on AppConfig
The DVA-C02 exam covers AppConfig under Domain 3: Deployment, Objective 3.2: 'Deploy and manage feature flags and configuration data using AWS AppConfig.' You should expect 1-2 scenario-based questions that test your understanding of:
The purpose of AppConfig and when to use it vs. Parameter Store or Secrets Manager.
The components: application, configuration profile, environment, deployment strategy, validator, monitor.
The deployment flow: validation, gradual rollout, monitoring, rollback.
How to use feature flags (percentage toggles) for canary deployments.
The AppConfig Agent and its benefits.
Common Wrong Answers and Why
'Use Parameter Store instead of AppConfig for feature flags.' Wrong because Parameter Store does not have built-in deployment strategies, validators, or automatic rollback. It is for storing configuration, not deploying it safely.
'AppConfig requires application restart to apply new configuration.' Wrong because AppConfig is designed for dynamic configuration at runtime without restart. The AppConfig Agent or polling allows live updates.
'AppConfig can automatically push configuration to applications in real time.' Wrong because AppConfig does not use push; it relies on polling (by the application or agent) with a 30-second interval. It is near real-time, not real-time.
'Validators are optional but recommended.' While technically optional, the exam emphasizes that validators are critical for safety. Questions may ask what happens if no validator is attached — the answer is that the deployment proceeds without validation.
'Deployment strategies can be changed mid-deployment.' Wrong. Once a deployment starts, you cannot change the strategy. You must stop and restart with a new strategy.
Specific Numbers and Terms to Memorize
Hosted configuration size limit: 1 MB (freeform), 2 MB (feature flags).
Maximum versions per configuration profile: 1,000.
Growth factor range: 1% to 100%.
Deployment duration range: 0 to 1440 minutes.
Final bake time range: 0 to 1440 minutes.
AppConfig Agent default polling interval: 30 seconds.
Validator types: JSON Schema and AWS Lambda.
Deployment states: BOOTSTRAPPING, DEPLOYING, DEPLOYED, COMPLETE, ROLLED_BACK.
Pricing: $0.05 per config profile per environment per month, $0.10 per deployment.
Edge Cases the Exam Loves
What happens if a validator fails? The deployment is rejected, and the previous configuration remains active.
What happens if the monitor alarm triggers? The deployment rolls back automatically.
Can you use AppConfig with Lambda? Yes, via the AppConfig Lambda extension (a Lambda layer).
Can you use AppConfig with on-premises servers? Not directly; the agent runs on EC2, ECS, EKS, or Lambda. For on-prem, you can poll the API.
How does the application know which configuration to use? It uses the client-id in GetConfiguration, which identifies the application instance.
How to Eliminate Wrong Answers
If the scenario mentions 'gradual rollout,' 'validation before deployment,' or 'automatic rollback,' the answer is likely AppConfig.
If the scenario mentions 'store database passwords,' the answer is Secrets Manager.
If the scenario mentions 'store configuration for many applications without deployment controls,' the answer is Parameter Store.
If the scenario mentions 'real-time updates,' look for AppConfig with Agent (still not real-time, but near real-time).
If the scenario mentions 'zero-downtime deployment without code change,' AppConfig is the correct service.
AppConfig decouples configuration from code, enabling dynamic configuration changes without redeployment.
Core components: Application, Configuration Profile, Environment, Deployment Strategy, Validator, Monitor.
Configuration sources: Hosted (AppConfig), SSM Parameter Store, SSM Document, S3, Lambda.
Hosted configuration size limits: 1 MB (freeform), 2 MB (feature flags). Max 1,000 versions per profile.
Deployment strategies: Linear, Exponential, Canary. Growth factor 1-100%, duration 0-1440 min, final bake 0-1440 min.
Validators run before deployment; if validation fails, deployment is rejected.
Monitors (CloudWatch alarms) trigger automatic rollback if alarm enters ALARM state.
AppConfig Agent polls every 30 seconds and caches configurations locally; reduces latency and API calls.
IAM permissions needed: appconfig:* plus permissions for external sources (ssm:GetParameter, s3:GetObject, lambda:InvokeFunction).
Pricing: $0.05 per config profile per environment per month, $0.10 per deployment.
These come up on the exam all the time. Here's how to tell them apart.
AWS AppConfig
Designed for deploying configuration changes with validation and rollback.
Supports gradual rollout strategies (linear, exponential, canary).
Built-in validators (JSON Schema and Lambda).
Automatic rollback via CloudWatch alarms.
Pricing per configuration profile and deployment.
AWS Systems Manager Parameter Store
Designed for storing configuration data and secrets.
No deployment strategies; changes are immediate and global.
No built-in validation of configuration values.
No automatic rollback; manual revert required.
Pricing per parameter (standard and advanced tiers).
Mistake
AppConfig is the same as AWS Systems Manager Parameter Store.
Correct
AppConfig and Parameter Store are different services. Parameter Store is a hierarchical key-value store for configuration data and secrets, but it lacks deployment strategies, validators, and automatic rollback. AppConfig is specifically designed for safe, gradual deployment of configuration changes with validation and rollback.
Mistake
AppConfig pushes configuration changes to applications in real time.
Correct
AppConfig does not use push technology. Applications must poll AppConfig (or use the AppConfig Agent) to retrieve configuration updates. The default polling interval is 30 seconds, so updates are near real-time, not instantaneous.
Mistake
AppConfig requires applications to restart to apply new configuration.
Correct
AppConfig is designed for dynamic configuration changes without restart. The application or AppConfig Agent retrieves the new configuration and applies it at runtime. No restart or redeployment is needed.
Mistake
You can only use AppConfig with AWS Lambda.
Correct
AppConfig works with any application running on EC2, ECS, EKS, Lambda, or on-premises (via API polling). The AppConfig Agent is available for EC2, ECS, EKS, and as a Lambda extension.
Mistake
AppConfig can only store feature flags.
Correct
AppConfig supports both feature flags (structured toggles) and freeform configuration (any JSON/YAML document). It can store allowlists, tuning parameters, and any other configuration data.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AppConfig is for deploying configuration changes with validation, gradual rollout, and automatic rollback. Parameter Store is for storing configuration data and secrets without deployment controls. Use AppConfig when you need to safely change configuration in production; use Parameter Store for static or hierarchical key-value storage.
No, AppConfig does not push updates in real time. Applications must poll the AppConfig API or use the AppConfig Agent, which polls every 30 seconds by default. Updates are near real-time, typically within 30 seconds of deployment completion.
Yes, you can use the AppConfig Lambda extension, which is a Lambda layer that runs the AppConfig Agent. The extension polls AppConfig and caches configuration, providing a local HTTP endpoint for your Lambda function to retrieve configuration.
Add validators to your configuration profile. You can use a JSON Schema validator to enforce structure, or a Lambda function for custom validation. Validators run at deployment start; if validation fails, the deployment is rejected.
If you have configured a CloudWatch alarm as a monitor in the environment, AppConfig will automatically roll back the deployment if the alarm enters ALARM state. You can also manually stop the deployment using the StopDeployment API.
Yes, by using a deployment strategy with a growth factor less than 100%. For example, a canary strategy deploys to a small percentage first, then after a bake time, deploys to the rest. You can also use feature flags with percentage toggles to control user exposure.
No, AppConfig charges $0.05 per configuration profile per environment per month, and $0.10 per deployment. The AppConfig Agent is free. There are no charges for hosted configuration storage or API calls, but standard data transfer rates apply.
You've just covered Feature Flags with AppConfig — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?