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

The access restriction must be applied to the REST API, not merely to the static website bucket. API Gateway resource policies can control who can invoke an API and can restrict access by source IP address ranges or CIDR blocks. That directly satisfies the requirement that only computers from the corporate CIDR range can invoke the API. An S3 bucket policy would restrict access to the static website content, but the API endpoint could still be called directly unless API Gateway is also protected. An IAM service- linked role is not the correct control plane for client source IP filtering. Network ACLs apply at the subnet level inside a VPC and do not control public API Gateway invocation. AWS documentation confirms API Gateway resource policies support specified source IP address ranges. ( AWS Documentation )

===============

The most operationally efficient way to remove time-bound data from a DynamoDB table is to use Time to Live (TTL) . TTL is a DynamoDB feature that lets you define an attribute (typically a Unix epoch timestamp) that represents an item’s expiration time. After the timestamp has passed, DynamoDB automatically marks the item as expired and later deletes it in the background. This directly satisfies the requirement because the telemetry is only valuable for a limited time, yet it is currently stored indefinitely.

Enabling TTL (option C) improves performance and operational efficiency by preventing the table from growing without bounds. As the item count grows, access patterns that rely on scans, large partitions, or indexes can degrade, and storage-related overhead increases. TTL helps keep the dataset “fresh” by automatically removing stale telemetry, reducing the amount of data the application must work around and decreasing overall storage footprint.

Option A is operationally heavier: scanning and deleting items with a scheduled Lambda introduces ongoing maintenance, costs, and risk of throttling (table scans can be expensive and disruptive). It also requires custom logic, error handling, and retries. Option B addresses cost optimization for archived data but does not fix the DynamoDB table size or the performance degradation caused by keeping old data in the table; archiving is useful, but you still need an efficient deletion mechanism from DynamoDB. Option D (on-demand capacity mode) changes how capacity is managed, not how much data is stored; it does not remove stale items and therefore does not address the core problem.

Therefore, the best and most operationally efficient solution is C : add a TTL attribute to each telemetry item and enable TTL on the DynamoDB table so DynamoDB automatically expires and deletes old telemetry.

This solution will meet the requirements by creating a single S3 bucket policy that denies access to the S3 bucket unless the request comes from one of the specified VPC endpoints. The aws:SourceVpce condition key is used to match the ID of the VPC endpoint that is used to access the S3 bucket. The StringNotEquals condition operator is used to negate the condition, so that only requests from the listed VPC endpoints are allowed. Option A is not optimal because it will create multiple S3 bucket policies, which is not possible as only one bucket policy can be attached to an S3 bucket. Option B is not optimal because it will use the aws:SourceVpc condition key, which matches the ID of the VPC that is used to access the S3 bucket, not the VPC endpoint. Option C is not optimal because it will use the StringNotEquals condition operator with a single value, which will deny access to the S3 bucket from all VPC endpoints except one.

For asynchronous Lambda invocations, AWS provides Lambda Destinations , which can route the result of every invocation to different targets based on outcome. Destinations support separate configuration for on-success and on-failure , and they send a structured payload that includes metadata and the function response (or error information). This payload is delivered as a JSON document , satisfying the requirement to record function responses in JSON format while also capturing every invocation record.

Option B matches this pattern directly: configure an on-failure destination (S3) and an on-success destination (SNS). With this configuration, each async invocation that succeeds results in a JSON record being delivered to the SNS topic, enabling downstream processing, notifications, or fan-out to other services. Each async invocation that fails results in a JSON record being delivered to S3, which provides durable, cost-effective storage for later analysis or replay workflows. This design requires minimal code changes because the routing is handled by Lambda’s destination configuration rather than custom logic in the function.

Option C relies on a DLQ for failures but then requires custom code to store success records in DynamoDB, increasing development effort and operational complexity. Option A is not aligned: canary deployments and log groups do not provide “multiple destinations per invocation outcome,” and CloudWatch Logs do not natively separate success/failure records as destinations with structured invocation payloads. Option D proposes OpenSearch as a success destination, but Lambda Destinations do not use OpenSearch directly as a destination target; the supported destination types are typically SQS, SNS, EventBridge, and Lambda , and you can store records in S3 through other integrations. Therefore, the best match that uses built-in destinations and records JSON invocation results is B .

