AWS Certified Developer Associate DVA-C02 (DVA-C02) — Questions 226–300

Amazon SNS is a fully managed publish/subscribe messaging service that effectively decouples microservices by allowing publishers to send messages to a central topic. This topic then fans out those messages to multiple subscribed endpoints or services asynchronously, ensuring that the publisher does not need to know about or directly interact with the consumers. This pattern promotes loose coupling, independent scaling, and fault tolerance across the system.

CloudFront cannot retrieve objects encrypted with SSE-C (Server-Side Encryption with Customer-Provided Keys) because it does not have a mechanism to store or pass the customer-provided encryption key to Amazon S3 during the object retrieval request. When CloudFront attempts to fetch such an object, S3 requires the encryption key as part of the request for decryption. Without the key, S3 denies access, resulting in a 403 Forbidden error, making SSE-C fundamentally incompatible with CloudFront's caching and distribution model.

An ECONNRESET error signifies that the remote server unexpectedly closed the connection, often due to the client's inability to establish or maintain network connectivity. For CodeBuild projects running in a private VPC subnet, outbound internet access is crucial for npm install to fetch packages from public registries. Configuring a NAT Gateway in a public subnet or utilizing a VPC endpoint for specific services like S3 (if npm packages are stored there) provides the necessary outbound path, resolving such network-related build failures.

AWS Systems Manager Run Command is the ideal capability for executing arbitrary scripts and commands on EC2 instances remotely and securely. It allows administrators to run shell scripts, PowerShell commands, or predefined Systems Manager documents directly on managed instances without needing SSH access. This direct, on-demand execution makes it perfectly suited for running deployment scripts as part of a configuration management process.

For successful cross-account access to an S3 bucket, a 'two-way street' of permissions is required. While the S3 bucket policy must explicitly grant access to the external account or user, the IAM user in that external account must also possess an identity-based IAM policy that permits the specific S3 actions, such as s3:GetObject or s3:PutObject. If the user's IAM policy is missing or too restrictive, even with a permissive bucket policy, access will be denied, as both policies must allow the action.

Enabling API Gateway caching directly addresses the problem by storing responses for a specified Time-To-Live (TTL). When subsequent identical requests arrive within the TTL, API Gateway serves the response from its managed cache, completely bypassing the backend Lambda function. This significantly reduces the load on the Lambda function, lowers invocation costs, and improves API response times for repeated requests.

The AWS CodeBuild action within a CodePipeline build stage is specifically designed to execute build commands and tests. If any command within the CodeBuild `buildspec.yml` exits with a non-zero status, CodeBuild reports a failure to CodePipeline. CodePipeline then automatically recognizes this failed action, stops the current pipeline execution, and prevents any subsequent stages, such as deployment, from being initiated, ensuring a 'fail fast' approach.

AWS Secrets Manager is the most appropriate solution for managing application credentials, offering robust features like automatic rotation. By integrating with a custom Lambda function, Secrets Manager can programmatically rotate credentials for databases, API keys, or other services on a defined schedule, significantly enhancing the security posture. The application only needs to be modified to retrieve the current secret value from Secrets Manager at runtime, abstracting the actual credential management and minimizing code changes.

The `ScannedCount` metric in DynamoDB represents the total number of items read from the table before any `FilterExpression` is applied. If the `ScannedCount` is 10,000 and the `Count` (number of items returned after filtering) is 0, it indicates that all 10,000 items were successfully retrieved from the table, but none of them met the criteria specified in the `FilterExpression`. This is a common scenario when the filter condition is very specific or no matching data exists.

An Application Load Balancer (ALB) with two distinct target groups, one designated for the "blue" (current production) environment and another for the "green" (new version) environment, is the standard and most effective architecture for blue/green deployments. The ALB acts as a stable entry point, and its listener rules can be precisely updated to shift traffic from the blue target group to the green target group after successful validation, enabling zero-downtime deployments and immediate rollback capabilities. This setup allows both versions to run concurrently, facilitating thorough testing of the new version before promoting it to full production traffic.

