Amazon AWS Certified Developer — Associate DVA-C02 Exam Dumps and Practice Test Questions Set2 Q16-30
Visit here for our full Amazon AWS Certified Developer — Associate DVA-C02 exam dumps and practice test questions.
Question 16:
What is the purpose of DynamoDB Streams?
A) Backup and restore
B) Cross-region replication
C) Capture item-level changes
D) Query optimization
Correct Answer: C
Explanation:
DynamoDB Streams captures a time-ordered sequence of item-level modifications in DynamoDB tables, providing a change data capture mechanism for building event-driven architectures. When enabled, Streams records all item-level changes including inserts, updates, and deletes within the last 24 hours. Each stream record contains information about the modification, including before and after images of the changed item.
Streams enable various architectural patterns and use cases. Common applications include triggering Lambda functions in response to data changes, replicating data to other databases or data warehouses, implementing materialized views, maintaining aggregates and derived data, sending notifications when specific changes occur, and building audit logs. The event-driven nature of Streams enables real-time processing of data changes without polling.
Stream records are organized into shards, similar to Kinesis streams. Each shard contains multiple stream records, and DynamoDB automatically manages shard creation and deletion based on table activity. Applications read from streams using the DynamoDB Streams API or by configuring Lambda event source mappings, which automatically poll the stream and invoke functions with batches of records.
Streams support four view types controlling what information appears in stream records: KEYS_ONLY contains only key attributes, NEW_IMAGE contains the entire item after modification, OLD_IMAGE contains the item before modification, and NEW_AND_OLD_IMAGES contains both before and after images. Choosing the appropriate view type depends on application requirements and minimizes unnecessary data transfer.
Backup and restore uses different DynamoDB features like on-demand backups and point-in-time recovery. Cross-region replication is implemented by Global Tables, which internally use Streams but expose a higher-level abstraction. Query optimization involves index design and query patterns. Streams specifically focus on change data capture. Combining Streams with Lambda creates powerful, serverless event-driven architectures that respond to data changes in real-time without managing infrastructure.
Question 17:
Which HTTP method should be used to update an existing resource partially?
A) PUT
B) POST
C) PATCH
D) UPDATE
Correct Answer: C
Explanation:
The PATCH HTTP method is designed specifically for partial updates to existing resources, allowing clients to send only the fields that need modification rather than the complete resource representation. This contrasts with PUT, which typically requires sending the entire resource representation. Using PATCH reduces bandwidth consumption and clearly indicates the operation’s intent to API consumers.
PATCH requests contain only the changes to apply to the resource, sent as a partial representation or as a set of instructions. Common formats include JSON Merge Patch or JSON Patch, each with different semantics for expressing changes. JSON Merge Patch provides a simple format where the request body contains only fields to update. JSON Patch uses a more structured format with explicit operations like add, remove, and replace.
RESTful API design benefits from using semantically correct HTTP methods. PATCH clearly indicates partial updates, while PUT suggests complete replacement. This distinction helps API consumers understand expected behavior and build correct client implementations. API Gateway and Lambda-based APIs should implement appropriate handlers for different HTTP methods, validating requests and performing corresponding operations.
PUT is used for complete resource replacement or creating resources at specific URIs. POST typically creates new resources or performs operations not fitting other methods. UPDATE is not a standard HTTP method. Understanding these methods is crucial for API design and development, ensuring compliance with HTTP specifications and RESTful principles.
When implementing PATCH endpoints in serverless applications, validate that requested fields exist and are modifiable, handle partial validation appropriately, and return updated resource representations. DynamoDB UpdateItem operations align well with PATCH semantics, updating only specified attributes. Implementing PATCH alongside PUT, POST, and DELETE provides complete CRUD functionality. CloudWatch metrics can track method usage, helping understand API consumption patterns and identify commonly modified fields for optimization opportunities.
Question 18:
Which AWS service provides centralized logging for Lambda functions?
A) Amazon S3
B) Amazon CloudWatch Logs
C) AWS CloudTrail
D) Amazon Kinesis
Correct Answer: B
Explanation:
Amazon CloudWatch Logs provides centralized logging for AWS Lambda functions, automatically capturing all output written to stdout and stderr by function code. When a Lambda function executes, the runtime sends logs to CloudWatch Logs, organizing them into log groups and log streams. Each function has a dedicated log group, and each concurrent execution writes to a separate log stream within that group.
CloudWatch Logs offers powerful querying capabilities through CloudWatch Logs Insights, enabling developers to search, filter, and analyze log data using a specialized query language. This facilitates troubleshooting by finding specific error messages, tracking request flows, analyzing performance patterns, and aggregating metrics from logs. Insights can query across multiple log groups simultaneously, useful for distributed applications spanning multiple functions.
Lambda automatically grants the necessary permissions for logging when you create a function with an execution role that includes basic Lambda execution permissions. The AWSLambda Basic Execution Role managed policy provides these permissions. Functions log to /aws/lambda/FUNCTION_NAME log groups by default. Retention periods are configurable from one day to indefinite retention, with costs varying based on storage duration and ingestion volume.
Structured logging improves log usefulness by outputting JSON-formatted logs instead of plain text. CloudWatch Logs Insights can then parse and query structured fields efficiently. Log levels (DEBUG, INFO, WARN, ERROR) help filter logs during investigation. Correlation IDs linking related log entries across multiple functions or services facilitate distributed tracing alongside X-Ray.
Amazon S3 can store logs but doesn’t provide real-time streaming or built-in querying capabilities that CloudWatch offers. CloudTrail logs API calls for audit and compliance, not application logs. Kinesis handles streaming data but isn’t the standard logging destination for Lambda. CloudWatch Logs remains the primary logging service for Lambda, integrating seamlessly with other AWS services and providing comprehensive log management, retention, and analysis capabilities essential for operating production serverless applications.
Question 19:
What is the maximum retention period for SQS messages?
A) 7 days
B) 10 days
C) 14 days
D) 30 days
Correct Answer: C
Explanation:
Amazon SQS retains messages for a maximum of 14 days (1,209,600 seconds), providing ample time for consumers to process messages even during system outages or high load periods. The default retention period is 4 days (345,600 seconds), configurable between 1 minute and the maximum 14 days. Understanding retention settings is crucial for designing resilient message-driven architectures.
Message retention determines how long SQS stores messages before automatic deletion. If consumers don’t process and delete messages within the retention period, SQS permanently removes them. Setting appropriate retention periods depends on application requirements, consumer processing patterns, and recovery time objectives. Longer retention provides a safety buffer for unexpected delays but increases storage costs proportionally.
For critical workflows requiring guaranteed processing, combining appropriate retention periods with dead-letter queues ensures message preservation even when processing repeatedly fails. Dead-letter queues receive messages that exceed the maximum receive count, preventing infinite retry loops. These messages remain in the dead-letter queue according to its retention period, allowing investigation and manual reprocessing.
Applications should set retention periods based on expected processing times and potential delay scenarios. E-commerce order processing might use longer retention to handle peak traffic periods, while real-time notifications might use shorter periods since delayed delivery loses value. Monitoring queue metrics like ApproximateAgeOfOldestMessage helps identify processing backlogs before messages approach retention expiration.
SQS charges are based on request volume, not message retention duration, so longer retention periods don’t directly increase costs. However, messages occupying queue space for extended periods might indicate processing issues requiring investigation. CloudWatch alarms on age metrics enable proactive issue detection. Understanding retention behavior helps design reliable message processing systems that handle failures gracefully while preserving critical messages for adequate processing windows.
Question 20:
Which Lambda concurrency type reserves specific capacity for a function?
A) Unreserved concurrency
B) Reserved concurrency
C) Provisioned concurrency
D) Burst concurrency
Correct Answer: B
Explanation:
Reserved concurrency in AWS Lambda allocates a specific number of concurrent executions exclusively to a function, guaranteeing that capacity is available when needed and preventing other functions from consuming that capacity. This setting serves two purposes: ensuring critical functions have sufficient capacity and limiting maximum concurrency to protect downstream resources from overload.
When you configure reserved concurrency for a function, Lambda subtracts that amount from the account’s unreserved concurrency pool. For example, if your account has 1,000 concurrent executions and you reserve 100 for a specific function, 900 remain available for other functions. The reserved function can scale up to its reserved limit but no further, while other functions share the remaining capacity.
Reserved concurrency differs from provisioned concurrency, which keeps function instances initialized and ready to respond immediately, reducing cold starts. Reserved concurrency simply guarantees capacity availability but doesn’t keep instances warm. Combining both features provides guaranteed capacity with minimal latency, though at higher costs due to provisioned concurrency charges.
Use cases for reserved concurrency include protecting downstream databases or APIs from overload by capping maximum concurrent connections, guaranteeing capacity for critical functions during high traffic, and isolating function workloads to prevent one function from consuming all account concurrency. Setting reserved concurrency to zero effectively disables a function without deleting it, useful for emergency shutdowns or maintenance.
Unreserved concurrency is capacity available to all functions without reservations. Burst concurrency refers to Lambda’s ability to rapidly scale, initially providing 500-3000 concurrent executions (region-dependent) with additional capacity at 500 per minute. Understanding these concurrency types enables proper capacity planning, ensures application reliability, and prevents resource exhaustion. CloudWatch metrics like ConcurrentExecutions and Throttles help monitor concurrency usage and identify capacity issues requiring configuration adjustments.
Question 21:
Which API Gateway deployment stage configuration determines request throttling limits?
A) Stage variables
B) Throttle settings
C) Usage plans
D) Method settings
Correct Answer: C
Explanation:
API Gateway Usage Plans define throttle limits and quota configurations that control request rates for API consumers. Usage plans are associated with API keys and applied to specific API stages, enabling different rate limits for different customer tiers or applications. This feature implements rate limiting, monetization strategies, and protects backend services from overuse.
Usage plans configure two types of throttling: rate limits specify requests per second, and burst limits define maximum concurrent requests. For example, a free tier might allow 1000 requests per day with a rate of 10 requests per second, while a premium tier allows 1 million requests per day at 1000 requests per second. These settings protect APIs from traffic spikes and ensure fair resource distribution among consumers.
Creating usage plans involves defining throttle and quota settings, then associating API keys with the plan. Clients include their API key in the x-api-key header when making requests. API Gateway enforces the associated plan’s limits, returning 429 Too Many Requests when limits are exceeded. Multiple API keys can share the same usage plan, simplifying management for applications with similar requirements.
Stage variables store configuration values varying across deployment stages but don’t directly control throttling. Throttle settings exist but are implemented through usage plans or method-level settings. Method settings configure individual method behaviors including caching, logging, and metrics, but usage plans provide the comprehensive rate limiting framework.
Usage plans enable API monetization by offering different service tiers with varying limits. They integrate with AWS Marketplace for selling API access. CloudWatch metrics track request counts and throttling, helping identify when consumers approach limits. Setting appropriate limits balances protecting backend resources with providing good user experience. Overly restrictive limits frustrate legitimate users, while permissive limits risk overwhelming backend services or incurring excessive costs.
Question 22:
What is the purpose of a Lambda Layer?
A) Network routing
B) Share code across functions
C) Increase memory allocation
D) Enable VPC access
Correct Answer: B
Explanation:
Lambda Layers enable sharing code, libraries, custom runtimes, and other dependencies across multiple Lambda functions without including them in each function’s deployment package. Layers reduce deployment package sizes, simplify dependency management, promote code reuse, and separate function logic from shared components. Each function can reference up to five layers, loaded into the execution environment during initialization.
Creating layers involves packaging libraries or code into a .zip file with a specific directory structure matching the runtime’s expectations. For example, Python layers place dependencies in python/lib/python3.x/site-packages/, while Node.js layers use nodejs/node_modules/. After uploading to Lambda, layers receive version ARNs that functions reference in their configuration.
Common use cases include sharing utility functions across multiple functions, distributing common dependencies like AWS SDK versions, providing custom runtimes for languages not natively supported, and deploying monitoring or security agents consistently across all functions. Organizations often maintain internal layer libraries for standardized logging, configuration, or security implementations.
Layers benefit deployment workflows by reducing individual function deployment sizes, speeding up deployments and cold starts. Updating shared code requires updating only the layer, not every function using it, though functions must be updated to reference the new layer version. Layer versioning ensures immutability; each layer version is permanent, preventing unintended changes to functions using specific versions.
Network routing is handled by VPC configuration, not layers. Memory allocation is a function-level setting. VPC access requires appropriate VPC configuration regardless of layers. Layers specifically address code sharing and dependency management challenges in Lambda applications. Best practices include versioning layers semantically, documenting layer contents, maintaining separate layers for different dependency groups, and testing layer updates before applying to production functions to ensure compatibility.
Question 23:
Which DynamoDB operation retrieves multiple items efficiently using partition and sort keys?
A) GetItem
B) Scan
C) Query
D) BatchGetItem
Correct Answer: C
Explanation:
The DynamoDB Query operation efficiently retrieves multiple items that share the same partition key value, optionally filtering by sort key conditions. Query is the most efficient way to retrieve related items because DynamoDB stores items with the same partition key together, enabling fast lookups without scanning the entire table. Understanding Query operations is fundamental for designing performant DynamoDB applications.
Query requires specifying the partition key value and optionally includes sort key conditions using comparison operators like equals, less than, greater than, begins_with, or between. Query returns all items matching these conditions, supporting pagination through the LastEvaluatedKey mechanism for result sets exceeding the 1 MB response limit. Filter expressions can further refine results, but filters apply after Query completes, consuming read capacity for filtered-out items.
Query supports both forward and backward traversal of sort keys through the ScanIndexForward parameter, enabling applications to retrieve the newest or oldest items first. Projections limit returned attributes, reducing response size and consumed read capacity. Query works on tables and secondary indexes, with different performance characteristics depending on index type.
GetItem retrieves a single item by specifying both partition and sort keys. Scan reads every item in the table or index, making it expensive and slow for large tables. BatchGetItem retrieves multiple specific items from one or more tables but requires knowing exact keys for each item, unlike Query which retrieves ranges.
Effective DynamoDB access patterns rely heavily on Query operations. Design table schemas with access patterns in mind, using partition keys to group related items and sort keys to enable range queries. Secondary indexes provide alternative query patterns without duplicating data. Avoid Scan operations in production workloads; if full table access is necessary, consider exporting to S3 for analysis. Query operations with proper key design provide consistent, fast performance regardless of table size.
Question 24:
Which AWS service manages secrets like database passwords with automatic rotation?
A) AWS Systems Manager Parameter Store
B) AWS Secrets Manager
C) AWS KMS
D) AWS IAM
Correct Answer: B
Explanation:
AWS Secrets Manager is specifically designed for managing secrets like database credentials, API keys, and other sensitive information with built-in automatic rotation capabilities. Secrets Manager integrates with RDS, Redshift, DocumentDB, and other databases to automatically update credentials on a schedule without application downtime. This automation reduces security risks associated with long-lived credentials and manual rotation processes.
Secrets Manager encrypts secrets at rest using AWS KMS and provides fine-grained access control through IAM policies. Applications retrieve secrets using the Secrets Manager API, CLI, or SDKs. Secrets Manager handles the complexity of rotation, updating both the secret stored in the service and the actual credential in the target system, ensuring applications always receive valid credentials.
Rotation works by invoking a Lambda function that performs the rotation process. Secrets Manager provides pre-built rotation functions for supported databases. Custom rotation functions enable rotating secrets for applications or services without built-in support. Rotation strategies include alternating between two users or using immediate rotation, depending on service capabilities and requirements.
Secrets Manager integrates with CloudFormation for infrastructure as code deployments, preventing secret values from appearing in templates through dynamic references. Version staging enables smooth transitions during rotation, preventing application errors when credentials change. Secrets Manager automatically retries failed requests and handles concurrent access properly.
AWS Systems Manager Parameter Store stores configuration data and can encrypt sensitive values using KMS, but lacks built-in automatic rotation. AWS KMS manages encryption keys, not secrets themselves. AWS IAM manages access permissions, not credential storage or rotation. While Parameter Store offers cost-effective secret storage, Secrets Manager provides comprehensive secret lifecycle management including rotation automation, making it preferable for managing frequently rotated credentials or meeting compliance requirements for credential rotation.
Question 25:
What is the maximum number of attributes in a DynamoDB item?
A) 100
B) 400
C) No limit
D) 1024
Correct Answer: C
Explanation:
DynamoDB items have no limit on the number of attributes they can contain, providing flexibility for varying data structures and accommodating complex objects. However, the total item size cannot exceed 400 KB, which is the practical constraint limiting attribute count. This size limit includes attribute names and values, so efficient naming and data modeling maximize usable space.
The flexible schema nature of DynamoDB allows different items in the same table to have completely different attributes, supporting diverse entity types in single-table design patterns. Items must have required partition key attributes and sort key attributes if the table uses a composite primary key, but all other attributes are optional and can vary between items.
Understanding item size calculation is important for capacity planning and cost optimization. Attribute names count toward item size, so short attribute names reduce overhead, though clarity shouldn’t be sacrificed excessively. Binary attributes like images are often better stored in S3 with references in DynamoDB, conserving capacity for metadata. Large attributes increase consumed read and write capacity units, directly impacting costs.
DynamoDB supports nested attributes through maps and lists, enabling complex hierarchical data structures within the 400 KB limit. Deeply nested structures can make querying and updating specific values more complex, requiring careful access pattern analysis during schema design. The number of nested levels is unlimited, but the total serialized size remains subject to the 400 KB constraint.
Single-table design patterns often store multiple entity types in one table, leveraging flexible schema capabilities. Items representing different entities naturally have different attributes. While there’s no attribute count limit, exceeding 400 KB requires splitting data across multiple items using item collections or moving large attributes to S3. Monitoring average item sizes through CloudWatch or manual analysis helps identify optimization opportunities and prevents unexpected capacity consumption or throttling.
Question 26:
Which Lambda execution context element is reused across multiple invocations?
A) Event object
B) Temporary directory
C) Execution role
D) Environment variables
Correct Answer: B
Explanation:
The Lambda execution context includes the /tmp directory, global variables, database connections, and background processes that persist across multiple invocations when Lambda reuses the same execution environment. The /tmp directory provides 512 MB of ephemeral storage that remains available between invocations in the same environment, enabling caching, temporary file storage, and performance optimizations.
When Lambda invokes a function, it may reuse an existing execution environment if one is available from a recent invocation. Code outside the handler function runs during environment initialization and executes only once per environment lifetime, not per invocation. This initialization phase is ideal for establishing database connections, loading configuration, initializing clients, and warming up caches that benefit subsequent invocations.
Leveraging context reuse improves performance and reduces costs by eliminating repeated initialization overhead. For example, establishing database connections outside the handler means subsequent invocations use the existing connection rather than creating new ones, significantly reducing latency. Similarly, data cached in /tmp remains available for future invocations, avoiding repeated downloads or computations.
The event object is unique to each invocation, containing request-specific data. Execution roles define permissions but aren’t part of the execution context. Environment variables are set during environment initialization and remain constant across invocations in that environment but aren’t the reusable resource. The /tmp directory specifically provides persistent storage within an execution context lifecycle.
Understanding execution context reuse requires careful coding. Always validate and refresh cached data appropriately, close connections gracefully in handler code, and handle initialization failures. Never store sensitive information in /tmp without encryption since subsequent invocations might use the same environment. Clear /tmp contents when starting if fresh state is required. Provisioned concurrency keeps execution environments initialized, maximizing context reuse benefits. Monitoring cold start frequency helps assess optimization effectiveness.
Question 27:
What is the purpose of API Gateway request validators?
A) Authentication
B) Rate limiting
C) Input validation
D) Response transformation
Correct Answer: C
Explanation:
API Gateway request validators provide input validation capabilities, checking incoming requests against defined schemas before passing them to backend integrations. This validation occurs at the API Gateway layer, rejecting invalid requests early and protecting backend services from malformed data. Request validators improve security, reduce unnecessary backend invocations, and provide consistent error responses for validation failures.
Validators can check request parameters including query strings, headers, and path parameters, ensuring required parameters are present and conform to defined types and patterns. Body validation uses JSON Schema to define expected request body structure, validating property types, required fields, string patterns, numeric ranges, and nested object structures. This comprehensive validation catches errors before consuming backend resources.
API Gateway provides three validation options: validate request body only, validate request parameters only, or validate both. Different methods within an API can use different validators, enabling flexible validation strategies. When validation fails, API Gateway automatically returns 400 Bad Request with error details, eliminating the need for custom validation logic in Lambda functions or other backends.
Authentication is handled by authorizers (Lambda or Cognito). Rate limiting uses throttle settings and usage plans. Response transformation uses mapping templates. Request validators specifically focus on input validation. Implementing validation at the API Gateway layer follows the principle of defense in depth, adding a security layer before requests reach application logic.
Defining JSON schemas for request validation requires understanding JSON Schema syntax and the expected data structure. Schemas can specify required properties, property types (string, number, boolean, object, array), formats (email, date-time, URI), patterns using regular expressions, and constraints like minimum/maximum values or string lengths. Well-defined schemas improve API documentation and client development experience. Validation at the gateway reduces Lambda execution time and costs by filtering invalid requests early.
Question 28:
Which service provides a serverless application repository for sharing Lambda applications?
A) AWS Marketplace
B) AWS SAR
C) GitHub
D) AWS CloudFormation Registry
Correct Answer: B
Explanation:
AWS Serverless Application Repository (AWS SAR) is a managed service for discovering, deploying, and sharing serverless applications built on Lambda, API Gateway, DynamoDB, and other AWS services. SAR enables developers to publish complete serverless applications with associated CloudFormation templates, making them easily discoverable and deployable by others. This service accelerates development by providing pre-built applications and reusable components.
Applications in SAR range from simple utilities like database backup functions to complete solutions like image processing pipelines, chatbots, or API backends. Each application includes a SAM or CloudFormation template defining all necessary resources, along with documentation, source code repository links, and parameter definitions. Users deploy applications directly from the SAR console or CLI, with CloudFormation handling resource provisioning.
SAR supports both public and private applications. Public applications are discoverable by all AWS users, enabling open-source sharing and community contributions. Private applications are accessible only within your AWS account or organization, facilitating internal tool distribution and standardization. Publishing to SAR requires defining application metadata, uploading templates and code to S3, and specifying required parameters.
AWS SAM (Serverless Application Model) integrates tightly with SAR. Developers use SAM CLI to package and publish applications to SAR with simple commands. The sam publish command handles template validation, artifact upload, and application creation or updating. SAM templates are a simpler, higher-level abstraction over CloudFormation for serverless resources.
AWS Marketplace sells commercial software but focuses on infrastructure and enterprise applications rather than serverless components. GitHub hosts source code but doesn’t provide integrated deployment or AWS resource management. CloudFormation Registry manages resource type extensions, not complete applications. SAR specifically addresses serverless application sharing with native AWS integration. Using SAR accelerates development, reduces duplication, and promotes best practices through shared implementations.
Question 29:
What does the principle of least privilege mean in IAM?
A) Grant maximum permissions
B) Grant minimum required permissions
C) Grant read-only permissions
D) Grant administrator permissions
Correct Answer: B
Explanation:
The principle of least privilege is a fundamental security concept in AWS Identity and Access Management (IAM) stating that users, roles, and services should receive only the minimum permissions necessary to perform their intended functions. This approach minimizes potential damage from compromised credentials, configuration errors, or malicious insiders by limiting the scope of possible actions.
Implementing least privilege requires carefully analyzing required permissions for each role, service, or user. Start with no permissions and incrementally add only those proven necessary through testing and operational requirements. Avoid using managed policies like AdministratorAccess except for truly administrative functions. Instead, create custom policies with specific actions on specific resources, using conditions to further restrict access based on context like IP address, time, or MFA status.
IAM policies support fine-grained permission control through resource ARNs, action patterns, and condition keys. For example, a Lambda function needing DynamoDB access should specify exact table ARNs rather than using wildcards. Actions should list specific operations like dynamodb:GetItem rather than dynamodb:*. Conditions can restrict access to specific times, source IPs, or encryption requirements.
Granting maximum, administrator, or even read-only permissions to all resources violates least privilege when narrower permissions suffice. While read-only access is safer than write access, it might expose sensitive data unnecessarily. The correct approach grants only proven necessary permissions, whether read, write, or administrative, limited to specific resources and conditions.
Regular permission audits using IAM Access Analyzer identify overly permissive policies and unused permissions. IAM policy simulation tests what actions policies allow before applying them. Access Advisor shows last-used permissions, helping identify unnecessary grants. CloudTrail logs reveal actual API calls, informing permission refinement. Following least privilege reduces security risks, supports compliance requirements, and limits blast radius when security incidents occur, making it essential for secure AWS environments.
Question 30:
Which method configures environment-specific settings in Lambda functions?
A) Function versions
B) Aliases
C) Environment variables
D) All of the above
Correct Answer: D
Explanation:
Lambda supports multiple mechanisms for managing environment-specific configurations, and all three listed options play complementary roles. Environment variables store configuration values like database endpoints or API keys. Function versions create immutable snapshots of function code and configuration. Aliases provide named pointers to versions, enabling environment-based routing. Together, these features enable comprehensive environment management strategies.
Environment variables are the most direct configuration method, allowing developers to define key-value pairs accessible at runtime. Each function version can have different environment variable values, enabling the same code to behave differently across development, staging, and production. Variables support encryption via AWS KMS for sensitive values, though Secrets Manager or Parameter Store offer better secret management for production workloads.
Function versions create immutable copies of function code, configuration, environment variables, and runtime settings. Publishing a version assigns a numeric version number (1, 2, 3, etc.) that cannot be modified. This immutability ensures consistent behavior and enables safe deployments. The $LATEST version represents the current editable function state, allowing development without impacting production.
Aliases provide friendly names that point to specific versions, enabling environment mapping without hardcoding version numbers. Common aliases include dev, staging, and prod, each pointing to appropriate versions. Updating an alias instantly redirects traffic to a different version, enabling rollbacks and gradual deployments. Aliases support weighted routing, directing percentages of traffic to different versions for canary deployments or A/B testing.
Combining these features creates robust deployment strategies. Develop using $LATEST, publish versions for releases, create aliases for environments, and use environment variables for environment-specific configuration. This approach separates code from configuration, enables testing identical code across environments, and provides quick rollback capabilities. CloudFormation or SAM templates manage these resources declaratively, ensuring consistent deployments.