How to Dynamically Deploy ECS Application Parameters Without Downtime Using AWS AppConfig?

A developer is creating an application on Amazon Elastic Container Service (Amazon ECS). The developer needs to configure the application parameters. The developer must configure limits for the application's maximum number of simultaneous connections and maximum number of transactions per second. The maximum number of connections and transactions can change in the future. The developer needs a solution that can automatically deploy these changes to the application, as needed, without causing downtime. Which solution will meet these requirements?

  1. Make the configuration changes for the application. Use AWS CodeDeploy to create a deployment configuration. Specify an in-place deployment to deploy the changes.
  2. Bootstrap the application to use the AWS Cloud Development Kit (AWS CDK) and make the configuration changes. Specify the ECSCanary10Percent15Minutes launch type in the properties section of the ECS resource. Deploy the application by using the AWS CDK to implement the changes.
  3. Install the AWS AppConfig agent on Amazon ECS. Configure an IAM role with access to AWS AppConfig. Make the deployment changes by using AWS AppConfig. Specify Canary10Percent20Minutes as the deployment strategy. Source Reference Answer
  4. Create an AWS Lambda function to make the configuration changes. Create an Amazon CloudWatch alarm that monitors the Lambda function every 5 minutes to check if the Lambda function has been updated. When the Lambda function is updated, deploy the changes by using AWS CodeDeploy.

Community Votes

C
75%
D
25%

75% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the distinction between deploying application code (which requires CodeDeploy/CDK) versus dynamically updating runtime configuration parameters, which should be handled by AWS AppConfig to avoid downtime.

AWS AppConfig, combined with its agent on Amazon ECS, allows dynamic retrieval of application configuration parameters like connection limits without redeploying the application or causing downtime, using a canary deployment strategy.

Many candidates choose D (Lambda + CloudWatch + CodeDeploy) because it sounds like a valid automation pattern, but it unnecessarily involves code deployment and polling, whereas AppConfig is purpose-built for dynamic configuration without redeployment.

Community Discussion (5 comments)

jasonczx 👍 3 Selected: C
The agent calls AWS AppConfig on your behalf by using an AWS Identity and Access Management (IAM) role and managing a local cache of configuration data. By pulling configuration data from the local cache, your application requires fewer code updates to manage configuration data, retrieves configuration data in milliseconds, and isn't affected by network issues that can disrupt calls for such data. https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-ec2.html
jasonczx 👍 2 Selected: C
The AWS AppConfig Agent is the recommended method for retrieving AWS AppConfig feature flags or free form configuration data. The agent automatically implements best practices and may lower your cost of using AWS AppConfig as a result of fewer API calls to retrieve configurations. https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-agent-how-to-use.html
jasonczx 👍 1 Selected: C
This environment variable configures the maximum number of connections that the agent uses to retrieve configurations from AWS AppConfig. https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-containers-agent.html
siheom 👍 1 Selected: D
vote D
jasonczx 👍 1 Selected: D
Lambda automatically handles scaling the number of execution environments until you reach your account's concurrency limit. By default, Lambda provides your account with a total concurrency limit of 1,000 concurrent executions across all functions in an AWS Region. https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

The core requirement is to dynamically update application parameters (maximum connections and transactions per second) on an Amazon ECS application without downtime. These are runtime configuration values, not code changes.

Why Option C is Correct

AWS AppConfig is a purpose-built service for managing, deploying, and validating application configurations dynamically. By installing the AWS AppConfig agent on ECS tasks:
  • The agent retrieves configuration data from AppConfig and caches it locally.
  • The application reads from the local cache in milliseconds, avoiding network disruptions.
  • You can use a Canary10Percent20Minutes deployment strategy to gradually roll out configuration changes, validating them before full deployment.
  • No container restart or ECS task redeployment is needed — the application simply picks up the new configuration values.
As community member jasonczx noted, the agent uses an IAM role to call AppConfig on behalf of the application and manages a local cache, making it resilient to network issues.

Why Other Options Are Wrong

  • Option A (CodeDeploy in-place): CodeDeploy is designed for deploying application code (new task definitions, container images). Changing a configuration value does not require a full deployment, and an in-place deployment could cause brief downtime.
  • Option B (AWS CDK with ECSCanary10Percent15Minutes): CDK is an Infrastructure as Code tool. Using it to push configuration changes means updating infrastructure or task definitions, which triggers ECS task replacements and is overkill for simple parameter changes.
  • Option D (Lambda + CloudWatch + CodeDeploy): This is an overly complex and incorrect approach. Polling a Lambda function every 5 minutes via CloudWatch is not a valid pattern for configuration management. Additionally, using CodeDeploy still implies a code deployment cycle, which is unnecessary and risks downtime.

Key Takeaway

When the question asks about changing application parameters at runtime without downtime, always think AWS AppConfig. It is the AWS-native solution for dynamic configuration management on ECS, EC2, Lambda, and more.

Official Reference

Exam Strategy

When you see keywords like 'application parameters', 'configuration changes', and 'without downtime' on ECS or EC2, immediately look for AWS AppConfig in the options. Avoid answers that involve redeploying code or infrastructure for what is essentially a configuration update.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide