Amazon Web Services Updated DVA-C02 Exam Questions and Answers by kareem

Feature flags are a classic configuration-management use case: values change over time, multiple applications share them, and clients should retrieve updates efficiently with local caching. AWS AppConfig (part of AWS Systems Manager) is purpose-built to deploy and manage application configuration and feature flags. It provides controlled rollout, validation, and centralized configuration management. For operational efficiency, AWS offers the AWS AppConfig Agent for compute environments such as EC2.

With option C, the AppConfig Agent runs on each EC2 instance and polls AppConfig on a configured interval for updates. The agent maintains a local cache and exposes the current configuration through a localhost HTTP endpoint . The application then reads the feature flag values from the local endpoint, which is fast and reduces direct calls to AWS APIs. This meets both requirements: periodic polling for new values and caching once retrieved, while minimizing application changes and centralizing operational control in AppConfig.

Option D (Parameter Store + in-memory cache) can work, but it pushes more responsibility into each application: polling logic, caching behavior, error handling, and consistency. Option A misuses Secrets Manager (intended for secrets, not dynamic flags) and adds ElastiCache operational overhead. Option B similarly adds DAX and DynamoDB infrastructure and is not a standard feature-flag pattern; it also requires the app to implement polling and caching logic, reducing operational efficiency.

Therefore, C is the most operationally efficient solution: store flags in AWS AppConfig , run the AppConfig Agent on EC2 to handle polling and caching, and have the application read flags from the agent’s localhost endpoint.

TTL for Automatic Deletion: DynamoDB ' s Time-to-Live effortlessly deletes expired items without manual intervention.

DynamoDB Stream: Captures changes to the table, including deletions of expired items, triggering downstream actions.

Lambda for Processing: A Lambda function connected to the stream provides custom logic for handling the deleted items.

Code Efficiency: This solution leverages native DynamoDB features and stream-based processing, minimizing the need for custom code.

The requirement is encryption in transit for sensitive data sent in API calls between two Apache-based EC2 fleets in peered VPCs . The most operationally efficient approach is to restrict network access and rely on standard TLS at the application layer. Among the provided options, the only operationally simple and directly relevant network control is security group referencing across VPC peering within the same account and Region.

By creating security groups that allow inbound traffic only from the other fleet’s security group , the developer ensures that only the intended instances can communicate over the required ports (for example, 443 for HTTPS). This is operationally efficient because it avoids managing IP allowlists that change with Auto Scaling and keeps the trust boundary tied to instance membership rather than addresses. It also supports least privilege by limiting which sources can reach the service.

Why the other options are not the best fit:

B (Site-to-Site VPN) is unnecessary for VPC peering in the same account/Region and adds significant operational overhead. It also does not replace the need for TLS at the application layer to guarantee encryption to the endpoint.

C (EBS encryption) addresses encryption at rest on volumes, not encryption in transit between fleets.

D (Nitro Enclaves) is heavy and unrelated to the core requirement; enclaves protect data-in-use and do not replace standard TLS for network encryption.

Important nuance: Security groups alone do not encrypt traffic; encryption is achieved by using HTTPS/TLS between the Apache services. However, option A is the most operationally efficient control offered here to implement secure connectivity between the fleets (paired with using HTTPS on Apache, which is the standard for encrypting API calls).

Therefore, A best meets the requirement with the least operational complexity.

API Gateway Mocking: This feature is built for decoupling development dependencies. Here ' s the process:

Create resources and methods in your API Gateway.

Set the integration type to ' MOCK ' .

Define Integration Responses, mapping HTTP status codes to desired mocked responses (JSON, etc.).

Deployment and Use:

Create a deployment stage for the API.

Frontend teams can call this API and get the mocked responses without a real backend.