Service Control Policies (SCPs) in AWS Organizations provide a powerful *preventive* control mechanism that applies centrally across all member accounts within an Organizational Unit (OU) or the entire organization. By implementing an SCP to explicitly deny the s3:PutBucketEncryption action unless the encryption algorithm is AES256, it effectively prevents any account from configuring S3 buckets without the required SSE-S3 encryption, ensuring compliance at the infrastructure level.

Secrets Manager stores credentials securely and retrieves them via API calls, but the question requires that credentials are never stored in application code or configuration files. The correct approach uses IAM database authentication with RDS, eliminating static credentials entirely by granting the Elastic Beanstalk environment’s IAM role direct access to the database. Secrets Manager is tempting because it is designed for secure credential storage and rotation, and would be correct if the application needed static credentials that could not be eliminated, such as when RDS does not support IAM authentication.

Increasing the allocated storage size, particularly for General Purpose SSD (gp2) volumes, directly improves I/O performance because throughput and IOPS scale with storage capacity. Larger gp2 volumes provide a higher baseline IOPS and accumulate I/O credits faster, enabling sustained burst performance and mitigating I/O bottlenecks. This ensures the database can read and write data to disk more efficiently, which is critical for write-intensive workloads.

A KMS key policy is the primary and mandatory control mechanism for defining who can use a Customer Master Key (CMK) for cryptographic operations, including kms:Decrypt. By explicitly allowing kms:Decrypt for the specified IAM role and implementing a default deny for all other principals, this policy directly enforces that only the designated role possesses the necessary permission to decrypt data encrypted with this specific KMS key. This ensures granular control over the sensitive data's accessibility in plaintext form.

'FunctionError': 'Unhandled' is set by the Lambda runtime whenever the function code throws or rejects an exception that isn't caught anywhere in the handler, meaning the error propagated all the way up and terminated the invocation.

The presence of the `X-Amz-Function-Error` header in the response, along with a `StatusCode: 200`, is the definitive indicator that the Lambda service successfully received and attempted to execute the function, but the function's code itself encountered an unhandled exception. This means an error occurred within the function's runtime environment that was not caught by a `try-catch` block or equivalent error handling mechanism. Consequently, the Lambda service reported the internal function error back to the invoker.

A Lambda authorizer, previously known as a custom authorizer, is a dedicated Lambda function invoked by API Gateway *before* the request reaches the backend integration. This authorizer receives the incoming token, performs custom validation logic (e.g., JWT signature verification, expiration checks), and returns an IAM policy that either permits or denies access to the requested API resource. Crucially, API Gateway can cache the policy generated by the authorizer, significantly reducing latency and computational overhead for subsequent requests with the same valid token.

Creating an IAM role with a policy that grants specific DynamoDB access and assigning it as the Lambda execution role is the secure and recommended AWS best practice. This approach provides the Lambda function with temporary, automatically rotated credentials, adhering to the principle of least privilege by allowing access only to the necessary DynamoDB actions and resources without ever exposing static, long-lived credentials.

The error message "AssumeRole permission denied" directly indicates that the AWS Lambda function, during its execution, attempted to call the AWS Security Token Service (STS) AssumeRole API operation to temporarily assume another IAM role, but its own execution role lacked the necessary sts:AssumeRole permission for that specific target role. The Lambda execution role defines what permissions the function has to interact with other AWS services. Without sts:AssumeRole explicitly granted for the target role in its policy, the function cannot obtain temporary credentials to perform actions under that role's permissions, leading to this specific authorization failure.

This policy precisely adheres to the principle of least privilege, granting only the `s3:PutObject` action, which is the exact permission required for the web application to upload files to Amazon S3. The resource is correctly scoped to `arn:aws:s3:::example-bucket/*`, ensuring the application can only write objects into the specified bucket and not affect other S3 resources or perform any other S3 operations. This minimal permission set significantly enhances security by limiting potential damage if the task's credentials were ever compromised.