An Inline Policy is a policy that is embedded directly into an IAM user, group, or role. When you use an inline policy, you maintain a strict one-to-one relationship between the policy and the identity. Since the requirement is to grant a specific " permanent " right to only one specific user within a group without changing the shared group policy, an inline policy attached directly to that individual user is the correct approach.

Requirement Summary:

NLP Lambda function with a large pre-trained model

Lambda layer became 8.7 GB → Exceeds AWS limits

Function returns RequestEntityTooLargeException

Need: High-performing, portable, low initialization time

Important AWS Limits:

Lambda Layers size limit (combined across all layers): 250 MB (unzipped)

Deployment package size (unzipped): 250 MB

Lambda container image support allows up to 10 GB image size

Evaluate Options:

A: Store model in S3 and load during execution

Leads to cold start latency every time

Model loading from S3 is slower and not suitable for real-time NLP

Not optimal for performance

B: Use EFS mounted to Lambda

⚠️ Valid for large models, but adds latency during cold start as model loads from EFS

Requires EFS setup, VPC, and has added network I/O overhead

Still slower than bundling in container image

C: Split into five Lambda layers

Still violates the total layer size limit of 250 MB (unzipped)

You cannot exceed that even with multiple layers

D: Use Docker container image

Allows bundling up to 10 GB of dependencies and models

High portability and performance

Avoids latency of downloading models at runtime

Ideal for scientific/NLP models

Lambda container image support: https://docs.aws.amazon.com/lambda/latest/dg/images-create.html

Lambda limits: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

Using large models with Lambda: https://aws.amazon.com/blogs/machine-learning/deploying-large-machine-learning-models-on-aws-lambda-with-container-images/

For in-place deployments, AWS CodeDeploy uses a set of predefined hooks that run in a specific order during each deployment lifecycle event. The hooks are ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. The run order of the hooks for in-place deployments is as follows:

ApplicationStop: This hook runs first on all instances and stops the current application that is running on the instances.

BeforeInstall: This hook runs after ApplicationStop on all instances and performs any tasks required before installing the new application revision.

AfterInstall: This hook runs after BeforeInstall on all instances and performs any tasks required after installing the new application revision.

ApplicationStart: This hook runs after AfterInstall on all instances and starts the new application that has been installed on the instances.

ValidateService: This hook runs last on all instances and verifies that the new application is running properly on the instances.

This solution will solve the deployment issue by deploying the new version of the application to one new EC2 instance at a time, while keeping the old version running on the existing instances. This way, there will always be at least four instances serving traffic during the deployment, and no downtime or performance degradation will occur. Option A is not optimal because it will increase the cost of running the Elastic Beanstalk environment without solving the deployment issue. Option B is not optimal because it will split the traffic between two versions of the application, which may cause inconsistency and confusion for the customers. Option D is not optimal because it will deploy the new version of the application to two existing instances at a time, which may reduce the capacity below four instances during the deployment.

The simplest and most efficient way to avoid hardcoding configuration such as a DynamoDB table name is to use Lambda environment variables. Environment variables are designed for runtime configuration and allow changing values without updating application code logic. The developer can store the table name in an environment variable (for example, TABLE_NAME) and read it from the runtime environment using the standard language method (such as os.environ in Python, process.env in Node.js, etc.).

This approach has very low operational overhead: updating the table name becomes a configuration change (in the Lambda console, IaC templates, or CI/CD pipeline) rather than a code change. It also keeps deployment packages stable and avoids unnecessary dependencies.

Option B is not suitable because /tmp is ephemeral storage that can be cleared between invocations and is not intended for configuration management.

Option C is heavier than necessary. Lambda layers are great for shared libraries and dependencies, but using a layer to store a single changing table name is awkward and forces a layer update and function reconfiguration when the value changes.

Option D does not solve the problem because a global variable is still set in the code. If the table name changes, the code must still be modified and redeployed.

Therefore, storing the table name in a Lambda environment variable is the most efficient solution.

