Courseiva

CCNA Deployment Questions

19 of 169 questions · Page 3/3 · Deployment · Answers revealed

Practice these questionsDomain overviewAll questions
151
MCQhard

A company is deploying a new microservice on AWS Lambda that processes high-resolution images and stores results in Amazon S3. The Lambda function currently uses 1024 MB of memory and has a timeout of 2 minutes. During peak load, many invocations are timing out. The function is CPU-bound during image processing. Which change is MOST likely to reduce timeouts without increasing costs unnecessarily?

A.Increase the function memory to 3008 MB.
B.Enable provisioned concurrency to reduce cold starts.
C.Increase the function memory to 2048 MB.
D.Increase the function timeout to 5 minutes.
AnswerC

AWS Lambda allocates CPU power proportionally to the configured memory setting, making it a direct lever for performance optimization. Increasing the function's memory to 2048 MB provides a full virtual CPU (vCPU) to the execution environment, significantly boosting computational resources. For CPU-bound microservices, this direct increase in processing power will reduce the overall execution time, making it a highly effective and often cost-efficient optimization.

Why this answer

Increasing memory from 1024 MB to 2048 MB proportionally increases CPU allocation in AWS Lambda (up to 1.7 GHz per vCPU at 1769 MB). Since the function is CPU-bound, this directly reduces processing time, mitigating timeouts without the cost spike of 3008 MB. The cost increase is linear with memory, so doubling memory doubles cost per invocation, but the reduced duration often offsets this, keeping total cost similar or lower.

Exam trap

The trap here is that candidates assume increasing timeout (Option D) is the simplest fix for timeouts, ignoring that CPU-bound functions need more CPU, not just more time, and that provisioned concurrency (Option B) is mistakenly thought to improve execution speed rather than just reducing cold start latency.

How to eliminate wrong answers

Option A is wrong because increasing memory to 3008 MB provides more CPU than needed for a CPU-bound task, leading to unnecessary cost without proportional performance gain (Lambda CPU scales linearly up to ~1769 MB, then plateaus). Option B is wrong because provisioned concurrency addresses cold starts, not timeout issues caused by insufficient CPU during peak load; it does not reduce execution time for CPU-bound processing. Option D is wrong because increasing the timeout to 5 minutes does not fix the root cause (CPU-bound processing is too slow); it only delays the timeout, allowing the function to run longer but still at the same slow speed, potentially increasing costs due to longer execution duration.

Practice this question →
152
MCQhard

A developer is using AWS CodeDeploy with a blue/green deployment on an Amazon ECS service running on Fargate. The developer wants to ensure that the new (green) task set is fully healthy and serving traffic before the old (blue) task set is terminated. The deployment should automatically roll back to the blue task set if the green task set fails health checks. Which configuration should the developer set in the CodeDeploy deployment group?

A.Deployment type: blue/green, with rollback configuration enabled to trigger automatic rollback and reroute traffic to the original task set
B.Deployment type: blue/green, Deployment configuration: CodeDeployDefault.ECSAllAtOnce
C.Deployment type: blue/green, Deployment configuration: CodeDeployDefault.ECSLinear10PercentEvery1Minutes
D.Deployment type: blue/green, with an Application Load Balancer
AnswerA

This configuration leverages AWS CodeDeploy's integrated rollback capabilities for blue/green deployments. By enabling rollback, CodeDeploy actively monitors predefined CloudWatch alarms or health checks during the traffic shifting phase. If any alarm is triggered, indicating a deployment failure or performance degradation, CodeDeploy automatically initiates a rollback, rerouting all traffic back to the original, stable task set to maintain application availability and minimize impact.

Why this answer

The developer needs to configure the CodeDeploy deployment group with a blue/green deployment type and enable automatic rollback. This ensures that if the green task set fails health checks, CodeDeploy automatically terminates the green deployment and reroutes traffic back to the original blue task set, meeting the requirement for a fully healthy green task set before termination.

Exam trap

The trap here is that candidates often confuse deployment configurations (like AllAtOnce or Linear) with rollback settings, assuming that a traffic shifting strategy alone ensures health checks and automatic rollback, but rollback must be explicitly configured in the deployment group.

How to eliminate wrong answers

Option B is wrong because CodeDeployDefault.ECSAllAtOnce is a deployment configuration that shifts all traffic to the green task set immediately, which does not ensure the green task set is fully healthy before the blue task set is terminated; it also lacks automatic rollback on health check failure. Option C is wrong because CodeDeployDefault.ECSLinear10PercentEvery1Minutes is a linear traffic shifting configuration that gradually moves traffic in 10% increments every minute, but it does not automatically roll back to the blue task set if the green task set fails health checks; it only controls the traffic shift rate. Option D is wrong because while an Application Load Balancer is required for blue/green deployments on ECS, it alone does not provide the automatic rollback behavior needed; the rollback configuration must be explicitly enabled in the deployment group.