A Lambda authorizer on the Application Load Balancer inspects the custom authorization header, validates the token, and returns an IAM policy allowing or denying the request. This enforces authentication at the load balancer before traffic reaches the EC2 instance.

AWS Step Functions is a serverless workflow service that enables developers to build resilient, distributed applications using visual state machines. It excels at orchestrating complex, multi-step processes, integrating seamlessly with Amazon SQS to consume messages and coordinate subsequent actions across various AWS services. Step Functions provides built-in state management, error handling, and retry policies, making it ideal for creating reliable, fault-tolerant workflows initiated by SQS messages.

High CPU utilization on EC2 instances can severely impact their ability to process requests and respond to health checks in a timely manner. If instances are consistently overloaded, they may fail the Application Load Balancer's (ALB) health checks, causing the ALB to mark them as unhealthy. Consequently, the ALB will stop routing traffic to these instances and return 503 Service Unavailable errors to clients, as it has no healthy targets to forward requests to.

Creating an interface VPC endpoint for API Gateway establishes a private connection from your VPC to the API Gateway service using AWS PrivateLink. This allows clients within your VPC to access the API Gateway endpoint without traversing the public internet, ensuring that all traffic remains within the AWS network and is restricted to the specified VPC.

Amazon CloudWatch Logs Insights is specifically designed for interactively searching, analyzing, and visualizing log data to troubleshoot operational problems and identify performance bottlenecks. It allows users to run powerful queries using a purpose-built query language to filter, aggregate, and extract specific information from log events, making it ideal for pinpointing the root causes of latency within application logs. This direct analytical capability is crucial for diagnosing issues.

Retrieving secrets outside the handler function, typically during the Lambda function's initialization phase, and caching them in a global variable is an optimal strategy for performance and cost efficiency. This approach ensures the secret is fetched only once per execution environment (during a cold start) and then reused for subsequent invocations (warm starts), significantly reducing latency and API call costs associated with repeated secret retrieval.

CodeBuild projects, by default, run in a managed AWS environment with public internet access but are isolated from private Amazon Virtual Private Cloud (VPC) networks. To access a private Maven repository residing within a private subnet of a VPC, an on-premises network via Direct Connect/VPN, or another private network, the CodeBuild project must be explicitly configured to run within a specified VPC. This configuration provisions Elastic Network Interfaces (ENIs) in the designated subnets, allowing the build environment to establish private network connectivity to the repository.

This is the correct AWS Serverless Application Model (SAM) resource for defining an Amazon API Gateway REST API within a serverless application. `AWS::Serverless::Api` allows developers to specify API endpoints, methods, and integrations with backend services like AWS Lambda functions. This resource abstracts away much of the underlying CloudFormation complexity required to set up a robust and scalable API Gateway, making it the idiomatic choice for exposing HTTP endpoints.

Elastic Beanstalk's .ebextensions/<filename>.config with container_commands are executed after the application and web server have been fully set up and are ready, but critically, before the new application version begins serving live traffic. This precise timing is ideal for database migrations, as the application can connect to the database to perform schema updates without impacting active users on the old version, ensuring a smooth transition for the new deployment.

When ECS stops a task, it sends a SIGTERM signal to allow the application to gracefully shut down. If the application does not catch this signal and stop accepting new connections or complete in-flight requests before exiting, the ALB may still send traffic to the task after it stops, resulting in 502 errors. This is a common issue during rolling updates.

Amazon RDS for MySQL supports encryption at rest, which must be configured during the initial creation of the DB instance. This ensures that the underlying storage volume, database snapshots, automated backups, and read replicas are all encrypted from the outset using an AWS Key Management Service (KMS) key. Attempting to enable encryption on an unencrypted instance after creation is not supported directly by RDS.

Automatic key rotation re-wraps the KMS key material annually without changing the key ID or ARN, so existing ciphertext and applications continue working. Enabling it on each customer managed key meets the yearly rotation requirement with no manual intervention.

