Back to AWS Certified Developer - Associate (DVA-C02)

Development with AWS Services

Develop code for applications hosted on AWS, Lambda functions, and data store integrations (~32% of exam).

5 minutes 5 Questions

AWS Development Services encompass a comprehensive suite of tools and services that developers use to build, deploy, and manage applications in the cloud. For the AWS Certified Developer Associate exam, understanding these core services is essential. **Compute Services**: AWS Lambda enables server…

Concepts covered
Event-driven architectural patternsUnit testing with AWS SAMStrongly consistent readsDynamoDB consistency modelsMicroservices architectureMonolithic architectureChoreography vs orchestration patternsFanout patternStateful vs stateless applicationsTightly coupled vs loosely coupled componentsSynchronous vs asynchronous patternsFault-tolerant application developmentResilient application patternsCreating and maintaining APIsAPI response and request transformationsAPI validation rulesOverriding API status codesWriting code for messaging servicesAWS SDKs and APIsHandling streaming dataAmazon Kinesis Data StreamsAmazon Q DeveloperAmazon EventBridge for event-driven patternsEventBridge rules and targetsRetry logic implementationCircuit breaker patternError handling patternsLambda VPC access configurationLambda environment variablesLambda memory and timeout configurationLambda concurrency settingsLambda runtime and handler configurationLambda layersLambda extensionsLambda triggers and event sourcesLambda destinationsLambda event lifecycleLambda dead-letter queuesLambda testing strategiesLambda integration with AWS servicesLambda performance tuningLambda Provisioned ConcurrencyLambda data processing and transformationLambda real-time stream processingDynamoDB partition keysHigh-cardinality partition key designEventually consistent readsDynamoDB query operationsDynamoDB scan operationsDynamoDB primary keysDynamoDB global secondary indexesDynamoDB local secondary indexesData serialization and deserializationData persistence patternsManaging data storesData lifecycle managementAmazon ElastiCacheDAX (DynamoDB Accelerator)Caching strategiesAmazon OpenSearch ServiceChoosing data stores by access patterns
Test mode:
Start practice test
DVA-C02 - Development with AWS Services Example Questions

Test your knowledge of Development with AWS Services

Question 1

A government agency operates a citizen portal using AWS Lambda behind API Gateway that serves public records from Amazon DynamoDB. The portal handles 55,000 requests per minute during business hours, with 65% of requests targeting the same 400 frequently accessed documents. Document content is static once published, but new documents are added daily and must be searchable within 10 minutes of publication. The team uses ElastiCache for Redis with cache-aside pattern and 15-minute TTL. During a recent audit, they discovered that the cache stores document metadata and full content together, consuming 12GB of memory. Analysis shows that 80% of initial requests only need metadata (title, date, category) for search results, while 20% proceed to view full document content. The metadata averages 2KB while full content averages 150KB per document. Cache memory is at 85% utilization and evictions are increasing. The team wants to optimize memory usage by 60% while maintaining fast search response times and ensuring document content remains quickly accessible when users click through. Which caching architecture modification should the development team implement?

Correct Answer: Separate cache entries for metadata and content with different TTLs, storing metadata with 15-minute TTL and loading content entries on-demand with 10-minute TTL to reduce memory footprint

The correct solution is to separate cache entries for metadata and content with different TTLs, storing metadata with 15-minute TTL and loading content entries on-demand with 10-minute TTL.

This approach directly addresses all requirements:

Memory Optimization Analysis:
- Current state: 400 documents × (2KB metadata + 150KB content) = 400 × 152KB = ~60.8MB for frequently accessed docs
- With separation: Metadata always cached (400 × 2KB = 800KB) + Content on-demand for 20% of requests
- Since only 20% of requests need full content, content cache entries are loaded on-demand and can expire more quickly
- This achieves the 60%+ memory reduction target by not pre-caching content that may never be accessed

Why This Works:
1. 80% of requests only need metadata (2KB), so fast search response times are maintained
2. Content is loaded on-demand when users click through, remaining quickly accessible
3. Different TTLs allow fine-tuning of cache behavior for each data type
4. The cache-aside pattern already in use works seamlessly with this separation

Why Other Options Are Incorrect:

The tiered approach using DAX for metadata and ElastiCache for content adds unnecessary complexity and cost. DAX is specifically designed for DynamoDB caching but doesn't provide memory optimization benefits over properly structured Redis caching. Managing two cache systems with DynamoDB Streams synchronization introduces operational overhead without addressing the core memory utilization problem.

Compressing content using LZ4 before caching only reduces the size of individual entries but still caches content that may never be accessed (the 80% of requests that only need metadata). This doesn't achieve the 60% memory reduction target since you're still storing compressed content for all 400 documents regardless of access patterns.

Storing only document IDs in Redis and using CloudFront with Lambda@Edge fundamentally changes the architecture from a caching solution to a CDN solution. This would require significant refactoring, doesn't leverage the existing ElastiCache investment, and CloudFront is better suited for static content delivery rather than dynamic database-backed queries with the 10-minute freshness requirement for new documents.

Question 2