Practice this question →
153
Multi-Selecthard

A developer is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment is set to use a 'OneAtATime' deployment configuration. The developer wants to ensure that the deployment does not cause downtime. Which TWO configurations are necessary?

Select 2 answers
A.Set the 'IgnoreApplicationStopFailures' flag to true.
B.Configure a load balancer for the Auto Scaling group.
C.Use an 'AllAtOnce' deployment configuration.
D.Configure health checks on the load balancer.
E.Install the CodeDeploy agent on each instance.
AnswersB, D

Configuring a load balancer for the Auto Scaling group is crucial for achieving zero-downtime deployments. A load balancer, such as an Application Load Balancer (ALB), can gracefully drain connections from instances being updated, ensuring active user sessions are not abruptly terminated. It then reroutes traffic to healthy, available instances, and only directs new traffic to instances once the updated application is fully deployed and passes health checks, thereby maintaining continuous service availability during the deployment process.

Why this answer

Registering the Auto Scaling group with a load balancer allows CodeDeploy to deregister each instance before deployment and re-register it after the new application version is installed and passes health checks. This ensures traffic is shifted away from the instance being updated, preventing downtime during a 'OneAtATime' deployment.

Exam trap

The trap here is that candidates often think setting 'IgnoreApplicationStopFailures' or using 'AllAtOnce' can achieve zero downtime, but without a load balancer and health checks, traffic cannot be shifted away from instances during deployment.

Practice this question →
154
Multi-Selectmedium

Which THREE steps should a developer include in a CI/CD pipeline to deploy a serverless application using AWS SAM? (Choose three.)

Select 3 answers
A.Run 'sam build' to prepare the application
B.Manually configure API Gateway stages
C.Run 'sam deploy' to create or update the CloudFormation stack
D.Run 'aws lambda update-alias' to shift traffic
E.Run 'sam package' to upload artifacts to S3
AnswersA, C, E

Correct. `sam build` is the first step in a SAM-based CI/CD pipeline. It compiles your source code, installs dependencies listed in `requirements.txt`, `package.json`, or similar manifests, and stages the runnable code under `.aws-sam/build`. It also rewrites the AWS SAM template to replace local artifact paths with the built-artifact locations, so downstream commands have a reproducible deployable bundle to consume.

Why this answer

In a typical SAM CI/CD pipeline, the three essential steps are: (A) running 'sam build' to prepare the application, (E) running 'sam package' to upload the build artifacts to an S3 bucket, and (C) running 'sam deploy' to create or update the CloudFormation stack. Option B is incorrect because manually configuring API Gateway stages is not a standard automated step in a CI/CD pipeline; SAM manages API Gateway configurations as part of the deployment. Option D is incorrect because 'aws lambda update-alias' is not a typical step in a SAM deployment; traffic shifting can be handled via SAM's deployment preferences.

Practice this question →
155
MCQmedium

A company uses AWS OpsWorks for configuration management. They have a stack with multiple layers. They want to deploy a new application version to the application layer using rolling updates. What is the correct way to achieve this?

A.Update the custom cookbook and run the 'setup' command on the layer.
B.Clone the stack and then delete the old stack.
C.Update the app with the new version and run the 'deploy' command on the stack.
D.Modify the Auto Scaling group to launch new instances with the updated app.
AnswerC

The correct procedure involves updating the application definition within the AWS OpsWorks stack to point to the new version's source, such as a new Git commit or S3 object. Subsequently, executing the 'deploy' command on the stack or a specific layer triggers the 'deploy' lifecycle event across all instances. This command instructs OpsWorks to pull the updated application code and run the associated deployment recipes, ensuring the new version is installed and services are restarted as configured.

Why this answer

In AWS OpsWorks, deploying a new application version to a layer is done by updating the app configuration with the new version and then running the 'deploy' command on the stack. This command triggers the built-in Chef deploy recipes on the layer's instances, performing a rolling update that installs the new application version while minimizing downtime. The 'deploy' lifecycle event is specifically designed for application deployment, unlike 'setup' which configures the instance's initial state.

Exam trap

The trap here is confusing the 'setup' lifecycle event (used for initial configuration) with the 'deploy' lifecycle event (used for application deployment), leading candidates to incorrectly choose Option A instead of C.

How to eliminate wrong answers

