A company introduced a new feature that should be accessible to only a specific group of premium customers. A developer needs the ability to turn the feature on and off in response to performance and

Question

Options

• AUse AWS AppConfig to manage the feature configuration and to validate and deploy changes.
• BUse AWS Secrets Manager to securely manage and validate the feature configurations. Enable
• CUse AWS Config to manage the feature configuration and validation. Set up AWS Config rules to
• DUse AWS Systems Manager Parameter Store to store and validate the configuration settings for

• A
  72% (18)
• B
  16% (4)
• C
  8% (2)
• D
  4% (1)

Explanation

AWS AppConfig (option A) is purpose-built for exactly this use case: managing application configuration, including feature flags, with built-in deployment strategies, rollback capabilities, and validators that catch bad configs before they reach production - all without requiring application redeployment or causing downtime.

Option B (Secrets Manager) is designed for storing and rotating secrets like passwords and API keys, not for feature configuration or controlled rollouts - it has no deployment strategy or validation workflow for config changes.

Option C (AWS Config) is a compliance and auditing service that records resource configurations and evaluates them against rules; it does not manage or deploy application-level feature configurations.

Option D (Parameter Store) can store configuration values, but it lacks AppConfig's built-in deployment strategies, canary/gradual rollouts, and pre-deployment validators that prevent bad configs from causing outages.

Memory tip: Think of AppConfig as a feature flag manager with a safety net - if the question mentions toggling features for specific users, gradual rollouts, or validating configs before deployment, AppConfig is the answer. Parameter Store is just storage; AppConfig is storage + deployment + validation.

No community discussion yet for this question.