75 of 169 questions · Page 1/3 · 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 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.
Refer to the exhibit. A developer is trying to deploy an EC2 instance using AWS CloudFormation. The stack creation fails with an 'AccessDenied' error when CloudFormation tries to create the EC2 instance. The developer has the IAM policy above. What is the MOST likely reason for the failure?
This is correct. When CloudFormation creates an EC2 instance with an IAM instance profile, the user or role making the API calls must have iam:PassRole permission with a Resource that explicitly includes the ARN of the role being passed. In this case, the template specifies one IAM role (via its instance profile), but the PassRole statement in the policy points to a different role ARN. Because the role ARN in the policy resource does not match the role ARN in the template, CloudFormation is denied the iam:PassRole action, which prevents the instance from launching even though all EC2 actions are allowed. To fix it, either change the template to use the role allowed by the PassRole policy or extend the policy's Resource to include the template's role ARN, using least privilege.
Why this answer
CloudFormation needs permission to pass the IAM role specified in the template. The policy allows PassRole only for a specific role ARN. If the template specifies a different role, CloudFormation cannot pass it, resulting in an AccessDenied error.
Option A is incorrect because ec2:DescribeImages is allowed in the policy. Option C is incorrect because ec2:RunInstances is allowed. Option D is incorrect because ec2:TerminateInstances is not called during stack creation, and the policy allows it anyway.
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.
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
In a blue/green deployment with Elastic Beanstalk, you first deploy the new application version to a separate environment (E). Then, you swap the CNAMEs of the two environments to route traffic to the new environment (B). After verifying the new environment works correctly, you terminate the old environment (C).
Option A is incorrect because you do not update the existing environment; you create a new one. Option D is incorrect because you swap CNAMEs, not manually update Route 53 DNS records.
A company is deploying a Node.js application on AWS Elastic Beanstalk. The application uses environment variables for configuration. The development team wants to ensure that the environment variables are not exposed in the source code or in the deployment logs. Which TWO actions should the team take? (Choose TWO.)
Storing sensitive values in AWS Systems Manager Parameter Store as SecureString parameters encrypts them with a KMS key and keeps them out of both source code and Elastic Beanstalk environment properties. The Node.js application fetches each secret at runtime using the SSM GetParameter API, which is authorized via IAM roles attached to the Elastic Beanstalk instance profile. This approach supports per-environment separation, parameter versioning, and the ability to update credentials without redeploying or changing the environment configuration.
Why this answer
Options C and D are correct. Storing environment variables in AWS Systems Manager Parameter Store (C) or AWS Secrets Manager (D) prevents exposure in source code or logs, as they are retrieved at runtime via SDK calls. Option A (detailed logging) does not prevent exposure; it may actually log the values.
Option B (Elastic Beanstalk environment properties) stores values in plaintext in the environment configuration, which can be viewed. Option E (embedding in .env file) exposes them in the source code and deployment artifacts.
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 developer is using AWS CodeDeploy to deploy an application to an Amazon EC2 Auto Scaling group. The deployment fails because the CodeDeploy agent on the instances is not running. Which TWO steps should the developer take to resolve this issue? (Choose TWO.)
Installing the CodeDeploy agent places the agent software on the instance (for example, under /opt/codedeploy-agent on Amazon Linux and Ubuntu) and creates the codedeploy-agent service. This agent is a long-running daemon that polls the CodeDeploy service for deployment commands, downloads the application revision artifacts from Amazon S3 or GitHub, and executes the AppSpec file hooks in the correct order. Until the agent binary is present, the instance cannot receive or process any CodeDeploy deployment, which is why this action is a required prerequisite before a deployment can even begin.
Why this answer
The issue is that the CodeDeploy agent is not running on the instances. To resolve this, the developer should first ensure the agent is installed (Option B) and then start the agent service (Option C). Option A is incorrect because attaching an IAM role allows permissions but does not install or start the agent.
Option D is incorrect because rebooting does not fix missing or stopped agents. Option E is incorrect because user data runs only at launch, not on existing instances; it is a preventive measure, not a fix for already-running instances.
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
To ensure only approved changes are deployed to production, the developer should implement a manual approval step (option C) to gate deployments, use separate pipelines for different environments (option D) to isolate changes, and include integration tests in the build stage (option E) to catch errors early. Automatic deployment to production (option A) bypasses approval, and deploying all feature branches directly (option B) introduces unverified code, making both risky.
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 developer is using AWS CloudFormation to deploy a stack that includes an Amazon RDS DB instance. The developer wants to update the DB instance to a larger instance type without causing downtime. The current template has DeletionPolicy set to 'Delete'. What should the developer do?
Blue/green deployment minimizes downtime by switching to a new stack.
Why this answer
A blue/green deployment allows you to create a new stack with the larger DB instance type in a separate environment (green), then switch the application traffic to the new database with minimal downtime. This approach avoids the downtime associated with in-place modifications, as CloudFormation updates to RDS instance types typically require a reboot, which causes an outage. By using a blue/green deployment, the developer can validate the new instance and cut over seamlessly.
Exam trap
The trap here is that candidates assume CloudFormation stack updates can resize RDS instances without downtime, but in reality, modifying the DBInstanceClass requires a reboot, making blue/green deployments the only zero-downtime option among the choices.
How to eliminate wrong answers
Option A is wrong because taking a snapshot and restoring to a larger instance type involves significant downtime during the restore process, and does not provide a zero-downtime update path. Option C is wrong because changing the DeletionPolicy to 'Retain' only affects stack deletion behavior, not updates; updating the stack with a larger instance type still triggers a reboot and downtime. Option D is wrong because promoting a read replica requires breaking replication and incurs downtime during the promotion process, and read replicas are not designed for zero-downtime instance type changes.
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 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 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
In a Blue/Green deployment, you create a new Auto Scaling group with the new application version and register it with the existing ALB. Option E is correct because after the new environment is ready, you gradually shift traffic from the old environment to the new environment using the ALB to ensure zero downtime. Option A is incorrect because you should reuse the existing ALB to avoid re-creating DNS and other configurations.
Option C is incorrect because updating the existing Auto Scaling group in-place would cause downtime (rolling update) rather than a true Blue/Green deployment. Option D is incorrect because terminating old instances immediately could cause downtime if the new environment fails; you should allow rollback by keeping old instances until traffic is fully shifted.
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 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 (Option A) is the most secure and maintainable approach for managing environment variables across stages. It provides hierarchical storage (e.g., /dev/myapp/var, /prod/myapp/var), supports encryption with AWS KMS, and can be referenced by Lambda functions using the AWS SDK. Option B (CloudFormation parameters) ties configuration to deployment templates and does not provide a secure, runtime-configurable store.
Option C (hardcoding) is insecure and not maintainable. Option D (storing in Lambda configuration) lacks the stage-specific hierarchy and encryption features of Parameter Store.
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.
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 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 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
Both Option B and Option C are correct. In AWS CodePipeline, a manual approval action pauses the pipeline until the specified approver(s) approve or reject the change. To implement this, you add a manual approval action in the pipeline (Option B) and then configure that action to require a specific IAM user or group to approve (Option C).
This ensures that only authorized personnel can approve the production deployment. Option A is incorrect because CloudWatch Events and Lambda can automate pipeline execution but do not provide a built-in manual approval mechanism. Option D is incorrect because CodeDeploy lifecycle hooks can pause the deployment process within the deployment group, but the requirement is a pipeline-level manual approval step, which is a native feature of CodePipeline.
Option E is incorrect because SNS is used for notifications; while you can notify approvers via SNS, the approval action itself is configured within CodePipeline, not through SNS.
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 setting up a CI/CD pipeline for a Python application using AWS CodeCommit, CodeBuild, and CodeDeploy. The developer wants to trigger the pipeline automatically when code is pushed to the master branch. Which TWO actions are required? (Choose two.)
The source stage must be configured to pull from CodeCommit.
Why this answer
Options B and D are correct because B is necessary: the pipeline source stage must use AWS CodeCommit as the provider to detect pushes to the repository. D is also required: a webhook configured in CodeCommit sends push events to the pipeline, triggering it automatically. Option A is incorrect because CodeDeploy is a deployment stage, not a trigger.
Option C is incorrect because a scheduled CloudWatch Events rule would trigger the pipeline on a schedule, not on code pushes. Option E is incorrect because CloudTrail logs API calls but does not trigger pipelines.
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?
Environment properties are secure and easily managed.
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 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
The correct actions are to create an IAM service role that allows CodeDeploy to access the instances (Option A) and install the CodeDeploy agent on each EC2 instance in the Auto Scaling group (Option E). The service role grants CodeDeploy the necessary permissions to deploy to the instances, and the agent must be running on each instance to receive and execute deployment commands. Option B is not required; a load balancer is optional and not necessary for successful deployments.
Option C is irrelevant; the Application Discovery Service is used for discovery and migration planning, not for CodeDeploy. Option D is not required; CodeDeploy supports both in-place and blue/green deployments, but the question does not specify which type, and a blue/green deployment is not mandatory for success.
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 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.
A developer is deploying a new version of a Lambda function using the AWS CLI. The developer wants to shift 10% of traffic to the new version and then gradually increase to 100% over 10 minutes. Which CLI command should the developer use?
This command precisely implements a canary deployment strategy by updating the `prod` alias. It configures the alias to direct 10% of the invocation traffic (calculated as 1.0 minus the specified `AdditionalVersionWeights` for the older version, 0.9) to the newly specified `function-version 2`. The remaining 90% of traffic continues to serve `version 1`, allowing for gradual rollout and monitoring of the new version before a full cutover.
Why this answer
The `update-alias` command with the `--routing-config` parameter allows you to implement canary deployments by assigning a percentage of traffic to a new Lambda function version. In this case, `AdditionalVersionWeights={"1":0.9}` routes 10% of traffic to version 2 (the new version) and 90% to version 1. However, note that this command only sets a static routing configuration; to gradually increase traffic to 100% over 10 minutes, you must update the alias multiple times (e.g., via a script) to adjust the weights progressively.
The command shown is the correct initial step to start the canary deployment.
Exam trap
The trap here is that candidates may confuse `publish-version` (which only creates a version) with the alias routing command needed to actually shift traffic, or they may think `invoke` can be used for deployment, but only `update-alias` with `--routing-config` enables the weighted traffic shift described in the question.
How to eliminate wrong answers
Option A is wrong because `publish-version` only creates a new immutable version of the Lambda function but does not route any traffic to it; it requires a separate alias update to shift traffic. Option B is wrong because `create-function` is used to create a new Lambda function from scratch, not to deploy a new version or manage traffic routing for an existing function. Option D is wrong because `invoke` is used to synchronously invoke a Lambda function with a payload, not to deploy or shift traffic between versions.
A company uses AWS CodeBuild for building and testing their application. They have a build project that runs on a Linux environment. They want to run a build in a custom Docker image that is stored in Amazon ECR. How should they configure the build project?
AWS CodeBuild projects allow you to define the build environment by specifying a custom Docker image. This is achieved by navigating to the "Environment" section of the CodeBuild project configuration and setting the "Image" field directly to the Amazon ECR image URI (e.g., `aws_account_id.dkr.ecr.region.amazonaws.com/repository-name:tag`). CodeBuild will then pull this specific image from ECR to execute the build commands, ensuring a consistent and controlled build environment.
Why this answer
AWS CodeBuild allows you to specify a custom Docker image from Amazon ECR by entering its URI directly in the 'Image' field under the environment configuration. This enables the build to run in a container that includes all necessary dependencies, without requiring a Dockerfile in the source code or a managed image.
Exam trap
The trap here is that candidates confuse specifying a Dockerfile to build a new image (Option A) with using an existing custom image as the build environment, leading them to overlook the direct ECR URI configuration in the environment settings.
How to eliminate wrong answers
Option A is wrong because adding a Dockerfile to the source code and specifying it in the buildspec is used for building a new Docker image, not for running the build in an existing custom image from ECR. Option C is wrong because managed images provided by AWS CodeBuild are pre-configured environments (e.g., Ubuntu, Windows) and do not include custom dependencies that the company needs. Option D is wrong because passing the image URI as an environment variable does not instruct CodeBuild to use that image as the runtime environment; the image must be specified in the environment configuration's 'Image' field.
A developer uses AWS CodeCommit to store source code. The developer wants to automatically trigger a build in AWS CodeBuild every time a new commit is pushed to the master branch. Which AWS service should the developer use to configure this integration?
CodePipeline integrates CodeCommit and CodeBuild for continuous integration.
Why this answer
AWS CodePipeline is the correct service because it provides a fully managed continuous delivery service that can be configured to automatically start a pipeline execution whenever a new commit is pushed to a specific branch in AWS CodeCommit. By setting up a CodeCommit source action in a pipeline, CodePipeline uses webhooks or polling to detect changes and then triggers the build project in AWS CodeBuild as the next stage. This creates a seamless CI/CD workflow without requiring custom event rules or additional services.
Exam trap
The trap here is that candidates often confuse event-driven triggers (CloudWatch Events/EventBridge) with the purpose-built CI/CD orchestration service (CodePipeline), overlooking that CodePipeline natively integrates with CodeCommit and CodeBuild to provide a complete pipeline with stages, transitions, and error handling.
How to eliminate wrong answers
Option A is wrong because Amazon CloudWatch Events (or EventBridge) can detect CodeCommit repository state changes and invoke targets like CodeBuild, but it is not the primary or recommended service for orchestrating a multi-stage CI/CD pipeline; it requires custom event rules and does not provide built-in pipeline sequencing, approval gates, or stage transitions. Option B is wrong because Amazon S3 events are designed for object-level operations in S3 buckets, not for detecting commits in a CodeCommit repository; CodeCommit does not emit S3 events. Option C is wrong because AWS CodeDeploy is a deployment service that automates application deployments to compute services like EC2, Lambda, or on-premises instances; it does not detect source code changes or trigger builds, and it is typically used as a deployment action within a pipeline, not as the trigger mechanism.
A developer is using AWS CodeDeploy to deploy an application to an Auto Scaling group of EC2 instances. The application is critical and must have zero downtime. The Auto Scaling group currently has 4 instances spread across 2 Availability Zones. Which predefined deployment configuration minimizes the number of instances taken out of service at any given time?
OneAtATime deploys to a single instance at a time, minimizing the number of instances offline and best preserving availability.
Why this answer
CodeDeployDefault.OneAtATime, is correct because it deploys the application to only one instance at a time, ensuring that the remaining instances continue to serve traffic. This minimizes the number of instances taken out of service at any given moment, which is critical for achieving zero downtime in an Auto Scaling group with 4 instances across 2 Availability Zones.
Exam trap
The trap here is that candidates may confuse deployment configurations designed for EC2 instances (like OneAtATime) with those for Lambda (like LambdaCanary10Percent5Minutes), or incorrectly assume HalfAtATime is the safest option without considering that OneAtATime minimizes the number of instances out of service even further.
How to eliminate wrong answers
Option A is wrong because CodeDeployDefault.AllAtOnce deploys to all instances simultaneously, taking all 4 instances out of service at once, which violates the zero-downtime requirement. Option B is wrong because CodeDeployDefault.HalfAtATime deploys to 2 instances at a time (half of 4), which takes more instances out of service than necessary compared to OneAtATime. Option D is wrong because CodeDeployDefault.LambdaCanary10Percent5Minutes is a deployment configuration for AWS Lambda functions, not for EC2 instances in an Auto Scaling group, and is therefore inapplicable.
A developer is using AWS Elastic Beanstalk to deploy a web application. The application uses an Amazon RDS database instance that is included in the Elastic Beanstalk environment. The developer wants to update the application code without affecting the database. What is the recommended approach?
Decoupling the database by provisioning a standalone Amazon RDS instance outside the Elastic Beanstalk environment ensures its independent lifecycle management, allowing for separate scaling, backups, and patching. The application then connects to this external database using environment properties, guaranteeing data persistence and availability even if the Elastic Beanstalk environment is rebuilt, terminated, or updated, which is critical for production workloads.
Why this answer
When an RDS instance is included in an Elastic Beanstalk environment, it is tied to the environment's lifecycle. If the environment is terminated or rebuilt, the database is also deleted. Decoupling the database by creating a standalone RDS instance and connecting the application to it externally ensures the database persists independently of application deployments, allowing code updates without risking data loss.
Exam trap
The trap here is that candidates assume swapping CNAMEs between environments (blue/green deployment) is sufficient to protect the database, but they overlook that the database is still lifecycle-managed within each environment and will be lost if the original environment is terminated.
How to eliminate wrong answers
Option A is wrong because directly updating code on EC2 instances bypasses Elastic Beanstalk's managed deployment process, leading to configuration drift and loss of rollback capability. Option B is wrong because swapping CNAMEs between environments does not decouple the database; the new environment would still have its own lifecycle-managed RDS instance, and the original database remains tied to the old environment. Option D is wrong because platform updates only update the Elastic Beanstalk platform version, not the application code, and the database remains lifecycle-coupled, so any environment rebuild or termination would still affect the database.
A company uses AWS CodePipeline to automate deployments of a microservices application to Amazon ECS with Fargate. The pipeline has a deploy stage that uses Amazon ECS Blue/Green deployment. The deployment fails intermittently with a 'Task failed to start' error. The developer needs to troubleshoot the issue. Which THREE steps should the developer take? (Choose three.)
The Amazon ECS service events tab is the authoritative source for recent service-level warnings and alarms, including deployment failures and stopped tasks. Each event often contains the exact error such as "CannotPullContainerError: Access Denied" or "task failed to start" along with a timestamp and the task ID. This is the first place an engineer should look because it directly records the reason ECS could not run the task.
Why this answer
Options B, C, and E are correct. Checking Amazon ECS service events (B) provides the task failure reason directly from the ECS service. Validating the task definition JSON (C) ensures correct container image references and configuration.
Verifying the task execution IAM role (E) ensures it has permissions to pull the container image from ECR. Option A (CodeBuild logs) is incorrect because the failure occurs during deployment, not build. Option D (CloudFormation stack events) is incorrect because the ECS service may not be created via CloudFormation or events there are not relevant for task failures.
A company uses AWS OpsWorks to manage a stack of EC2 instances. After a deployment, the application becomes unresponsive. The engineer suspects that a configuration file was not updated correctly. What is the best way to verify the deployed configuration?
When OpsWorks manages an EC2 instance, it uses Chef to apply configuration. The `/var/lib/aws/opsworks` directory on the instance is the authoritative location where Chef recipes, generated configuration files, and custom JSON are stored and executed. Directly inspecting these files allows a developer to verify the exact configuration that was actually deployed and applied to the instance, which is crucial for diagnosing why an application might be unresponsive due to misconfiguration.
Why this answer
OpsWorks stores its configuration data, including the applied custom JSON and stack settings, in /var/lib/aws/opsworks on each EC2 instance. By SSHing into the instance and inspecting these files, the engineer can directly verify whether the configuration file was updated correctly after deployment, bypassing any application-level logging or abstraction.
Exam trap
The trap here is that candidates assume CloudWatch Logs or Systems Manager Run Command are the best tools for configuration verification, overlooking the fact that OpsWorks stores its deployed configuration locally on the instance in a specific directory that can only be inspected directly via SSH.
How to eliminate wrong answers
Option A is wrong because AWS Systems Manager Run Command can execute scripts, but it does not provide direct access to the OpsWorks-specific configuration files stored on the instance; it would require the script to read those files, which is less direct than SSH inspection. Option B is wrong because OpsWorks stack logs may show JSON syntax errors in custom JSON, but they do not reveal whether the configuration file was correctly applied to the instance after deployment; syntax errors are only one possible cause. Option D is wrong because application logs in CloudWatch Logs may indicate configuration errors, but they are an indirect indicator and may not reflect the exact state of the configuration file on disk, especially if the application fails before logging.
A developer uses AWS CodePipeline with a manual approval step before deployment. The developer wants to ensure that if a new commit is pushed while a pipeline execution is waiting for approval, the waiting execution is canceled and a new one starts with the latest commit. Which pipeline execution mode should be configured?
Superseded mode is designed to prioritize the most recent changes by immediately stopping any currently active pipeline execution, including those paused at a manual approval step. Upon cancellation of the in-progress execution, a brand new pipeline execution is initiated using the latest source code revisions. This ensures that developers can quickly iterate and deploy updates without waiting for older, potentially stalled, deployments to complete, making it ideal for continuous integration/continuous delivery (CI/CD) workflows where rapid feedback is crucial.
Why this answer
The Superseded execution mode is designed to automatically cancel any in-progress pipeline execution when a new commit is pushed, and start a new execution with the latest source changes. This ensures that the manual approval step does not block newer commits, as the waiting execution is replaced by the one triggered by the latest commit. In contrast, other modes either queue or run executions in parallel, which would not cancel the waiting approval step.
Exam trap
The trap here is that candidates may confuse Superseded with Queued, thinking that queuing will handle the latest commit, but Queued only delays execution without canceling the waiting approval step.
How to eliminate wrong answers
Option A is wrong because Queued mode places new executions in a queue, waiting for the current execution to complete before starting the next one, which would not cancel the waiting approval step. Option C is wrong because Parallel mode allows multiple executions to run concurrently, which would not cancel the waiting execution and could lead to multiple approvals or deployments. Option D is wrong because Single mode is not a valid execution mode in AWS CodePipeline; the valid modes are Queued, Superseded, and Parallel.
A team wants CloudFormation to prevent accidental deletion of a production DynamoDB table during stack updates. What should they configure?
CloudFormation provides the `DeletionPolicy` and `UpdateReplacePolicy` attributes specifically to control the lifecycle of resources during stack operations. Setting `DeletionPolicy` to `Retain` ensures that a resource is not deleted when its containing stack is deleted or the resource is removed from the template. Similarly, `UpdateReplacePolicy` set to `Retain` prevents the old physical resource from being deleted if it is replaced during a stack update, directly addressing the requirement to prevent accidental resource deletion.
Why this answer
The DeletionPolicy attribute with a value of Retain instructs AWS CloudFormation to preserve the DynamoDB table when its stack resource is deleted during a stack update or stack deletion. Similarly, UpdateReplacePolicy Retain ensures that if a resource replacement is required during an update, the existing table is kept rather than deleted. This directly prevents accidental data loss by overriding CloudFormation's default behavior of deleting resources that are removed from the template or replaced.
Exam trap
The trap here is that candidates may confuse operational settings (like write capacity) or unrelated services (Lambda layers, API Gateway) with CloudFormation's resource lifecycle policies, missing the direct purpose of DeletionPolicy and UpdateReplacePolicy.
How to eliminate wrong answers
Option A is wrong because a larger write capacity setting only affects DynamoDB's throughput performance and has no impact on resource lifecycle or deletion prevention. Option B is wrong because a Lambda layer is used to package runtime dependencies for Lambda functions and does not influence CloudFormation's resource deletion behavior. Option C is wrong because an API Gateway usage plan throttles and monitors API requests for billing or rate-limiting purposes and is unrelated to CloudFormation stack resource protection.
A developer is deploying a serverless application using the AWS Serverless Application Model (SAM). The developer runs 'sam deploy' and receives an error: 'Error: Failed to create changeset for the stack.' What is a common cause of this error?
When `sam deploy` (or `aws cloudformation deploy`) is executed, the CloudFormation service first validates the template's syntax and structure. If the SAM template, which is an extension of CloudFormation, contains a syntax error (e.g., incorrect YAML/JSON formatting, invalid intrinsic function usage, or malformed resource properties), CloudFormation will fail to parse it. This failure occurs early in the deployment process, specifically preventing the successful creation of a changeset, as the service cannot understand the desired state described by the invalid template.
Why this answer
The 'Failed to create changeset for the stack' error typically occurs when the SAM template contains a syntax error, such as invalid YAML formatting, missing required properties, or incorrect resource definitions. AWS CloudFormation validates the template before creating a changeset, and any syntax issue will cause the changeset creation to fail immediately. This is the most common cause because SAM templates are YAML-based and prone to indentation or structural mistakes.
Exam trap
The trap here is that candidates often confuse changeset creation failures with permission or bucket issues, but the error message specifically points to template validation, not infrastructure or IAM problems.
How to eliminate wrong answers
Option B is wrong because if the S3 bucket specified for artifacts does not exist, the error would be 'Unable to upload artifact...' or 'Bucket not found', not a changeset creation failure. Option C is wrong because insufficient IAM permissions to create CloudFormation stacks would result in an 'AccessDenied' or authorization error, not a changeset creation failure. Option D is wrong because AWS CodeDeploy is not required for SAM deployments; SAM uses CloudFormation for infrastructure provisioning, and CodeDeploy is only relevant if you configure a separate deployment pipeline.
A developer is using AWS CloudFormation to create a stack that includes an EC2 instance. The stack creation fails because the instance type is not supported in the selected Availability Zone. What should the developer do?
Updating the stack to specify a different subnet or removing the explicit Availability Zone (AZ) specification is the most effective and flexible solution. If a specific AZ lacks capacity for the requested instance type, deploying into a different subnet, which is tied to another AZ, can resolve the issue. Alternatively, by not specifying an AZ, CloudFormation can automatically select an available AZ with sufficient capacity for the desired instance type, ensuring successful deployment while maintaining the intended resource configuration. This leverages CloudFormation's intelligence to handle underlying infrastructure constraints.
Why this answer
When an EC2 instance type is not supported in a specific Availability Zone (AZ), the developer can update the CloudFormation stack to either specify a different subnet (which implicitly selects a different AZ) or omit the Availability Zone parameter entirely, allowing AWS to automatically choose an AZ where the instance type is supported. This avoids the need to delete the stack or change the instance type, preserving other stack resources and configurations.
Exam trap
The trap here is that candidates assume the only fix is to change the instance type (Option B) or restart from scratch (Option A), overlooking CloudFormation's ability to update the stack's subnet or AZ selection to match the instance type's availability.
How to eliminate wrong answers
Option A is wrong because deleting the stack and starting over is unnecessary and inefficient; the issue can be resolved by updating the stack's subnet or AZ specification without losing existing resources. Option B is wrong because changing the instance type may not be desirable if the developer specifically needs that instance type for performance or cost reasons; the problem is the AZ constraint, not the instance type itself. Option D is wrong because creating the stack in a different region is an overreaction; the instance type is likely supported in other AZs within the same region, and changing regions could introduce latency, cost, or compliance issues.
A developer is using AWS CodeDeploy to deploy a new version of an AWS Lambda function. The developer wants to gradually shift traffic from the old version to the new version in 10-minute increments. Which deployment configuration should the developer use?
This CodeDeploy configuration precisely aligns with the requirement for gradual, incremental traffic shifts. It systematically routes 10% of traffic to the new Lambda version, waits for 10 minutes, then shifts another 10%, repeating this process until 100% of traffic is successfully moved. This ensures a controlled, step-by-step rollout, allowing for continuous monitoring and potential rollback at each 10-minute interval.
Why this answer
The Linear10PercentEvery10Minutes configuration shifts traffic from the old Lambda version to the new version in 10% increments every 10 minutes, which matches the developer's requirement of gradually shifting traffic in 10-minute increments. This is a linear deployment type in AWS CodeDeploy that provides a steady, incremental traffic shift over time.
Exam trap
The trap here is confusing canary deployments (which shift a small percentage immediately and then the remainder after a wait) with linear deployments (which shift traffic in equal increments over time), leading candidates to select a canary configuration when a linear one is required.
How to eliminate wrong answers
Option A is wrong because Canary10Percent10Minutes shifts 10% of traffic to the new version immediately, then waits 10 minutes before shifting the remaining 90% all at once, which does not provide gradual 10-minute increments. Option B is wrong because Canary10Percent30Minutes shifts 10% immediately, then waits 30 minutes before shifting the remaining 90%, which does not match the 10-minute increment requirement. Option D is wrong because AllAtOnce shifts 100% of traffic to the new version immediately with no gradual traffic shifting, which contradicts the developer's requirement.
A developer is deploying a new version of an AWS Lambda function using the AWS CLI. The developer wants to create a new version and update the alias to point to the new version. Which sequence of CLI commands should the developer use?
First, updating the function code ensures the `$LATEST` version contains the desired new logic. Next, publishing a version creates an immutable snapshot of this updated code, providing a stable reference point. Finally, updating the alias to point to this newly published version allows for controlled traffic shifting, enabling safe deployments, rollbacks, and advanced strategies like canary releases.
Why this answer
The correct sequence is to first update the function code, then publish a new version, and finally update the alias to point to that new version. The `update-function-code` command uploads the new code to the $LATEST version, `publish-version` creates an immutable numbered version from $LATEST, and `update-alias` updates the alias to reference that specific version. This ensures the alias always points to a stable, published version rather than the mutable $LATEST.
Exam trap
The trap here is that candidates often think they can update the alias before publishing the version, or they confuse the order of operations by assuming the alias can point to $LATEST, but the exam requires the alias to reference a specific published version for immutability and rollback safety.
How to eliminate wrong answers
Option A is wrong because it attempts to update the alias before the new version exists, which would fail or point to a non-existent version. Option B is wrong because it creates a new alias instead of updating an existing one, and also attempts to update the alias before the version is published. Option C is wrong because it publishes a version before updating the function code, which would publish the old code, and then updates the function code to $LATEST without publishing a new version, leaving the alias pointing to the old published version.
A developer is deploying an application using AWS Elastic Beanstalk. The application needs to connect to an Amazon RDS database. What is the best practice for storing database credentials?
AWS Secrets Manager is the recommended and most secure service for storing and managing sensitive credentials. It encrypts secrets at rest and in transit, allows for automatic rotation of credentials, and provides fine-grained access control through AWS IAM policies, ensuring only authorized applications or services can retrieve them at runtime. This approach minimizes the exposure window and enhances the overall security posture by centralizing secret management.
Why this answer
AWS Secrets Manager provides a secure, auditable service for rotating and managing database credentials. By retrieving secrets at runtime via the AWS SDK, the application avoids embedding sensitive data in code or configuration, which is a key security best practice for Elastic Beanstalk deployments.
Exam trap
The trap here is that candidates often confuse Elastic Beanstalk environment properties with secure storage, not realizing they are stored in plaintext and accessible via the environment configuration, unlike Secrets Manager which provides encryption and rotation.
How to eliminate wrong answers
Option A is wrong because hardcoding credentials in application code exposes them in version control and static analysis, violating the principle of least privilege and making rotation impossible without redeployment. Option B is wrong because Elastic Beanstalk environment properties are stored in plaintext in the environment configuration and can be viewed by anyone with access to the Elastic Beanstalk console or API, offering no encryption at rest or rotation capabilities. Option C is wrong because storing credentials in an S3 bucket with public read access exposes them to the entire internet, directly violating AWS security best practices and potentially leading to data breaches.
A company uses AWS Elastic Beanstalk to deploy a web application. The development team wants to ensure that the deployment does not cause any downtime and that new instances are fully registered with the load balancer before old instances are terminated. Which deployment policy should they use?
This policy adds new instances before removing old ones, ensuring zero downtime.
Why this answer
The Rolling with an additional batch deployment policy launches a new batch of instances in addition to the current ones, registers them with the load balancer, and only then terminates the old instances. This ensures zero downtime because the new instances are fully serving traffic before any old instances are removed, unlike standard rolling deployments which terminate old instances before new ones are fully ready.
Exam trap
The trap here is that candidates often confuse 'Rolling with an additional batch' with 'Immutable' deployment, but the key distinction is that Immutable creates a completely separate environment and swaps URLs, while Rolling with an additional batch operates within the same environment by temporarily adding extra instances.
How to eliminate wrong answers
Option A is wrong because Immutable deployment launches a completely new set of instances in a new Auto Scaling group, then swaps the load balancer target group; while it also avoids downtime, it does not use an 'additional batch' approach and is more resource-intensive. Option C is wrong because Rolling deployment terminates old instances in batches before new instances are fully registered with the load balancer, causing potential downtime during the transition. Option D is wrong because All at once deployment terminates all existing instances and deploys the new version simultaneously, causing downtime until the new instances are healthy and registered.
A developer is using AWS Elastic Beanstalk to deploy a web application. The application requires a highly available environment across multiple Availability Zones. The developer wants to update the application without any downtime while minimizing the number of new instances launched. Which deployment policy should the developer use?
This policy launches a new batch of instances alongside the existing ones, ensuring capacity is never reduced. It achieves zero downtime with minimal additional instances compared to immutable.
Why this answer
(Rolling with additional batch) is correct because it launches a new batch of instances before taking the old ones out of service, ensuring full capacity is maintained during the deployment. This provides high availability across multiple Availability Zones while minimizing the number of new instances compared to an immutable deployment, which would double the instance count. The additional batch absorbs the traffic during the rolling update, preventing any downtime.
Exam trap
The trap here is that candidates confuse 'Rolling' with 'Rolling with additional batch', assuming both provide zero downtime, but only the latter guarantees full capacity throughout the update by adding an extra batch to absorb traffic.
How to eliminate wrong answers
Option A is wrong because 'All at once' deploys the new version to all instances simultaneously, causing downtime as all instances are replaced at the same time. Option B is wrong because 'Rolling' updates instances in batches without an extra batch, which reduces capacity during the update and can lead to downtime if the application cannot handle reduced load. Option D is wrong because 'Immutable' launches a completely new set of instances in a new Auto Scaling group, then swaps the environment, which minimizes downtime but launches the maximum number of new instances (doubling the count), contradicting the requirement to minimize new instances.
Ready to test yourself?
Try a timed practice session using only Deployment questions.