Option A is wrong because the 'setup' command runs the setup lifecycle event, which configures the instance's packages, dependencies, and custom cookbooks, but it does not deploy application code; deploying a new app version requires the 'deploy' command. Option B is wrong because cloning the stack and deleting the old stack is an unnecessarily disruptive and manual process that does not achieve a rolling update; OpsWorks supports in-place rolling updates via the 'deploy' command without stack recreation. Option D is wrong because modifying the Auto Scaling group to launch new instances with an updated app bypasses OpsWorks's deployment lifecycle and does not perform a controlled rolling update; it would replace instances without the orchestrated 'deploy' recipes that handle application-specific tasks like database migrations or cache clearing.

Practice this question →
156
MCQhard

A developer is using AWS CodeDeploy with a blue/green deployment strategy to update an application running on Amazon ECS with the Fargate launch type. After the new (green) task set is created and traffic is shifted to it, users immediately report errors when trying to write data. The developer discovers that the green task set is connecting to a different database than the blue task set. The database endpoints are configured in the ECS task definition. What is the simplest way to prevent this issue in future deployments?

A.Modify the blue/green deployment configuration to use the same database endpoint for both task sets by updating the environment variables in the task definition before deployment.
B.Create two separate Amazon RDS databases and use an Amazon Route 53 weighted routing policy to distribute traffic.
C.Use an Application Load Balancer (ALB) with stickiness to route each user to the correct task set.
D.Use AWS CloudFormation to create a new database stack for each deployment and update the task definition dynamically.
AnswerA

During an AWS CodeDeploy blue/green deployment, both the existing (blue) and new (green) application versions must access the same persistent data store to maintain data consistency. By updating environment variables within the ECS task definition, such as `DATABASE_ENDPOINT`, before deployment, both task sets can be configured to point to the single, shared database instance. This approach avoids data migration complexities and ensures a seamless transition without modifying the container image itself, making it the most straightforward and efficient solution for database connectivity.

Why this answer

The issue stems from the green task set using a different database endpoint than the blue task set, which is configured via environment variables in the ECS task definition. By updating the task definition to use the same database endpoint before deployment, both task sets will connect to the same database, ensuring consistency during the traffic shift. This is the simplest fix as it requires no additional infrastructure or complex routing changes.

Exam trap

The trap here is that candidates may think the issue is about traffic routing or session persistence (options B or C), rather than recognizing that the root cause is a configuration mismatch in the task definition environment variables, which is a common oversight in blue/green deployments.

How to eliminate wrong answers

Option B is wrong because creating two separate RDS databases and using Route 53 weighted routing would introduce data inconsistency and complexity, as users would write to different databases, defeating the purpose of a single application state. Option C is wrong because using an ALB with stickiness would route users to either the blue or green task set based on session affinity, but it does not address the root cause of different database endpoints; the task sets would still connect to different databases, causing data fragmentation. Option D is wrong because using CloudFormation to create a new database stack for each deployment is overly complex and unnecessary; it would require managing multiple databases and updating the task definition dynamically, which is not the simplest solution and could lead to data loss or inconsistency.

Practice this question →
157
MCQhard

A developer is deploying a serverless application using AWS SAM. The application consists of multiple Lambda functions and an API Gateway REST API. The developer needs to ensure that the API Gateway endpoint is created before the Lambda functions are deployed, because the functions need the endpoint URL as an environment variable. How should the developer configure the SAM template?

A.Separate the deployment into two stacks: first deploy API Gateway, then deploy Lambda functions
B.Add a DependsOn clause to each Lambda function resource to wait for the API Gateway resource
C.Define the Lambda functions to use the ServerlessRestApi implicit API and reference the API's output in the function's environment variables
D.Use a custom resource in CloudFormation to create the API Gateway endpoint before Lambda functions
AnswerC

Defining Lambda functions to use the `ServerlessRestApi` implicit API within the AWS Serverless Application Model (SAM) template is the recommended and most efficient approach. SAM automatically provisions and configures the API Gateway and integrates it with the Lambda functions, establishing all necessary permissions and dependencies. Referencing the API's output, such as its endpoint URL, in the function's environment variables provides a clean and dynamic way for the Lambda function to interact with its associated API at runtime, ensuring correct configuration.

Why this answer

AWS SAM automatically creates an implicit API Gateway REST API (logical ID `ServerlessRestApi`) when you define an `AWS::Serverless::Api` or use the `Events` property on a function. You can reference its endpoint URL using the `Fn::Sub` intrinsic function with the `ServerlessRestApi` logical ID, such as `!Sub 'https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/${Stage}'`. This ensures the API Gateway resource is created before the Lambda functions that reference it, as CloudFormation resolves dependencies through intrinsic function references.

Exam trap

The trap here is that candidates may think `DependsOn` is sufficient to pass the endpoint URL, but it only orders creation and does not inject the URL into environment variables, which requires an intrinsic function reference like `Fn::Sub` or `Fn::GetAtt`.