A cybersecurity firm is building a threat intelligence platform that processes security event logs from multiple enterprise clients. Each client's data flows through Amazon Kinesis Data Streams, where a consumer application correlates events to detect potential security breaches. The current architecture uses a standard consumer with the GetRecords API polling at 1-second intervals. During a recent security incident affecting one of their largest clients, the security analysts complained that threat alerts were arriving with a 15-20 second delay from when the events actually occurred. The development team confirmed that the Lambda processing time averages only 200ms per batch, and the stream has adequate shard capacity. The client generating the incident data sends approximately 4MB per second of logs. After investigation, the team discovered that three other consumer applications are also reading from the same stream for compliance logging, backup archival, and dashboard visualization purposes. What is causing the delayed threat detection, and which solution should the developer implement?

Correct Answer: The four consumers are sharing the 2MB per second per-shard read throughput limit, causing read throttling. Register the threat detection consumer as an enhanced fan-out consumer to receive dedicated throughput.

The correct answer identifies the root cause as multiple consumers sharing the limited read throughput of Kinesis Data Streams.

In Amazon Kinesis Data Streams, each shard has a read throughput limit of 2MB per second when using the standard GetRecords API. This limit is shared among ALL consumers reading from that shard. With four consumers (threat detection, compliance logging, backup archival, and dashboard visualization) all polling the same stream, each consumer effectively gets only a fraction of the available throughput.

The client is sending 4MB per second of logs, which means the stream likely has at least 2-4 shards. However, with four consumers sharing the read capacity, each consumer can only read about 0.5MB per second per shard (2MB ÷ 4 consumers). This creates a bottleneck where the threat detection application cannot keep up with the incoming data rate, causing the 15-20 second delay.

Enhanced Fan-Out (EFO) is the correct solution because it provides each registered consumer with a dedicated 2MB per second per-shard throughput that is NOT shared with other consumers. By registering the threat detection consumer as an EFO consumer, it will receive its own dedicated pipe of data with approximately 70ms latency (compared to ~200ms+ for standard consumers), eliminating the contention issue.

The Lambda concurrency explanation is incorrect because the problem states Lambda processing averages only 200ms per batch, indicating no processing bottleneck.

Reducing the polling interval to 200ms would actually violate Kinesis limits (GetRecords can be called at most 5 times per second per shard) and would not solve the throughput sharing problem.

Splitting shards increases write capacity but does not solve the fundamental issue of multiple consumers competing for shared read throughput on each shard - each new shard would still have the same shared 2MB/s read limit.

Question 3

A regional insurance company is migrating their claims processing system to AWS. The system stores claim documents and metadata in Amazon DynamoDB, with each claim containing policyholder information, claim status, adjuster notes, and payment details. Claims adjusters frequently update the status field and add notes as claims progress through review stages. The current implementation retrieves the entire claim document (average size 15KB), modifies the status or notes fields in the application, and writes the complete document back to DynamoDB. With 500 adjusters processing claims throughout the day, the system generates 25,000 update operations daily. The operations team has noticed that 90% of updates only modify 2-3 attributes while rewriting all 45 attributes in each claim record. Network bandwidth costs and write capacity consumption have exceeded budget projections. The team needs to optimize update operations to reduce both data transfer and write costs while preserving the complete claim history. Which DynamoDB persistence technique should the development team use to address this inefficiency?

Correct Answer: Use UpdateItem API with UpdateExpression to modify only the specific attributes being changed rather than replacing the entire item

The correct answer is to use UpdateItem API with UpdateExpression to modify only the specific attributes being changed rather than replacing the entire item.

This solution directly addresses the core inefficiency described in the scenario. The UpdateItem API with UpdateExpression allows you to update individual attributes of an item without retrieving or rewriting the entire document. This is the fundamental DynamoDB feature designed specifically for partial updates.

Key benefits of this approach:

  1. Reduced Write Capacity Consumption: DynamoDB charges for write capacity based on the size of the item being written. With UpdateExpression, you only consume capacity for the attributes being modified, not the entire 15KB document.

  2. Reduced Network Transfer: Instead of sending 15KB for each update operation, you only send the few attributes being changed (status and notes), dramatically reducing bandwidth costs.

  3. Atomic Updates: UpdateItem operations are atomic, ensuring data consistency without complex application logic.

  4. No Read-Modify-Write Pattern Needed: The current implementation reads the entire item, modifies it in the application, and writes it back. UpdateExpression eliminates the need to read the item first, reducing both read and write operations.

The other options are incorrect for the following reasons:

Using a separate table with TransactWriteItems adds unnecessary complexity and cost. It requires maintaining two tables, increases transaction overhead, and TransactWriteItems consumes additional capacity units. This doesn't solve the fundamental issue of updating attributes efficiently.

Using PutItem with conditional expressions still replaces the entire item, which is exactly the current problem. PutItem always writes the complete item regardless of how many attributes changed, so this would not reduce data transfer or write costs.

Configuring Global Tables distributes data across regions for disaster recovery and low-latency access in multiple regions, but it doesn't reduce the amount of data being written per operation. In fact, it would increase costs by replicating the inefficient full-document writes across multiple regions.

More Development with AWS Services questions
1770 questions (total)
Start 100 question test