Pass the Amazon Web Services AWS Certified Associate DVA-C02 Questions and answers with CertsForce

The requirements describe a Git-driven workflow where each new branch automatically gets its own deployment with minimal setup and management. AWS Amplify is designed for exactly this use case for web (and supporting mobile backends): it integrates directly with Git providers and offers continuous deployment . Amplify’s feature branch deployments automatically create a separate deployment (and typically a distinct preview URL) for each connected branch, enabling developers to test and review changes per branch without manually provisioning environments.

With Amplify, the developer connects the repository once, selects the branches to deploy, and Amplify automatically builds and deploys the application whenever code changes are pushed. When a new branch is added, Amplify can be configured to deploy it as a separate environment, providing isolated testing, previewing, and validation. This dramatically reduces operational overhead because Amplify manages build settings, hosting, SSL, and branch-based environments without needing custom CI/CD wiring.

Option A (ECR + ECS + GitHub Actions) can support branch deployments, but it requires substantial operational work: container build pipelines, task/service management, networking, scaling, and environment isolation per branch. Option B (Elastic Beanstalk) can manage deployments, but branch-based automatic deployments are not as native; creating separate environments and managing application versions typically requires more manual steps or additional automation. Option C (Lambda aliases) is not a general-purpose web/mobile deployment approach and does not naturally map “new Git branch” to an isolated deployment environment without significant custom tooling.

Therefore, D is the best fit with the least operational overhead: use AWS Amplify with feature branch deployments to automatically create and manage separate deployments for Git branches.

This solution will ensure that all orders and updates are stored to Amazon S3 with the least development effort because it uses DynamoDB Streams to capture changes in the DynamoDB table and trigger a Lambda function to write those changes to the S3 bucket. This way, the original Lambda function and API Gateway API endpoint do not need to be modified, and no additional services are required. Option A is not optimal because it will require more development effort to create a new Lambda function and a new API Gateway API endpoint, and to modify the original Lambda function to post updates to the new API endpoint. Option B is not optimal because it will introduce additional costs and complexity to use Amazon Kinesis Data Streams to create a new data stream, and to modify the Lambda function to publish orders to the data stream. Option D is not optimal because it will require more development effort to modify the Lambda function to publish to a new Amazon SNS topic, and to create and subscribe a new Lambda function to the topic.

To prove integrity (and authenticity) of data in transit, the correct cryptographic primitive is a digital signature. AWS KMS supports signing and verification operations using asymmetric KMS keys designed for signing (for example, RSA_SIGN_PSS, RSA_SIGN_PKCS1, or ECC_NIST_P256 key specs). The developer signs the data (or more commonly, a hash of the data) using the private key, and the external recipient verifies the signature using the corresponding public key. If the data is modified in transit, signature verification fails, proving the content was changed.

Option C exactly describes this model: sign with the private key, share the public key. The private key remains protected (ideally never leaving KMS). The public key can be distributed safely because it cannot be used to forge signatures.

Option A (encryption) provides confidentiality, not integrity proof to a third party, and sharing a symmetric encryption key is insecure and breaks key management principles.

Option B is incorrect because symmetric keys do not provide non-repudiation and generally require the verifier to possess the same secret key, which would allow the verifier to forge signatures too. While HMAC can validate integrity between trusted parties, it does not meet the typical “prove integrity” requirement to an external party without sharing a secret.

Option D is backward and insecure: you never share a private key.

Therefore, use an asymmetric KMS signing key to sign with the private key and provide the public key for verification.

The goal is minimal downtime during deployment and fast rollback if problems occur. In Elastic Beanstalk, the approach that best satisfies both is a blue/green deployment.

With blue/green, the developer deploys the new application version to a separate environment (green) while the current production environment (blue) continues serving traffic. Once validation is complete (health checks, smoke tests), the developer performs a controlled CNAME swap (or routing switch) so traffic shifts from blue to green with near-zero downtime. This reduces risk because the existing environment remains intact and can immediately resume traffic if issues are detected.

Rollback time is also minimized because reverting is simply switching traffic back to the original environment (swap back), rather than rolling back changes across the same environment.

Why the other options are weaker:

All-at-once (C) introduces the highest downtime and risk because it replaces all instances at once, potentially taking the application fully offline and making rollback slower.

Rolling (A) reduces downtime compared to all-at-once, but instances are still updated in-place; if issues appear mid-deployment, rollback is more complex and slower than swapping environments.

Rolling with additional batches (B) can further reduce capacity impact by adding extra instances during deployment, but rollback still involves reversing updates in the same environment and is typically slower than blue/green.

Therefore, deploying to a new environment and using blue/green provides the least downtime and the fastest rollback.