How to eliminate wrong answers

Option A is wrong because separating into two stacks introduces unnecessary complexity and cross-stack output references, which is not required when SAM can handle the dependency within a single stack. Option B is wrong because `DependsOn` only ensures resource creation order but does not provide the endpoint URL as an environment variable; the developer still needs to reference the API Gateway output, and `DependsOn` alone does not pass the URL. Option D is wrong because using a custom resource to create the API Gateway endpoint is over-engineered and redundant; SAM already provides a built-in implicit API resource that handles creation and dependency resolution automatically.

Practice this question →
158
MCQhard

A developer needs to deploy a serverless application using AWS CloudFormation. The application includes an AWS Lambda function, an Amazon API Gateway REST API, and an Amazon DynamoDB table. The developer wants to create a stack that can be updated without downtime. Which CloudFormation feature should be used?

A.Drift detection
B.StackSets
C.Nested stacks
D.Change Sets
AnswerD

AWS CloudFormation Change Sets provide a powerful mechanism to preview the proposed changes to your stack before they are actually applied. By generating a Change Set, developers can review exactly which resources will be added, modified, or deleted, and understand the potential impact on existing resources. This foresight is crucial for planning updates that minimize or eliminate downtime, allowing for adjustments to the template or deployment strategy to ensure continuous service availability.

Why this answer

Change Sets allow you to preview how changes to your CloudFormation stack will affect your running resources before you apply them. By reviewing the change set, you can ensure that the update does not cause downtime, for example by replacing resources without interruptions. This makes Change Sets the appropriate feature for updating a stack without downtime.

Practice this question →
159
MCQhard

A developer is deploying a microservices architecture on Amazon ECS. The services need to communicate with each other securely. The developer wants to use service discovery and ensure that traffic between services is encrypted. Which combination of services should the developer use?

A.Use AWS Cloud Map for service discovery and AWS App Mesh with mutual TLS
B.Use Amazon API Gateway and AWS Lambda
C.Use Amazon Route 53 private hosted zones and enable DNSSEC
D.Use an Application Load Balancer for each service and enable TLS termination
AnswerA

AWS Cloud Map provides robust service discovery, allowing microservices to dynamically locate each other using either DNS queries or an API. When combined with AWS App Mesh, a service mesh solution, it enables advanced traffic management and security features. App Mesh facilitates mutual TLS (mTLS) between services by injecting Envoy proxies, ensuring that both the client and server services authenticate each other with certificates, thus securing inter-service communication at the transport layer without requiring application code changes. This combination is the most suitable for secure, dynamic microservice interactions.

Why this answer

AWS Cloud Map provides service discovery by registering ECS service instances with DNS-based or API-based resolution, enabling dynamic routing between microservices. AWS App Mesh with mutual TLS (mTLS) encrypts traffic between services and enforces identity-based authentication, ensuring end-to-end encryption and secure communication. This combination directly addresses the requirements for service discovery and encrypted traffic.

Exam trap

The trap here is that candidates often confuse TLS termination at a load balancer (which only encrypts traffic from client to ALB) with mutual TLS between services, or assume DNS-based discovery alone (like Route 53) provides encryption, when it does not.

How to eliminate wrong answers

Option B is wrong because Amazon API Gateway and AWS Lambda are typically used for building serverless APIs, not for service-to-service communication within a microservices architecture on ECS; they lack native service discovery and mTLS encryption between ECS tasks. Option C is wrong because Route 53 private hosted zones provide DNS-based service discovery but DNSSEC only validates DNS responses, it does not encrypt traffic between services. Option D is wrong because an Application Load Balancer (ALB) terminates TLS at the load balancer, not between services, and does not provide service discovery or mTLS for inter-service communication.

Practice this question →
160
MCQmedium

A company uses AWS CodePipeline to deploy a Node.js application to AWS Elastic Beanstalk. The build stage runs successfully, but the deploy stage fails with an error: 'The deployment failed because no instances were found for the environment.' What is the most likely cause?

A.The CodeDeploy application is not configured correctly.
B.The IAM role for CodePipeline lacks permissions to describe EC2 instances.
C.The build artifact is not named correctly for Elastic Beanstalk.
D.The Elastic Beanstalk environment has no running instances due to a failed health check.
AnswerD

If an Elastic Beanstalk environment's instances consistently fail health checks (e.g., application not responding on the configured port, high resource utilization), the underlying Auto Scaling group will terminate them. If new instances launched by Auto Scaling also fail to become healthy, the environment can enter a degraded state with zero healthy, running instances. In this scenario, when CodePipeline attempts to deploy a new application version, it correctly reports "no instances found" because there are no available, healthy targets to receive the deployment.