AWS Security Token Service (STS) is the dedicated AWS service for creating and providing temporary, limited-privilege credentials for AWS users, federated users, or applications. Developers utilize STS API operations like AssumeRole, GetFederationToken, or GetSessionToken to obtain these credentials, which consist of an access key ID, a secret access key, and a session token. These temporary credentials can be configured with a specific duration, such as 30 minutes, making them ideal for secure, short-lived access to AWS resources.

Amazon ElastiCache provides a fully managed, in-memory caching service, making it an excellent choice for storing web application session state. By centralizing session data in an ElastiCache Redis or Memcached cluster, all EC2 instances can access and update the same session information, ensuring session stickiness and persistence even if a user's subsequent request is routed to a different instance. Its low-latency access and high availability features, including replication and automatic failover, are critical for responsive and resilient user experiences in distributed environments.

AWS Secrets Manager is the correct service for securely storing and managing database credentials because it is purpose-built for this task. It offers robust features like automatic rotation of credentials for supported databases, integration with other AWS services, and fine-grained access control. This automation significantly reduces the operational burden and enhances security by ensuring credentials are regularly updated without manual intervention.

In a CloudFormation CI/CD pipeline, AWS CodeBuild is crucial for validating templates using tools like `cfn-lint`, running unit tests on custom resources or Lambda functions, and packaging deployment artifacts. It can also be used to transform CloudFormation templates, for instance, by using `sam build` for SAM templates, before they are deployed. CodeBuild's compute environment executes commands defined in a `buildspec.yml` file, making it the workhorse for all pre-deployment processing and quality checks within the pipeline.

AWS Secrets Manager is purpose-built for securely storing, managing, and retrieving database credentials, API keys, and other secrets throughout their lifecycle. It integrates directly with various AWS services and databases to provide robust automatic rotation, ensuring credentials are regularly updated without manual intervention. Retrieving secrets at runtime, rather than just at startup, minimizes the exposure window and allows for dynamic credential updates without requiring application restarts, significantly enhancing the overall security posture.

Enabling DynamoDB Accelerator (DAX) significantly improves read performance by providing an in-memory cache for frequently accessed data. DAX intercepts read requests before they reach the DynamoDB table, serving cached items with microsecond latency. This drastically reduces the read load on the underlying DynamoDB table, effectively mitigating read-related throttling issues and enhancing application responsiveness for read-intensive workloads.

An IAM role cannot be directly attached to an EC2 instance; it must be associated via an Instance Profile. The Instance Profile acts as a container for the IAM role, making its temporary credentials available to applications running on the EC2 instance through the instance metadata service. If the IAM role is not correctly embedded within an Instance Profile and that profile is not attached to the EC2 instance, the application will lack the necessary credentials to assume the role and perform actions like accessing DynamoDB.

Enabling access logging on a specific API Gateway stage is a fundamental configuration step for capturing API traffic. This setting dictates that API Gateway will generate detailed information about every request and response passing through that stage, including caller IP, request latency, and response status. Without this explicit enablement on the stage, no access logs will be generated, regardless of other logging infrastructure being in place. Therefore, it is a prerequisite for any access logging functionality.

For successful cross-account access to an S3 bucket, both the resource-based policy (the S3 bucket policy) on the target bucket AND an identity-based policy (IAM policy) attached to the user or role in the requesting (target) account must explicitly grant the necessary permissions. Even if the bucket policy allows the action, the requesting IAM principal must also have an IAM policy allowing it to perform s3:PutObject. This "two-policy" evaluation model ensures comprehensive security, making this the correct reason for denial if the IAM policy is missing.

Creating the DynamoDB client outside the Lambda handler function, in the global scope, is the recommended best practice for optimizing Lambda performance. This ensures the client is initialized only once when the Lambda execution environment is first created during a cold start. For subsequent 'warm' invocations within the same execution environment, the pre-initialized client is reused, significantly reducing latency by avoiding repeated client setup overhead and connection establishment.

