Visit here for our full Amazon AWS Certified Developer – Associate DVA-C02 exam dumps and practice test questions.
Question 1:
Which AWS service allows you to run code without provisioning or managing servers?
A) Amazon EC2
B) AWS Lambda
C) Amazon ECS
D) AWS Elastic Beanstalk
Answer: B
Explanation:
AWS Lambda is a serverless compute service that allows developers to run code without provisioning or managing servers. Lambda automatically handles all the infrastructure management tasks including server and operating system maintenance, capacity provisioning, automatic scaling, code monitoring, and logging. Developers simply upload their code, and Lambda takes care of everything required to run and scale the code with high availability. This serverless architecture enables developers to focus on writing application logic rather than managing infrastructure.
Lambda operates on an event-driven execution model where code runs in response to triggers from various AWS services or custom applications. When an event occurs, Lambda automatically provisions the compute resources needed to execute the function, runs the code, and then deallocates resources when execution completes. This pay-per-use model means you only pay for the compute time consumed, measured in milliseconds, rather than paying for continuously running servers. Lambda supports multiple programming languages including Python, Node.js, Java, C#, Go, Ruby, and custom runtimes.
The service provides automatic scaling capabilities that can handle from a few requests per day to thousands of requests per second without any manual intervention. Each function execution runs in an isolated environment with its own resources and file system. Lambda integrates seamlessly with other AWS services including S3 for storage events, DynamoDB for database triggers, API Gateway for HTTP requests, SNS for notifications, CloudWatch for monitoring, and many others. Common use cases include real-time file processing, data transformation, backend APIs, automation tasks, and IoT data processing.
Option A is incorrect because Amazon EC2 requires provisioning and managing virtual server instances, including capacity planning, patching, and scaling configuration. Option C is incorrect because Amazon ECS is a container orchestration service that still requires managing underlying infrastructure or Fargate capacity. Option D is incorrect because while Elastic Beanstalk reduces infrastructure management complexity, it still involves server provisioning and is not fully serverless like Lambda.
Question 2:
What is the maximum execution duration for an AWS Lambda function?
A) 5 minutes
B) 10 minutes
C) 15 minutes
D) 30 minutes
Answer: C
Explanation:
The maximum execution duration for an AWS Lambda function is 15 minutes (900 seconds). This timeout limit applies to each individual function invocation and represents the maximum amount of time Lambda will allow a function to run before forcibly terminating it. Developers can configure the timeout value for their functions anywhere from 1 second up to the 15-minute maximum, depending on the expected execution time of their code. Setting an appropriate timeout value is important for preventing functions from running indefinitely due to bugs or unexpected conditions while also ensuring legitimate long-running operations have sufficient time to complete.
When a Lambda function exceeds its configured timeout, Lambda terminates the execution and returns a timeout error. Any work the function was performing remains incomplete, and if the function was processing an event from a stream like Kinesis or DynamoDB Streams, that event may be retried. Understanding timeout behavior is crucial for designing reliable serverless applications, particularly when implementing error handling, retry logic, and idempotency patterns. Functions that consistently approach or exceed timeout limits may need to be redesigned, perhaps by breaking large tasks into smaller functions or using AWS Step Functions to orchestrate longer workflows.
The 15-minute limit makes Lambda suitable for many common workloads including API backends, data processing, and automation tasks. However, for operations that genuinely require longer execution times such as complex batch processing, video transcoding, or large-scale data analysis, alternative AWS services may be more appropriate. Options include running containers on ECS or EKS, using EC2 instances, leveraging AWS Batch for batch computing workloads, or using Step Functions to coordinate multiple shorter Lambda executions into a longer workflow.
Developers should implement appropriate monitoring using CloudWatch metrics to track function duration and identify functions approaching timeout limits. CloudWatch Logs capture timeout events, making it possible to detect and troubleshoot timeout issues. Best practices include setting timeouts conservatively based on expected execution times, implementing proper error handling for timeout scenarios, and designing functions to complete within reasonable time frames.
Option A is incorrect because 5 minutes is below the actual maximum limit. Option B is incorrect because 10 minutes is also below the actual limit. Option D is incorrect because 30 minutes exceeds the current Lambda maximum execution duration of 15 minutes.
Question 3:
Which DynamoDB feature provides automatic scaling of read and write capacity?
A) Provisioned capacity mode
B) On-demand capacity mode
C) Reserved capacity mode
D) Burst capacity mode
Answer: B
Explanation:
On-demand capacity mode in Amazon DynamoDB provides automatic scaling of read and write capacity without requiring capacity planning or provisioning. In this mode, DynamoDB automatically accommodates workload increases and decreases, instantly scaling to handle any level of traffic. Tables using on-demand mode can serve thousands of requests per second without requiring developers to specify expected throughput levels, making it ideal for applications with unpredictable traffic patterns, variable workloads, or new applications where traffic patterns are unknown.
With on-demand mode, DynamoDB charges for actual read and write requests rather than provisioned capacity units. There is no minimum capacity requirement, and you pay only for what you use on a per-request basis. This eliminates the need for capacity planning and removes the risk of throttling due to insufficient provisioned capacity or paying for unused capacity during low-traffic periods. On-demand mode is particularly valuable for development and testing environments, applications with sporadic traffic, and workloads that experience sudden unpredictable spikes in demand.
DynamoDB tables using on-demand mode can handle up to double the previous peak traffic on the table. If a workload sustains a new peak level, DynamoDB adapts rapidly to accommodate the increased traffic. Tables can be switched between on-demand and provisioned capacity modes once per day, providing flexibility to optimize costs based on workload characteristics. For consistently high and predictable traffic, provisioned capacity mode with auto-scaling may offer better cost efficiency, but on-demand mode provides ultimate simplicity and eliminates capacity management overhead.
The service maintains the same single-digit millisecond latency, high availability, and durability regardless of capacity mode. Global tables, point-in-time recovery, and other DynamoDB features work identically in both capacity modes. Monitoring through CloudWatch provides visibility into request metrics, throttling events, and cost optimization opportunities.
Option A is incorrect because provisioned capacity mode requires explicitly configuring read and write capacity units, though it can use auto-scaling. Option C is incorrect because reserved capacity is a pricing option for provisioned capacity, not a capacity mode itself. Option D is incorrect because burst capacity is a temporary capacity buffer in provisioned mode, not an automatic scaling feature.
Question 4:
Which AWS service is used to store and retrieve Docker container images?
A) Amazon S3
B) Amazon ECR
C) Amazon ECS
D) AWS CodeArtifact
Answer: B
Explanation:
Amazon Elastic Container Registry (ECR) is a fully managed Docker container registry service that makes it easy to store, manage, share, and deploy Docker container images. ECR eliminates the need to operate your own container repositories or worry about scaling the underlying infrastructure. It is integrated with Amazon ECS and Amazon EKS, simplifying development to production workflows by allowing developers to push container images to ECR and then reference those images in container definitions for deployment.
ECR provides secure, scalable, and reliable container image storage with features including image encryption at rest using AWS KMS, image scanning for security vulnerabilities, lifecycle policies for automated image cleanup, cross-region and cross-account replication, and fine-grained access control using IAM policies. Images stored in ECR are automatically encrypted and highly available, distributed across multiple Availability Zones within a region. The service integrates with AWS Identity and Access Management to control who can access repositories and what actions they can perform, enabling secure team collaboration and CI/CD pipeline integration.
ECR supports both private repositories for storing proprietary images within your AWS account and public repositories through the Amazon ECR Public Gallery for sharing container images publicly. The service charges only for the amount of data stored in repositories and data transferred to the internet, with no upfront fees or commitments. Image lifecycle policies can automatically expire old or unused images to optimize storage costs. ECR also provides detailed CloudWatch metrics and events for monitoring repository activity and integrating with alerting systems.
Container images in ECR can be pulled by services running anywhere, including on-premises environments with appropriate network connectivity and authentication. The Docker CLI and other standard container tools work seamlessly with ECR using token-based authentication generated through the AWS CLI or SDK. This compatibility ensures ECR fits naturally into existing containerized development and deployment workflows.
Option A is incorrect because while S3 can technically store any data including container images, it is not specialized for container registry functionality and lacks features like image scanning and native container tool integration. Option C is incorrect because ECS is a container orchestration service that runs containers, not a registry for storing images. Option D is incorrect because CodeArtifact is designed for software package management (npm, Maven, etc.), not specifically for Docker container images.
Question 5:
What is the primary purpose of AWS CloudFormation?
A) To monitor application performance
B) To provision and manage AWS resources using infrastructure as code
C) To deploy application code to EC2 instances
D) To create backup snapshots of EBS volumes
Answer: B
Explanation:
AWS CloudFormation is a service that enables developers and system administrators to provision and manage AWS resources using infrastructure as code. CloudFormation allows you to define your entire infrastructure in template files using JSON or YAML format, describing all the AWS resources needed for your application including EC2 instances, RDS databases, S3 buckets, VPCs, security groups, and hundreds of other resource types. These templates serve as a single source of truth for infrastructure configuration and can be version-controlled, reviewed, and shared like any other code.
CloudFormation provides several key capabilities that make infrastructure management more efficient and reliable. The service handles resource creation in the correct order, automatically determining dependencies between resources to ensure components are created in the proper sequence. It manages the complexity of updating existing infrastructure by calculating the minimal set of changes needed and executing them safely. Rollback capabilities automatically revert changes if errors occur during stack creation or updates, maintaining infrastructure integrity. CloudFormation also supports parameterization, allowing the same template to be reused across different environments with environment-specific values.
Stacks are the fundamental unit in CloudFormation, representing a collection of AWS resources defined in a template and managed as a single unit. You can create, update, and delete entire stacks, and CloudFormation ensures all resources are properly coordinated. Change sets allow you to preview how proposed changes will affect running resources before executing updates, reducing the risk of unintended modifications. StackSets extend CloudFormation capabilities to deploy stacks across multiple AWS accounts and regions from a single operation, crucial for multi-account governance.
CloudFormation integrates with other AWS services including AWS Service Catalog for governed resource provisioning, AWS Config for compliance monitoring, and CloudWatch for operational monitoring. The service enables repeatable deployments, disaster recovery preparedness, infrastructure auditing, and consistent configuration across environments. Templates can be modularized using nested stacks and shared through the CloudFormation Registry.
Option A is incorrect because monitoring is handled by CloudWatch, not CloudFormation. Option C is incorrect because code deployment to EC2 is typically done with CodeDeploy or Elastic Beanstalk, though CloudFormation can define the infrastructure. Option D is incorrect because backup snapshots are managed through AWS Backup or EC2 snapshot features, not CloudFormation’s primary purpose.
Question 6:
Which S3 storage class is most cost-effective for infrequently accessed data that needs millisecond access?
A) S3 Standard
B) S3 Intelligent-Tiering
C) S3 Standard-IA
D) S3 Glacier
Answer: C
Explanation:
S3 Standard-IA (Infrequent Access) is the most cost-effective S3 storage class specifically designed for data that is accessed less frequently but requires rapid access when needed. Standard-IA provides millisecond access times identical to S3 Standard but at a significantly lower storage cost, making it ideal for data that needs to remain immediately accessible but is not accessed regularly. This storage class is perfect for backups, disaster recovery files, long-term storage of data that occasionally needs to be retrieved quickly, and older data that must remain instantly accessible.
S3 Standard-IA offers the same high durability (99.999999999%), availability, and performance as S3 Standard, with data stored redundantly across multiple Availability Zones. The key difference is the pricing model: Standard-IA has lower storage costs than S3 Standard but charges a retrieval fee per GB retrieved and requires a minimum storage duration of 30 days and minimum object size of 128 KB. Objects deleted or transitioned before 30 days incur charges for the full 30 days, and objects smaller than 128 KB are charged as 128 KB. These characteristics make Standard-IA economical when access patterns are genuinely infrequent.
The storage class maintains immediate retrieval capabilities without the need for restoration or waiting periods, unlike Glacier storage classes which require hours for retrieval. This makes Standard-IA suitable for use cases where occasional immediate access is required but the frequency doesn’t justify S3 Standard costs. Examples include monthly reports that need instant access during audit periods, application logs retained for compliance that are rarely reviewed, and user-generated content that sees declining access over time but must remain available.
S3 Lifecycle policies can automatically transition objects from S3 Standard to Standard-IA based on age, enabling cost optimization without manual intervention. For example, you might configure a policy to move objects to Standard-IA 30 days after creation when access patterns typically decline. S3 analytics can help determine optimal transition timing by analyzing actual access patterns.
Option A is incorrect because S3 Standard is designed for frequently accessed data and costs more than Standard-IA. Option B is incorrect because while Intelligent-Tiering can be cost-effective, it adds monitoring and automation fees and is better for unpredictable access patterns. Option D is incorrect because S3 Glacier is for archival storage requiring hours for retrieval, not millisecond access.
Question 7:
What is the purpose of AWS X-Ray?
A) To scan code for security vulnerabilities
B) To analyze and debug distributed applications
C) To perform load testing on applications
D) To encrypt data at rest
Answer: B
Explanation:
AWS X-Ray is a distributed tracing service that helps developers analyze and debug distributed applications, particularly those built using microservices architecture. X-Ray provides end-to-end visibility into requests as they travel through your application, collecting data about the requests your application serves and providing tools to view, filter, and gain insights into that data. This capability is essential for understanding application behavior, identifying performance bottlenecks, troubleshooting errors, and optimizing application architecture in complex distributed systems.
X-Ray works by tracking requests from beginning to end as they flow through various components of your application including frontend web servers, backend services, databases, queues, and external APIs. The service creates a service map that visually represents the architecture and shows how components interact, including latency information and error rates for each component. Trace data captures detailed timing information for each service call, allowing developers to identify which component in a request path is causing slowness or errors. Segments represent work done by individual components, and subsegments provide more granular timing of operations within segments.
Integration with AWS services is straightforward, with automatic instrumentation available for many services. Applications running on Lambda, EC2, ECS, Elastic Beanstalk, and API Gateway can send trace data to X-Ray with minimal configuration. The X-Ray SDK is available for multiple programming languages including Java, Node.js, Python, Ruby, .NET, and Go, enabling developers to instrument custom application code. The SDK automatically captures information about incoming HTTP requests, downstream calls to AWS services, database queries, and outgoing HTTP calls. Developers can add custom annotations and metadata to traces for business-specific insights.
X-Ray’s analysis tools include filtering capabilities to search traces based on specific criteria, latency histograms to visualize response time distributions, and anomaly detection to identify unusual patterns. The service integrates with CloudWatch for alarms and metrics, enabling automated responses to application issues. X-Ray is particularly valuable for microservices architectures where traditional debugging approaches fail due to distributed nature and complex interdependencies.
Option A is incorrect because code security scanning is performed by services like CodeGuru Security or third-party tools. Option C is incorrect because load testing is performed by services or tools like AWS Fault Injection Simulator or external load testing tools. Option D is incorrect because data encryption is handled by KMS and service-specific encryption features.
Question 8:
Which AWS service provides a managed message queue for decoupling application components?
A) Amazon SNS
B) Amazon SQS
C) Amazon Kinesis
D) AWS Step Functions
Answer: B
Explanation:
Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables decoupling and scaling of distributed application components. SQS eliminates the complexity and overhead associated with managing and operating message-oriented middleware, allowing developers to focus on application logic rather than infrastructure. The service provides reliable, highly scalable hosted queues for storing messages as they travel between application components, ensuring that messages are not lost and enabling components to operate asynchronously and independently.
SQS offers two types of message queues: Standard queues provide maximum throughput, best-effort ordering, and at-least-once delivery, making them suitable for most use cases where occasional duplicate messages can be handled. FIFO (First-In-First-Out) queues provide exactly-once processing and strict ordering, essential for applications where message order is critical and duplicates would cause problems. Standard queues support nearly unlimited transactions per second, while FIFO queues support up to 3,000 messages per second with batching or 300 without batching.
The service provides several key features including message retention for up to 14 days with configurable retention periods, visibility timeout to prevent multiple consumers from processing the same message simultaneously, dead-letter queues for handling messages that cannot be processed successfully after multiple attempts, long polling to reduce cost and latency by allowing consumers to wait for messages to arrive, and delay queues to postpone message delivery. Messages can be up to 256 KB in size, with larger payloads supported through extended client library using S3.
SQS enables common architectural patterns including work queue distribution where producers add tasks to a queue and multiple worker processes consume and process tasks in parallel, load leveling where queues buffer requests during traffic spikes preventing downstream system overload, and resilience where systems continue accepting requests even when processing components are temporarily unavailable. The service integrates seamlessly with Lambda for event-driven serverless processing, with other AWS services through EventBridge, and with applications using AWS SDKs.
Option A is incorrect because SNS is a pub/sub notification service for message distribution to multiple subscribers, not a message queue. Option C is incorrect because Kinesis is designed for real-time data streaming and analytics, not asynchronous message queuing. Option D is incorrect because Step Functions orchestrates workflows but does not provide message queuing functionality.
Question 9:
What is the default visibility timeout for an Amazon SQS message?
A) 10 seconds
B) 30 seconds
C) 60 seconds
D) 120 seconds
Answer: B
Explanation:
The default visibility timeout for an Amazon SQS message is 30 seconds. The visibility timeout is a critical mechanism in SQS that prevents multiple consumers from processing the same message simultaneously. When a consumer retrieves a message from a queue, SQS does not delete the message but instead makes it temporarily invisible to other consumers for the duration of the visibility timeout. This gives the consuming application time to process and delete the message. If the message is not deleted within the visibility timeout period, it becomes visible again in the queue and can be received by another consumer.
Understanding visibility timeout behavior is essential for designing reliable message processing systems. The timeout value should be set appropriately based on how long message processing typically takes. If the timeout is too short, messages may become visible again before processing completes, potentially resulting in duplicate processing. If the timeout is too long and a consumer fails, other consumers must wait unnecessarily before the message becomes available for retry. The visibility timeout can be configured per queue with values ranging from 0 seconds to 12 hours, and can also be changed for individual messages during processing using the ChangeMessageVisibility API.
Applications processing messages should implement appropriate patterns to handle visibility timeout. For long-running tasks, consumers can extend the visibility timeout while processing continues, preventing the message from returning to the queue prematurely. When processing completes successfully, the message must be explicitly deleted using the DeleteMessage API. If processing fails and the message should be retried, the consumer can either let the visibility timeout expire naturally or explicitly change the timeout to zero, returning the message to the queue immediately.
The visibility timeout works in conjunction with other SQS features including receive count tracking, which counts how many times a message has been received, and dead-letter queues, which automatically move messages that cannot be processed successfully after a specified number of attempts. Together, these features enable robust error handling and prevent problematic messages from blocking queue processing indefinitely.
Option A is incorrect because 10 seconds is shorter than the default timeout. Option C is incorrect because 60 seconds is double the actual default. Option D is incorrect because 120 seconds is four times the default timeout value.
Question 10:
Which AWS SDK method is used to upload objects to Amazon S3?
A) putObject
B) uploadObject
C) sendObject
D) storeObject
Answer: A
Explanation:
The putObject method is the standard AWS SDK method used to upload objects to Amazon S3 across all supported programming languages. This method provides the fundamental capability to store data in S3 buckets, accepting parameters including the bucket name, object key, file content or stream, and optional metadata such as content type, encryption settings, storage class, and custom metadata. The putObject method handles single-part uploads for objects and is the most commonly used method for uploading files to S3 in application code.
When using putObject, developers specify the target bucket and key (filename) along with the data to upload. The method supports various input sources depending on the programming language including file paths, byte arrays, streams, and buffers. Optional parameters allow controlling object properties such as ACL permissions, server-side encryption, caching directives, and content encoding. The method returns a response containing the ETag of the uploaded object, which serves as a unique identifier and can be used for verifying upload integrity or for conditional operations.
For large files, AWS SDKs provide higher-level abstractions like the TransferManager in Java or upload methods in other languages that automatically handle multipart uploads for improved performance and reliability. These methods break large files into smaller parts, upload them in parallel, and automatically retry failed parts. However, putObject remains the fundamental method and is perfectly suitable for smaller files and many common use cases. The method integrates with other S3 features including versioning, lifecycle policies, event notifications, and access logging.
Best practices for using putObject include implementing proper error handling for network issues or permission errors, setting appropriate content type metadata for proper browser handling, considering using presigned URLs for direct browser uploads to reduce server load, and implementing retry logic with exponential backoff for failed uploads. For applications uploading many files or large files, consider using multipart upload capabilities or transfer acceleration for better performance.
Option B is incorrect because uploadObject is not the standard method name in AWS SDKs. Option C is incorrect because sendObject is not used for S3 uploads. Option D is incorrect because storeObject is not a valid AWS SDK method for S3.
Question 11:
What is the maximum size of an item in Amazon DynamoDB?
A) 256 KB
B) 400 KB
C) 1 MB
D) 4 MB
Answer: B
Explanation:
The maximum size of an item in Amazon DynamoDB is 400 KB. This limit includes both the attribute names and their values, meaning the total size of all attributes within a single item cannot exceed 400 KB. This size constraint is an important consideration when designing DynamoDB table schemas and determining what data belongs together in a single item versus what should be separated into multiple items or stored in other services. Understanding this limit helps developers make appropriate design decisions for data modeling and application architecture.
The 400 KB item size limit affects several aspects of DynamoDB operations and design patterns. When calculating item size, attribute names contribute to the total, so using shorter attribute names can help maximize available space for actual data values. Binary data, strings, and nested attributes all count toward the limit. For applications needing to store data larger than 400 KB, common design patterns include storing large attributes in S3 and keeping only references in DynamoDB, splitting large items across multiple DynamoDB items using a composite key strategy, or using compression to reduce data size before storage.
DynamoDB’s flexible schema allows items within the same table to have different attributes and sizes, as long as each individual item remains under 400 KB. This flexibility enables storing varied data types in a single table while respecting size constraints. Applications should implement validation to ensure items do not exceed the size limit, as attempts to write oversized items result in validation exceptions. Monitoring average and maximum item sizes helps identify potential issues before they cause errors in production.
The item size limit also impacts capacity consumption and costs. Read and write capacity units in provisioned mode are calculated based on item size, with each write capacity unit supporting one write per second for items up to 1 KB, and larger items consuming multiple capacity units proportionally. Query and scan operations return data in 1 MB pages, so the number of items per page varies based on item size. Understanding these relationships helps optimize both performance and costs.
Option A is incorrect because 256 KB is below the actual maximum item size. Option C is incorrect because 1 MB exceeds the DynamoDB item size limit. Option D is incorrect because 4 MB is significantly larger than the actual 400 KB limit.
Question 12:
Which AWS service provides serverless API management and creation?
A) Amazon Route 53
B) AWS API Gateway
C) Amazon CloudFront
D) AWS AppSync
Answer: B
Explanation:
AWS API Gateway is a fully managed service that makes it easy to create, publish, maintain, monitor, and secure APIs at any scale, providing comprehensive serverless API management capabilities. API Gateway acts as a front door for applications to access data, business logic, or functionality from backend services including Lambda functions, EC2 instances, or any web application. The service handles all tasks involved in accepting and processing concurrent API calls including traffic management, authorization and access control, monitoring, and API version management, enabling developers to focus on application logic rather than infrastructure.
API Gateway supports three types of APIs: REST APIs provide full-featured API management with resource-based policies and extensive customization options; HTTP APIs offer a simplified, lower-cost option optimized for building proxy APIs to Lambda or HTTP backends with reduced latency and lower pricing; and WebSocket APIs enable real-time two-way communication for applications like chat, streaming dashboards, and real-time notifications. Each API type is optimized for different use cases, with REST APIs providing maximum flexibility and HTTP APIs offering the best performance and cost for simpler requirements.
The service provides extensive features including request and response transformation to modify data formats between clients and backends, throttling and rate limiting to protect backend services from traffic spikes, multiple authentication mechanisms including IAM, Cognito, Lambda authorizers, and API keys, deployment stages for managing multiple versions and environments, request validation to catch errors before they reach backends, and comprehensive monitoring through CloudWatch metrics and logs. Integration with AWS WAF provides protection against common web exploits and bots.
API Gateway enables several important architectural patterns including creating microservices APIs by routing different API paths to different Lambda functions, building serverless backends where API Gateway and Lambda eliminate all server management, implementing API versioning to evolve APIs without breaking existing clients, and caching responses to reduce load on backends and improve latency. The service integrates seamlessly with other AWS services including Lambda for compute, Cognito for user authentication, CloudFormation for infrastructure as code, and X-Ray for distributed tracing.
Option A is incorrect because Route 53 is a DNS service, not for API management. Option C is incorrect because CloudFront is a CDN for content delivery, not API management. Option D is incorrect because while AppSync provides GraphQL API capabilities, API Gateway is the primary service for general API management including REST and HTTP APIs.
Question 13:
What is the purpose of AWS Secrets Manager?
A) To encrypt data in transit
B) To securely store and rotate secrets like database credentials and API keys
C) To manage SSL certificates
D) To create IAM policies
Answer: B
Explanation:
AWS Secrets Manager is a secrets management service that helps protect access to applications, services, and IT resources by enabling secure storage, retrieval, and automated rotation of secrets such as database credentials, API keys, OAuth tokens, and other sensitive configuration data. Secrets Manager eliminates the need to hardcode sensitive information in application code or configuration files, reducing security risks and simplifying secrets management across the application lifecycle. The service provides centralized secrets management with fine-grained access control, audit logging, and automatic rotation capabilities.
One of the key features of Secrets Manager is automatic secret rotation, which can change credentials on a defined schedule without requiring application downtime or manual intervention. For supported databases including Amazon RDS, Amazon Redshift, and Amazon DocumentDB, Secrets Manager provides built-in rotation functions that automatically change credentials and update database permissions. Custom rotation functions can be implemented using Lambda for any other secret type, enabling rotation of API keys, third-party service credentials, or custom authentication mechanisms. Automatic rotation significantly improves security by ensuring credentials change regularly without operational burden.
Secrets Manager integrates deeply with other AWS services through IAM for access control, CloudWatch for monitoring and alerting, CloudTrail for audit logging of secret access, VPC endpoints for private connectivity without internet access, and SDKs and CLI for programmatic access. Applications retrieve secrets at runtime using the Secrets Manager API, ensuring they always have current credentials even after rotation occurs. The service handles the complexity of secret versioning automatically, allowing zero-downtime transitions between old and new secret values during rotation.
The service provides several capabilities that simplify secrets management including encryption at rest using AWS KMS with customer-managed keys, replication across multiple AWS regions for disaster recovery and low-latency access, resource-based policies for cross-account access, and tagging for organization and cost tracking. Secrets Manager charges per secret stored per month and per API call, making cost management straightforward. The service is particularly valuable for applications requiring compliance with standards that mandate credential rotation and access auditing.
Option A is incorrect because encrypting data in transit is handled by TLS/SSL protocols, not Secrets Manager’s primary purpose. Option C is incorrect because SSL certificate management is primarily handled by AWS Certificate Manager. Option D is incorrect because IAM policy creation is done through IAM service, not Secrets Manager.
Question 14:
Which method is used to retrieve an item from a DynamoDB table by its primary key?
A) getItem
B) query
C) scan
D) fetchItem
Answer: A
Explanation:
The getItem method is the most efficient way to retrieve a single item from a DynamoDB table when you know the complete primary key (partition key and sort key if applicable). This method provides direct, low-latency access to items by performing a read operation that targets exactly one item using the primary key. GetItem is significantly more efficient and faster than query or scan operations because it directly accesses the specific item location within the table’s storage using the key, consuming minimal read capacity and providing consistent single-digit millisecond latency.
When using getItem, you must specify the complete primary key for the item you want to retrieve. For tables with only a partition key, you provide that key value. For tables with a composite primary key consisting of both partition key and sort key, you must provide both values. The method returns the entire item with all its attributes by default, but you can use projection expressions to retrieve only specific attributes, reducing data transfer and potentially lowering costs. GetItem supports both eventually consistent and strongly consistent reads, with strongly consistent reads providing the most up-to-date data at slightly higher cost.
The getItem operation consumes read capacity units based on the item size and consistency type specified. One strongly consistent read of an item up to 4 KB consumes one read capacity unit, while eventually consistent reads consume half a read capacity unit for the same item. Larger items consume additional capacity units proportionally. For retrieving multiple items by their keys, the batchGetItem method provides more efficient batch processing, retrieving up to 100 items or 16 MB of data in a single request across one or more tables.
Best practices for using getItem include implementing appropriate error handling for cases where items do not exist, using projection expressions to retrieve only needed attributes, choosing appropriate consistency levels based on application requirements, and considering caching frequently accessed items at the application layer to reduce database calls. For applications needing to retrieve items based on non-key attributes or ranges of values, query or scan operations are more appropriate than getItem.
Option B is incorrect because query is used to retrieve multiple items based on partition key and optional filter conditions, not a single item by complete primary key. Option C is incorrect because scan reads entire tables and is the least efficient retrieval method. Option D is incorrect because fetchItem is not a valid DynamoDB method name.
Question 15:
What is the purpose of an AWS Lambda layer?
A) To add additional compute capacity to functions
B) To share code and dependencies across multiple Lambda functions
C) To encrypt function code
D) To increase function timeout limits
Answer: B
Explanation:
AWS Lambda layers are a distribution mechanism for libraries, custom runtimes, and other function dependencies that allows sharing code and dependencies across multiple Lambda functions. Layers enable developers to package shared components separately from function code, reducing deployment package sizes, promoting code reuse, and simplifying dependency management across multiple functions. When a function uses a layer, Lambda extracts the layer contents into the /opt directory in the function’s execution environment, making libraries and dependencies available to the function code without including them in the deployment package.
Lambda layers provide several significant benefits for serverless application development. They reduce deployment package size by separating large dependencies from function code, enabling faster uploads and deployments. Layers promote code reuse and consistency by allowing multiple functions to share the same libraries, SDKs, or custom code, ensuring all functions use identical versions of shared dependencies. Layer updates can be deployed independently of function code, allowing dependency updates without modifying or redeploying function code. Layers can be shared across AWS accounts by granting appropriate permissions, facilitating standardization across organizations.
Each Lambda function can reference up to five layers, and the total unzipped size of the function and all layers must not exceed 250 MB. Layers are versioned, and functions reference specific layer versions, providing control over when dependency updates are adopted. Common use cases for layers include packaging large libraries like machine learning frameworks that rarely change, sharing custom utilities or helper functions across multiple functions in a microservices architecture, providing custom runtimes for unsupported programming languages, and centralizing configuration or policy code that needs consistency across functions.
Creating and managing layers involves packaging dependencies with appropriate directory structure, publishing layers to Lambda, and granting permissions for functions or accounts to use layers. AWS provides some public layers for common use cases, and organizations can create private layers for internal use. Best practices include organizing layers by update frequency (grouping stable dependencies separately from frequently changing ones), maintaining clear version documentation, testing layer updates thoroughly before deploying to production functions, and monitoring layer usage across the account to optimize costs and performance.
Option A is incorrect because layers do not add compute capacity; memory and CPU allocation are controlled by function memory configuration. Option C is incorrect because encryption is handled by Lambda’s encryption features and KMS, not layers. Option D is incorrect because timeout limits are configured per function and cannot be increased using layers.
Question 16:
Which service would you use to implement user authentication and authorization for a mobile application?
A) AWS IAM
B) Amazon Cognito
C) AWS Directory Service
D) AWS Single Sign-On
Answer: B
Explanation:
Amazon Cognito is the AWS service specifically designed to implement user authentication and authorization for mobile and web applications. Cognito provides a complete identity solution including user sign-up, sign-in, access control, and integration with social identity providers and enterprise identity systems. The service eliminates the need to build and maintain custom authentication infrastructure, providing scalable, secure user management that handles millions of users while meeting compliance requirements including HIPAA, PCI DSS, SOC, and ISO standards.
Cognito consists of two main components: User Pools and Identity Pools. User Pools provide user directory services with built-in sign-up and sign-in capabilities, customizable UI for authentication flows, multi-factor authentication, email and phone verification, password policies, and account recovery mechanisms. User Pools support federation with social identity providers like Facebook, Google, and Amazon, as well as SAML-based enterprise identity providers. Users sign in to User Pools and receive JWT tokens that applications use to authorize access to resources. The service handles all aspects of token generation, validation, and refresh automatically.
Identity Pools (formerly Federated Identities) provide AWS credentials to users so they can access AWS services directly from client applications. Identity Pools support both authenticated users from User Pools or third-party providers and unauthenticated guest users. The service exchanges user tokens for temporary AWS credentials using STS, with permissions defined by IAM roles. This enables mobile and web applications to access services like S3, DynamoDB, or Lambda directly without proxying requests through backend servers, improving performance and reducing infrastructure costs.
Cognito provides additional features including adaptive authentication that uses device and session information to assess risk, advanced security features for protecting against compromised credentials, user migration capabilities for moving existing user bases to Cognito, custom authentication flows for specialized requirements, and trigger points for Lambda functions to customize authentication workflows. The service integrates seamlessly with API Gateway for protecting REST APIs, ALB for application authentication, and AppSync for GraphQL APIs. Pricing is based on monthly active users with a generous free tier, making it cost-effective for applications of all sizes.
Option A is incorrect because IAM is designed for AWS resource access by AWS services and internal users, not end-user application authentication. Option C is incorrect because Directory Service provides managed Microsoft Active Directory for enterprise scenarios, not mobile app authentication. Option D is incorrect because AWS SSO is for workforce identity management across AWS accounts and business applications, not customer-facing mobile apps.
Question 17:
What is the maximum size of a Lambda deployment package including layers?
A) 50 MB
B) 100 MB
C) 250 MB
D) 500 MB
Answer: C
Explanation:
The maximum unzipped size of a Lambda deployment package including all layers is 250 MB. This limit applies to the total size of the function code and all referenced layers when extracted in the Lambda execution environment. Understanding this size constraint is crucial for designing Lambda functions, particularly when using large libraries or dependencies. The 250 MB limit ensures Lambda functions start quickly and run efficiently, as larger deployment packages require more time to download and extract during cold start initialization.
There are actually several size limits for Lambda deployment packages that developers need to understand. The zipped deployment package that you upload directly can be up to 50 MB. For larger packages up to 250 MB unzipped, you must upload the package to S3 and reference it when creating or updating the function. The total size of all layers referenced by a function plus the function code cannot exceed 250 MB when unzipped. The /tmp directory available to functions during execution provides an additional 10 GB of temporary storage for downloading or generating files at runtime.
When deployment packages approach the size limits, several strategies can help reduce size including using Lambda layers to separate large, stable dependencies from frequently changing function code, removing unnecessary files and dependencies from deployment packages, using tree shaking or similar techniques to include only code actually used by the function, compressing files that will be decompressed at runtime, and considering containerized Lambda functions which support up to 10 GB container images for scenarios requiring very large dependencies.
Large deployment packages impact Lambda performance in several ways. Cold starts take longer because Lambda must download and extract the deployment package before executing the function. This cold start latency increases with package size and can affect user-facing applications requiring low latency. Network transfer time for deploying or updating functions increases with package size. However, runtime performance once the function is initialized is not directly affected by package size unless the code itself is inefficient.
For applications requiring dependencies larger than 250 MB, alternatives include using container-based Lambda functions which support up to 10 GB container images, mounting Amazon EFS file systems to Lambda functions for access to large data files or models, downloading dependencies from S3 to the /tmp directory during function initialization, or refactoring the application to use smaller, more focused functions.
Option A is incorrect because 50 MB is the limit for direct upload, not the total unzipped limit. Option B is incorrect because 100 MB does not correspond to any Lambda size limit. Option D is incorrect because 500 MB exceeds the actual unzipped deployment package limit.
Question 18:
Which AWS service provides continuous integration and continuous delivery capabilities?
A) AWS CodeCommit
B) AWS CodeBuild
C) AWS CodePipeline
D) AWS CodeDeploy
Answer: C
Explanation:
AWS CodePipeline is the service that provides comprehensive continuous integration and continuous delivery (CI/CD) capabilities by orchestrating and automating the entire software release process from source code changes to production deployment. CodePipeline enables developers to model, visualize, and automate the steps required to release software, ensuring that code changes flow through defined stages including source, build, test, and deployment consistently and reliably. The service integrates with various AWS and third-party tools to create complete CI/CD workflows tailored to specific application requirements.
A CodePipeline consists of stages, with each stage containing one or more actions that perform specific tasks. Source stages connect to repositories like CodeCommit, GitHub, or S3 to detect code changes and trigger pipeline execution. Build stages compile code, run unit tests, and create deployment artifacts using services like CodeBuild or Jenkins. Test stages execute integration tests, security scans, or other validation processes. Deploy stages push changes to environments using services like CodeDeploy, Elastic Beanstalk, ECS, or CloudFormation. Actions within stages can run sequentially or in parallel, and approval actions can require manual approval before proceeding to subsequent stages.
CodePipeline provides several key capabilities that make release automation reliable and efficient. The service automatically detects changes in source repositories and triggers pipeline execution, eliminating manual intervention. Pipeline execution history and artifact management maintain complete traceability of what code versions have been deployed. Integration with CloudWatch Events enables custom notifications and trigger mechanisms. The service supports multiple deployment strategies including blue/green deployments, rolling deployments, and canary deployments through integration with CodeDeploy. Failed pipeline executions can be retried from any stage without restarting the entire pipeline.
The service integrates seamlessly with the AWS developer tools ecosystem including CodeCommit for source control, CodeBuild for build automation, CodeDeploy for deployment automation, and CloudFormation for infrastructure deployment. Third-party integrations extend functionality to include GitHub, Jenkins, and many other popular tools. CodePipeline supports complex workflows including cross-region deployments, multi-account deployments, and conditional executions based on previous stage results. The service charges based on the number of active pipelines per month, with pricing that scales with usage.
Option A is incorrect because CodeCommit provides Git repository hosting, not complete CI/CD orchestration. Option B is incorrect because CodeBuild provides build and test execution but not full pipeline orchestration. Option D is incorrect because CodeDeploy handles deployment automation but not the entire CI/CD workflow integration.
Question 19:
What is the purpose of the AWS SDK for JavaScript?
A) To compile JavaScript code
B) To provide programmatic access to AWS services from JavaScript applications
C) To debug JavaScript applications
D) To minify JavaScript code
Answer: B
Explanation:
The AWS SDK for JavaScript provides programmatic access to AWS services from JavaScript applications running in browsers, Node.js, or other JavaScript runtime environments. The SDK enables developers to interact with AWS services by making API calls directly from their code, eliminating the need to construct HTTP requests manually or handle low-level communication details. The SDK handles authentication, request signing, error handling, retries, and data serialization, allowing developers to focus on application logic rather than AWS API implementation details.
The SDK is available in two versions: AWS SDK for JavaScript v2 and the newer AWS SDK for JavaScript v3 (modular architecture). Version 3 provides significant improvements including modular architecture allowing importing only needed service clients to reduce bundle size, first-class TypeScript support for improved developer experience, middleware stack for customizing request/response processing, and improved performance through better code splitting and tree shaking. Both versions support comprehensive service coverage across virtually all AWS services including compute, storage, databases, machine learning, analytics, and more.
Using the SDK involves installing the package via npm, configuring credentials through environment variables, credential files, or IAM roles, importing required service clients, and calling service methods using JavaScript promises or async/await syntax. For example, developers can use the S3 client to upload and download files, the DynamoDB client to read and write database items, the Lambda client to invoke functions, or the SQS client to send and receive messages. The SDK automatically handles regional endpoints, retries with exponential backoff, and request signing using the configured credentials.
The JavaScript SDK is particularly important for several use cases including serverless applications where Lambda functions written in Node.js interact with AWS services, frontend web applications using Cognito Identity Pool credentials to access AWS services directly from browsers, backend Node.js applications requiring AWS service integration, and React Native mobile applications communicating with AWS backends. The SDK enables building entirely serverless architectures where client applications interact directly with AWS services without traditional backend servers.
Best practices for using the SDK include implementing proper error handling for network and service errors, using environment variables or IAM roles for credentials rather than hardcoding them, implementing retry logic with exponential backoff for transient failures, monitoring API usage and costs through CloudWatch and billing alerts, and keeping the SDK updated to the latest version for security patches and new features.
Option A is incorrect because the SDK does not compile JavaScript code; compilation is handled by tools like Babel or TypeScript compiler. Option C is incorrect because debugging is done using browser developer tools or Node.js debugging capabilities. Option D is incorrect because code minification is performed by build tools like webpack or uglify, not the AWS SDK.
Question 20:
Which DynamoDB operation is most efficient for retrieving multiple items across multiple partition keys?
A) getItem
B) query
C) scan
D) batchGetItem
Answer: D
Explanation:
The batchGetItem operation is the most efficient method for retrieving multiple items when you know the primary keys of the items you want to retrieve, even if those items are distributed across multiple partition keys or even multiple tables. BatchGetItem allows retrieving up to 100 items or 16 MB of data in a single request, making it significantly more efficient than calling getItem repeatedly for each item. The operation reduces the number of network round trips and API calls required, improving application performance and reducing costs associated with API requests.
When using batchGetItem, you specify the primary keys for all items you want to retrieve, and DynamoDB returns the items in a single response. The operation works across multiple tables, allowing you to retrieve items from different tables in one call. DynamoDB automatically splits batch requests into multiple parallel operations as needed to achieve optimal performance. Unlike query operations which are limited to items sharing the same partition key, batchGetItem can retrieve items from any partition keys, providing maximum flexibility for access patterns requiring items from across the table.
The operation consumes read capacity based on the total size of all items retrieved and the consistency model specified. Each item up to 4 KB consumes one read capacity unit for strongly consistent reads or 0.5 RCU for eventually consistent reads. If the batch request exceeds provisioned throughput, DynamoDB returns unprocessed keys in the response, and your application should retry those items with appropriate backoff. The SDK automatically handles retries for unprocessed items when using batch operation helpers.
BatchGetItem has some important characteristics and limitations to understand. Items are retrieved in arbitrary order, not necessarily the order requested, so applications should not depend on result ordering. If any requested items do not exist, they are simply omitted from the response rather than causing errors. The operation cannot perform filtering or projection differently per item; all items retrieved use the same projection expression if specified. For scenarios requiring complex filtering or retrieving items based on non-key attributes, scan or query operations with filters may be necessary despite being less efficient.
Best practices for using batchGetItem include implementing retry logic with exponential backoff for unprocessed keys, grouping related items that are frequently accessed together to maximize batch efficiency, monitoring capacity consumption to ensure batches do not consistently exceed provisioned throughput, and considering caching frequently accessed items to reduce database calls. When items to retrieve are within the same partition key, query operations may be more appropriate and efficient.
Option A is incorrect because getItem retrieves only one item per call, making it inefficient for multiple items. Option B is incorrect because query can only retrieve items sharing the same partition key, not across multiple partition keys efficiently. Option C is incorrect because scan is the least efficient operation, reading entire tables or large portions rather than targeted item retrieval.