Why this answer

The error 'no instances were found for the environment' directly indicates that the Elastic Beanstalk environment has no running EC2 instances. This typically occurs when the environment's health checks have failed, causing all instances to be terminated or remain in a degraded state. Without any healthy instances, CodePipeline cannot deploy the application, as Elastic Beanstalk requires at least one running instance to perform a deployment.

Exam trap

The trap here is that candidates often confuse the error with a permissions or artifact issue, but the specific wording 'no instances were found' points directly to the Elastic Beanstalk environment's instance count, not to IAM roles or build outputs.

How to eliminate wrong answers

Option A is wrong because CodeDeploy is not used with Elastic Beanstalk; Elastic Beanstalk uses its own deployment mechanism (e.g., rolling updates, immutable deployments) and does not rely on a CodeDeploy application. Option B is wrong because CodePipeline does not need permissions to describe EC2 instances for an Elastic Beanstalk deployment; the pipeline interacts with Elastic Beanstalk via the CreateApplicationVersion and UpdateEnvironment APIs, not directly with EC2. Option C is wrong because the build artifact name does not affect instance availability; Elastic Beanstalk accepts any valid artifact (e.g., .zip or .war) and the error message specifically mentions missing instances, not artifact naming issues.

Practice this question →
161
MCQmedium

A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group of Amazon EC2 instances. 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.' The developer needs to identify the root cause. Which AWS service should the developer use to view detailed error logs from the failed deployment?

A.Amazon CloudWatch Logs (if configured) or the CodeDeploy agent log files on the EC2 instances
B.AWS X-Ray
C.AWS CloudTrail
D.AWS CodeDeploy console
AnswerA

The CodeDeploy agent, which runs on the target EC2 instances, generates detailed logs for every step of the deployment process, including lifecycle hook script execution and file transfers. These logs are stored locally on the instance (e.g., /var/log/aws/codedeploy-agent/codedeploy-agent.log on Linux) and provide the most granular information for troubleshooting. If configured, the agent can stream these logs to Amazon CloudWatch Logs, offering a centralized and easily accessible location for analysis without requiring direct SSH access to each instance.

Why this answer

When a CodeDeploy deployment fails due to instance-level errors, the most direct way to investigate is to examine the CodeDeploy agent logs located on each EC2 instance at `/opt/codedeploy-agent/deployment-root/deployment-logs/codedeploy-agent.log`. If Amazon CloudWatch Logs has been configured to stream these logs, you can also view them centrally in the CloudWatch console. These logs contain detailed error messages from the `codedeploy-agent` process, including script failures, permission issues, or missing dependencies that caused the deployment to fail.

Exam trap

The trap here is that candidates assume the CodeDeploy console provides detailed error logs, but it only shows aggregated failure counts and high-level messages, while the actual root cause is buried in the agent logs on the EC2 instances or in CloudWatch Logs if configured.

How to eliminate wrong answers

Option B is wrong because AWS X-Ray is a distributed tracing service for analyzing and debugging request flows in microservices applications, not a log viewer for deployment errors. Option C is wrong because AWS CloudTrail records API calls made to AWS services (e.g., who triggered the deployment), but it does not capture the internal agent-level error logs from individual EC2 instances. Option D is wrong because the AWS CodeDeploy console only shows high-level deployment status and failure summaries (e.g., 'failed instances'), not the detailed per-instance error logs needed to diagnose root causes.

Practice this question →
162
MCQmedium

A developer is using AWS CodePipeline to deploy a web application. The pipeline has a source stage that pulls from CodeCommit and a deploy stage that uses AWS Elastic Beanstalk. The developer wants to run unit tests automatically before deploying to Elastic Beanstalk. Which action should the developer add to the pipeline?

A.Add a test stage that uses an AWS CodeBuild project configured to run unit tests
B.Add a manual approval step before the deploy stage
C.Configure Elastic Beanstalk health checks to run tests
D.Replace Elastic Beanstalk with AWS CodeDeploy
AnswerA

AWS CodeBuild is specifically designed to run custom build and test commands as part of a CI/CD pipeline. By integrating a CodeBuild project into a dedicated test stage within AWS CodePipeline, developers can execute unit tests, integration tests, or even security scans against their application code in a managed compute environment. This ensures that code quality and functionality are validated automatically before proceeding to deployment, catching issues early in the development lifecycle.

Why this answer

AWS CodeBuild can be integrated as a test stage in CodePipeline to run unit tests automatically. By adding a CodeBuild project configured with a buildspec.yml file that executes unit tests, the pipeline will run tests after the source stage and before the deploy stage, ensuring only code that passes tests is deployed to Elastic Beanstalk.