When a Lambda function attempts to read from a DynamoDB table with insufficient Read Capacity Units (RCUs), DynamoDB will throttle the requests. This throttling results in ProvisionedThroughputExceededException errors, forcing the Lambda function to implement retry logic, which significantly prolongs its execution time. Repeated retries against a persistently throttled table can cause the function to approach or exceed its configured timeout, indicating a clear resource bottleneck.

Increasing the read and write capacity units (RCU/WCU) on the DynamoDB table directly raises its maximum sustained throughput. These units define the number of strongly consistent reads and 1KB writes the table can handle per second. By provisioning more capacity, the table can accommodate a higher volume of operations, directly mitigating throttling errors that occur when request rates exceed the current limits.

The security group associated with the EC2 instances acts as a virtual firewall, controlling inbound and outbound traffic. For ALB health checks to succeed, the EC2 instance's security group must have an inbound rule that explicitly permits traffic from the ALB's security group or its private IP range on the health check port. If this rule is missing or misconfigured, the ALB's health check probes will be blocked at the network level, preventing a successful connection and causing the ALB to mark the instance as unhealthy.

When an object is encrypted with SSE-KMS, retrieving it requires not only s3:GetObject permission on the object but also kms:Decrypt permission on the specific KMS key used to encrypt it; if the IAM policy grants only the S3 action and omits the KMS action, the decrypt call fails and S3 surfaces this as an Access Denied error even though the S3-level permissions look correct.

The Lambda function's IAM execution role must include permissions such as sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes. These permissions are essential for the Lambda service, acting on behalf of the function, to successfully poll the SQS queue, retrieve messages, and then delete them after successful processing. Without these explicit permissions, the Lambda function would be unable to interact with the SQS queue as an event source, preventing message consumption.

For the Lambda function to successfully rotate database credentials, it must establish a network connection to the database instance. If the database resides within a VPC, the Lambda function must be configured to execute within that same VPC or a peered VPC, with appropriate security groups and network ACLs allowing outbound connections to the database's port and inbound connections from the Lambda's Elastic Network Interface (ENI). Lack of network reachability is a common cause of rotation failures.

Amazon S3 Event Notifications are the native mechanism for S3 buckets to publish events, such as object creation (s3:ObjectCreated:*), to various destinations. These notifications can directly invoke AWS Lambda functions asynchronously, providing a highly scalable and decoupled way to trigger serverless processing whenever new data arrives in an S3 bucket. This direct integration eliminates the need for intermediary services for simple object-triggered workflows, making it the most suitable and efficient choice for this scenario.

Provisioned concurrency pre-initializes a specified number of execution environments for a Lambda function, ensuring they are ready to process requests immediately. This effectively eliminates cold start latency for invocations routed to these pre-warmed instances, as the entire initialization phase (including code download, runtime bootstrapping, and `init` code execution) has already completed. It guarantees consistently low latency for critical, latency-sensitive applications by maintaining a pool of ready-to-go containers.

To retrieve any object from an S3 bucket, regardless of its encryption status, the principal (user or role) must have explicit permission to perform the s3:GetObject action. This action grants the ability to download the object's data, which is a fundamental prerequisite before any decryption process can even begin. Without this permission, S3 will deny the request to access the object entirely, making decryption impossible.

Implementing exponential backoff and retry in the Lambda function code for DynamoDB API calls is the most effective solution. This pattern automatically handles transient errors like throttling by retrying failed requests with progressively longer delays between attempts. This approach allows DynamoDB time to recover from temporary capacity constraints, significantly increasing the success rate of API calls without overwhelming the database, thus making the Lambda function more resilient.

Amazon ElastiCache, particularly when configured with Redis, provides a highly scalable, in-memory data store offering extremely low-latency read and write access essential for responsive session management. It supports high availability through replication and automatic failover, ensuring session data persistence and resilience against node failures. This centralized caching layer allows multiple web servers to efficiently share and access session state, enabling stateless application design crucial for scalability and seamless user experience across instances.

