AWS Service Catalog and AWS AppConfig are the governed self-service and runtime configuration services on DOP-C02. Service Catalog wraps CloudFormation templates into approved-and-launchable products that developers can self-serve from a curated portfolio - solving "how do I let developers spin up RDS without IAM-DBAdmin" without abandoning the IaC discipline. AppConfig delivers feature flags and runtime configuration with validators and gradual deployment strategies - solving "how do I toggle a behavior at runtime without a redeploy" with auto-rollback safety.
This guide assumes you know what a CloudFormation template is and what a feature flag is. The DOP-C02 focus: Service Catalog portfolios, products, and versions, launch constraints, template constraints, notification constraints, StackSet constraints, ResourceUpdate constraints, portfolio sharing across Organizations, TagOptions for governance tagging, AppConfig applications, environments, configuration profiles, deployment strategies, JSON Schema and Lambda validators, auto-rollback on CloudWatch alarm, feature flag evaluations from clients, and AppConfig vs Parameter Store vs Secrets Manager selection.
Why Service Catalog and AppConfig Matter on DOP-C02
DOP-C02 explicitly lists "implementing infrastructure patterns, governance controls, and security standards into reusable IaC templates (for example, AWS Service Catalog, CloudFormation modules, AWS CDK)" as a Domain 2.1 skill, and AppConfig was a 2023 addition that the exam guide highlights as net-new versus DOP-C01. Community pass reports cite scenarios where Service Catalog wins over IAM-policy-only approaches because it delivers provisioning + governance + tagging + resource update locking in one product, while plain IAM only handles permission gating.
Real-world DevOps teams hit a recurring tension: developers want speed, security wants control. Service Catalog resolves it by letting developers self-serve from a portfolio of pre-approved CloudFormation templates without ever touching IAM permissions for the underlying services - they only need servicecatalog:ProvisionProduct. AppConfig resolves the analogous tension for runtime configuration: changes are validated, deployed gradually, and auto-rolled back, without redeploying the application.
The exam tests precise scoping: when does Service Catalog beat raw CloudFormation StackSets, when does AppConfig beat Parameter Store, and which Service Catalog constraint type addresses which governance need.
- Service Catalog product: a versioned CloudFormation template (or Terraform configuration via Service Catalog Terraform engine) wrapped for governed launch.
- Portfolio: a grouping of products with shared access control and tags.
- Provisioned product: an instance of a product that an end user has launched; backed by a CloudFormation stack.
- Launch constraint: an IAM role that Service Catalog assumes when launching the product, decoupling the user's IAM from the underlying resource creation.
- Template constraint: a JSON rule that restricts what parameter values an end user can supply (e.g.,
Type: String, AllowedValues: [t3.micro, t3.small]). - Notification constraint: an SNS topic to notify on product launch events.
- StackSet constraint: deploys the product as a StackSet across multiple accounts and regions.
- ResourceUpdate constraint: prevents end users from updating tags managed by the catalog admin.
- TagOption: a key-value pair the admin defines once and assigns to portfolios/products to enforce consistent tagging.
- AppConfig application: a logical grouping of related configurations.
- AppConfig environment: a deployment target within an application (e.g., dev, staging, prod).
- Configuration profile: a pointer to where the configuration data lives (S3, Parameter Store, CodeCommit, hosted) plus validators and type (
AWS.Freeform,AWS.AppConfig.FeatureFlags). - Deployment strategy: how a configuration version is rolled out (linear vs all-at-once), with bake time and growth factor.
- Validator: a JSON Schema or Lambda function that approves/rejects a new configuration version before deployment.
- Reference: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html
Plain-Language Explanation: Service Catalog and AppConfig
The two services solve adjacent problems with different mechanisms. Three angles cover the governed-launch model, the runtime-configuration model, and the validators.
Analogy 1: The Restaurant Approved Recipe Book vs Daily Special Menu
A restaurant chain has two governance surfaces. Service Catalog is the approved recipe book - corporate has vetted 30 dishes, each with exact ingredients (template parameters), each with a maximum portion (template constraint), each requiring a specific kitchen setup (launch constraint - the head chef has the keys, not the line cook). New cooks self-serve dishes from the book without needing access to the spice locker (the underlying IAM); they just request "Margherita Pizza, large" and corporate's approved cook role does the actual prep.
AppConfig is the daily special menu board - the kitchen runtime can switch what is on offer without rewriting the recipe book. "Today's salmon special: 30 percent off" is a feature flag pushed to all locations gradually (deployment strategy). If sales drop more than expected, the menu auto-reverts (auto-rollback on alarm).
Validators are the food safety inspector - any new menu item must pass a JSON Schema check (allergens labeled correctly) and optionally a Lambda check (the special must not violate the day's stock levels) before it goes live.
Analogy 2: The Hospital Approved Procedures Catalog vs Per-Shift Protocol Updates
A hospital has two governance surfaces. Service Catalog is the approved procedures catalog - 200 vetted procedures, each with controlled parameters (parameter constraints: dosage ranges, equipment lists). Any qualified doctor can launch "Standard Cholecystectomy, ASA-2 patient" and the OR is provisioned with the right team (launch constraint - the hospital's authorized team config role, not the doctor's personal credentials). TagOptions are the standard charge codes attached to every procedure for billing and reporting.
AppConfig is the per-shift clinical protocol updates - the new sepsis protocol can be turned on for the night shift gradually (deployment strategy: 10 percent of beds, then 50 percent, then 100), validated against the JSON schema (mandatory fields like trigger threshold present), and auto-reverted if the morning report shows worse outcomes (alarm-based rollback).
Feature flags are the per-doctor toggles - "Dr. Smith's experimental antibiotic protocol" can be enabled for a subset of patients without redeploying the entire EHR system. Clients (the EHR) call AppConfig at request time and behave differently based on the flag value.
Analogy 3: The Construction Permit System vs Real-Time Site Adjustments
A city has two control surfaces. Service Catalog is the building permit office - 50 pre-approved building types (single-family home, two-story apartment, commercial warehouse), each with constrained parameters (lot size limits, height restrictions). Citizens self-serve permits without becoming city planners; the office's permit-issuance role (launch constraint) does the actual filing.
AppConfig is the traffic signal control center - "this intersection's green-light timing increases by 5 seconds" can be deployed to one signal, validated, then expanded to a corridor, then citywide, with automatic reversion if accident reports spike during the change window.
StackSet constraint is the multi-jurisdiction permit mode - a single permit application provisions the same warehouse across three connected districts simultaneously, useful for chain stores opening in adjacent neighborhoods.
For Service Catalog launch constraint reasoning ("user does not need underlying IAM"), the restaurant cook + spice locker maps cleanest. For AppConfig deployment strategies and auto-rollback, the traffic signal control center is closest. For TagOptions and governance tagging, the hospital procedure billing codes is intuitive. Reference: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints.html
Service Catalog Architecture
Service Catalog has three primary entities and a constraint system layered on top.
Portfolios, Products, and Versions
A product is a CloudFormation template (or Terraform configuration via the Terraform engine). Each product has multiple versions (e.g., v1.0, v1.1) so admins can iterate without breaking existing provisioned products.
A portfolio groups products and assigns them to IAM principals (users, groups, roles) via principal grants. End users see only the products in portfolios they have access to.
End users provision a product, supplying parameter values; Service Catalog calls CloudFormation under a launch constraint role and tracks the result as a provisioned product with terminate, update, view-history operations.
Constraint Types
Constraints attach to (portfolio, product) pairs:
- Launch constraint: an IAM role Service Catalog assumes during launch. The end user only needs
servicecatalog:ProvisionProduct; the role has whatever permissions the underlying CloudFormation needs (RDS create, EC2 launch). Without launch constraints, end users would need direct IAM for every resource the template creates - defeating the governance point. - Template constraint: JSON rules narrowing parameter values (
AllowedValues,MinValue,MaxValue, regex patterns). Stricter than CloudFormation parameter constraints because they apply only when launched via Service Catalog. - Notification constraint: an SNS topic for launch events.
- StackSet constraint: deploy the product as a CloudFormation StackSet across multiple accounts and regions in one provision call.
- ResourceUpdate constraint (
TagUpdates): prevents the end user from changing tags on resources owned by the catalog admin.
Portfolio Sharing
You share a portfolio with another account or organization unit via:
- Account-level sharing: per-account explicit grant; the recipient account imports the portfolio.
- Organizations sharing: share with an OU or the entire org; recipients see the portfolio without explicit imports.
- Hub-and-spoke pattern: central portfolio in a tooling account, shared to all member accounts; products are versioned and propagated.
When a shared product is launched in a recipient account, the launch constraint role exists in the recipient account (not the source) - shared portfolios require each recipient to have an equivalent launch role.
The end user provisioning a product needs only servicecatalog:ProvisionProduct and servicecatalog:DescribeRecord permissions. The launch constraint role has the heavy permissions (CloudFormation create stack, RDS create instance, EC2 launch). This is the central governance value - developers self-serve compliant resources without holding the powerful IAM directly. Reference: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints-launch.html
TagOptions
TagOptions are admin-defined key-value pairs that you attach to portfolios or products. When a product is launched, the matching TagOptions are applied to the resulting CloudFormation stack and propagated to taggable resources. This enforces consistent tagging (CostCenter, DataClassification) without depending on end users to remember.
Updating a TagOption on a portfolio does not propagate to existing provisioned products. To enforce a new tag on already-launched products, you must update each provisioned product (which triggers a CloudFormation stack update) - or use AWS Config remediation to tag-fix retroactively. Reference: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/tagoptions.html
Service Catalog vs StackSets vs Direct CloudFormation
| Need | Pick |
|---|---|
| End user self-service launch with governance | Service Catalog |
| Same baseline to many accounts, no end user choice | StackSets |
| Power user with full CloudFormation IAM | Direct CloudFormation |
| Consistent tagging without user awareness | Service Catalog with TagOptions |
| Versioned product catalog | Service Catalog |
| Multi-account launch from a single portfolio | Service Catalog with StackSet constraint |
AppConfig Architecture
AppConfig has four entities: applications, environments, configuration profiles, and deployment strategies.
Application and Environment
An application is the logical scope (e.g., OrdersService). An environment is a deployment target within an application (dev, staging, prod); each environment can have CloudWatch alarms attached for auto-rollback.
Configuration Profile
A configuration profile points to where the configuration data lives:
- AppConfig hosted: data stored inside AppConfig itself.
- Amazon S3: data fetched from S3.
- Systems Manager Parameter Store: data fetched from Parameter Store.
- Systems Manager Document: data fetched from an SSM document.
- CodeCommit: data fetched from a CodeCommit repo path.
The profile also has a type:
AWS.Freeform: arbitrary text/JSON/YAML.AWS.AppConfig.FeatureFlags: a structured feature-flag schema.
Validators
A configuration profile can have validators that run when a new configuration version is deployed:
- JSON Schema validator: validates structure against a schema (must include required fields, enum constraints, type checks).
- Lambda validator: invokes a Lambda function with the configuration data; the Lambda returns success or failure.
If any validator fails, the deployment is rejected before any client receives the new version.
Deployment Strategy
A deployment strategy defines:
- Deployment duration: total time from start to all targets.
- Growth factor: percentage of additional traffic per growth interval.
- Growth type:
LINEAR(uniform) orEXPONENTIAL. - Final bake time: time to wait at 100 percent before declaring success (during which a CloudWatch alarm can trigger rollback).
- Replicate to: optionally save to SSM (cross-account propagation).
AWS provides predefined strategies:
AppConfig.AllAtOnce: 100 percent immediately, no bake time.AppConfig.Linear50PercentEvery30Seconds: 50 percent at 30 seconds, 100 percent at 60 seconds.AppConfig.Canary10Percent20Minutes: 10 percent for 20 minutes, then ramp to 100 percent over 20 more minutes.
Auto-Rollback on CloudWatch Alarm
Each environment can have CloudWatch alarms attached. During a deployment (and during the final bake time), if any attached alarm transitions to ALARM, AppConfig automatically rolls back to the previous configuration version. This is the bridge between configuration changes and runtime health.
The CloudWatch alarm-based rollback is active only during the deployment duration plus final bake time. After the bake time completes successfully, AppConfig no longer monitors for rollback - subsequent alarms do not auto-revert. For continuous protection, you would need a fresh deployment of the previous version triggered by an EventBridge rule on the alarm. Reference: https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-deployment-strategy.html
Feature Flags
The AWS.AppConfig.FeatureFlags profile type provides a structured feature flag schema:
- Each flag has a name, description, attributes.
- A flag value is
enabled: true|falseplus optional attributes (e.g.,rolloutPercentage: 50). - Clients evaluate flags by reading the deployed configuration and inspecting the flag value.
Feature flags + deployment strategies + validators give you Launch-Darkly-like behavior natively in AWS, with the runtime cost being the AppConfig data plane API calls (extension layer caches reduce these dramatically).
AppConfig Data Plane
Clients fetch configuration via the AppConfig data plane:
- AppConfig Agent: a sidecar (Lambda extension layer, ECS sidecar, EC2 daemon) that polls AppConfig periodically and exposes the current configuration over a local HTTP endpoint. Clients read from
localhost, never directly from AppConfig. - SDK direct: clients call
StartConfigurationSessionandGetLatestConfigurationthemselves.
The agent pattern is preferred because it caches and reduces API calls.
AppConfig vs Parameter Store vs Secrets Manager
| Need | Pick |
|---|---|
| Static config rarely changing (DB endpoint) | Parameter Store |
| Secrets requiring rotation (DB password) | Secrets Manager |
| Feature flags with gradual rollout | AppConfig |
| Runtime config with validators + auto-rollback | AppConfig |
Hierarchical structured config (/app/env/key) |
Parameter Store |
| Cross-region replicated secret | Secrets Manager (replica) |
| JSON schema-validated config | AppConfig |
AppConfig stores configuration data; it is not designed for credentials. Use Secrets Manager for rotated secrets and Parameter Store SecureString for low-frequency secrets. AppConfig's data plane is optimized for high-throughput reads, not encryption-at-rest with rotation. Reference: https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html
Service Catalog Operational Patterns
DOP-C02 scenarios test three Service Catalog operational patterns. Constrained product launch: the portfolio defines launch constraints (the IAM role assumed at provision time) and template constraints (which CloudFormation parameters end users may override). End users with only servicecatalog:ProvisionProduct permission can launch products but cannot view or alter the underlying CloudFormation stack — the constraint role does the heavy lifting. TagOptions for cost allocation: TagOptions attached to a portfolio enforce mandatory tag keys and values on every provisioned product, so the central platform team can guarantee tags like cost-center, environment, and owner are present without each end-user having to remember them. Cross-account product sharing via AWS Organizations: instead of duplicating portfolios per account, share once across the organization and update centrally — version updates propagate to consumer accounts without re-provisioning.
AppConfig Deployment Strategy Selection
AppConfig's three managed deployment strategies map to three risk profiles the exam tests. AppConfig.AllAtOnce rolls out the new configuration to 100% of clients in a single pulse — fast for trivial changes, dangerous for behavioural ones. AppConfig.Linear50PercentEvery30Seconds progresses in 50/50 steps with a 30-second bake — useful when an alarm is wired to short-circuit on regression. AppConfig.Canary10Percent20Minutes runs a true canary: 10% for 20 minutes, then 20%, then 40%, then 100% — the most defensive default for production feature flags. The exam plants stems where a candidate picks AllAtOnce on a behaviour change behind a feature flag and the answer is "shift to a canary strategy and wire a CloudWatch alarm to halt deployment."
Common Pitfalls (常考陷阱)
- Forgetting Service Catalog launch constraint role: end users will get IAM permission errors during launch even though they have
ProvisionProduct. - Sharing a portfolio without recipient launch role: the launch constraint references a role in the recipient account; if it does not exist, launch fails.
- Updating TagOptions and expecting retroactive application: TagOptions only apply at launch.
- Treating AppConfig auto-rollback as continuous protection: it only monitors during the deployment + bake window.
- Storing secrets in AppConfig: use Secrets Manager or Parameter Store SecureString instead.
- Skipping validators: deploying invalid configurations to production is a self-inflicted outage; validators catch it.
- Using the AppConfig SDK directly without caching: high-throughput clients should use the AppConfig agent (Lambda extension or sidecar) to cache and avoid throttling.
FAQ
Q1: When should I prefer Service Catalog over CloudFormation StackSets?
Service Catalog when end users need to self-serve with parameter choice; StackSets when admins push the same baseline to many accounts without end-user input. Service Catalog with the StackSet constraint combines both - end users provision a product that itself fans out as a StackSet.
Q2: Can Service Catalog use Terraform?
Yes, AWS launched the Service Catalog Terraform Reference Engine and AWS-supported Terraform integration. Products can be Terraform configurations stored in S3, with Service Catalog managing version control and end-user launches. CloudFormation remains the default and most-tested option.
Q3: How does AppConfig differ from a feature-flag SaaS like LaunchDarkly?
AppConfig is AWS-native (no extra vendor), integrates with CloudWatch alarms for auto-rollback, has built-in validators, and is part of Systems Manager. SaaS feature-flag tools typically have richer client SDKs, advanced targeting (per-user attributes), and dedicated dashboards. For AWS-only workloads with simple flag needs, AppConfig is sufficient and zero-additional-vendor.
Q4: Does AppConfig support nested configurations or per-tenant data?
AppConfig delivers the same configuration to all clients in an environment. For per-tenant or per-user configuration, the configuration document itself can include the structure (e.g., tenants: { tenantA: {...}, tenantB: {...} }), and clients select their slice. AppConfig does not natively segment by client identity.
Q5: Can I use Service Catalog products in CodePipeline?
Yes, CodePipeline has a Service Catalog action that creates or updates a product and version from a CodeCommit/S3 source. This is the pattern for "developers commit a CloudFormation template; CodePipeline tests it; Service Catalog publishes a new version automatically."
Q6: What happens to provisioned products when their underlying product is deleted?
Provisioned products survive the deletion of the underlying product version. End users can still terminate, update (within the version they originally launched), and view history. New launches of that version are not possible. To remove provisioned products, you must terminate them explicitly.
Q7: How do I handle secrets that AppConfig clients need to read?
Use AppConfig for non-secret runtime config (feature flags, thresholds, behavior toggles) and Secrets Manager / Parameter Store SecureString for secrets. Clients read both - AppConfig for behavior config and Secrets Manager for credentials. Mixing them in AppConfig is an anti-pattern.
Wrap-Up
Service Catalog wraps CloudFormation templates into governed self-service products with launch constraints, template constraints, TagOptions, StackSet fan-out, and portfolio sharing - giving developers velocity without IAM sprawl. AppConfig delivers runtime configuration and feature flags with validators, gradual deployment strategies, and CloudWatch-alarm-based auto-rollback - giving operators safe runtime control without redeploys. Pick Service Catalog for governed provisioning, AppConfig for governed runtime configuration, Parameter Store for static config, and Secrets Manager for rotated secrets. Memorise the constraint types, the deployment-strategy growth and bake mechanics, and the data-plane caching pattern, and these scenarios resolve to recognition.