Exam trap

The trap here is that candidates may confuse health checks (which monitor runtime health) with unit tests (which validate code logic), or think a manual approval step can substitute for automated testing, but AWS specifically tests the understanding that CodeBuild is the service designed for running custom build and test commands in a pipeline.

How to eliminate wrong answers

Option B is wrong because a manual approval step pauses the pipeline for human review, but does not execute unit tests automatically; it only gates deployment. Option C is wrong because Elastic Beanstalk health checks monitor the environment's operational status (e.g., HTTP response codes), not run unit tests on the application code. Option D is wrong because replacing Elastic Beanstalk with CodeDeploy does not add automated testing; CodeDeploy is a deployment service, not a test runner.

Practice this question →
163
MCQeasy

A developer is using AWS CodePipeline to deploy a web application. The pipeline has stages: Source, Build, Staging Deploy, Staging Test, and Prod Deploy. The developer wants to ensure that if the Staging Test stage fails, the pipeline automatically stops and does not proceed to Prod Deploy. Which action should the developer take?

A.No action is needed; CodePipeline automatically stops on stage failure
B.Add a manual approval step before Prod Deploy
C.Disable the transition from Staging Test to Prod Deploy
D.Configure the pipeline execution mode to 'Superseded'
AnswerA

AWS CodePipeline is inherently designed to halt execution when any action within a stage fails, causing the entire stage to be marked as failed. This default behavior prevents the pipeline from automatically transitioning to subsequent stages, ensuring that faulty code or configurations do not progress further into environments like staging or production. Therefore, no explicit configuration is needed to stop the pipeline on stage failure; it is a built-in safety mechanism.

Why this answer

AWS CodePipeline's default behavior is to stop execution when a stage fails, preventing the pipeline from proceeding to subsequent stages. When the Staging Test stage fails, the pipeline transitions to a 'Failed' status and does not automatically continue to Prod Deploy. No additional configuration is required for this behavior.

Exam trap

The trap here is that candidates may overthink the solution and assume additional configuration is needed, when in fact CodePipeline's default behavior already stops on stage failure, making options like manual approval or disabling transitions unnecessary.

How to eliminate wrong answers

Option B is wrong because adding a manual approval step before Prod Deploy would require human intervention to proceed, but it does not automatically stop the pipeline on Staging Test failure; the pipeline would still wait for approval even if the test failed, which is not the desired behavior. Option C is wrong because disabling the transition from Staging Test to Prod Deploy would prevent any execution to Prod Deploy, even if the Staging Test stage succeeds, which is overly restrictive and not conditional on failure. Option D is wrong because configuring the pipeline execution mode to 'Superseded' controls how multiple pipeline executions are handled (e.g., canceling a running execution when a new one starts), not how the pipeline responds to stage failures.

Practice this question →
164
MCQeasy

A development team wants to automatically deploy a web application to Amazon EC2 instances when new code is pushed to the master branch of an AWS CodeCommit repository. Which AWS service should the team use to orchestrate the build, test, and deployment phases?

A.AWS CloudFormation
B.AWS CodeBuild
C.AWS CodePipeline
D.AWS CodeDeploy
AnswerC

AWS CodePipeline is a fully managed continuous delivery service that automates release pipelines for rapid and reliable application and infrastructure updates. It orchestrates the entire CI/CD workflow, seamlessly integrating with various AWS services like CodeCommit for source, CodeBuild for build and test, and CodeDeploy for deployment. This comprehensive orchestration capability makes it the ideal choice for automatically deploying a web application through a defined, multi-stage pipeline.

Why this answer

AWS CodePipeline is the correct service because it is a fully managed continuous delivery service that orchestrates the entire build, test, and deployment phases as a pipeline. It can be configured to automatically trigger on code pushes to the master branch of an AWS CodeCommit repository, then invoke AWS CodeBuild for building and testing, and finally deploy to EC2 instances via AWS CodeDeploy, providing end-to-end automation.

Exam trap

The trap here is that candidates often confuse AWS CodeBuild with CodePipeline because both can be triggered by CodeCommit pushes, but CodeBuild alone cannot orchestrate multiple sequential phases like testing and deployment, which is the key requirement in the question.

How to eliminate wrong answers

Option A is wrong because AWS CloudFormation is an infrastructure-as-code service for provisioning and managing AWS resources, not for orchestrating build, test, and deployment phases triggered by code pushes. Option B is wrong because AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces software packages, but it does not orchestrate the entire pipeline or trigger on repository events by itself. Option D is wrong because AWS CodeDeploy is a deployment service that automates application deployments to EC2 instances or other compute services, but it does not handle the build or test phases or orchestrate a multi-stage pipeline.