AWS Config rules continuously evaluate S3 buckets against predefined or custom compliance standards, such as requiring server-side encryption or blocking public access. When a non-compliant bucket is detected, Config can automatically trigger remediation actions, like applying a default encryption policy or enabling S3 Block Public Access, ensuring ongoing adherence to security policies across all accounts where the rule is deployed. This proactive approach ensures that any newly created or modified non-compliant buckets are swiftly brought into compliance without manual intervention.

Adding a manual approval action in the CodePipeline pipeline is the standard and correct way to introduce a human approval gate. When the pipeline reaches this action, it automatically pauses and waits for an authorized user to approve or reject via the AWS Management Console, CLI, or SDK (using the ApproveManualApproval or RejectManualApproval APIs). This native action supports IAM-based access control, optional SNS notifications, and an auditable approval history, and it integrates directly with the pipeline's state machine.

DynamoDB On-demand capacity mode is specifically designed for workloads with unpredictable traffic patterns and sudden, sharp spikes. It operates on a pay-per-request model, automatically scaling throughput up or down instantly to accommodate actual traffic volume without requiring any capacity planning. This eliminates the risk of throttling during peak loads and avoids over-provisioning during quiet periods, making it ideal for highly variable session data.

AWS policy evaluation logic dictates that an explicit `Deny` statement in any policy always overrides an `Allow` statement, even if the `Allow` is present in an identity-based policy attached to the Lambda execution role. If the S3 bucket's resource policy explicitly denies the Lambda role access for `s3:PutObject`, this denial will take precedence, preventing the Lambda function from uploading objects despite its own role permissions. This is a common security control for resource owners.

When S3 performs server-side encryption with AWS KMS (SSE-KMS), it requires the calling principal, such as the Lambda function's execution role, to have the kms:GenerateDataKey permission. This specific permission allows S3 to request a unique data key from KMS to encrypt the object data itself. Without this crucial permission, S3 cannot obtain the necessary encryption key to perform the server-side encryption during the PutObject operation, leading to a failure.

Enabling DynamoDB Auto Scaling, powered by AWS Application Auto Scaling, is the most effective solution for preventing throttling due to fluctuating workloads. Auto Scaling dynamically adjusts the table's provisioned read and write capacity units (RCUs/WCUs) up or down in response to actual traffic patterns and utilization metrics. By automatically increasing capacity during peak demand and decreasing it during lulls, it ensures sufficient throughput to avoid throttling while optimizing costs.

For an Amazon ECS task to successfully send container logs to CloudWatch Logs, the assigned Task Execution IAM role must possess specific permissions. These include logs:CreateLogStream to create the necessary log stream within the specified log group and logs:PutLogEvents to write log data to that stream. Without these critical permissions, the ECS agent will be unable to interact with CloudWatch Logs, resulting in logging failures.

Amazon CloudWatch Logs provides a scalable and centralized service for ingesting, storing, and analyzing logs from various sources, including EC2 instances, Lambda functions, and custom applications. This service is crucial for meeting PCI DSS requirements for comprehensive audit trails, enabling the collection of system-level events, application logs, and security logs necessary for monitoring and incident response. Its ability to aggregate logs from disparate sources into a single, queryable repository significantly aids in demonstrating compliance with logging and monitoring mandates.

The Parallel state is specifically designed to execute multiple independent branches of a workflow concurrently. Each branch within a Parallel state runs simultaneously, allowing for the efficient, parallel invocation of services like AWS Lambda functions. The state completes only when all its branches have finished their execution, aggregating their outputs into a single result, which perfectly addresses the requirement of calling three independent Lambda functions at the same time.

By increasing the SQS batch size to 100, the Lambda function processes up to 100 messages in a single invocation. Since the function is capable of handling this volume, this optimization significantly reduces the total number of Lambda invocations required to process a given message backlog. Fewer invocations directly translate to a lower invocation rate, effectively alleviating the throttling issues experienced by the function and optimizing resource utilization.

