There are two bad ways to change how a running application behaves. The first is to bake every setting into the deployment artifact, so that flipping a timeout or a feature requires a full build-and-deploy through your pipeline. The second is to edit configuration directly in production with no validation, no gradual rollout, and no way to undo a bad value except by editing it again — after it has already taken down the fleet. AWS AppConfig exists to remove both bad options: it treats configuration as something you deploy safely and gradually, separately from your code, with validation up front and automatic rollback if it goes wrong.
For the AWS Certified DevOps Engineer – Professional (DOP-C02) exam, AppConfig sits squarely in the “SDLC automation” and “resilient cloud solutions” domains, because it’s how you change behavior in production without shipping new code and without accepting the blast radius of an unguarded config edit. This guide covers its structure, its deployment mechanics, its two validation modes, and the automatic-rollback behavior that makes it a safe config service rather than just a key/value store.
AppConfig is a capability of AWS Systems Manager, so you’ll sometimes see it referred to as “SSM AppConfig.” Don’t confuse it with SSM Parameter Store — they’re related but solve different problems, which we’ll pin down at the end.
The Problem AppConfig Solves
Configuration changes are deceptively dangerous. A one-character edit to a JSON config — a wrong feature flag, a bad connection limit, a malformed value — can be as catastrophic as a bad code deploy, but historically it hasn’t had any of the safety rails a code deploy gets: no gradual rollout, no health monitoring, no automatic rollback. AppConfig brings the discipline of deployment to configuration:
- Validate before it ships — reject syntactically or semantically invalid config so it never reaches an instance.
- Roll it out gradually — expose the new config to a growing percentage of your fleet over time instead of all at once.
- Monitor while it rolls out — watch a CloudWatch alarm during the rollout.
- Roll back automatically — if that alarm fires, revert to the last known-good configuration with no human in the loop.
That last point is the DOP-scale differentiator. On the exam, when a scenario asks how to change a runtime setting across a fleet safely, gradually, and with automatic rollback on error, AppConfig is the answer.
The AppConfig Hierarchy
AppConfig has a small object model. Learn these four nouns and their relationships and most of the service falls into place:
| Object | What it represents | Example |
|---|---|---|
| Application | A logical grouping — usually one microservice or app | checkout-service |
| Environment | A deployment target group within the application | production, beta, us-east-1-fleet |
| Configuration profile | A pointer to where the config lives plus how to validate it | checkout-limits, checkout-flags |
| Deployment | One rollout of one configuration version to one environment using one strategy | ”Deploy v7 of checkout-limits to production” |
An application contains one or more environments and one or more configuration profiles. You deploy a specific version of a profile to a specific environment using a deployment strategy. Critically, CloudWatch alarms are attached at the environment level — that’s what enables monitoring and automatic rollback for anything deployed to that environment.
Configuration Profiles: Freeform vs Feature Flags
A configuration profile comes in one of two types, and knowing the difference is exam-relevant:
- Freeform configuration — any configuration data you define: JSON, YAML, or plain text. Timeouts, limits, allow-lists, connection settings, tuning parameters.
- Feature flag configuration — an AppConfig-managed profile with a built-in schema for feature toggles and their attributes, so you can turn features on/off and attach values per flag without designing your own format.
Feature flags are just one kind of profile — the mechanics of deployment, validation, and rollback described below apply to both types identically. (If you’ve read the proactive monitoring guide, you’ll recall that AWS now steers feature-flag and progressive-rollout use cases to AppConfig feature flags after CloudWatch Evidently reached end of support — this is the service it points to.) For everything else in this guide, “configuration” means either type.
Where the configuration data actually lives
A freeform profile points at a source that holds the config data. AppConfig supports several:
| Source | Use it when |
|---|---|
| AppConfig hosted configuration store | You want AppConfig to store versions for you — the simplest option, no other service needed |
| SSM Parameter Store | The value already lives in Parameter Store |
| SSM Document | You maintain config as a Systems Manager document |
| Amazon S3 | The config object is a file in a bucket |
The hosted store is the common default: each time you save a change, AppConfig keeps it as a new immutable version, and you deploy versions.
Validators: Catch Bad Config Before It Deploys
This is where AppConfig stops being a fancy key/value store. Before a configuration version can be deployed, it can be run through validators. There are two types, and the exam likes to contrast them:
| Validator type | What it checks | How |
|---|---|---|
| JSON Schema | Structure — required keys, types, allowed ranges | You supply a JSON Schema; AppConfig validates the config against it |
| AWS Lambda | Semantics — any custom rule you can express in code | AppConfig invokes your Lambda with the config; the function approves or rejects it |
Use a JSON Schema validator to guarantee the shape is right — that maxRetries is an integer between 1 and 10, that a required field is present. Use a Lambda validator when correctness depends on logic a schema can’t express — cross-field consistency, a lookup against another system, business rules. You can attach both. Validators run when you create a new configuration version and again as part of starting a deployment, so invalid configuration is rejected before any instance ever receives it.
// A minimal JSON Schema validator: maxConnections must be 1–1000
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"maxConnections": { "type": "integer", "minimum": 1, "maximum": 1000 }
},
"required": ["maxConnections"]
}Deployment Strategies: How Fast, How Watched
When you deploy a configuration version to an environment, you choose a deployment strategy that controls the rate of rollout. A strategy is defined by a handful of parameters:
| Parameter | Meaning |
|---|---|
| Deployment type | Linear (fixed % steps) or Exponential (accelerating steps) |
| Growth factor | The percentage of targets added at each step |
| Deployment duration | Total time over which the rollout progresses (“bake”) |
| Final bake time | An extra monitoring window after 100% before the deployment is marked complete |
| Replicate to | Optionally copy the strategy to an SSM Document |
AWS ships several predefined strategies so you don’t have to build your own for common cases:
- AppConfig.AllAtOnce — 100% immediately. Fast, minimal safety; good for
beta, notproduction. - AppConfig.Linear50PercentEvery30Seconds — quick, stepped rollout for testing.
- AppConfig.Canary10Percent20Minutes — expose to 10% first, then grow exponentially over 20 minutes. A cautious production default.
The bake time is the important concept. During the deployment and the final bake window, AppConfig is watching — and that’s exactly when automatic rollback can trigger.
Automatic Rollback with CloudWatch Alarms
Here’s the mechanism that makes AppConfig safe rather than merely gradual. You associate one or more CloudWatch alarms with an environment (these are the environment’s “monitors”), and grant AppConfig an IAM role that lets it read those alarms. Then, during any deployment to that environment — throughout the rollout and the final bake time — AppConfig checks the alarms:
- You deploy config v7 to
productionwith theCanary10Percent20Minutesstrategy. - AppConfig exposes v7 to 10% of the fleet and begins baking.
- Your application’s error-rate CloudWatch alarm crosses its threshold and enters
ALARM. - AppConfig automatically rolls back every target to the previous good version (v6). No human action, no pipeline re-run.
This is the answer to any DOP scenario that reads like “change a production setting gradually and revert automatically if error rates spike.” The alarm is the health signal; the bake time is the window during which that signal matters; the rollback is automatic. It’s the same operational philosophy as a canary code deployment — but applied to configuration, and cross-account/cross-service by nature. For the code-side equivalent (CodeDeploy alarms and auto-rollback), see the deployment strategies guide; for the broader auto-remediation pattern, the incident response guide covers alarm-driven automation.
Retrieving Configuration at Runtime
Deploying config is only half the loop — the application has to read it. AppConfig uses a session-based data API:
StartConfigurationSessionopens a session for a given application/environment/profile.GetLatestConfigurationis polled to receive the current configuration (and only the changes since the last poll, to save bandwidth).
Writing that polling loop by hand is error-prone, so AWS provides the AWS AppConfig Agent (available as a Lambda extension, a sidecar container, or a host agent). The agent handles the session and polling for you, caches the latest configuration locally, and serves it to your app over a local HTTP endpoint — which means your code reads config with near-zero latency and you don’t pay for a GetLatestConfiguration call on every request. On the exam, the agent/extension is the recommended, low-latency way to consume AppConfig, especially from Lambda.
# With the AppConfig Lambda extension, your function reads config locally:
curl "http://localhost:2772/applications/checkout-service/environments/production/configurations/checkout-limits"Configuration Deployment Is Not Code Deployment
A distinction the exam rewards: deploying configuration with AppConfig is not the same as deploying code with CodeDeploy/CodePipeline. AppConfig changes the behavior or data of an already-running application — no new artifact, no instance replacement, no traffic shifting between versions of your code. CodeDeploy changes which code is running. They can work together (ship code with CodePipeline; tune its behavior with AppConfig), and they share the “gradual rollout + alarm-based rollback” philosophy, but they operate on different things. When a scenario is about changing a setting, flag, or value without a redeploy, that’s AppConfig; when it’s about shipping a new build, that’s the CI/CD services covered in the SDLC automation guide.
AppConfig vs Parameter Store vs Secrets Manager
Because all three store configuration-shaped data, scenarios test whether you can pick the right one:
| Service | Best for | Gradual rollout? | Validation? | Auto-rollback? |
|---|---|---|---|---|
| AWS AppConfig | Safely deploying config changes to running apps | Yes | Yes (JSON Schema + Lambda) | Yes (CloudWatch alarm) |
| SSM Parameter Store | Storing config values and secrets cheaply, hierarchically | No | No | No |
| AWS Secrets Manager | Secrets that need automatic rotation | No | No | No |
The mental model: Parameter Store and Secrets Manager store values; AppConfig deploys them safely. In fact AppConfig can source a freeform profile from Parameter Store — you store the value there and let AppConfig own the validated, gradual, monitored rollout on top. When a scenario stresses controlled rollout, validation, or automatic rollback, it’s AppConfig; when it’s plain storage or secret rotation, it’s the other two. For the storage-side comparison in depth, see Secrets Manager vs Parameter Store.
Common Exam Traps
- AppConfig vs Parameter Store. Storing a value ≠ safely deploying it. If the question mentions gradual rollout, validation, or rollback, it’s AppConfig.
- Config deployment vs code deployment. Changing a setting on a running app is AppConfig; shipping a new artifact is CodeDeploy/CodePipeline.
- Where alarms attach. CloudWatch alarms for rollback are configured on the environment, not the profile or the deployment.
- Validator choice. Structure → JSON Schema validator; custom logic → Lambda validator.
- Bake time is the rollback window. Rollback can trigger during the rollout and the final bake time, not after the deployment is marked complete.
- Evidently is gone. Feature flags now map to AppConfig; don’t pick CloudWatch Evidently on a current-dated question.
Frequently Asked Questions
Is AWS AppConfig a separate service or part of Systems Manager?
It’s a capability of AWS Systems Manager. You’ll find it under Systems Manager, and it’s sometimes written “SSM AppConfig,” but it has its own applications, environments, profiles, and deployments.
How does AppConfig roll back automatically?
You associate CloudWatch alarms with the AppConfig environment and give AppConfig an IAM role to read them. During a deployment’s rollout and final bake time, if an associated alarm enters ALARM, AppConfig automatically reverts all targets to the previously deployed configuration version.
What’s the difference between a JSON Schema validator and a Lambda validator?
A JSON Schema validator checks the structure of the configuration — types, required fields, allowed ranges. A Lambda validator runs your own code to check semantics or business rules a schema can’t express. You can attach both; validation happens before the config is deployed.
When should I use AppConfig instead of Parameter Store?
Use Parameter Store to store a value cheaply and hierarchically. Use AppConfig when you need to deploy a configuration change safely — with validation, a gradual rollout, health monitoring, and automatic rollback. AppConfig can even source its data from Parameter Store.
How does my application read AppConfig configuration?
Through the data API — StartConfigurationSession then polling GetLatestConfiguration — or, more commonly, via the AWS AppConfig Agent (Lambda extension, sidecar, or host agent), which caches config locally and serves it over a local endpoint for low latency and lower cost.
Does deploying with AppConfig replace my instances or shift traffic?
No. AppConfig changes configuration for an already-running application; it doesn’t replace instances or shift traffic between code versions. That’s what code-deployment services like CodeDeploy do.
Conclusion
AWS AppConfig turns configuration changes from an unguarded production edit into a proper, monitored deployment. Its object model is small — application, environment, configuration profile, deployment — but the value is in the mechanics wrapped around it: validators that reject bad config before it ships, deployment strategies with bake time that roll changes out gradually, and CloudWatch-alarm automatic rollback that reverts a bad change without a human. Layer in the distinction between config deployment and code deployment, and between AppConfig and plain storage services, and you’ve covered what the DOP-C02 exam expects.
The exam tests this as scenarios — “change a setting fleet-wide, gradually, and revert on error” — so the reliable way to lock it in is timed, scenario-driven practice. The Sailor.sh AWS Certified DevOps Engineer – Professional (DOP-C02) mock exam bundle is built around exactly these “which service, which mechanism” questions, each with a detailed explanation of why the right answer wins and why the near-misses (Parameter Store, Secrets Manager, CodeDeploy) don’t. Use this article to learn the mechanics; use full-length practice to make the recognition automatic. For the complete domain map and logistics, start with the DOP-C02 exam guide for 2026.