Practice this question →
165
Multi-Selecthard

A company is deploying a microservices architecture using AWS Lambda and Amazon API Gateway. The developer wants to implement a canary release deployment for the API. Which THREE steps should the developer take? (Choose THREE.)

Select 3 answers
A.Configure stage variables to point the canary stage to a different Lambda function alias.
B.Enable canary by setting the traffic percentage in the API Gateway stage.
C.Use API Gateway canary release settings to create a canary stage.
D.Use Amazon CloudFront to distribute traffic between two API Gateway stages.
E.Use Lambda canary releases to gradually shift traffic.
AnswersA, B, C

Configuring stage variables within the API Gateway canary stage is the precise mechanism to direct a portion of incoming requests to a specific Lambda function alias, representing the new version of the backend service. This allows the canary stage to dynamically resolve the target Lambda version, ensuring that only the designated traffic percentage interacts with the updated code. It's fundamental for separating the base deployment from the experimental one.

Why this answer

Stage variables in API Gateway can be configured to point the canary stage to a different Lambda function alias, enabling the canary to invoke a separate version of the function for testing. This allows the canary to route a percentage of traffic to a new Lambda version while the main stage continues using the stable alias, supporting gradual rollouts.

Exam trap

The trap here is that candidates may confuse Lambda alias weighted routing (Option E) with API Gateway canary releases, but the question explicitly asks for API-level canary deployment, which requires API Gateway's native canary settings, not just Lambda-level traffic shifting.

Practice this question →
166
MCQeasy

A developer is deploying a Docker container to Amazon ECS using the Fargate launch type. The developer wants to ensure the container has access to an Amazon RDS database. What is the best way to securely pass the database credentials to the container?

A.Pass the credentials as plain text environment variables in the task definition.
B.Store the credentials in an Amazon S3 bucket and download them at container startup.
C.Store the credentials in the container image as environment variables.
D.Use AWS Systems Manager Parameter Store or AWS Secrets Manager to store the credentials and reference them in the task definition.
AnswerD

Utilizing AWS Systems Manager Parameter Store or AWS Secrets Manager for credential storage is the recommended secure practice for Amazon ECS. Both services encrypt secrets at rest and in transit, provide robust IAM-based access control, and integrate seamlessly with ECS task definitions to inject secrets at runtime. This method ensures credentials are never exposed in plain text within the task definition or container image, leveraging the task's IAM role for secure, on-demand retrieval and supporting features like automatic rotation with Secrets Manager.

Why this answer

AWS Systems Manager Parameter Store and AWS Secrets Manager are designed to securely store and manage sensitive information like database credentials. In Amazon ECS with Fargate, you can reference these secrets directly in the task definition using the 'secrets' parameter, which injects them as environment variables at runtime without exposing them in plain text or requiring additional code to fetch them. This approach adheres to the principle of least privilege and integrates natively with IAM roles for secure access.

Exam trap

The trap here is that candidates may think environment variables are inherently secure or that storing credentials in S3 is a safe alternative, overlooking the native integration and security guarantees of AWS Secrets Manager and Parameter Store for ECS tasks.

How to eliminate wrong answers

Option A is wrong because passing credentials as plain text environment variables in the task definition exposes them in the ECS console, API responses, and logs, violating security best practices. Option B is wrong because downloading credentials from an S3 bucket at container startup requires storing AWS access keys in the container or granting broad S3 permissions, and the credentials could be exposed in transit or logs; it also adds unnecessary complexity and latency. Option C is wrong because embedding credentials in the container image as environment variables makes them accessible to anyone with access to the image registry and prevents rotation without rebuilding the image, violating immutable infrastructure principles.

Practice this question →
167
MCQmedium

A team uses AWS CodeCommit for source control and wants to automatically trigger a build and deployment when code is pushed to the master branch. Which AWS service should be used to create this automation?

A.AWS CodeBuild
B.AWS CodePipeline
C.AWS Lambda
D.AWS CodeDeploy
AnswerB

AWS CodePipeline is a fully managed continuous delivery service that automates release pipelines for fast and reliable application and infrastructure updates. It seamlessly integrates with AWS CodeCommit as a primary source stage, automatically detecting code changes (e.g., pushes to a specific branch) and initiating the entire pipeline workflow. CodePipeline orchestrates subsequent stages like build, test, and deploy using other AWS services, making it the ideal choice for end-to-end CI/CD.

Why this answer

AWS CodePipeline is the correct service because it is a fully managed continuous delivery service that can be configured to automatically start a pipeline execution when a change is pushed to a specific branch in AWS CodeCommit. By setting the source stage to the CodeCommit repository and master branch, CodePipeline triggers subsequent build and deploy actions without manual intervention, enabling a complete CI/CD workflow.