When an application's health check endpoint makes a synchronous call to a third-party service without proper timeout handling, a slow or unresponsive external dependency can cause the health check to hang indefinitely. This prolonged unresponsiveness will eventually exceed the Application Load Balancer's configured health check timeout threshold. Consequently, the ALB will mark the task as unhealthy and return a 503 error for requests routed to it, leading to intermittent service disruptions as tasks are cycled.

SSL/TLS (Secure Sockets Layer/Transport Layer Security) is the industry standard protocol for encrypting data in transit directly between a client application and a database server. It establishes a secure, encrypted channel, ensuring confidentiality, integrity, and authentication of the data exchanged. For an RDS instance, configuring the database client to use SSL/TLS guarantees that all data transmitted between the on-premises application and the RDS database is encrypted throughout its journey, fulfilling the requirement for data encryption in transit.

Usage plans in Amazon API Gateway are the definitive mechanism for enforcing per-client quotas and throttling limits. They allow you to associate specific API keys with defined request rates (e.g., requests per second) and burst capacities, as well as total request quotas over a given period. This ensures that individual API consumers adhere to their subscribed service tiers, preventing any single client from monopolizing API resources and providing granular control over API consumption.

AWS Systems Manager Parameter Store is a secure, hierarchical service for storing configuration data and secrets, including database passwords, as String, StringList, or SecureString parameters. SecureString parameters are encrypted with AWS KMS and can be retrieved via the AWS SDK, CLI, or directly from EC2 and Lambda, with IAM policies controlling access. It is a low-cost, no-extra-fee option (beyond KMS) and supports versioning, making it a lightweight and practical choice when you don't need built-in automatic rotation.

When an S3 object is encrypted using Server-Side Encryption with AWS KMS (SSE-KMS), S3 requires permission to interact with the specified KMS key to generate a unique data key for object encryption. The `kms:GenerateDataKey` permission is essential for the Lambda's execution role to allow S3, acting on the Lambda's behalf, to request and use this data key from AWS KMS. Without this specific permission, the encryption process fails, resulting in an error during the object upload.

Secrets Manager stores the database passwords centrally and supports native rotation, while the EC2 instance profile's IAM role grants retrieval permissions without embedding long-lived credentials. This removes hard-coded secrets and satisfies the secure, manageable requirement.

Setting a bucket policy allows you to define granular permissions and conditions for all principals interacting with the S3 bucket. By using a `Deny` statement with a condition that checks for the absence of the `s3:x-amz-server-side-encryption` header during a `s3:PutObject` action, you can effectively enforce that all new objects uploaded to the bucket must be encrypted at rest using server-side encryption. This ensures compliance across all uploads, regardless of the uploader's individual IAM permissions.

Enabling static website hosting on the S3 bucket is the essential configuration that activates the bucket's website endpoint (e.g., bucket-name.s3-website-region.amazonaws.com), which serves the site over HTTP and automatically resolves requests to an index document (like index.html) and a custom error document. Without this setting, the bucket only exposes its REST API endpoints, which require Signature Version 4 authentication and cannot render a browser-facing website. Therefore, this is a mandatory step for hosting any static site on Amazon S3.

Granting only `s3:ListBucket` on the bucket ARN itself satisfies least privilege, because listing objects is a bucket-level operation evaluated against the bucket resource, not the objects within it. Omitting `s3:GetObject` and any wildcard resource prevents unintended read access to object contents.

AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces deployable artifacts. For a serverless application, CodeBuild is an ideal choice for the build and test phase within a CI/CD pipeline. It can execute unit tests against the application code, compile any necessary language runtimes, and then package the application code along with its dependencies into a deployment-ready artifact, such as a .zip file, suitable for AWS Lambda.

When a CloudFormation stack is deleted, resources with DeletionPolicy: Delete are removed from the AWS account. For an S3 bucket, applying DeletionPolicy: Delete ensures that the bucket and all its contents are permanently deleted when the associated CloudFormation stack is terminated. This is the correct approach to ensure the bucket's lifecycle is tied directly to the stack's lifecycle, preventing orphaned resources. This attribute explicitly instructs CloudFormation to remove the resource.