AWS Certified Associate DVA-C02 Release Date

AWS CodeArtifact emits events when repository actions occur, such as publishing a new package. AWS documentation recommends Amazon EventBridge as the native service for routing AWS service events to targets with minimal configuration and no infrastructure to manage.

By creating an EventBridge rule that matches CodeArtifact package publication events and routing those events directly to an Amazon SNS topic , the developer can notify the team immediately. SNS provides built-in email subscriptions, retries, and delivery guarantees without custom code.

Option C is the most operationally efficient because it uses fully managed, serverless services and requires no custom compute, code maintenance, or orchestration. EventBridge directly supports SNS as a target, making the configuration straightforward.

Option A is invalid because CodeArtifact does not directly publish notifications to SNS topics. Options B and D introduce unnecessary complexity by adding Lambda or Step Functions and Amazon SES, increasing operational overhead without added value.

Therefore, using EventBridge to route CodeArtifact events to SNS is the AWS-recommended and simplest solution.

The correct answer is C because AWS AppConfig provides built-in support for feature flags , allowing developers to enable or disable features dynamically without redeploying application code. This is exactly what the question requires: keeping features hidden from end users until the features are ready for release, and then selectively activating them when appropriate.

AWS documentation describes AppConfig as a service for managing application configuration in a safe and controlled way. Feature flags in AppConfig let teams separate deployment from release , which is a core best practice in modern application development. A developer can deploy code that contains unfinished or hidden functionality, while the actual visibility and activation of that functionality is controlled through feature flag values stored in an AppConfig configuration profile. When the feature is ready, the flag can be turned on without changing the application package.

Option A is incorrect because AWS AppSync is a managed GraphQL service and is not the AWS feature flag service for application configuration management. Option B is incorrect because DynamoDB Streams are used for capturing item-level changes and reacting to table updates, not for controlled feature activation. Option D is incorrect because Amplify DataStore is intended for client-side data synchronization and offline access patterns, not centralized production feature flag management.

Using AppConfig also provides operational benefits such as deployment strategies, configuration validation, and rollback support, which make it safer than building a custom feature toggle mechanism. For these reasons, AWS AppConfig feature flags are the most appropriate and AWS-recommended solution for hiding prerelease features and selectively enabling them later.

Therefore, C is the correct answer.

For client-side encryption with AWS KMS, the documented pattern is envelope encryption : you use KMS to generate and protect a data encryption key (DEK) , and you use that DEK locally to encrypt the actual data. This is the correct approach for large payloads (such as 10 MB documents), because the KMS Encrypt API is intended for encrypting small amounts of data (KMS is not designed to directly encrypt multi-megabyte application payloads).

With envelope encryption, the application calls GenerateDataKey on AWS KMS, specifying the KMS key (customer managed key) to use. KMS returns two versions of the DEK in the response:

a plaintext DEK (usable immediately by the application for local cryptographic operations), and

a ciphertext (encrypted) DEK that is encrypted under the specified KMS key.

The application then uses the plaintext DEK to encrypt the 10 MB document on the client side (for example, using an authenticated encryption mode such as AES-GCM via a standard crypto library). After encryption completes, the application must not persist the plaintext DEK; instead, it stores the encrypted document alongside the ciphertext DEK . Later, to decrypt, the application sends the ciphertext DEK to KMS using Decrypt to recover the plaintext DEK, and then decrypts the document locally.

Therefore, option D is correct because it explicitly uses GenerateDataKey and the plaintext DEK to encrypt the data, which is the required envelope-encryption flow. Options A, B, and C do not follow the correct KMS envelope-encryption process for large client-side payloads.