Exam trap

The trap here is that candidates confuse individual services (CodeBuild for building, CodeDeploy for deploying) with the orchestration service (CodePipeline) needed to chain them together in response to a source code event.

How to eliminate wrong answers

Option A is wrong because AWS CodeBuild is a build service that compiles source code and runs tests, but it does not have native event-driven triggers to automatically start on a CodeCommit push; it requires an external trigger like CodePipeline or a webhook. Option C is wrong because AWS Lambda can be used to react to CodeCommit events via CloudWatch Events or SNS, but it is not a purpose-built CI/CD service and would require custom code to orchestrate build and deployment steps, making it less suitable than CodePipeline. Option D is wrong because AWS CodeDeploy is a deployment service that automates application deployments to compute services like EC2 or Lambda, but it cannot directly listen to CodeCommit push events or orchestrate a build step; it relies on a pipeline or other trigger to initiate deployments.

Practice this question →
168
MCQmedium

A developer is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment fails during the 'BeforeInstall' lifecycle event. Which file should the developer check to debug the failure?

A.index.js
B.appspec.yml
C.taskdef.json
D.buildspec.yml
AnswerB

The appspec.yml file is central to AWS CodeDeploy, serving as the deployment specification. It explicitly defines the source files to be deployed, their destination on the target instance, and, critically, the lifecycle event hooks. Within these hooks, the appspec.yml specifies which scripts CodeDeploy should execute at each stage, such as BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. Failures during these script executions directly manifest as lifecycle hook failures, making appspec.yml the primary configuration for managing deployment scripts and their outcomes.

Why this answer

The 'BeforeInstall' lifecycle event in AWS CodeDeploy is a hook defined in the appspec.yml file. This file specifies the deployment lifecycle hooks, including scripts to run before installation. When a deployment fails during this event, the appspec.yml is the primary file to inspect for misconfigured scripts, incorrect permissions, or missing script paths.

Exam trap

The trap here is that candidates confuse the deployment configuration file (appspec.yml) with build configuration files (buildspec.yml) or application code files (index.js), leading them to check the wrong file for deployment lifecycle failures.

How to eliminate wrong answers

Option A is wrong because index.js is a JavaScript application file, not a deployment configuration file; CodeDeploy does not read index.js for lifecycle events. Option C is wrong because taskdef.json is used by Amazon ECS to define task definitions, not by CodeDeploy for EC2/on-premises deployments. Option D is wrong because buildspec.yml is used by AWS CodeBuild to define build commands, not by CodeDeploy for deployment lifecycle hooks.

Practice this question →
169
MCQhard

A developer is using AWS Elastic Beanstalk to deploy a Node.js application. The developer wants to run a custom script to set environment variables before the application starts. Which configuration file and location should the developer use?

A.Add a configuration file in the .ebextensions directory that uses container_commands.
B.Add a Procfile to the application root.
C.Place a shell script in the .ebextensions/scripts directory.
D.Add a cron.yaml file to the .ebextensions directory.
AnswerA

Elastic Beanstalk configuration files placed in the `.ebextensions` directory provide a robust mechanism for customizing the environment. `container_commands` are specifically designed to execute custom commands on the EC2 instances after the application source code has been deployed and dependencies installed, but critically, before the application server starts processing requests. This execution phase makes them ideal for running custom scripts, performing database migrations, or setting up application-specific configurations that depend on the deployed code.

Why this answer

`.ebextensions` configuration files with `container_commands` allow you to run custom commands before the application starts. `container_commands` execute after the application and web server have been set up but before the application is deployed, making them ideal for setting environment variables or running setup scripts. The files must be in YAML or JSON format and placed in the `.ebextensions` directory at the root of your source bundle.

Exam trap

The trap here is that candidates confuse `container_commands` with `commands` (which run before the application setup) or assume a Procfile is used in Elastic Beanstalk, when in fact Elastic Beanstalk uses platform-specific hooks like `.platform/hooks/prebuild` or `.ebextensions` for custom scripts.

How to eliminate wrong answers

Option B is wrong because a Procfile is used by Heroku, not AWS Elastic Beanstalk; Elastic Beanstalk uses its own platform hooks and configuration files. Option C is wrong because placing a shell script in `.ebextensions/scripts` is not a recognized configuration method; Elastic Beanstalk does not automatically execute scripts from that path. Option D is wrong because `cron.yaml` is used for periodic tasks (cron jobs) in Elastic Beanstalk worker environments, not for running pre-deployment setup scripts.

Practice this question →
← PreviousPage 3 of 3 · 169 questions total

Ready to test yourself?

Try a timed practice session using only Deployment questions.

Start 20-question session