AWS CodeArtifact publishes events to Amazon EventBridge when a package is created, modified, or deleted. The most operationally efficient (serverless) way to send an email notification from an EventBridge event is to set an Amazon SNS topic as the target. The team subscribes to the SNS topic. This avoids the need to write and maintain custom Lambda code (Option B) or Step Functions (Option D).

Amazon SQS provides server-side encryption (SSE) to protect messages at rest by using AWS Key Management Service (AWS KMS). When SSE is enabled on an SQS queue, all messages are encrypted automatically before they are stored and decrypted only when they are retrieved by authorized consumers.

AWS documentation states that SSE for SQS transparently encrypts the entire message payload , including the message body and message attributes. This ensures that sensitive data is protected without requiring changes to application code or custom encryption logic.

Option A enforces encryption in transit , not at rest. Option B is invalid because SSE is configured at the queue level, not inside message payloads. Option D does not improve security because message attributes are also stored as part of the message and require SSE to be protected.

Enabling SSE on the queue is the simplest, most secure, and AWS-recommended solution. It ensures compliance with encryption requirements while minimizing operational overhead.

Comprehensive Detailed and Lengthy Step-by-Step Explanation with All AWS Developer References:

1. Understanding the Use Case:

The company wants to gradually release a new feature to 15% of users to perform testing. AWS AppConfig is designed to manage and deploy configurations, including feature flags, allowing controlled rollouts.

2. Key AWS AppConfig Features:

Feature Flags: Enable or disable features dynamically without redeploying code.

Variants: Define different configurations for subsets of users.

Targeting Rules: Specify rules for which users receive a particular variant.

3. Explanation of the Options:

Option A: " Set up a custom script within the application to randomly select 15% of users. Assign a flag for the new feature to the selected users. " While possible, this approach requires significant operational effort to manage user selection and ensure randomness. It does not leverage AWS AppConfig ' s built-in capabilities, which increases overhead.

Option B: " Create separate AWS AppConfig feature flags for both groups of users. Configure the flags to target 15% of users. " Creating multiple feature flags for different user groups complicates configuration management and does not optimize the use of AWS AppConfig.

Option C: " Create an AWS AppConfig feature flag. Define a variant for the new feature, and create a rule to target 15% of users. " This is the correct solution. Using AWS AppConfig feature flags with variants and targeting rules is the most efficient approach. It minimizes operational overhead by leveraging AWS AppConfig ' s built-in targeting and rollout capabilities.

Option D: " Use AWS AppConfig to create a feature flag without variants. Implement a custom traffic splitting mechanism in the application code. " This approach requires custom implementation within the application code, increasing complexity and operational effort.

4. Implementation Steps for Option C:

Set Up AWS AppConfig:

Open the AWS Systems Manager Console.

Navigate to AppConfig.

Create a Feature Flag:

Define a new configuration for the feature flag.

Add variants (e.g., " enabled " for the new feature and " disabled " for no change).

Define a Targeting Rule:

Use percentage-based targeting to define a rule that applies the " enabled " variant to 15% of users.

Targeting rules can use attributes like user IDs or geographic locations.

Deploy the Configuration:

Deploy the configuration using a controlled rollout to ensure gradual exposure.

Centralized logging for microservices means collecting application logs from many services into a single managed logging backend where logs can be searched, retained, and monitored. For containerized microservices on AWS, the standard approach is to send each service’s stdout/stderr logs to Amazon CloudWatch Logs.

Option A is the appropriate solution: create separate CloudWatch Logs streams (and typically log groups) per microservice. This scales naturally as microservices increase, supports retention policies, metric filters, alarms, and integrations with tools like CloudWatch Logs Insights for querying across services. Container orchestrators (ECS/EKS) can be configured to use the CloudWatch Logs log driver so logs are shipped automatically without custom log shipping agents.

Option B (CloudTrail) logs AWS API activity, not application logs.

Option C (VPC Flow Logs) captures network flow metadata, not application-level logs.

Option D (Cloud Map) is service discovery, not logging.

Therefore, using CloudWatch Logs streams per microservice is the correct central logging approach.