75 of 254 questions · Page 1/4 · Deployment · Answers revealed
Match each AWS service to its port number (if applicable).
Drag a concept onto its matching description — or click a concept then click the description.
3306
6379
5432
11211
1521
Why these pairings
Default ports are important for configuring security groups and connecting to databases.
A company uses AWS Elastic Beanstalk to deploy a web application. The deployment is successful, but the application health checks fail. The application runs on a single EC2 instance. What should a developer do to troubleshoot this issue?
The Elastic Beanstalk console aggregates application, web server, and deployment logs (full or tail) in one place, letting the developer see stack traces, startup errors, or misconfigured health check paths that are the actual root cause of a failing health check.
Why this answer
Viewing the application logs in the Elastic Beanstalk console helps identify why the application is not responding to health checks. Logs can reveal application errors, missing dependencies, or configuration issues. Option D is wrong because SSH may not be configured for the instance, and restarting the web server without understanding the root cause may not resolve the issue.
Option B is incorrect because modifying the CloudFormation template to increase instance size does not address health check failures. Option C is incorrect because adding an Application Load Balancer does not fix underlying application problems.
A developer is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment must be as fast as possible while ensuring that at least 50% of instances remain healthy throughout. Which deployment configuration should be used?
The CodeDeployDefault.HalfAtATime configuration updates half of the instances in the Auto Scaling group at a time, ensuring that at least 50% of the instances remain healthy and available throughout the deployment process. This default strikes an optimal balance between deployment speed and application availability, making it a robust choice for production environments where some temporary capacity reduction is acceptable. It is significantly faster than `OneAtATime` while still providing strong resilience.
Why this answer
CodeDeployDefault.HalfAtATime is the correct choice because it deploys to half of the instances in the Auto Scaling group at a time, ensuring that at least 50% of instances remain healthy throughout the deployment. This configuration balances speed (by deploying to multiple instances concurrently) with the required availability constraint, making it the fastest option that satisfies the 'at least 50% healthy' requirement.
Exam trap
The trap here is that candidates may confuse 'HalfAtATime' with 'OneAtATime' thinking slower is safer, or incorrectly assume 'AllAtOnce' is fastest without considering the health constraint, or invent a configuration name like 'MinHealthyPercent' that does not exist in CodeDeploy.
How to eliminate wrong answers
Option A (CodeDeployDefault.OneAtATime) is wrong because it deploys to only one instance at a time, which is the slowest deployment configuration and does not meet the requirement for maximum speed. Option C (CodeDeployDefault.AllAtOnce) is wrong because it deploys to all instances simultaneously, which can cause all instances to become unhealthy at once, violating the 'at least 50% healthy' requirement. Option D (CodeDeployDefault.MinHealthyPercent) is wrong because it is not a valid deployment configuration name in CodeDeploy; the correct parameter is 'minimumHealthyHosts' which can be set to a percentage, but 'MinHealthyPercent' is not a predefined configuration.
A CloudFormation update may replace an RDS database. The developer wants to preview replacement risk before executing. What should be created?
A CloudFormation change set provides a comprehensive preview of the proposed modifications that CloudFormation will make to your stack's resources before you execute an update. It explicitly lists which resources will be added, modified, or replaced, including critical resources like an RDS database. This allows you to review the exact impact, such as a potential database replacement, and confirm it aligns with your intentions before applying the update to your infrastructure.
Why this answer
A change set in AWS CloudFormation allows you to preview how proposed changes to a stack will be executed, including whether any resources will be replaced (e.g., an RDS database). By reviewing the change set, you can see if the update will cause replacement (indicated by 'Replacement: True') before you actually apply the changes, enabling risk assessment without modification.
Exam trap
The trap here is that candidates confuse a stack policy (which controls update permissions) with a change set (which provides a preview of changes), or they think monitoring tools like CloudWatch can predict infrastructure changes.
How to eliminate wrong answers
Option A is wrong because a stack policy only protects specified resources from being updated or deleted during a stack update; it does not provide a preview of replacement risk. Option C is wrong because a nested stack output is used to return values from a nested stack to the parent stack, not to preview update impacts. Option D is wrong because a CloudWatch dashboard is a monitoring tool for metrics and logs, not a mechanism to preview CloudFormation stack update behavior.
A developer is deploying a microservices application on Amazon ECS using Fargate. The application uses an Application Load Balancer (ALB) to distribute traffic. The developer needs to perform a blue/green deployment with automatic rollback if health checks fail. What should the developer use?
AWS CodeDeploy, when configured for blue/green deployments with Amazon ECS, provides a robust and automated solution for deploying new application versions. It creates a new 'green' environment with the updated tasks alongside the existing 'blue' environment, allowing for thorough testing before traffic is shifted. CodeDeploy manages the traffic routing via a load balancer and can automatically roll back to the stable 'blue' version if deployment health checks fail, ensuring minimal downtime and risk.
Why this answer
AWS CodeDeploy natively supports blue/green deployments for Amazon ECS, allowing you to specify a blue/green configuration that automatically shifts traffic from the old (blue) task set to the new (green) task set. It integrates with the ALB to perform health checks and can automatically roll back the deployment if the health checks fail, meeting the requirement without manual intervention.
Exam trap
The trap here is that candidates often confuse ECS service auto scaling or CloudFormation updates with deployment strategies, but neither provides the built-in blue/green traffic shifting and automatic health-check-based rollback that CodeDeploy offers.
How to eliminate wrong answers
Option A is wrong because ECS service auto scaling adjusts the number of tasks based on load, not the deployment strategy; it does not perform blue/green deployments or automatic rollback on health check failures. Option B is wrong because manually updating the ECS service via the AWS Management Console does not provide a built-in blue/green deployment mechanism or automatic rollback; it would require manual monitoring and intervention. Option C is wrong because AWS CloudFormation can update an ECS service with a new task definition, but it does not natively support blue/green deployments or automatic rollback based on health checks; it would require custom logic or additional resources to achieve this.
A developer uses AWS SAM (Serverless Application Model) to define a serverless application. The developer wants to run the application locally for testing. Which AWS SAM CLI command should be used?
This command is specifically designed for local development and testing of serverless applications defined by AWS SAM. It emulates the API Gateway service on your local machine, creating HTTP endpoints that route requests to your Lambda functions running in a Docker container. This allows developers to test their API endpoints and Lambda logic without deploying to the AWS cloud, significantly accelerating the development cycle.
Why this answer
`sam local start-api` starts a local HTTP server that emulates the API Gateway endpoint and invokes your Lambda functions defined in the SAM template. This allows you to test API requests and responses locally without deploying to AWS, making it the appropriate command for local testing of a serverless application.
Exam trap
The trap here is that candidates confuse `sam build` or `sam package` as commands that also run the application locally, but these commands are solely for packaging and deployment preparation, not for local execution.
How to eliminate wrong answers
Option B is wrong because `sam build` is used to prepare the application for deployment by resolving dependencies and creating build artifacts, but it does not run the application locally. Option C is wrong because `sam deploy` deploys the application to the AWS cloud using CloudFormation, which is not a local testing command. Option D is wrong because `sam package` uploads the deployment artifacts to an S3 bucket and generates a packaged template, but it does not execute or test the application locally.
A developer uses AWS CodePipeline to deploy a serverless application defined with AWS SAM. The pipeline consists of Source (S3), Build (CodeBuild), and Deploy (CloudFormation) stages. The developer wants to run integration tests after the stack is deployed but before the pipeline completes. Which approach should the developer use?
AWS CodePipeline is designed for continuous delivery, allowing developers to define multiple stages, including a dedicated 'Test' stage. Within this stage, an 'Invoke' action can be configured to execute an AWS Lambda function. This Lambda function can then contain the logic to perform various integration or end-to-end tests against the newly deployed serverless application, ensuring automated validation post-deployment. This approach fully automates the testing process within the pipeline.
Why this answer
AWS CodePipeline allows you to add a test stage after the Deploy stage, and you can configure an action that invokes an AWS Lambda function to run integration tests. This ensures tests run automatically after the CloudFormation stack is deployed but before the pipeline completes, meeting the requirement without manual intervention.
Exam trap
The trap here is that candidates may confuse CloudFormation Outputs with event-driven triggers or assume SAM has built-in post-deployment hooks, when in fact CodePipeline's custom action with Lambda is the correct mechanism for running automated tests after deployment.
How to eliminate wrong answers
Option B is wrong because CloudFormation stack Outputs are used to export values for cross-stack references, not to trigger Lambda functions; triggering Lambda from CloudFormation requires custom resources or event subscriptions, not Outputs. Option C is wrong because AWS SAM does not support post-deployment hooks in the SAM template; SAM uses lifecycle hooks (e.g., PreTraffic, PostTraffic) only for Lambda canary deployments, not for general integration testing. Option D is wrong because a manual approval step requires human intervention to run tests, which contradicts the requirement to run tests automatically before the pipeline completes.
A developer is deploying a serverless application using the AWS Serverless Application Model (SAM). The application consists of an API Gateway, a Lambda function, and a DynamoDB table. The developer wants to enable canary deployments for the Lambda function. What should the developer do?
This is the correct and most efficient method for enabling canary deployments with SAM. The AutoPublishAlias property in a SAM Lambda function resource automatically creates a new Lambda version and an alias pointing to it upon deployment, facilitating robust version management. The DeploymentPreference property then configures the traffic shifting strategy, including options for canary or linear deployments, automated rollback alarms, and pre/post-traffic hooks, all orchestrated by AWS CodeDeploy under the hood, enabling fully automated canary deployments.
Why this answer
The AWS SAM template supports canary deployments for Lambda functions by adding the `AutoPublishAlias` property (which automatically creates and publishes a new version to a Lambda alias) and the `DeploymentPreference` property (which defines the traffic-shifting strategy, such as `Canary10Percent5Minutes`). This enables CodeDeploy to gradually shift traffic from the current version to the new version without manual intervention.
Exam trap
The trap here is that candidates may think they need to manually create a Lambda alias or use CodePipeline for canary deployments, when in fact SAM's `AutoPublishAlias` and `DeploymentPreference` properties automate the entire canary deployment workflow via CodeDeploy.
How to eliminate wrong answers
Option A is wrong because CodeDeploy deployment groups are not directly configured in a SAM template; SAM abstracts this by generating the necessary CodeDeploy resources automatically when you use `DeploymentPreference`. Option B is wrong because manually creating a Lambda alias and configuring traffic shifting defeats the purpose of using SAM's built-in canary deployment support, which automates the entire process and integrates with CodeDeploy. Option D is wrong because AWS CodePipeline can orchestrate the overall CI/CD pipeline but is not required for canary deployments; SAM's `DeploymentPreference` property alone enables canary deployments without needing CodePipeline.
A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment'. The deployment configuration is set to CodeDeployDefault.OneAtATime. What is the most likely cause of this failure?
CodeDeploy deployment configurations, such as `CodeDeployDefault.OneAtATime`, often specify a minimum healthy host threshold, which can be 100%. If a deployment fails on even a single instance due to issues like a failed lifecycle hook or an application startup problem, it immediately violates this strict healthy host requirement. This single failure is sufficient to cause the entire deployment to stop or roll back, triggering an error that indicates the minimum number of healthy hosts could not be maintained.
Why this answer
CodeDeployDefault.OneAtATime deploys to one instance at a time. The deployment stops immediately if a single instance fails, because the deployment configuration expects no failures. The error 'too many individual instances failed' is triggered by that single failure, since the deployment cannot proceed to the next instance without violating the minimum healthy hosts requirement, which is set to maintain availability.
Exam trap
The trap here is that candidates assume 'too many individual instances failed' means multiple instances failed independently, when in fact with OneAtATime a single instance failure is enough to fail the entire deployment because the minimum healthy hosts requirement is not maintained.
How to eliminate wrong answers
Option A is wrong because an unsupported operating system would cause a different error (e.g., 'Unsupported OS') and would affect all instances uniformly, not trigger a per-instance failure that cascades due to the OneAtATime configuration. Option B is wrong because changing to AllAtOnce would increase risk by deploying to all instances simultaneously, potentially causing a full outage; the error is not about the deployment speed but about the minimum healthy hosts requirement being violated. Option C is wrong because insufficient IAM permissions would typically result in an authorization error (e.g., 'AccessDenied') during the deployment setup or agent communication, not a per-instance failure that triggers the 'too many individual instances failed' message.
A company uses AWS Elastic Beanstalk to run a web application. They want to deploy a new version with zero downtime and roll forward if successful. They have two environments: a production environment (current version) and a staging environment (new version). After verifying the staging environment, they want to swap the URLs so that production now points to the new version. Which deployment strategy should they use?
Blue/green deployment with environment CNAME swap is the most robust strategy for zero-downtime deployments and easy rollback. It involves creating a completely new, separate Elastic Beanstalk environment (the "green" environment) running the new application version, while the existing "blue" environment continues to serve traffic. After thorough testing of the green environment, the CNAME record of the load balancer is atomically swapped, redirecting all traffic to the new environment instantly. This approach ensures the new version is fully validated before going live and allows for immediate rollback by swapping the CNAME back.
Why this answer
Blue/green deployment with an environment CNAME swap allows you to run two separate Elastic Beanstalk environments (production and staging) simultaneously. After verifying the new version in the staging environment, you swap the CNAME records so that the production URL points to the staging environment, achieving zero downtime and a roll-forward strategy. This approach decouples the deployment from the existing environment, ensuring no disruption to live traffic during the swap.
Exam trap
The trap here is that candidates confuse immutable deployments (which also launch new instances) with blue/green deployments, but immutable deployments do not create a separate environment with its own URL for a CNAME swap, making them unsuitable for the described two-environment swap requirement.
How to eliminate wrong answers
Option B (All at once deployment) is wrong because it deploys the new version to all instances simultaneously, causing downtime during the deployment process and not allowing a roll-forward strategy with separate environments. Option C (Rolling deployment with additional batch) is wrong because it updates instances in batches while keeping the same environment, which can cause temporary capacity reduction and does not provide a separate staging environment for verification before swapping URLs. Option D (Immutable deployment) is wrong because it launches a new set of instances in the same environment and then swaps them in, but it does not create a separate environment with its own URL for a CNAME swap; it still operates within a single environment, making it unsuitable for the described two-environment swap scenario.
A company uses AWS CodePipeline to deploy a static website to Amazon S3. The pipeline includes a deploy action that uses AWS CloudFormation to create the S3 bucket and upload files. The developer notices that the deploy action fails intermittently with a 'BucketAlreadyExists' error. What is the most likely cause?
S3 bucket names are globally unique across all AWS accounts and regions, acting as a universal namespace. Therefore, if any other AWS account, anywhere in the world, has already registered a bucket with the exact name specified in the CloudFormation template, the creation attempt will fail. The `BucketAlreadyExists` error precisely indicates this global naming conflict, preventing the new bucket from being provisioned.
Why this answer
The 'BucketAlreadyExists' error occurs when an S3 bucket name is globally unique across all AWS accounts. If the bucket name specified in the CloudFormation template has already been claimed by another AWS account, the deployment will fail intermittently if the bucket is deleted and recreated or if the pipeline runs in a different region where the name is taken. This is a common issue when using hardcoded or non-unique bucket names.
Exam trap
The trap here is that candidates often confuse 'BucketAlreadyExists' with permission or policy errors, but AWS specifically tests the global uniqueness constraint of S3 bucket names as a distinct failure mode in deployment pipelines.
How to eliminate wrong answers
Option A is wrong because enabling versioning on an S3 bucket does not cause a 'BucketAlreadyExists' error; versioning affects object version management, not bucket creation. Option B is wrong because incorrect IAM permissions would result in an 'AccessDenied' error, not a 'BucketAlreadyExists' error, as the CloudFormation service would fail to call the S3 CreateBucket API due to lack of authorization. Option D is wrong because a restrictive bucket policy would cause errors during object uploads or access, not during bucket creation; the 'BucketAlreadyExists' error occurs at the bucket creation step, before any policy is evaluated.
An IAM policy is attached to an EC2 instance role. The instance is part of a CodeDeploy deployment group. The deployment fails because the CodeDeploy agent cannot download the revision. What is the most likely reason?
This policy statement correctly identifies a common issue: the CodeDeploy agent needs explicit `s3:GetObject` permissions for the *exact* S3 bucket and path where the application revision is stored. If the IAM policy only grants access to a generic bucket like 'my-bucket', but the actual deployment package resides in a different bucket, such as 'another-bucket', the agent will be unable to download the necessary files, causing the deployment to fail due to an access denied error.
Why this answer
The CodeDeploy agent on the EC2 instance downloads the application revision from an S3 bucket. For this to succeed, the IAM role attached to the instance must include an s3:GetObject permission on the specific bucket and object. Without it, the agent cannot retrieve the revision file, causing the deployment to fail.
Options A and B are irrelevant because the agent does not call CodeDeploy API actions like GetDeployment or CreateDeployment; those are used by the user or CI/CD pipeline initiating the deployment. Option C is incorrect because IAM policies for S3 actions do not require a region in the resource ARN.
Exam trap
The trap here is that candidates confuse the permissions needed by the CodeDeploy agent (S3 read access) with the permissions needed by the user or pipeline (CodeDeploy API actions), leading them to select a CodeDeploy action instead of the correct S3 action.
How to eliminate wrong answers
Option A is wrong because the CodeDeploy agent does not call the codedeploy:GetDeployment action; that action is used by the AWS CLI, SDK, or console to retrieve deployment details. Option B is wrong because the codedeploy:CreateDeployment action is performed by the user or automation tool initiating the deployment, not by the CodeDeploy agent on the instance. Option C is wrong because S3 is a global service and its resource ARNs do not include a region element; specifying a region in an S3 ARN would be syntactically invalid.
A company uses AWS CloudFormation to manage its infrastructure. The developer wants to update a stack but only if the update does not cause any resource replacement. Which CloudFormation stack update option should be used?
Creating a change set allows you to preview the exact modifications CloudFormation will perform on your stack before applying them. The change set details which resources will be added, modified, or, critically, replaced, along with the specific properties that trigger these actions. By reviewing this detailed summary, administrators can identify and adjust the template to avoid unintended resource replacements, ensuring a controlled and predictable update process.
Why this answer
A change set allows you to preview the changes that CloudFormation will make to your stack, including whether any resources will be replaced. By reviewing the change set, you can see if any resource replacement is listed and choose not to execute it if you want to avoid replacements. This gives you full control to update the stack only when no replacements are required.
Exam trap
The trap here is that candidates may confuse change sets with direct updates, thinking that direct updates also provide a preview, or they may invent fictional options like 'Force rollback' or 'Preserve stack settings' that sound plausible but are not part of the CloudFormation service.
How to eliminate wrong answers
Option A is wrong because the direct update option immediately applies the template changes without any preview, so you cannot know in advance whether resource replacement will occur. Option C is wrong because the 'Force rollback' option is not a standard CloudFormation feature; rollback is triggered automatically on update failure, not used to prevent replacement. Option D is wrong because there is no 'Preserve stack settings' option in CloudFormation; this is a fictional option that does not exist in the AWS API.
Refer to the exhibit. A developer has the above IAM policy attached. The developer is trying to push code to a CodeCommit repository and trigger a CodePipeline. The push succeeds but the pipeline does not start. What is the most likely reason?
While the developer has permissions to push code, the automated trigger mechanism relies on a CloudWatch Events rule. This rule, when detecting a code push event, attempts to invoke CodePipeline. For this invocation to succeed, the CloudWatch Events rule itself must be associated with an IAM role that possesses "codepipeline:StartPipelineExecution" permissions on the target pipeline. Without this specific service-level permission, the rule cannot initiate the pipeline, even if the developer has their own permissions.
Why this answer
The pipeline is triggered by a CloudWatch Events rule that monitors code push events. For the rule to invoke the pipeline, it must have an IAM role with permission to start the pipeline. If that role is missing or lacks permissions, the pipeline won't start even though the developer has push permissions.
Option A is incorrect because the developer's policy allows GitPush, so push succeeds. Option C is incorrect because the developer has StartPipelineExecution permission, but that's not how the pipeline is triggered—it's an event-driven trigger. Option D is incorrect because CodeCommit does not require a trigger to be configured; the CloudWatch Events rule handles the event.
A development team is using AWS Elastic Beanstalk to deploy a web application. The team wants to perform a blue/green deployment. Which THREE steps are required to complete the blue/green deployment?
Elastic Beanstalk assigns each environment a CNAME (e.g., myapp-env.eba-123.us-east-1.elasticbeanstalk.com), and the 'Swap environment CNAMEs' action atomically exchanges the DNS names of the blue and green environments. This makes the new environment assume the old environment's URL, instantly redirecting all traffic to the green stack with zero downtime. It is the core traffic-shifting mechanism for blue/green on Elastic Beanstalk, and you can roll back by swapping the CNAMEs again.
Why this answer
Elastic Beanstalk blue/green deployment requires creating a completely new environment rather than updating the existing one, so option E (deploy the new application version to a separate Elastic Beanstalk environment) is correct because the new version must run in its own environment alongside the original. Option B (swap the CNAMEs of the two environments) is correct because Elastic Beanstalk's Swap Environment URLs feature exchanges the CNAMEs so that the environment URL users already use now resolves to the new environment, redirecting traffic without DNS changes. Option C (terminate the old environment after verifying the new environment) is correct because once the swap is validated and the new environment is healthy, the original environment is no longer needed and should be terminated to avoid unnecessary resource charges.
Option A is incorrect because updating the existing environment in place is a rolling/all-at-once deployment, not blue/green, and would not provide an instant rollback path. Option D is incorrect because Elastic Beanstalk blue/green uses the built-in CNAME swap rather than manually editing a Route 53 DNS record.
Exam trap
DVA-C02 often tests the confusion between in-place deployments and blue/green, or the misconception that you need to manually update Route 53 records instead of using the Elastic Beanstalk CNAME swap feature.
A company uses AWS Elastic Beanstalk to deploy a web application. The developer wants to perform a blue/green deployment to minimize downtime. The developer creates a new environment and deploys the new version. After verifying the new environment is healthy, the developer needs to swap the URLs so that traffic is routed to the new environment. Which AWS Elastic Beanstalk feature should the developer use?
The 'Swap environment URLs' feature in Elastic Beanstalk is specifically designed for zero-downtime blue/green deployments. It atomically exchanges the CNAME records of two distinct environments, typically a 'blue' production environment and a 'green' new version. This ensures that traffic is seamlessly redirected to the new application version without any service interruption, making it ideal for deploying updates.
Why this answer
Use the 'Swap environment URLs' feature in the Elastic Beanstalk console. This feature swaps the CNAME records between two environments, allowing you to route traffic to the new, healthy environment with minimal downtime. Option B is not recommended because deleting the old environment before fully verifying the new one is risky.
Option C involves Route 53 weighted routing, which is not an Elastic Beanstalk feature and requires manual DNS management outside of Elastic Beanstalk. Option D is incorrect because environment CNAMEs are managed by Elastic Beanstalk and cannot be changed manually.
A developer is using AWS CodePipeline with multiple actions in a stage. The pipeline has a build action that produces artifacts, followed by a deploy action. The developer wants to ensure that if the deploy action fails, the pipeline stops and does not continue to the next stage. How can they achieve this?
AWS CodePipeline is designed to inherently stop the entire pipeline execution immediately upon the failure of any action within any stage. This default behavior is crucial for maintaining the integrity of the CI/CD process, preventing the deployment of potentially faulty code or artifacts to subsequent environments. No explicit configuration is required to enable this safety mechanism, as it is a fundamental aspect of CodePipeline's operational design.
Why this answer
AWS CodePipeline stages are sequential by default: if any action within a stage fails, the entire stage fails and the pipeline stops, preventing execution of subsequent stages. No additional configuration is needed to halt the pipeline on a deploy action failure, as this is the inherent behavior of a pipeline stage with multiple actions.
Exam trap
The trap here is that candidates may overthink and assume they need to configure a special failure behavior, when in fact the default sequential pipeline execution already stops on any action failure.
How to eliminate wrong answers
Option A is wrong because CodePipeline does not support an 'Abort' action configuration; the only failure behaviors are 'Fail' (default) and 'Succeed' (to ignore the failure). Option B is wrong because 'runOrder' controls the execution order of actions within a stage, not a blocking mechanism on failure; setting it to 'Blocked' is not a valid value. Option D is wrong because setting the execution mode to 'PARALLEL' would cause actions in the stage to run concurrently, which does not affect the pipeline's stopping behavior on failure and could even allow other actions to continue after a failure.
A developer is deploying a static website to Amazon S3 and wants to use Amazon CloudFront for content delivery. The developer wants to ensure that only CloudFront can access the S3 bucket. Which S3 bucket policy should the developer use?
Granting CloudFront access through an Origin Access Identity (OAI) is the recommended and most secure method. An OAI is a special CloudFront user that you associate with your distribution, and then you modify the S3 bucket policy to explicitly grant read permissions only to this specific OAI. This ensures that content can only be accessed through your CloudFront distribution, preventing direct public access to the S3 bucket and securing your origin.
Why this answer
An Origin Access Identity (OAI) is a special CloudFront user that you can associate with your distribution. By configuring the S3 bucket policy to grant access only to that OAI, you ensure that direct S3 requests are denied, and only requests routed through CloudFront can retrieve objects. This provides a secure, private origin without exposing the bucket publicly.
Exam trap
The trap here is that candidates often choose IP-based restrictions (Option C) or Referer header checks (Option A) because they seem simpler, but AWS explicitly recommends OAI for secure S3 origin access in CloudFront, and the exam tests this best practice.
How to eliminate wrong answers
Option A is wrong because the Referer header can be easily spoofed by clients, so it does not provide a reliable security mechanism to restrict access exclusively to CloudFront. Option B is wrong because making the bucket public defeats the purpose of restricting access to CloudFront only, and anyone with the S3 URL can bypass CloudFront entirely. Option C is wrong because CloudFront IP address ranges are shared with other AWS services and can change without notice, making this approach both insecure and difficult to maintain; it also does not prevent direct access from other sources within the same IP range.
A team uses AWS CodeBuild to run automated tests. The buildspec.yaml file contains a 'pre_build' phase that sets environment variables. During a build, the build fails with 'Error: Cannot find module 'express' when running a Node.js application. The application's package.json is in the source root. What is the most likely cause?
For Node.js projects, the `express` module, like other project dependencies, must be explicitly installed into the build environment. This is typically achieved by running `npm install` (or `yarn install`) within the `install` or `pre_build` phase of the CodeBuild `buildspec.yml`. Without this command, the `node_modules` directory will not be populated, leading to a "cannot find module 'express'" error when the application attempts to import it.
Why this answer
AWS CodeBuild runs each phase in the buildspec in order: install, pre_build, build, post_build. If the buildspec does not include an 'npm install' (or 'npm ci') command in the install or pre_build phase, the Node.js dependencies listed in package.json — including express — are never downloaded into node_modules. The build then fails when it tries to require('express').
The fix is to add 'npm install' to the install phase.
Exam trap
DVA-C02 often tests the misconception that CodeBuild automatically installs dependencies — candidates assume the runtime handles it, but you must explicitly run npm install in the buildspec.
How to eliminate wrong answers
Option A is wrong because a Node.js runtime incompatibility would typically produce a different error (e.g., syntax or engine mismatch), and express is broadly compatible; the error 'Cannot find module' specifically means the module is not present. Option B is wrong because NODE_ENV=production skips devDependencies, but express is a regular dependency, so it would still be installed if npm install ran. Option D is wrong because the question states package.json is in the source root, so the path is correct.
A company deploys a microservices application using AWS CloudFormation. Each microservice is deployed as a separate stack. The developer wants to pass the output values (e.g., API endpoint URLs) from one stack to another. Which CloudFormation feature should be used?
This is the native and most efficient CloudFormation mechanism for sharing values between *independent* stacks. A stack can explicitly `Export` an output value, making it discoverable and consumable by other CloudFormation stacks within the same AWS account and region. These other stacks can then use the `Fn::ImportValue` intrinsic function to reference the exported value by its unique name, establishing a direct and managed dependency without requiring custom code or complex workarounds. This approach ensures proper dependency tracking and simplifies value propagation.
Why this answer
Cross-stack references using Export and ImportValue allow you to share values between CloudFormation stacks. You export a value from one stack and import it into another, enabling loose coupling. This is the standard way to pass outputs between separate stacks.
Exam trap
DVA-C02 often tests the difference between nested stacks and cross-stack references. Candidates may confuse nested stacks (which are part of a single stack) with cross-stack references (which link separate stacks).
How to eliminate wrong answers
Option A is wrong because custom resources with Lambda are used to execute custom logic during stack operations, not for passing values between stacks. Option B is wrong because stack outputs alone do not enable cross-stack referencing; they must be exported. Option C is wrong because nested stacks are used to compose stacks within a single parent stack, not for sharing values between independent stacks.
A company has a production environment using AWS Elastic Beanstalk with a multi-container Docker platform. The application consists of a PHP web server and a Redis cache, each running in separate containers. The deployment uses a rolling update policy with a batch size of 1. Recently, during deployments, some users experience intermittent 502 Bad Gateway errors for about 30 seconds. The errors occur when the old containers are terminated and new containers are not yet ready to serve traffic. The development team wants to eliminate this downtime without increasing the deployment time significantly. The team has access to modify the Elastic Beanstalk environment configuration and the Dockerrun.aws.json file. Which action should the team take to resolve the issue?
Configuring a health check grace period is crucial for allowing newly launched instances or containers sufficient time to fully initialize and pass their application-level health checks. This delay prevents the load balancer from prematurely marking an instance as unhealthy simply because it hasn't completed its startup routine. By doing so, it ensures that traffic is only routed to instances that are genuinely ready to serve requests, thereby maintaining application availability during deployments.
Why this answer
Configuring a health check grace period allows new containers time to become healthy before the load balancer routes traffic to them, preventing the 502 errors during the transition. Option A is incorrect because increasing the batch size would cause more containers to be replaced simultaneously, potentially increasing downtime. Option C is incorrect because 'All at once' deployment would terminate all old containers before starting new ones, causing full downtime.
Option D is incorrect because reducing the health check interval would make the load balancer check more frequently, which could cause premature routing to unhealthy instances and exacerbate the issue.
A company uses CodePipeline to deploy a web application to Elastic Beanstalk. The deployment fails at the Build stage with an error 'BUILD FAILED'. Which step should the developer take first to troubleshoot?
When a CodePipeline build stage fails, the `buildspec.yml` file is the primary configuration for the AWS CodeBuild project responsible for compiling code, running tests, and packaging artifacts. Syntax errors within this YAML file, such as incorrect indentation, invalid commands, or missing required phases, will directly prevent CodeBuild from executing its defined steps successfully. Reviewing the CodeBuild project logs, which detail the execution of each command specified in `buildspec.yml`, is crucial for identifying the exact line or phase where the build process encountered an unrecoverable error.
Why this answer
The error 'BUILD FAILED' originates from the Build stage, which is executed by CodeBuild. The first step in troubleshooting a CodeBuild failure is to review the buildspec.yml file for syntax errors or misconfigurations, as this file defines the build commands, environment variables, and phases. Incorrect YAML formatting, missing required fields (e.g., 'phases'), or invalid commands will cause the build to fail immediately, making it the most direct and logical starting point.
Exam trap
The trap here is that candidates may jump to checking Elastic Beanstalk logs or CloudTrail, assuming the failure is related to deployment or API issues, when the error clearly indicates a build-stage failure that is most often caused by a misconfigured buildspec.yml file.
How to eliminate wrong answers
Option B is wrong because CodeDeploy is used in the Deploy stage, not the Build stage; verifying the application revision would only be relevant if the failure occurred during deployment, not during the build process. Option C is wrong because Elastic Beanstalk environment logs pertain to runtime issues with the deployed application, not to build-time failures in CodeBuild; the build fails before any deployment to Elastic Beanstalk occurs. Option D is wrong because AWS CloudTrail records API calls for auditing and security, but it does not provide granular details about build execution errors, such as syntax errors in buildspec.yml or command failures within CodeBuild.
A developer is using AWS CodePipeline to automate the deployment of a microservices application. The pipeline consists of a source stage (GitHub), a build stage (AWS CodeBuild), and a deploy stage (Amazon ECS). The developer wants to ensure that only approved changes are deployed to production. Which THREE actions should the developer take? (Choose THREE.)
In CodePipeline, a manual approval step is an action that pauses the pipeline execution at a specified stage and sends an SNS notification to designated reviewers. The reviewer must sign in, review the deployment details, and choose Approve or Reject before the Deploy stage can run, providing a human control point for production changes. This is the recommended way to satisfy a 'gates' requirement without removing automation.
Why this answer
Option C is correct because inserting a manual approval action (an Approval action in CodePipeline, typically using Amazon SNS to notify approvers) between the build stage and the ECS deploy stage gates production deployment so that only changes a human explicitly approves proceed to production. Option D is correct because using separate pipelines for dev, staging, and prod isolates environments, so a change must pass through the earlier pipelines before a production pipeline is triggered, preventing unvetted commits from reaching production. Option E is correct because adding integration tests in the CodeBuild build stage (via buildspec.yml commands) validates the microservices against their dependencies and fails the pipeline on errors, so broken or unapproved-quality changes never reach the deploy stage.
Option A is incorrect because automatically deploying every commit to production removes any approval gate and directly contradicts the requirement that only approved changes be deployed. Option B is incorrect because deploying all feature branches directly to production bypasses review, testing, and approval, which is exactly the risk the developer wants to eliminate.
Exam trap
DVA-C02 often tests the misconception that automation alone ensures safety, so candidates select auto-deploy options instead of recognizing that approval gates and environment separation are required for controlled production releases.
A developer is deploying a serverless application using AWS SAM. The application includes an AWS Lambda function that is triggered by an S3 bucket event when an object is created. The developer wants to ensure that the Lambda function has the correct permissions to be invoked by S3. Which resource should the developer define in the SAM template?
AWS::Lambda::Permission creates the resource-based policy granting S3 the lambda:InvokeFunction action, which is what allows the bucket's event notification to invoke the function. Execution roles govern outbound calls, not inbound invocation, so this resource satisfies the stated requirement.
Why this answer
AWS::Lambda::Permission is the correct resource because it explicitly grants the S3 service principal permission to invoke the Lambda function when an object is created. In AWS SAM, this resource is automatically generated when you define an S3 event source on a Lambda function, but if you need to declare it manually or override permissions, you use AWS::Lambda::Permission with a SourceArn pointing to the S3 bucket and a SourceAccount to prevent confused deputy attacks.
Exam trap
The trap here is that candidates confuse the Lambda execution role (IAM::Role) with the invocation permission (Lambda::Permission), or mistakenly think S3 uses a bucket policy or event source mapping to trigger Lambda, when in fact S3 uses a push-based notification that requires a resource-based policy on the Lambda function.
How to eliminate wrong answers
Option B is wrong because AWS::S3::BucketPolicy controls access to the S3 bucket itself (e.g., who can read/write objects), not who can invoke a Lambda function; S3 uses a Lambda resource-based policy, not a bucket policy, to trigger invocations. Option C is wrong because AWS::Lambda::EventSourceMapping is used for poll-based event sources like DynamoDB Streams, Kinesis, or SQS, not for S3 event notifications, which are push-based and do not require an event source mapping. Option D is wrong because AWS::IAM::Role defines the execution role for the Lambda function (what the function can do), not the permissions for S3 to invoke the function; invocation permissions are handled via a resource-based policy on the Lambda function itself.
A developer is using the AWS CLI to deploy a new version of a Lambda function. The developer runs the following command: aws lambda update-function-code --function-name my-function --zip-file fileb://my-code.zip After the command completes, the developer checks the function and sees that the code has been updated but the version number is still $LATEST. The developer wants to create a new version so that the previous version is preserved. What should the developer do next?
The publish-version command is the precise and correct mechanism to create an immutable, numbered version of a Lambda function based on the current state of its $LATEST qualifier. Since the developer has already successfully updated the function's code (which implicitly updates $LATEST), this command will capture that specific, updated code as a new, distinct version. This new version can then be referenced by aliases, enabling controlled deployments and reliable rollbacks.
Why this answer
The `update-function-code` command without the `--publish` flag only updates the `$LATEST` version of the Lambda function. To create an immutable, numbered version that preserves the previous code, the developer must explicitly run the `publish-version` command, which takes the current `$LATEST` code and publishes it as a new version (e.g., version 2). This ensures the previous version (version 1) remains unchanged and can be referenced via its version ARN.
Exam trap
The trap here is that candidates assume the `update-function-code` command automatically creates a new version, but it only updates `$LATEST` unless the `--publish` flag is explicitly used, leading them to incorrectly choose Option A or D.
How to eliminate wrong answers
Option A is wrong because the `--publish` flag is used with `update-function-code` to publish a new version in a single step, but running the command again without it will not retroactively publish the already-updated `$LATEST`; it would simply re-upload the same code. Option B is wrong because deleting and recreating the function is unnecessary and destructive—it removes all existing versions, aliases, and event source mappings, which is not required to simply create a new version from the updated code. Option D is wrong because `update-function-configuration` modifies settings like memory, timeout, or environment variables, not the version number; version numbers are immutable and can only be created via `publish-version` or the `--publish` flag during code update.
A company uses AWS Elastic Beanstalk to deploy a Python web application. After a successful deployment, the environment's health turns 'Severe' and the application returns HTTP 502 errors. What is the most likely cause?
When a Python application deployed on Elastic Beanstalk has a missing dependency in its `requirements.txt` file, the application server (e.g., Gunicorn, uWSGI) will fail to start correctly or crash immediately upon startup. The proxy server (e.g., Nginx, Apache) on the EC2 instance will then be unable to establish a connection or forward requests to the unresponsive application server. This common scenario directly leads to a 502 Bad Gateway error, as the proxy cannot communicate with the upstream application process.
Why this answer
A missing dependency in requirements.txt causes the Python application to fail during startup, leading to the EC2 instances reporting an unhealthy status to the Elastic Load Balancer. Elastic Beanstalk relies on the application process to respond to health checks; if the app crashes due to an ImportError, the load balancer receives no valid HTTP response and returns 502 Bad Gateway errors. The environment health turns 'Severe' because the platform detects that the application process is not running or is failing repeatedly.
Exam trap
The trap here is that candidates often confuse HTTP 502 with 503 or 504, or assume that a missing dependency would cause a deployment failure rather than a runtime error that still allows the environment to be created but with a broken application.
How to eliminate wrong answers
Option A is wrong because insufficient storage on EC2 instances would typically cause deployment failures or disk-full errors, not HTTP 502 errors; the load balancer would still receive a response from the web server, albeit potentially slow or incomplete. Option C is wrong because an incorrectly configured health check path would cause the load balancer to mark instances as unhealthy and return 503 Service Unavailable, not 502 Bad Gateway; 502 indicates the upstream server (the application) is not responding correctly. Option D is wrong because an incorrect RDS connection string would cause the application to fail at runtime when querying the database, but the web server would still start and respond to health checks with a 200 status unless the application crashes entirely on startup due to the misconfiguration.
A company is using AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error: 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The application is deployed to a t2.micro instance with 1 GB of RAM. The deployment uses an in-place update with a deployment configuration that has a minimum of 1 healthy host. What is the most likely cause of the failure?
A t2.micro instance has only 1 GB of RAM, which is a very limited resource for many modern web applications. If the application, especially during startup or initial load after deployment, consumes memory beyond this capacity, the operating system may become unresponsive or critical services could crash. This resource exhaustion would cause the instance's health checks, monitored by CodeDeploy and potentially an associated Load Balancer or Auto Scaling Group, to fail, leading to a deployment rollback or failure.
Why this answer
The most likely cause is option A: the application uses too much memory, causing the instance to become unhealthy during deployment. The t2.micro instance has only 1 GB of RAM. If the web application consumes significant memory, deploying a new version can trigger out-of-memory (OOM) errors, leading the instance to fail health checks.
The deployment configuration requires a minimum of 1 healthy host, so when the instance becomes unhealthy, the deployment fails with the error about too few healthy instances. Option B (insufficient disk space) is unlikely because t2.micro instances typically have at least 8 GB of EBS storage, which is usually sufficient for downloading application revisions. Option C (CodeDeploy agent timeout) would produce a different error, such as 'deployment timed out,' not a message about healthy instances.
Option D (insufficient IAM permissions) would result in authorization failures, such as 'AccessDenied' errors, not a health-related failure. Therefore, memory exhaustion due to the small instance size is the best explanation.
A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with a 'ScriptMissing' error. What is the most likely cause?
The ScriptMissing error occurs specifically when the appspec.yml file references a script under hooks (such as BeforeInstall or ApplicationStart) by filename, but that script file does not actually exist in the deployed revision bundle at the expected path, so the agent cannot locate it to execute.
Why this answer
The 'ScriptMissing' error occurs when the appspec.yml file references a lifecycle event hook script that is not present in the application revision. CodeDeploy expects the script to exist at the specified path. Option A is incorrect: the deployment group can be configured for an Auto Scaling group, and that is not the cause of ScriptMissing.
Option B is incorrect: buildspec.yml is used by AWS CodeBuild, not CodeDeploy. Option C is incorrect: while the application revision must be stored in S3 (or GitHub), the error is not about the bucket location but about a missing script within the revision.
A developer has set up an AWS CodePipeline pipeline that automatically deploys a web application through a series of stages: Source, Build, Staging, and Production. The developer wants to require a manual approval before the pipeline proceeds to the Production stage. How should the developer implement this?
Correct. A manual approval action placed as a separate stage or as an action in the transition between stages pauses the pipeline until approval is granted.
Why this answer
AWS CodePipeline supports manual approval actions that can be added as a stage or between stages to pause the pipeline and require explicit approval before proceeding. By placing the manual approval action between the Staging and Production stages, the pipeline will halt after the Staging stage completes and wait for an approver to manually approve the transition to the Production stage, ensuring no automatic deployment to production occurs without human oversight.
Exam trap
The trap here is that candidates may think a manual approval action must be placed inside a stage (like Staging) rather than as a separate stage between stages, but CodePipeline allows stages to be ordered sequentially, and the approval action must be in its own stage or at the end of a stage to block the transition to the next stage.
How to eliminate wrong answers
Option A is wrong because adding a manual approval action in the Staging stage would pause the pipeline during the Staging stage itself, not between Staging and Production, so the deployment would proceed to Production automatically after the Staging stage completes, defeating the requirement. Option C is wrong because configuring the Production stage to use a CloudFormation change set with execution role does not introduce a manual approval step; it only controls how CloudFormation executes changes, not a human approval gate. Option D is wrong because using an SNS topic to notify developers of the deployment does not block the pipeline; it only sends notifications, so the pipeline would continue to Production without any manual approval.
A team uses AWS CodePipeline to deploy a microservices application to Amazon ECS. The pipeline has a Source stage (GitHub), a Build stage (CodeBuild), and a Deploy stage (ECS). During a deployment, the pipeline fails at the Deploy stage with the error: 'Action execution failed: Deployment failed. The service my-service has reached the maximum number of tasks.' The service is configured with a desired count of 2 and a maximum percent of 200%. What is the most likely cause of this failure?
The `maximum healthy percent` deployment configuration parameter defines the upper limit on the number of tasks that can be running for a service during a deployment, expressed as a percentage of the desired task count. If the desired count is 2 and the maximum is 200%, then up to 4 tasks (2 * 200%) can run concurrently at any point. If 4 tasks are already active, the service cannot launch additional tasks for the new deployment, leading to the 'maximum tasks allowed' error.
Why this answer
With a desired count of 2 and a maximum percent of 200%, ECS allows up to 4 tasks during a deployment (2 × 200% = 4). If there are already 4 tasks running (e.g., from a previous deployment that did not complete or a manual scaling action), the new deployment cannot start additional tasks because it would exceed the maximum allowed. Option A is incorrect because insufficient memory would cause a different error, such as a task failing to start.
Option C is incorrect because a high minimum healthy percent would prevent task replacement but would not directly cause a 'maximum number of tasks' error. Option D is incorrect because the error is about task count, not EC2 instance limits.
A company wants to deploy a serverless application using AWS Lambda and API Gateway. The deployment process must support automatic rollbacks if the new version fails CloudWatch alarms. Which AWS service should be used to orchestrate this deployment?
AWS CodeDeploy is the correct choice because it natively supports advanced deployment strategies for AWS Lambda functions, including canary and linear deployments. It facilitates gradual traffic shifting to new Lambda function versions, allowing for real-time monitoring of performance and errors. Crucially, CodeDeploy integrates with Amazon CloudWatch alarms to automatically roll back to the deployment to the previous stable version if predefined error thresholds are exceeded during the deployment, ensuring application stability and minimizing user impact.
Why this answer
AWS CodeDeploy is the correct choice because it natively supports deployment strategies like canary, linear, and all-at-once, and can be configured with CloudWatch alarms to automatically trigger rollbacks when a new version fails. This makes it ideal for serverless applications using Lambda and API Gateway, where you need safe, automated deployments with health-check-driven rollback capabilities.
Exam trap
The trap here is that candidates often confuse CodePipeline (which orchestrates the overall pipeline) with CodeDeploy (which handles the actual deployment and rollback logic), leading them to select CodePipeline even though it lacks native automatic rollback based on CloudWatch alarms.
How to eliminate wrong answers
Option A is wrong because AWS Elastic Beanstalk is a PaaS service for web applications and does not natively support serverless deployments with Lambda and API Gateway, nor does it provide automatic rollback based on CloudWatch alarms. Option C is wrong because AWS CloudFormation with a change set is used for infrastructure provisioning and updating, not for orchestrating deployment strategies or automatic rollbacks based on alarm thresholds. Option D is wrong because AWS CodePipeline is a CI/CD orchestration service that can trigger deployments but does not itself manage deployment strategies or automatic rollbacks; it delegates that to services like CodeDeploy.
A company uses AWS CloudFormation to manage infrastructure. The development team wants to deploy a new version of a Lambda function without downtime. The function is part of a stack. Which action should the team take?
The most appropriate and robust method is to update the existing CloudFormation stack by modifying the Lambda function's code within the template and then deploying the stack update. CloudFormation intelligently handles the deployment, often creating new versions of the Lambda function and potentially updating aliases, which can be orchestrated to achieve zero-downtime deployments. This approach maintains infrastructure as code principles and leverages CloudFormation's native, controlled update capabilities.
Why this answer
Updating the CloudFormation stack with the new Lambda function code and deploying the stack update is the correct approach because CloudFormation performs a rolling update on the Lambda function, replacing the old version with the new one without deleting the stack. This ensures zero downtime as the update is applied in place, and the function remains available throughout the process.
Exam trap
The trap here is that candidates mistakenly think manual changes (Option C) or creating a new stack (Option D) are safer, but CloudFormation's stack update is designed for zero-downtime deployments, and manual edits cause drift that CloudFormation will revert.
How to eliminate wrong answers
Option A is wrong because creating a change set and executing it after the current stack is deleted would cause downtime; the stack must exist for the change set to apply, and deleting the stack removes all resources. Option C is wrong because manually updating the Lambda function code in the console and then updating the stack creates a drift between the stack template and the actual resource, which CloudFormation will overwrite with the original code during the stack update, negating the manual change. Option D is wrong because creating a new CloudFormation stack for the new function and deleting the old stack introduces downtime during the deletion and creation process, and does not provide a seamless transition.
A company is deploying a new web application on Amazon EC2 instances behind an Application Load Balancer. The application must be deployed with no downtime. The deployment uses AWS CodeDeploy with a Blue/Green deployment configuration. Which TWO actions should be taken to achieve zero-downtime deployment? (Choose TWO.)
Registering a newly created Auto Scaling group running the new application version into the existing ALB is the foundational blue/green action. The new ASG is placed in its own target group, so its instances can pass health checks and receive test traffic without altering the old ASG. This isolates the new environment while keeping the old one fully available for a controlled cutover.
Why this answer
Option B is correct because a CodeDeploy blue/green deployment for EC2 requires provisioning a replacement environment — a new Auto Scaling group running the new application revision — and registering it with the existing Application Load Balancer so it can serve traffic. Option E is correct because zero downtime is achieved by having the ALB gradually shift traffic from the original (blue) target group to the replacement (green) target group, using CodeDeploy's traffic-shifting controls (e.g., all-at-once, linear, or canary) before the old instances are terminated. Option A is wrong because creating a separate load balancer is unnecessary and would not provide the controlled traffic rerouting that CodeDeploy performs through the ALB's target groups.
Option C is wrong because updating the existing Auto Scaling group in place is an in-place deployment, not blue/green, and would replace instances without the parallel green environment needed for zero downtime. Option D is wrong because terminating the old instances immediately removes the safety net and can cause dropped connections; the original environment must be kept until traffic has fully shifted and the deployment succeeds.
Exam trap
DVA-C02 often tests the misconception that Blue/Green requires a new load balancer or that old instances should be terminated immediately — candidates must remember that the ALB and target groups enable traffic shifting and that old instances are retained for rollback.
The exhibit shows an IAM policy attached to a user who needs to deploy applications using AWS CodeDeploy. The user reports that they cannot create a deployment for the MyApplication/MyDeploymentGroup. What is the most likely reason?
The `codedeploy:CreateDeployment` action requires explicit permissions on both the CodeDeploy application resource and the deployment group resource. While the policy correctly specifies the deployment group ARN (e.g., `arn:aws:codedeploy:...:deploymentgroup/MyApplication/MyDeploymentGroup`), it critically omits the necessary `application` ARN (e.g., `arn:aws:codedeploy:...:application/MyApplication`). This omission means the user lacks the required authorization on the application itself to successfully initiate a deployment.
Why this answer
The IAM policy shown in the exhibit likely grants permissions on the deployment group resource (e.g., arn:aws:codedeploy:region:account:deploymentgroup:MyApplication/MyDeploymentGroup) but omits the corresponding application resource (arn:aws:codedeploy:region:account:application:MyApplication). AWS CodeDeploy requires permissions on both the application and the deployment group for operations like CreateDeployment. Without the application-level permission, the request is implicitly denied, causing the failure.
Thus, the most likely reason is that the policy does not include permission on the application resource.
Exam trap
DVA-C02 often tests the misconception that permissions on a deployment group alone are sufficient for CodeDeploy operations, when in fact permissions on both the application and deployment group resources are required.
How to eliminate wrong answers
Option A is wrong because the policy explicitly grants access to the correct deployment group (as shown in the exhibit), so it does not restrict to a different one. Option B is wrong because the policy includes the codedeploy:CreateDeployment action, so the user does have permission to call that action. Option C is wrong because GetDeployment and GetDeploymentGroup are read-only actions not required for creating a deployment; the failure is due to missing write permission on the application resource, not read permissions.
A developer is using AWS CodeDeploy to perform a canary deployment for an AWS Lambda function. The deployment should first shift 10% of traffic to the new version, and then shift the remaining 90% after 5 minutes. Which deployment configuration should be used?
The Canary10Percent5Minutes CodeDeploy configuration precisely implements a canary deployment by initially shifting 10% of traffic to the new Lambda function version. After a 5-minute bake time, during which the new version can be monitored for errors or performance degradation, the remaining 90% of traffic is automatically shifted. This phased approach allows for early detection of issues with minimal user impact, aligning perfectly with the requirements of a canary release strategy.
Why this answer
The Canary10Percent5Minutes deployment configuration is specifically designed for canary deployments with AWS Lambda, shifting 10% of traffic to the new version immediately and then automatically shifting the remaining 90% after a 5-minute interval. This matches the requirement exactly, as CodeDeploy uses this predefined configuration to orchestrate the traffic shift in two steps with a built-in wait period.
Exam trap
The trap here is that candidates often confuse deployment configurations (like Canary10Percent5Minutes) with deployment types (like BlueGreen), or they misremember the exact traffic percentages and intervals, leading them to select Linear10PercentEvery10Minutes or AllAtOnce instead of the precise configuration that matches the 10% initial shift and 5-minute wait.
How to eliminate wrong answers
Option A is wrong because AllAtOnce shifts 100% of traffic to the new version immediately, with no gradual traffic shifting or canary phase, which does not meet the requirement for a 10% initial shift and a 5-minute wait. Option C is wrong because Linear10PercentEvery10Minutes shifts traffic in 10% increments every 10 minutes, which would take 90 minutes to complete the full shift and does not match the specified 5-minute wait after the initial 10% shift. Option D is wrong because BlueGreen is a deployment type, not a deployment configuration; it refers to the strategy of routing all traffic to a new environment after validation, but CodeDeploy requires a specific traffic-shifting configuration (like Canary10Percent5Minutes) to control the canary behavior within a blue/green deployment.
A developer is deploying a multi-container Docker application on Amazon ECS using the Fargate launch type. The application consists of a web server and a background worker. The web server must be scaled independently and must be accessible from the internet via an Application Load Balancer. The worker should not be accessible from the internet. Which ECS configuration should the developer use?
This approach correctly leverages ECS services for independent lifecycle management and scaling of distinct application components. By defining separate task definitions and services for the web server and worker, each can be scaled independently based on its specific load requirements, optimizing resource utilization. Placing the web server service in a public subnet, typically behind an Application Load Balancer, allows it to serve internet traffic, while the worker service in a private subnet ensures it remains isolated from direct public access, enhancing security and adhering to best practices for backend components.
Why this answer
It uses two separate ECS services, each with its own task definition, allowing independent scaling of the web server and worker. Placing the web server in a public subnet with an Application Load Balancer makes it internet-accessible, while the worker in a private subnet is isolated from direct internet traffic, meeting the security requirement.
Exam trap
The trap here is that candidates assume containers in the same task definition can be independently scaled or that service discovery alone provides network isolation, but in ECS, containers in the same task share the same resources and scaling lifecycle, and service discovery does not restrict internet access.
How to eliminate wrong answers
Option A is wrong because placing both containers in the same task definition forces them to be scaled together as a unit, preventing independent scaling of the web server, and exposing only the web server port does not isolate the worker from the internet since both containers share the same network namespace. Option C is wrong because creating one ECS service with two tasks, each containing one container, does not allow independent scaling of the web server and worker; the service scales all tasks together, and the worker task would still be in the same subnet as the web server unless explicitly placed in a private subnet, which is not specified. Option D is wrong because placing both containers in the same task (same task definition) again couples their scaling and lifecycle, and using service discovery (AWS Cloud Map) does not prevent the worker from being internet-accessible; service discovery only provides DNS-based service resolution within a VPC, not network isolation.
A developer is deploying a new version of an application to Amazon ECS using AWS CodeDeploy. The application uses a blue/green deployment strategy. After the deployment, traffic is automatically shifted to the new task set. However, the developer wants to test the new version with a small percentage of users before shifting all traffic. What should the developer do?
Using CodeDeploy to perform a canary deployment is the correct approach for gradually shifting traffic to a new application version in ECS. CodeDeploy integrates with ECS and an Application Load Balancer (ALB) to manage two target groups (one for the old task set, one for the new). It progressively updates the ALB listener rules to route a specified percentage of traffic, like 10% initially, to the new version, allowing for controlled rollout and easy rollback.
Why this answer
CodeDeploy supports canary deployments for ECS, which allow you to shift a specified percentage of traffic to the new task set initially (e.g., 10%) and then, after a configured interval, shift the remaining traffic. This matches the requirement to test with a small percentage of users before shifting all traffic. Option B directly implements this canary strategy.
Exam trap
The trap here is that candidates confuse 'canary deployment' (traffic shifting) with 'auto scaling' (task count scaling) or think that modifying the task definition or target group alone can achieve gradual traffic routing.
How to eliminate wrong answers
Option A is wrong because changing CPU/memory allocation in the task definition does not control traffic shifting; it affects resource provisioning and may cause deployment failures but does not route a percentage of traffic to the new version. Option C is wrong because target groups route traffic to all healthy tasks in a service, not to a specific task set; you cannot use a target group to selectively route a small percentage to one task set without additional traffic-shifting logic. Option D is wrong because ECS service auto scaling adjusts the number of tasks based on load, not the percentage of traffic directed to a new version; it does not implement a canary traffic shift.
A developer is deploying a web application using AWS Elastic Beanstalk. The application experiences high traffic during peak hours. The developer wants to ensure that the environment can scale out quickly without manual intervention. Which Elastic Beanstalk configuration should be used?
Configuring Auto Scaling triggers based on CloudWatch alarms provides a robust and dynamic solution for automatically adjusting EC2 instance capacity in response to real-time application load. CloudWatch monitors key metrics like CPU utilization or network I/O, and when predefined thresholds are breached, it triggers Auto Scaling policies to add or remove instances. This ensures optimal performance and cost efficiency by scaling resources precisely when needed, without manual intervention or reliance on predictable schedules.
Why this answer
Elastic Beanstalk integrates with Auto Scaling to automatically adjust the number of EC2 instances based on demand. By configuring Auto Scaling triggers that respond to CloudWatch alarms (e.g., CPU utilization > 70%), the environment can scale out quickly and without manual intervention during peak hours.
Exam trap
The trap here is that candidates often confuse scheduled scaling (Option A) with dynamic scaling, not realizing that scheduled actions cannot handle unpredictable spikes, while CloudWatch-triggered Auto Scaling provides real-time, event-driven scaling.
How to eliminate wrong answers
Option A is wrong because scheduled scaling actions are time-based and cannot adapt to unpredictable traffic spikes; they only add capacity at fixed times. Option B is wrong because manually adding EC2 instances defeats the purpose of automation and does not scale out quickly without manual intervention. Option C is wrong because using a fixed number of EC2 instances prevents any scaling, leading to either over-provisioning or under-provisioning during high traffic.
A company is deploying a new microservice using AWS Lambda and Amazon API Gateway. Which THREE steps should be included in the deployment pipeline? (Choose three.)
After defining the API's resources, methods, and integrations, the API Gateway REST API must be explicitly deployed to a stage to make it publicly accessible. A stage acts as a logical reference to a specific version of your API, allowing for independent configuration of settings like throttling, caching, and logging. This deployment step publishes the API, generating an invoke URL that clients can use to access the microservice.
Why this answer
Deploying the API Gateway API to a stage is essential because it makes the API publicly available at a specific URL (e.g., https://api-id.execute-api.region.amazonaws.com/prod). Without a stage deployment, any updates to the API resources and methods remain in draft state and are not accessible to clients.
Exam trap
The trap here is that candidates may confuse the deployment of the Lambda function (which is a separate step) with the deployment of the API Gateway API, or incorrectly assume that DNS updates or cache invalidation are mandatory steps in a standard serverless deployment pipeline.
A company runs a web application on AWS Elastic Beanstalk. The application currently runs in a single environment. The developer wants to deploy a new version with zero downtime and be able to test the new version thoroughly before it receives any production traffic. Which deployment strategy should the developer use?
This strategy describes a blue/green deployment, which is ideal for comprehensive pre-production testing. A completely new "green" Elastic Beanstalk environment is provisioned with the new application version, running in parallel to the existing "blue" production environment. This isolated green environment allows for extensive functional and performance testing without impacting live users. Once validated, a DNS CNAME swap instantly redirects all production traffic to the new green environment, ensuring zero downtime and a quick rollback option by swapping back if needed.
Why this answer
It describes a blue/green deployment strategy, which creates a separate 'green' environment with the new application version, allowing thorough testing before swapping the environment URLs (CNAME records) in Elastic Beanstalk. This ensures zero downtime because the swap is instantaneous and the original 'blue' environment remains untouched until the swap occurs.
Exam trap
The trap here is that candidates confuse immutable deployments (which replace instances but not the environment) with blue/green deployments (which replace the entire environment), leading them to choose Option B because both involve launching new instances, but only blue/green allows pre-production testing without traffic exposure.
How to eliminate wrong answers
Option A is wrong because a rolling deployment with a batch size of one instance at a time updates instances in-place, which still causes a brief period where old and new versions coexist and does not allow testing the new version before it receives production traffic. Option B is wrong because an immutable deployment launches a new set of instances and then swaps the Auto Scaling group, but it does not provide a separate environment for pre-production testing; the new instances immediately serve traffic after the swap. Option D is wrong because a rolling deployment with an additional batch launches new instances before terminating old ones, which reduces downtime but still updates the existing environment in-place and does not allow isolated testing of the new version before it receives traffic.
An organization wants to deploy a microservices architecture using AWS Lambda functions. They need to manage environment variables for each function across different stages (dev, test, prod). Which approach is the MOST secure and maintainable?
AWS Systems Manager Parameter Store supports hierarchical paths such as /myapp/dev/db_url and /myapp/prod/db_url, enabling a single Lambda function to retrieve stage-specific configuration at runtime via GetParameter. This keeps configuration external to code, can be secured with IAM policies and KMS encryption for SecureString parameters, and supports versioning and change history. It is the correct approach because it is centralized, stage-aware, and directly accessible from Lambda without redeploying infrastructure.
Why this answer
AWS Systems Manager Parameter Store allows you to store configuration data and secrets as parameters with hierarchical paths (e.g., /myapp/dev/db-url, /myapp/prod/db-url). This centralizes management, supports versioning, and enables fine-grained IAM access control per stage. Lambda functions can retrieve these parameters at runtime, ensuring that sensitive values are not exposed in code or function configuration.
This approach is both secure (encryption via KMS, audit via CloudTrail) and maintainable (update once, applies everywhere).
Exam trap
DVA-C02 often tests the misconception that Lambda environment variables are secure enough for secrets, but they are stored in plaintext and lack centralized management; candidates must recognize that Parameter Store (or Secrets Manager) is the preferred secure and maintainable solution for cross-stage configuration.
How to eliminate wrong answers
Option B is wrong because CloudFormation parameters are resolved at deployment time and become part of the stack, making it difficult to update values without redeploying; they also lack built-in encryption and fine-grained access control for secrets. Option C is wrong because hardcoding environment variables in code is a severe security risk (secrets in source control) and violates the principle of least privilege; it also makes changes require code redeployment. Option D is wrong because Lambda environment variables are stored in plaintext (though can be encrypted with KMS) and are limited to 4 KB total; they are not centrally managed across stages and require updating each function individually, which is not maintainable for microservices.
A team uses AWS CodePipeline to automate deployments. They notice that a deployment to Amazon ECS fails because the task definition is not updated. The pipeline includes a source stage from CodeCommit, a build stage using AWS CodeBuild, and a deploy stage to Amazon ECS. What is the most likely missing step?
The build stage in AWS CodePipeline is responsible for compiling code, building container images, and crucially, generating output artifacts that subsequent stages will consume. For an Amazon ECS deployment, this often includes an updated task definition JSON file (referencing the new container image) or an `imageDetails.json` file. If the build stage fails to correctly output this updated task definition as a designated artifact, the deploy stage will not receive the necessary information to deploy the latest application version. Consequently, the deploy stage might either fail due to missing input or, more subtly, proceed by using an older, cached, or default task definition, resulting in the application not reflecting the most recent code changes.
Why this answer
In a CodePipeline that deploys to Amazon ECS, the build stage must output the updated task definition file (typically `imagedefinitions.json` or a task definition JSON) as an artifact. Without this artifact, the deploy stage cannot reference the new task definition revision, so it continues using the old one, causing the deployment to fail.
Exam trap
The trap here is that candidates assume the task definition is automatically updated by the deploy action or that manual registration in the ECS console is required, when in fact the build stage must explicitly output the updated definition as an artifact for the pipeline to use.
How to eliminate wrong answers
Option A is wrong because a manual approval step would pause the pipeline but not affect whether the task definition is updated; it does not cause the deployment to fail due to an outdated task definition. Option B is wrong because setting the deploy stage action to 'Create a new ECS service' would create a new service instead of updating the existing one, which is not the missing step for updating the task definition. Option C is wrong because the task definition does not need to be manually registered in the ECS console; the pipeline should register it automatically via the deploy action, and the issue is that the updated definition is not passed as an artifact.
A company is using AWS CodePipeline to automate the deployment of a microservices application to Amazon ECS. The pipeline has the following stages: Source (GitHub), Build (CodeBuild), Deploy (ECS). The Deploy stage uses an ECS task definition and updates the service. Recently, the pipeline failed at the Deploy stage with the error: 'The task definition family is inactive.' The developer checks the ECS console and sees that the task definition family exists but is inactive. The developer also notices that the pipeline uses a parameter 'TASK_DEFINITION_FAMILY' with the value 'my-app'. What is the most likely cause?
When a pipeline references only the task definition family name (e.g., 'my-app') without pinning a revision number, ECS resolves it to the family's most recent revision; if that latest revision was deregistered and marked inactive, for example after a manual cleanup or rollback, the deploy action fails with exactly this 'family is inactive' error, so the fix is to reference an active revision explicitly or re-register one.
Why this answer
The error 'The task definition family is inactive' indicates that the pipeline is using the task definition family name 'my-app' without specifying a revision number. When a task definition family is marked as inactive, it means the latest revision in that family is inactive. CodePipeline requires a specific active revision number to deploy successfully.
Therefore, the most likely cause is that the pipeline is referencing only the family name, and the latest revision is inactive. Option D correctly identifies this issue. Option A is incorrect because the family exists.
Option B is incorrect because environment variables are unrelated to the error. Option C is incorrect because the pipeline's IAM role permissions are not the issue; the error is about the task definition state, not permissions.
Which THREE factors should a developer consider when choosing between a blue/green deployment and a rolling deployment for an Amazon ECS service?
Rolling deployments operate by gradually replacing a small subset of old application instances with new ones until all are updated. This phased approach means that if a critical issue is discovered, the rollback process must also proceed in stages, replacing the faulty new instances with the previous stable version across the entire fleet. Consequently, the time required to fully revert to a stable state can be considerably longer compared to other strategies, making this a valid consideration.
Why this answer
Rolling deployments in Amazon ECS update a subset of tasks at a time, which means if a rollback is needed, the deployment must reverse the updates incrementally, potentially taking longer than a blue/green deployment where traffic can be switched back instantly. This slower rollback is a key trade-off when choosing between the two strategies.
Exam trap
The trap here is that candidates may assume rolling deployments always require manual rollback (Option A) when in fact ECS supports automatic rollback via the service's 'deployment circuit breaker' feature, and they may overlook the cost implications of running dual environments in blue/green deployments (Option C).
A developer is using AWS CodeDeploy to deploy an application to an EC2 Auto Scaling group. The application must remain fully available; only one instance should be taken offline at a time. The developer wants to configure the deployment to update instances one by one, ensuring that the deployment fails fast if any instance fails to deploy. Which deployment configuration should the developer choose?
The CodeDeployDefault.OneAtATime configuration updates only one instance in the target deployment group at a time. This strategy ensures maximum application availability by keeping the vast majority of instances serving traffic throughout the deployment process. It minimizes the blast radius of any potential deployment failure and allows for quick rollback or termination of the deployment if issues are detected on the single updated instance, making it ideal for critical applications requiring continuous operation.
Why this answer
CodeDeployDefault.OneAtATime, is correct because it deploys the application to one instance at a time, ensuring that only one instance is taken offline during the deployment. This satisfies the requirement for the application to remain fully available. Additionally, this configuration fails fast: if any instance fails to deploy, the deployment stops immediately, preventing further instances from being updated.
Exam trap
The trap here is that candidates may confuse deployment configurations (like OneAtATime) with deployment types (like BlueGreen), or incorrectly assume that HalfAtATime updates instances one by one when it actually updates half the fleet at a time.
How to eliminate wrong answers
Option A is wrong because CodeDeployDefault.AllAtOnce deploys to all instances simultaneously, which would take all instances offline at once and violate the requirement for only one instance to be offline at a time. Option B is wrong because CodeDeployDefault.HalfAtATime deploys to half the instances at a time, which would take more than one instance offline simultaneously, not meeting the one-at-a-time requirement. Option D is wrong because CodeDeployDefault.BlueGreen is a deployment type that shifts traffic between two environments (blue and green), not a deployment configuration that controls the number of instances updated at a time within a single Auto Scaling group; it also does not inherently provide a one-at-a-time update pattern.
A developer is setting up a CI/CD pipeline using AWS CodePipeline to deploy an application to Amazon ECS. The pipeline has a source stage that pulls code from an AWS CodeCommit repository. The developer wants the pipeline to execute only when commits are pushed to the 'main' branch. How should the developer configure this?
When configuring a CodePipeline, the CodeCommit source action within the source stage includes a mandatory `BranchName` parameter. By specifying the desired branch, such as 'main', directly in this configuration, CodePipeline is explicitly instructed to monitor only that particular branch for new commits. This native integration ensures that the pipeline automatically initiates an execution solely upon pushes to the designated branch, making it the most direct and efficient method for branch-specific triggering.
Why this answer
AWS CodePipeline allows you to specify a branch name directly in the source action configuration for CodeCommit. When you configure the source stage, you can set the 'BranchName' parameter to 'main', which ensures the pipeline only triggers on commits pushed to that specific branch. This is the simplest and most direct method to filter by branch without additional services or custom logic.
Exam trap
The trap here is that candidates might overthink the solution by considering external services like CloudWatch Events or Lambda, when the correct answer is a simple configuration option already built into the CodePipeline source stage.
How to eliminate wrong answers
Option A is wrong because Amazon CloudWatch Events rules can trigger a pipeline on various events, but they do not natively filter by branch name; you would need to add a custom event pattern or use a Lambda function to inspect the branch, which is unnecessary and more complex than the built-in branch filter. Option C is wrong because using an AWS Lambda function in the source stage to filter the branch adds unnecessary complexity and cost; CodePipeline already supports branch filtering natively in the source action configuration. Option D is wrong because CodePipeline does not have a 'pipeline trigger settings' feature with a branch filter pattern; branch filtering is configured within the source stage action, not as a separate trigger setting.
A developer needs to package and deploy a serverless application with Lambda functions, API Gateway, and DynamoDB using concise syntax. Which framework is AWS-native for this purpose?
AWS Serverless Application Model (SAM) is an open-source framework specifically designed to build, package, and deploy serverless applications on AWS. It extends AWS CloudFormation by providing a simplified syntax for defining serverless resources like Lambda functions, APIs, and databases. Using the SAM CLI, developers can easily test applications locally, package their code and dependencies, and deploy them to the AWS cloud as CloudFormation stacks, streamlining the entire serverless development lifecycle.
Why this answer
The AWS Serverless Application Model (SAM) is an AWS-native framework that uses a simplified YAML or JSON syntax to define and deploy serverless resources such as Lambda functions, API Gateway, and DynamoDB. It extends AWS CloudFormation, allowing developers to package and deploy with concise syntax using the `sam build` and `sam deploy` commands, making it the correct choice for this purpose.
Exam trap
The trap here is that candidates may confuse AWS SAM with general-purpose infrastructure-as-code tools like Terraform or AWS CloudFormation, but the question specifically asks for a framework with concise, AWS-native syntax for serverless applications, which SAM uniquely provides.
How to eliminate wrong answers
Option B is wrong because AWS Control Tower is a governance and multi-account management service, not a framework for packaging and deploying serverless applications. Option C is wrong because Amazon Macie is a data security and privacy service that uses machine learning to discover and protect sensitive data, not a deployment framework. Option D is wrong because AWS Backup is a centralized backup service for managing backups across AWS services, not a framework for defining or deploying serverless resources.
A company uses AWS Elastic Beanstalk to deploy a web application. The application requires a database connection string that is different for each environment (development, staging, production). The developer wants to set these values without hardcoding them in the application code. Which configuration method should the developer use?
Elastic Beanstalk environment properties are the native and recommended mechanism for passing configuration values to your application. These properties are defined directly within the Elastic Beanstalk environment configuration, either via the console, CLI, or configuration files, and are automatically injected as environment variables into the application's runtime on the EC2 instances. This allows for distinct configurations, such as database endpoints or API keys, to be managed separately for development, staging, and production environments without modifying application code.
Why this answer
Elastic Beanstalk environment properties allow you to inject configuration values (like database connection strings) into your application at deployment time without hardcoding them. These properties are set per environment in the Elastic Beanstalk console or via CLI, and the application retrieves them as environment variables, making them environment-specific. While database connection strings are sensitive, environment properties are the simplest configuration method within Elastic Beanstalk for such values.
AWS Systems Manager Parameter Store (Option D) is more secure for secrets but is not a native Elastic Beanstalk feature and requires additional setup; the question specifically asks for a configuration method within Elastic Beanstalk's native capabilities.
Exam trap
The trap here is that candidates often overcomplicate the solution by choosing AWS Systems Manager Parameter Store (Option D) for secret management, but the question specifically asks for a configuration method within Elastic Beanstalk's native features, where environment properties are the simplest and most direct approach for environment-specific values, even for sensitive ones like database connection strings.
How to eliminate wrong answers
Option A is wrong because .ebextensions configuration files are used for customizing the Elastic Beanstalk environment (e.g., installing packages, creating files) but not for setting environment-specific database connection strings; they are static per application version, not dynamic per environment. Option C is wrong because Amazon RDS within Elastic Beanstalk is a feature that provisions a database tied to the environment, but it does not solve the problem of setting a connection string that differs per environment—the connection string is automatically generated and managed by Elastic Beanstalk, not manually configured. Option D is wrong because AWS Systems Manager Parameter Store can store secrets, but using it requires additional IAM configuration and code changes to fetch the parameter, which is more complex than the built-in environment properties; the question asks for the simplest method within Elastic Beanstalk's native capabilities.
A developer is using AWS CloudFormation to deploy a stack that includes an Amazon S3 bucket and an AWS Lambda function. The Lambda function needs to be granted permission to read objects from the S3 bucket. Which resource should the developer define in the CloudFormation template to provide these permissions?
An AWS::IAM::Role is the correct and standard mechanism for granting a Lambda function the necessary permissions to interact with other AWS services, such as reading from an S3 bucket. This resource defines an identity that the Lambda function assumes during execution, specified by an `AssumeRolePolicyDocument` allowing the `lambda.amazonaws.com` service principal. Attached policies within the role then explicitly define the actions (e.g., `s3:GetObject`) the function is authorized to perform on specified resources.
Why this answer
The Lambda function requires an IAM role (AWS::IAM::Role) with a policy that grants s3:GetObject permissions on the S3 bucket. This role is assumed by the Lambda service at runtime, allowing the function to read objects from the bucket. The role must include a trust policy that allows lambda.amazonaws.com to assume it.
Exam trap
The trap here is that candidates often confuse resource-based policies (like S3 bucket policies or Lambda permission statements) with identity-based policies (like IAM roles), thinking a bucket policy alone can grant the Lambda function access, when in fact the Lambda function needs an IAM role with the appropriate permissions to assume and use.
How to eliminate wrong answers
Option B (AWS::Lambda::Permission) is wrong because it grants a resource-based policy to allow another AWS service or account to invoke the Lambda function, not to grant the Lambda function permissions to access S3. Option C (AWS::S3::BucketPolicy) is wrong because a bucket policy controls access to the S3 bucket from external principals, but it does not grant the Lambda function's execution role the necessary IAM permissions; while a bucket policy could be used to allow the Lambda role, the standard and recommended approach is to attach permissions to the Lambda execution role. Option D (AWS::IAM::ManagedPolicy) is wrong because it defines a reusable policy document but does not create a role; the Lambda function needs an IAM role to assume, not just a managed policy.
A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails during the 'Install' lifecycle event. The developer checks the logs and finds that the scripts in the 'appspec.yml' file are not being executed because the instances are not in a healthy state. What could be the reason for the instances being unhealthy?
During an AWS CodeDeploy deployment, new instances launched by an Auto Scaling group or existing instances undergoing a blue/green deployment need adequate time to initialize and for the application to start successfully. If the Auto Scaling group's health check grace period is too short, instances might be prematurely marked unhealthy by the Auto Scaling group before the CodeDeploy agent has finished installing dependencies, starting services, or even completing its deployment lifecycle events. This premature marking can lead to instances being terminated or removed from service before they are fully operational, disrupting the deployment and causing application instability.
Why this answer
If the health check grace period is too short, instances may be marked unhealthy by the Auto Scaling group before the CodeDeploy installation scripts complete. This causes the deployment to fail during the 'Install' lifecycle event. Option B is incorrect because even if the ELB is not configured to route traffic, it would not directly cause instance health check failures during deployment; it would affect traffic routing.
Option C is incorrect because an outdated CodeDeploy agent might cause script execution failures, but the logs indicate scripts are not executed because instances are unhealthy, not because of agent issues. Option D is incorrect because IAM permissions affect access to artifacts, but the error is about instance health, not access denied.
A developer is deploying a serverless application using AWS SAM. The application consists of an API Gateway endpoint that triggers an AWS Lambda function. The developer wants to enable canary deployments to gradually shift traffic to a new Lambda version. Which SAM resource attribute should the developer configure?
When deploying serverless applications using AWS SAM or CloudFormation, `AutoPublishAlias` automatically creates or updates an alias to point to the newly deployed Lambda function version. Coupled with `DeploymentPreference`, which integrates with AWS CodeDeploy, this configuration enables sophisticated traffic shifting strategies such as linear or canary deployments. This allows for gradual routing of traffic to the new function version, enabling real-time monitoring for health and performance, and facilitating automated rollbacks if issues are detected, directly addressing the need for controlled traffic shifting.
Why this answer
`AutoPublishAlias` automatically creates and updates a Lambda alias (e.g., `live`) that points to the latest version of your function, while `DeploymentPreference` enables canary, linear, or all-at-once traffic shifting between the old and new alias versions. Together, they allow gradual traffic migration to a new Lambda version without manual alias management.
Exam trap
The trap here is that candidates confuse `ProvisionedConcurrency` or `ReservedConcurrentExecutions` with deployment strategies, but these are performance and scaling controls, not traffic-shifting mechanisms.
How to eliminate wrong answers
Option A is wrong because `ReservedConcurrentExecutions` controls the maximum concurrent invocations for a function to prevent throttling, not traffic shifting between versions. Option B is wrong because `Timeout` sets the maximum execution duration for a Lambda function (up to 900 seconds) and has no role in deployment strategies. Option D is wrong because `ProvisionedConcurrency` pre-warms a specific number of execution environments to reduce cold starts, but it does not manage gradual traffic routing between versions.
A company uses AWS OpsWorks for configuration management and deployment of applications on EC2 instances. The company wants to migrate to AWS Systems Manager for automation and patching. Which Systems Manager capability should be used to execute scripts and commands on EC2 instances as part of a deployment?
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.
Why this answer
AWS Systems Manager Run Command is the correct capability because it allows you to remotely and securely execute scripts and commands on EC2 instances as part of a deployment. Run Command is designed for one-time or on-demand execution, which aligns with the need to run deployment scripts. State Manager is for ongoing configuration management, not for one-time deployment tasks.
Exam trap
Candidates may mistakenly choose State Manager because it can also run scripts as part of a desired state, but the question specifically asks for executing scripts 'as part of a deployment', which is typically a one-time action. Run Command is purpose-built for ad-hoc command execution, making it the right choice.
How to eliminate wrong answers
Option A is wrong because AWS Systems Manager Patch Manager is specifically for automating the patching of operating systems and applications, not for executing arbitrary scripts or commands as part of a deployment. Option C is wrong because AWS Systems Manager Automation is used for automating complex, multi-step operational tasks (e.g., AMI creation or instance recovery) and requires an Automation document, not for simple script execution on individual instances. Option D is wrong because AWS Systems Manager Run Command executes scripts or commands on demand, but it does not enforce a persistent desired state or schedule; State Manager is the correct choice for ongoing deployment and configuration management.
A developer is deploying a microservices application on Amazon ECS using Fargate. The developer wants to implement a blue/green deployment strategy using AWS CodeDeploy. The current production environment uses an Application Load Balancer (ALB). What is the minimum configuration required to enable blue/green deployments?
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.
Why this answer
AWS CodeDeploy for Amazon ECS requires an Application Load Balancer (ALB) with two target groups to handle traffic routing during a blue/green deployment. The blue target group serves the current production version, while the green target group serves the new version. CodeDeploy shifts traffic from blue to green by updating the ALB listener rules, and after a successful deployment, the green target group becomes the new production target.
Exam trap
The trap here is that candidates assume a single target group is sufficient because they think blue/green only requires swapping task definitions, but CodeDeploy explicitly needs two target groups to manage traffic routing and rollback independently.
How to eliminate wrong answers
Option B is wrong because a single target group cannot support blue/green deployments, as CodeDeploy needs two distinct target groups to route traffic between the old and new task sets; adding CloudFront does not replace this requirement. Option C is wrong because ECS service discovery namespace is used for internal service-to-service DNS resolution, not for traffic routing or deployment strategies like blue/green. Option D is wrong because a Network Load Balancer (NLB) with a single target group cannot be used with CodeDeploy for ECS blue/green deployments, as CodeDeploy requires an ALB with HTTP/HTTPS listener rules to shift traffic between target groups; NLBs operate at layer 4 and do not support the necessary traffic shifting mechanism.
A company uses AWS CodeCommit for source control and AWS CodeBuild for building a Java application. They have a CodePipeline that deploys the built artifacts to an Auto Scaling group using CodeDeploy. Recently, the build stage started failing with the error: 'BUILD FAILED: Could not resolve dependencies for project'. The developer checks the buildspec.yml and sees that it uses Maven to download dependencies from a private repository. The developer also notices that the build environment is a managed Docker image. What is the most likely cause?
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.
Why this answer
CodeBuild runs in a managed Docker image that, by default, has internet access but no route to private VPC resources such as an internal Maven repository. To reach a private repository hosted inside a VPC, the CodeBuild project must be configured with VPC settings (VPC ID, subnets, security groups). Without that, Maven cannot resolve dependencies and the build fails.
Exam trap
DVA-C02 often tests the misconception that IAM permissions alone control access to private repositories, when the real issue is network reachability from CodeBuild's managed environment into a VPC.
How to eliminate wrong answers
Option A is wrong because IAM permissions govern AWS API access, not network reachability to a private Maven repository; the error is a resolution/network failure, not an authorization failure. Option C is wrong because a buildspec syntax error would produce a YAML or phase parsing error, not a Maven dependency resolution error. Option D is wrong because a Java version mismatch would produce a compilation or UnsupportedClassVersionError, not a dependency resolution failure.
A developer is deploying a serverless application using AWS SAM. The developer wants to define a Lambda function that is invoked by an Amazon API Gateway REST API. Which SAM resource type should the developer use to define the API?
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.
Why this answer
AWS::Serverless::Api defines an API Gateway REST API in SAM. Option A is wrong because AWS::Serverless::SimpleTable defines a DynamoDB table, not an API. Option C is wrong because AWS::ApiGateway::RestApi is a raw CloudFormation resource, not a SAM shorthand resource type.
Option D is wrong because AWS::Serverless::Function defines a Lambda function, not an API.
A developer is using AWS Elastic Beanstalk to deploy a web application. The developer wants to run database migration scripts as part of the deployment process before the new application version starts serving traffic. Which Elastic Beanstalk configuration file should the developer use to define the migration commands?
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.
Why this answer
`container_commands` in `.ebextensions/<filename>.config` runs commands after the application and web server have been set up but before the new application version starts serving traffic. This makes it the ideal place to execute database migration scripts that must complete before the environment accepts requests, ensuring data consistency.
Exam trap
The trap here is confusing `commands` with `container_commands`; candidates often pick `commands` because they sound similar, but they run at different lifecycle stages, and only `container_commands` guarantees execution after the application stack is ready but before traffic is routed.
How to eliminate wrong answers
Option B is wrong because `commands` in `.ebextensions/<filename>.config` runs before the application and web server are set up, so the database migration scripts would execute too early, potentially before the application dependencies or environment variables are ready. Option C is wrong because a `Procfile` is used to specify the processes that run your application (e.g., web server, worker), not to define deployment lifecycle commands like database migrations. Option D is wrong because `buildspec.yml` is a configuration file for AWS CodeBuild, not for Elastic Beanstalk; it defines build phases and commands for a CI/CD pipeline, not deployment hooks within Elastic Beanstalk.
A company uses AWS CloudFormation to manage infrastructure. The development team wants to implement a CI/CD pipeline that automatically updates a CloudFormation stack when code is pushed to a CodeCommit repository. The pipeline should also run tests before deploying. Which THREE services should be used together to achieve this? (Choose THREE.)
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.
Why this answer
AWS CodeBuild is correct because it can compile source code, run tests, and produce artifacts that are ready for deployment. In this CI/CD pipeline, CodeBuild executes the test suite after code is pushed to CodeCommit, ensuring that only validated code proceeds to update the CloudFormation stack.
Exam trap
The trap here is that candidates may confuse AWS CodeDeploy with CloudFormation stack updates, but CodeDeploy handles application-level deployments (e.g., code to instances) while CloudFormation manages infrastructure provisioning and updates, so CodeDeploy is not used for stack updates in this context.
A company is implementing a CI/CD pipeline using AWS CodeCommit, CodeBuild, and CodeDeploy. The developer wants to ensure that the pipeline automatically deploys to production only after a manual approval step. Which TWO actions should the developer take?
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.
Why this answer
Option B is correct because AWS CodePipeline natively supports a manual approval action that pauses the pipeline at a chosen stage until an approver acts, which is exactly the mechanism needed to gate production deployments. Option C is correct because the manual approval action can be configured with an IAM principal (user, role, or group) whose members are authorized to approve or reject, enforcing controlled authorization for the production gate. Option A is not appropriate because a CloudWatch Events rule invoking a Lambda function is an event-driven workaround, not the built-in approval mechanism, and Lambda cannot natively 'wait' for human approval without complex polling.
Option D is incorrect because CodeDeploy lifecycle hooks pause during a deployment for scripts or validation, not for a human approval gate before the deployment stage. Option E is incorrect because an SNS topic can notify approvers of a pending approval, but notification alone does not implement the required approval gate.
Exam trap
DVA-C02 often tests whether candidates know that CodePipeline has a built-in manual approval action, tempting them to build custom Lambda/SNS approval workflows that are unnecessary and do not actually gate the pipeline.
A developer wants to deploy a static website to AWS. The website content is stored in an S3 bucket. Which combination of actions is required to host the website? (Choose TWO.)
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.
Why this answer
To host a static website on S3, you must enable static website hosting on the bucket (option B) and make the objects publicly readable (option E). Option A (server access logging) is optional for tracking requests, not required. Option C (restricting access to a specific IP) would prevent public access, which is needed for a public website.
Option D (CloudFront) is an optional CDN service, not a requirement for S3 static website hosting.
A developer is designing a CI/CD pipeline for a serverless application using AWS CodePipeline. The pipeline must automatically build and deploy the application when changes are pushed to a CodeCommit repository. The application uses AWS CloudFormation for infrastructure provisioning. Which TWO actions should the developer include in the pipeline?
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.
Why this answer
AWS CodeBuild can compile source code, run unit tests, and produce deployment artifacts, which is a standard build phase in a CI/CD pipeline. Option E is correct because AWS CloudFormation is the native AWS service for provisioning and updating infrastructure as code, making it the appropriate deployment action for a serverless application defined in templates.
Exam trap
The trap here is that candidates often confuse AWS CodeDeploy with CloudFormation for serverless deployments, not realizing that CodeDeploy is for EC2/on-premises and CloudFormation is the correct service for provisioning serverless infrastructure.
A company uses AWS CodePipeline to deploy a critical web application. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (CodeDeploy). During a recent deployment, the CodeDeploy stage failed because the target EC2 instances were not in a healthy state. The developer needs to ensure that the pipeline automatically rolls back the deployment to the last successful version if the deployment fails. What should the developer do?
AWS CodeDeploy deployment groups offer a built-in feature to automatically roll back a deployment when it fails. This configuration ensures that if any step within the deployment process, such as application installation or health checks, reports a failure, CodeDeploy will automatically revert the instances in the deployment group to the last successfully deployed application revision. This mechanism is specifically designed to maintain application availability and quickly recover from faulty deployments without manual intervention.
Why this answer
CodeDeploy deployment groups have a built-in automatic rollback configuration that can be enabled to revert to the last successful deployment revision when a deployment fails. This feature directly addresses the requirement without requiring additional services or manual steps, as it operates within the CodeDeploy service itself.
Exam trap
The trap here is that candidates may confuse CodePipeline's built-in rollback capabilities with CodeDeploy's automatic rollback, or incorrectly assume that CloudWatch alarms or manual approvals can directly perform rollbacks without custom logic.
How to eliminate wrong answers
Option B is wrong because AWS CloudFormation is an infrastructure-as-code service for managing resources, not a deployment service for CodePipeline; enabling rollback on failure in CloudFormation would roll back the stack, not the CodeDeploy deployment. Option C is wrong because CloudWatch alarms can trigger actions like SNS notifications or Auto Scaling, but they cannot directly trigger a rollback in CodePipeline or CodeDeploy without custom Lambda functions or additional configuration. Option D is wrong because a manual approval step only pauses the pipeline for human review before proceeding; it does not automatically roll back a failed deployment to the last successful version.
A company is using AWS CodeBuild to compile a Java application. The build takes a long time because Maven dependencies are downloaded each time. How can the developer reduce build time?
For Java applications, a significant portion of build time is often consumed by downloading project dependencies from remote Maven repositories. Configuring a CodeBuild cache to store the local Maven repository (~/.m2 directory) in an Amazon S3 bucket allows these dependencies to be persisted and reused across subsequent builds. This dramatically reduces build duration by eliminating redundant network transfers and dependency resolution steps, as CodeBuild can efficiently restore the cache before the build starts, making it highly effective for improving build performance.
Why this answer
Configuring an Amazon S3 cache for the Maven repository allows CodeBuild to reuse previously downloaded dependencies across builds, eliminating the need to re-download them each time. This significantly reduces build time by leveraging the local cache stored in S3, which is a best practice for dependency-heavy builds like Java applications with Maven.
Exam trap
The trap here is that candidates may confuse CodeBuild's cache with EC2-based solutions (like custom AMIs) or assume that increasing compute resources solves all performance issues, when the actual bottleneck is network latency for repeated downloads.
How to eliminate wrong answers
Option A is wrong because using a higher compute type (e.g., more CPU/memory) does not address the root cause of repeated network downloads; it only speeds up the build steps themselves, not the dependency resolution. Option B is wrong because CodeBuild does not support custom AMIs; it uses managed build environments based on Docker images, and pre-installing dependencies in a custom image would require a custom Docker image, not an AMI. Option C is wrong because increasing the timeout value only prevents the build from failing due to time limits; it does not reduce the actual time spent downloading dependencies.
A developer is using AWS CodeDeploy to deploy an application to an EC2 Auto Scaling group. The developer wants to monitor the deployment and automatically roll back if a specified Amazon CloudWatch alarm is triggered during the deployment. Which CodeDeploy feature should the developer configure?
AWS CodeDeploy deployment groups can be configured with one or more Amazon CloudWatch alarms. When a deployment is in progress or completes, CodeDeploy continuously monitors these alarms for any state changes. If any configured alarm transitions to an ALARM state, CodeDeploy can be set to automatically roll back the deployment, reverting the application to its previous stable version. This mechanism ensures that problematic deployments are quickly undone, minimizing impact on end-users.
Why this answer
The Deployment group alarm configuration in AWS CodeDeploy allows you to specify Amazon CloudWatch alarms that, when triggered during a deployment, automatically initiate a rollback. This feature is configured at the deployment group level and ensures that if a predefined alarm (e.g., high error rate or latency) enters the ALARM state, CodeDeploy stops the deployment and reverts to the last known good revision. This provides automated, policy-driven rollback without manual intervention.
Exam trap
The trap here is that candidates confuse the deployment group alarm configuration (which monitors CloudWatch alarms during deployment) with a deployment configuration (which controls traffic shifting and failure thresholds), leading them to select Option B instead of A.
How to eliminate wrong answers
Option B is wrong because 'Deployment configuration with alarm' is not a valid CodeDeploy feature; CodeDeploy deployment configurations define traffic routing and failure thresholds, not alarm-based rollback triggers. Option C is wrong because 'Revision rollback' is a manual or automated action that can be initiated by the deployment group alarm configuration, but it is not a feature you configure to monitor alarms—it is the outcome of the alarm trigger. Option D is wrong because 'EC2 instance health check' refers to the health checks performed by Auto Scaling or Elastic Load Balancing to determine instance health, not to CloudWatch alarm-based rollback logic in CodeDeploy.
A company uses AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.' Which of the following is the MOST likely cause?
CodeDeploy deployments are often configured with health checks, either through integration with Elastic Load Balancers or custom scripts defined in the `appspec.yml` file (e.g., in `AfterInstall` or `ApplicationStart` hooks). If the newly deployed application version fails to pass these configured health checks on the target instances, CodeDeploy automatically detects this issue. This failure triggers a pre-configured rollback to the last known good application version, ensuring service continuity and preventing the deployment of faulty code into production environments.
Why this answer
The error message indicates that instances failed deployment, which is most commonly caused by the new application version failing the health checks configured in the deployment group. CodeDeploy uses these health checks (e.g., ELB health checks or custom scripts) to determine if an instance is healthy after deployment; if the application crashes or returns non-200 status codes, CodeDeploy marks the instance as failed and aborts the deployment.
Exam trap
The trap here is that candidates often confuse deployment failures caused by health check failures with infrastructure issues like missing IAM roles or agents, but the specific error message about 'too many individual instances failed deployment' directly points to application-level health check failures, not permission or agent problems.
How to eliminate wrong answers
Option B is wrong because if the deployment group did not exist, CodeDeploy would return a 'DeploymentGroupDoesNotExistException' error, not a generic instance failure error. Option C is wrong because insufficient IAM permissions would cause a different error, such as 'AccessDeniedException' when CodeDeploy tries to call EC2 or Auto Scaling APIs, not a per-instance deployment failure. Option D is wrong because if the CodeDeploy agent is not installed, the instance would show as 'Unknown' or 'Not Registered' in the deployment group, and the error would be about missing agent, not about too many instances failing health checks.
A developer is using AWS CodeCommit as a source repository. They want to automatically build and test code whenever a new branch is created. Which AWS service should they use to trigger the pipeline?
Amazon CloudWatch Events (now Amazon EventBridge) is the correct service for capturing and reacting to events from AWS CodeCommit. It allows developers to create rules that match specific repository activities, such as pushes to a branch or pull request state changes. These rules then route the events to various targets, including AWS CodePipeline to initiate a build, an AWS Lambda function for custom logic, or an Amazon SNS topic for notifications, making it the central hub for event-driven automation.
Why this answer
Amazon CloudWatch Events (now part of Amazon EventBridge) can capture AWS CodeCommit repository events, such as the creation of a new branch. By setting a rule that matches the 'Reference Created' event type, you can automatically trigger an AWS CodePipeline pipeline execution, enabling continuous integration for new branches.
Exam trap
The trap here is that candidates may confuse the service that emits the event (CodeCommit) with the service that routes the event to the pipeline (CloudWatch Events/EventBridge), leading them to incorrectly select Lambda or SNS as the trigger mechanism.
How to eliminate wrong answers
Option B is wrong because Amazon S3 event notifications are designed for object-level events in S3 buckets (e.g., PUT, DELETE), not for Git repository events like branch creation in CodeCommit. Option C is wrong because Amazon SNS is a pub/sub messaging service for sending notifications, not a trigger mechanism for directly invoking a pipeline; it would require an intermediary to process the message and start the pipeline. Option D is wrong because AWS Lambda can be invoked by CodeCommit events via CloudWatch Events, but it is not the service that directly triggers the pipeline; the question asks which service triggers the pipeline, and Lambda would need custom code to call the pipeline API, whereas CloudWatch Events can natively target CodePipeline.
A developer is using AWS CodeBuild to build a Java application. The build fails with the error 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE'. What is the most likely cause?
A "pull image" error in AWS CodeBuild directly signifies that the CodeBuild service was unable to retrieve the specified Docker image from its source repository. This can occur if the image name or tag is incorrect, leading to the image not being found, or if CodeBuild lacks the necessary IAM permissions to access a private repository like Amazon ECR. Network connectivity issues to the repository or misconfigured repository policies could also prevent a successful image pull, halting the build before any commands execute.
Why this answer
The error 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE' in AWS CodeBuild indicates that the service cannot pull the specified Docker image from the repository. This occurs when the image name/tag is incorrect, the image does not exist in the specified registry (e.g., Amazon ECR or Docker Hub), or the CodeBuild service role lacks the necessary permissions (e.g., ecr:GetDownloadUrlForLayer, ecr:BatchGetImage) to access the repository. Option B correctly identifies this as the most likely cause.
Exam trap
The trap here is that candidates often confuse build-phase errors (like syntax errors in commands) with environment setup errors (like image pull failures), leading them to select options related to build commands or artifacts instead of recognizing the error message's specific reference to container image retrieval.
How to eliminate wrong answers
Option A is wrong because insufficient memory would cause a different error, such as 'BUILD_CONTAINER_MEMORY_LIMIT_EXCEEDED' or a container OOM kill, not an image pull failure. Option C is wrong because a syntax error in the build command would result in a build phase failure (e.g., 'Error: command not found' or a non-zero exit code), not a container image pull error. Option D is wrong because the absence of artifacts in buildspec.yml would cause a build success but no output, or a warning, not a container image pull failure.
A developer is using AWS Elastic Beanstalk to deploy a web application. The application uses an in-environment Amazon RDS database instance. The developer needs to update the application code without risking data loss. The database must not be affected by environment operations such as termination or updates. What is the recommended approach?
Elastic Beanstalk's in-environment databases are tightly coupled to the environment's lifecycle, meaning they are terminated along with the environment, leading to data loss. By provisioning a standalone Amazon RDS instance, the database becomes an independent, persistent resource. This decouples the data layer from the application environment, ensuring data persistence across environment updates, terminations, or blue/green deployments, making it the recommended best practice for production applications.
Why this answer
Decoupling the RDS database from the Elastic Beanstalk environment by creating a standalone RDS instance ensures that the database is not tied to the environment's lifecycle. In-environment databases are automatically deleted when the environment is terminated or updated, risking data loss. By reconfiguring the application to point to an external RDS instance, the database persists independently of environment operations, meeting the requirement to avoid data loss during code updates or environment changes.
Exam trap
The trap here is that candidates may assume the 'Swap environment URLs' blue/green deployment (Option C) inherently protects the database, but they overlook that in-environment databases are still tied to the environment lifecycle, so the original database can be lost when the old environment is terminated.
How to eliminate wrong answers
Option B is wrong because taking a snapshot before each deployment and restoring it after does not prevent data loss during the deployment window; any writes between the snapshot and restore would be lost, and it introduces unnecessary complexity and downtime. Option C is wrong because the 'Swap environment URLs' feature for blue/green deployment swaps traffic between two environments, but if both environments use in-environment databases, the database in the original environment is still at risk of deletion or data loss during termination or updates. Option D is wrong because creating a new environment with a new RDS instance and manually migrating data does not guarantee zero data loss during the migration process, and it duplicates effort without addressing the core issue of decoupling the database from the environment lifecycle.
A developer is deploying a Node.js application to AWS Elastic Beanstalk. The application uses environment variables for database credentials. What is the BEST way to securely provide these credentials to the application?
Elastic Beanstalk environment properties are injected as process environment variables at instance launch, keeping credentials out of source code and configuration files. They are stored encrypted at rest by the platform and can reference Secrets Manager or SSM Parameter Store values.
Why this answer
Elastic Beanstalk allows you to set environment properties in the environment configuration, which are injected as environment variables into the application's runtime. This approach keeps sensitive credentials out of the source code and deployment artifacts, adhering to the principle of least privilege and secure credential management. For a Node.js application, these environment variables can be accessed via `process.env`, providing a secure and flexible way to manage database credentials without hardcoding or storing them in files.
Exam trap
The trap here is that candidates may think storing credentials in a configuration file (Option B) is acceptable because it separates code from configuration, but they overlook that the configuration file is still part of the deployment package and can be accessed by anyone with access to the artifact or the running environment.
How to eliminate wrong answers
Option A is wrong because storing credentials in a file in the source code repository exposes them to anyone with access to the repository, violating security best practices and potentially leading to credential leakage in version control history. Option B is wrong because including credentials in the application's configuration file within the deployment package embeds them in the deployable artifact, making them accessible to anyone who can access the deployment package or the running environment's filesystem. Option C is wrong because hardcoding credentials in the application code is a severe security risk, as it exposes secrets in the codebase, makes rotation difficult, and violates the principle of separating configuration from code.
A company uses AWS Elastic Beanstalk to deploy a web application. The development team wants to deploy a new version of the application to a separate environment for testing before switching production traffic. Which deployment strategy should be used?
Blue/green deployment is the correct strategy because it involves provisioning an entirely new, separate Elastic Beanstalk environment (the "green" environment) running the updated application version. This new environment can be thoroughly tested and validated in isolation without affecting the live "blue" environment. Once testing is complete, traffic is seamlessly redirected to the new environment by swapping the CNAME URL, enabling zero-downtime updates and providing an immediate rollback path by simply reverting the URL swap.
Why this answer
Blue/green deployment (Option C) creates a separate, independent environment (green) for the new version, allowing thorough testing before swapping the environment's URLs to route production traffic to the green environment. This minimizes risk and enables quick rollback. Option A (immutable) launches a new Auto Scaling group in the same environment but does not isolate the new version in a separate environment; Option B (all at once) updates all instances simultaneously in the same environment, causing downtime; Option D (rolling) updates instances in batches in the same environment, exposing some users to the new version during deployment.
A developer is deploying a new version of a Lambda function using the AWS CLI. The function is part of a serverless application that processes S3 events. The developer wants to ensure that the new version is production-ready and that the old version is still available for rollback. Which CLI command should the developer use to create a new version of the Lambda function?
The `aws lambda publish-version` command is the correct method to create an immutable snapshot of a Lambda function's code and configuration. This action assigns a unique, sequential version number to the current state of the `$LATEST` function, making it available for consistent invocation, rollbacks, and integration with aliases for controlled deployments. It explicitly captures the function's current definition.
Why this answer
The `aws lambda publish-version` command creates an immutable, versioned snapshot of the Lambda function's code and configuration, which is required for production-ready deployments. This ensures the old version remains available for rollback while the new version is published with a unique version number (e.g., $LATEST, 1, 2). The command explicitly publishes the current $LATEST version as a new numbered version, making it production-ready without affecting existing versions.
Exam trap
The trap here is that candidates confuse deploying code with `update-function-code` (which only updates $LATEST) with publishing a new version, assuming that any code update automatically creates a version; in reality, you must explicitly run `publish-version` to create an immutable, numbered version for production use and rollback.
How to eliminate wrong answers
Option B is wrong because `update-function-configuration` only modifies the function's configuration settings (e.g., handler, runtime, environment variables) and does not create a new version; it updates the $LATEST version in place, leaving no immutable snapshot for rollback. Option C is wrong because `update-function-code` only deploys new code to the $LATEST version, overwriting the existing code without creating a new numbered version; the old code is lost unless a version was previously published. Option D is wrong because `create-function` is used to create a new Lambda function from scratch, not to deploy a new version of an existing function; it would fail if the function already exists or create a separate function, which does not preserve the old version for rollback.
Which TWO actions should a developer take to ensure that an AWS CodeDeploy deployment is successful when deploying to an Auto Scaling group? (Choose TWO.)
Creating an IAM service role is mandatory because CodeDeploy uses this role to assume permissions to call Amazon EC2 and Auto Scaling APIs, letting it enumerate instances, read tags, and perform deployment actions. Without this role, CodeDeploy cannot even start a deployment or resolve the target instances in the Auto Scaling group, making it a fundamental prerequisite.
Why this answer
Option A is correct because CodeDeploy requires an IAM service role (the CodeDeploy service role) that grants it permissions to perform actions on the developer's behalf, such as reading tags, accessing S3 revision bundles, and calling EC2 Auto Scaling APIs to manage instances during deployment. Option E is correct because the CodeDeploy agent must be installed and running on each EC2 instance in the Auto Scaling group so the instance can poll CodeDeploy, receive the revision, and execute the deployment lifecycle event hooks (ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService). Option B is not required because an Application Load Balancer is only needed for load-balanced or blue/green scenarios, not for a basic in-place deployment to an Auto Scaling group.
Option C is incorrect because Application Discovery Service is used for migration planning and discovery, not for CodeDeploy deployments. Option D is not required because CodeDeploy supports in-place deployments to Auto Scaling groups, so blue/green is optional rather than mandatory.
Exam trap
DVA-C02 often tests whether candidates confuse 'nice-to-have' deployment features (ALB, blue/green) with hard prerequisites (IAM service role, CodeDeploy agent) — the exam expects you to identify the minimum required configuration.
A company wants to deploy an application using AWS Elastic Beanstalk. The application requires a relational database. What is the BEST practice for managing the database?
Creating an Amazon RDS database instance separately and configuring the application to connect to it is a best practice for decoupling the database from the application's environment. This approach ensures that the database's lifecycle, including scaling, backups, and patching, is independent of the Elastic Beanstalk environment. This prevents accidental data loss if the Beanstalk environment is terminated or rebuilt, providing greater data persistence and operational flexibility.
Why this answer
The best practice for managing a relational database in Elastic Beanstalk is to decouple the database from the application lifecycle by creating an Amazon RDS instance separately. This ensures the database is not deleted when the Elastic Beanstalk environment is terminated, provides better control over backups, scaling, and maintenance, and allows the application to connect via environment variables or configuration files. Using a separate RDS instance aligns with production best practices for durability and operational flexibility.
Exam trap
The trap here is that candidates assume the integrated RDS option in Elastic Beanstalk is the simplest and therefore best approach, but the exam tests the understanding that decoupling the database from the environment lifecycle is the production best practice to avoid accidental data loss.
How to eliminate wrong answers
Option B is wrong because adding an RDS database via the Elastic Beanstalk console ties the database lifecycle to the environment, meaning the database is deleted when the environment is terminated, which is risky for production workloads. Option C is wrong because Amazon S3 is an object storage service, not a relational database; it cannot support SQL queries, transactions, or relational data models required by the application. Option D is wrong because Amazon DynamoDB is a NoSQL key-value and document database, not a relational database; it does not support SQL joins, ACID transactions across multiple tables, or schema enforcement needed for relational workloads.
A developer is deploying a serverless application using AWS SAM. The application consists of an API Gateway REST API and multiple AWS Lambda functions. The developer wants to deploy the application to a production environment with minimal downtime. Which deployment strategy should the developer use?
SAM's built-in canary deployment, integrated with AWS CodeDeploy, provides a robust mechanism for safely deploying serverless applications with gradual traffic shifting. This strategy allows a small percentage of traffic to be routed to the new Lambda version while monitoring for errors via CloudWatch alarms. If issues arise, CodeDeploy can automatically roll back to the previous stable version, minimizing impact and ensuring high availability during updates.
Why this answer
AWS SAM supports built-in canary deployments with traffic shifting, which gradually routes a percentage of traffic to the new version while monitoring CloudWatch alarms. This minimizes downtime and allows automatic rollback if errors occur. It is the recommended strategy for serverless applications on API Gateway and Lambda.
Exam trap
DVA-C02 often tests the misconception that SAM can perform rolling updates on Lambda functions like EC2 Auto Scaling groups, when in fact Lambda uses versions and aliases with traffic shifting.
How to eliminate wrong answers
Option A is wrong because Elastic Beanstalk is for EC2-based applications, not serverless Lambda/API Gateway stacks. Option B is wrong because deleting and redeploying causes downtime and loses stack resources. Option C is wrong because rolling updates are not natively supported for Lambda functions in SAM; Lambda versions and aliases are used for traffic shifting instead.
A company uses AWS CodePipeline with a manual approval step before deployment. The developer wants to ensure that if a pipeline execution is waiting for approval and new code is pushed, the awaiting execution is canceled and a new one starts with the latest code. Which pipeline execution mode should be configured?
The Superseded execution mode is designed to prioritize the latest changes by canceling any currently running pipeline execution when a new source revision is detected. This ensures that the manual approval step, if present, will always apply to the most recent code changes, preventing the deployment of outdated versions. A new pipeline execution is then immediately initiated with the latest code, requiring a fresh approval for the most current state.
Why this answer
The Superseded execution mode is correct because it automatically cancels any currently running or waiting pipeline execution when a new one is triggered, ensuring that only the latest code proceeds through the pipeline. This is ideal for scenarios with manual approval steps where stale executions should not block or delay the deployment of the most recent commit.
Exam trap
The trap here is that candidates may confuse Superseded with Queued, assuming that queuing is the default or safest option, but they miss that Superseded is specifically designed to replace pending executions with the latest code push.
How to eliminate wrong answers
Option A is wrong because Queued mode places executions in a queue and runs them sequentially, meaning a waiting approval would not be canceled and the new push would wait until the previous execution completes. Option C is wrong because Parallel mode allows multiple executions to run concurrently, which would not cancel the awaiting execution and could lead to conflicting deployments. Option D is wrong because Single mode is not a valid execution mode in AWS CodePipeline; the available modes are Queued, Superseded, and Parallel.
A SAM application should gradually shift Lambda traffic and roll back on errors. Which two pieces are needed?
A Lambda alias, when combined with deployment preferences (often managed by AWS CodeDeploy), is the primary mechanism for implementing gradual traffic shifts for Lambda functions. This approach allows a new version of a Lambda function to incrementally receive a percentage of invocations, enabling canary or linear deployments and controlled rollouts to minimize risk.
Why this answer
AWS SAM uses Lambda aliases with deployment preferences (e.g., Canary10Percent5Minutes or Linear10PercentEvery10Minutes) to gradually shift traffic from the old version to the new version. Option C is correct because CloudWatch alarms can be tied to the deployment preferences to automatically roll back the traffic shift if the alarm enters the ALARM state, indicating errors or degraded health.
Exam trap
The trap here is that candidates often confuse deployment-related features (like S3 lifecycle rules or public buckets) with the actual AWS services (Lambda alias and CodeDeploy) that handle traffic shifting and rollback, leading them to select irrelevant options.
Ready to test yourself?
Try a timed practice session using only Deployment questions.