This solution allows the Lambda function to be invoked by the DynamoDB stream whenever updates are made to items in the DynamoDB table. Event source mapping is a feature of Lambda that enables a function to be triggered by an event source, such as a DynamoDB stream, an Amazon Kinesis stream, or an Amazon Simple Queue Service (SQS) queue. The developer can configure event source mapping for the Lambda function using the AWS Management Console, the AWS CLI, or the AWS SDKs. Changing the StreamViewType parameter value to NEW_AND_OLD_IMAGES for the DynamoDB table will not affect the invocation of the Lambda function, but only change the information that is written to the stream record. Mapping an Amazon Simple Notification Service (Amazon SNS) topic to the DynamoDB stream will not invoke the Lambda function directly, but require an additional subscription from the Lambda function to the SNS topic. Increasing the maximum runtime (timeout) setting of the Lambda function will not affect the invocation of the Lambda function, but only change how long the function can run before it is terminated.

Storing secrets in environment variables encrypted with AWS KMS is a standard secure practice for Lambda. By using a Customer Managed Key (CMK), you can audit every decryption request via CloudTrail. This ensures the keys are never in plaintext in the management console or code. Options B and C are highly insecure as they expose keys in URLs or client-side code. Tags (Option D) are not meant for sensitive secrets and are not encrypted.

Step-by-Step Breakdown:

Requirement Summary:

AWS AppSync API needs to invoke Lambda functions

Some Lambda functions are long-running

AppSync should return immediately, minimizing operational overhead

**Option A: AppSync + Lambda as data source using Event Mode

Correct: AWS AppSync supports asynchronous (event) invocation of Lambda data sources using Event Mode.

Event Mode means:

AppSync invokes Lambda asynchronously

Immediately returns a response to the client (typically a predefined payload or null)

Ideal for fire-and-forget workloads or when the response is not immediately needed

Option B: Increase Lambda timeout

Incorrect: This keeps AppSync waiting.

Even with increased timeout, synchronous invocations would block AppSync responses.

Option C: SQS queue + polling Lambda

Possible but too complex for this use case.

Requires additional infrastructure: queue + mapping + custom logic.

Higher operational overhead compared to built-in AppSync Event Mode.

Option D: Enable caching in AppSync

Irrelevant: AppSync cache is for optimizing repeated read queries, not for async workflows.

Asynchronous Lambda with AppSync: https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-lambda.html#async-lambda-invocation

Lambda as AppSync Data Source: https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-lambda-resolvers.html

Event Mode Docs: https://docs.aws.amazon.com/appsync/latest/devguide/lambda-resolvers.html#event-invocation-mode

DynamoDB Streams: Capture near real-time changes to DynamoDB tables, triggering downstream actions.

Lambda for Processing: Lambda functions provide a serverless way to execute code in response to events like DynamoDB Stream updates.

Minimal Code Changes: This solution requires the least modifications to the existing application.

AWS Secrets Manager is specifically designed for sensitive information like database credentials. It supports automatic rotation and cross-account access. Using the " AWS Parameters and Secrets Lambda Extension " is the modern, high-performance way to retrieve secrets. It caches the secret locally in the Lambda execution environment, reducing latency and cost (API call volume) while ensuring the credentials are not stored in plaintext in environment variables or source code.

Step Functions Retriers: Retriers provide a built-in way to gracefully handle transient errors within State Machines. Here ' s how to use them:

Directly attach a retrier to the problematic ' GetResource ' task.

Configure the retrier:

ErrorEquals: Set this to [ ' TooManyRequestsException ' ] to target the specific error.

IntervalSeconds: Set to 10 for the desired retry delay.

MaxAttempts: Set to 1, as you want only one retry attempt.

Error Handling:

Upon ' TooManyRequestsException ' , the retrier triggers the task again after 10 seconds.

On a second failure, Step Functions moves to the next state or fails the workflow, as per your design.

' IllegalArgumentException ' causes error propagation as intended.

Requirement Summary:

Lambda function accesses RDS for MySQL

Credentials are currently hardcoded in code (insecure)

Must enable automated credential rotation every 30 days

Option A: Use AWS Secrets Manager + automatic rotation

Best and secure option

Secrets Manager allows:

Secure storage of secrets

Integration with RDS for automatic rotation

Scheduled rotation every X days (e.g., 30 days)

Lambda can fetch credentials via SDK (GetSecretValue)

Option B: Use SSM Parameter Store + rotation

SSM does not support automatic rotation of secrets.

You ' d need to build custom rotation logic = higher operational overhead.

Option C: Encrypted S3 + Object Lambda rotation

Not intended for credential storage.

S3 is not a secrets management system, and Object Lambda does not perform rotation.

Option D: SSM + EventBridge rotation

No native integration between Parameter Store and EventBridge for secret rotation.

You’d need to build custom Lambda functions = higher maintenance.

Secrets Manager rotation for RDS: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html

Secure retrieval in Lambda: https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html

Integration with RDS MySQL: https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_rds_config.html