Courseiva

CCNA SDLC Automation Questions

74 questions · SDLC Automation · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

A company runs a critical e-commerce application on AWS. They use AWS CodePipeline to manage deployments. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (CodeDeploy to an Auto Scaling group). Recently, a deployment caused a 5-minute outage because the new application version had a bug that caused the health checks to fail. The Auto Scaling group marked instances as unhealthy and replaced them, but during the replacement, traffic was routed to the remaining instances, which also failed health checks, causing a full outage. The company wants to implement a deployment strategy that prevents any traffic from being routed to unhealthy instances and automatically rolls back if the deployment fails. They also want to minimize deployment time and cost. Which solution should the DevOps team implement?

A.Add a manual approval step in CodePipeline before deploy
B.Use CodeDeploy in-place deployment with automatic rollback enabled
C.Use CodeDeploy blue/green deployment with automatic rollback enabled
D.Increase the health check grace period in the Auto Scaling group
AnswerC

Blue/green creates a new environment, tests it, and shifts traffic only if healthy; rollback is automatic

Why this answer

The correct solution is to use a blue/green deployment with CodeDeploy and automatic rollback enabled. In a blue/green deployment, a new Auto Scaling group (green) is created alongside the existing one (blue). Traffic is shifted to the green group only after all health checks pass.

If health checks fail, the deployment is automatically rolled back by terminating the green group, ensuring no traffic is routed to unhealthy instances. This prevents any outage. Option B (in-place deployment with rollback) updates instances in place, which can cause downtime if instances fail health checks, as the Auto Scaling group replaces them sequentially, potentially routing traffic to unhealthy instances.

Option A (manual approval) slows down deployment and does not automate rollback based on health checks. Option D (increasing health check grace period) only delays detection of failures and does not prevent traffic from being routed to unhealthy instances.

Practice this question →
2
MCQmedium

A company is using AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The deployment configuration uses a linear traffic shifting with a 10-minute interval. The application logs show that the new version of the application crashes on startup. What is the MOST effective way to handle this situation to ensure successful future deployments?

A.Increase the interval in the linear traffic shifting to 30 minutes to allow more time for instances to stabilize.
B.Configure the deployment to automatically roll back when a failure occurs and ignore the error.
C.Switch to a blue/green deployment strategy to minimize the impact on existing instances.
D.Add a script in the AppSpec file's 'Validate Service' lifecycle hook to check the application health and fail the deployment if the application does not start successfully.
AnswerD

Adding a script to the ValidateService lifecycle hook is the correct solution because this hook executes after ApplicationStart and is designed to verify application readiness. When the script detects that the application did not start successfully—for example, it curls a local endpoint or checks the listening port—it returns a nonzero exit code, causing CodeDeploy to fail the deployment immediately. This check ensures unhealthy instances are identified before any production traffic is shifted, preventing user-facing outages and allowing you to fix the root cause.

Why this answer

The 'Validate Service' lifecycle hook in the AppSpec file runs after the application is installed and started, allowing you to execute a custom script that verifies the application is healthy. If the script detects that the new version crashes on startup, it can return a non-zero exit code, which causes CodeDeploy to mark that instance as failed and trigger the deployment failure. This provides an early, automated validation that prevents the deployment from proceeding with a broken application, directly addressing the root cause of the crash.

Exam trap

The trap here is that candidates often confuse recovery mechanisms (like rollback or blue/green) with prevention mechanisms, failing to realize that the most effective solution is to catch the failure early using the ValidateService lifecycle hook, which directly validates application health before traffic is shifted.

How to eliminate wrong answers

Option A is wrong because increasing the linear traffic shifting interval to 30 minutes does not fix the underlying issue of the application crashing on startup; it only delays the inevitable failure and wastes time. Option B is wrong because configuring automatic rollback is a recovery mechanism, not a prevention strategy, and ignoring the error would mask the problem, leading to repeated failures without addressing the root cause. Option C is wrong because switching to a blue/green deployment strategy does not prevent the new application version from crashing; it only isolates the impact on existing instances, but the deployment would still fail if the new version is broken.

Practice this question →
3
MCQmedium

Refer to the exhibit. A DevOps engineer ran the above AWS CLI command after a CloudFormation stack update. What does the status 'ROLLBACK_COMPLETE' indicate?

A.The stack update is in progress.
B.The stack was deleted successfully.
C.The stack was created successfully.
D.The stack update failed and CloudFormation reverted to the previous stack.
AnswerD

When an update operation fails, CloudFormation automatically initiates a rollback to the stack's previous template and resources, and ROLLBACK_COMPLETE is the final state after that restoration finishes. The stack is still present and functional from its prior state, but the attempted changes were discarded. This is the only status in the output that matches both the 'update' command and the terminal rollback outcome, so it directly confirms a failed update followed by a rollback.

Why this answer

The 'ROLLBACK_COMPLETE' status indicates that the CloudFormation stack update operation failed, and CloudFormation automatically reverted the stack to its previous stable state. This is a built-in safety mechanism: if any resource fails to update, CloudFormation triggers a rollback to undo all changes made during the update, ensuring the stack returns to its last known good configuration.

Exam trap

The trap here is that candidates confuse 'ROLLBACK_COMPLETE' with a successful operation or a deletion, when in fact it specifically means the update failed and the stack was reverted to its prior state.

How to eliminate wrong answers

Option A is wrong because 'ROLLBACK_COMPLETE' is a terminal state, not an in-progress state; an update in progress would show 'UPDATE_IN_PROGRESS' or 'UPDATE_ROLLBACK_IN_PROGRESS'. Option B is wrong because a successful deletion would show 'DELETE_COMPLETE', not 'ROLLBACK_COMPLETE'. Option C is wrong because a successful creation would show 'CREATE_COMPLETE', not 'ROLLBACK_COMPLETE'.

Practice this question →
4
MCQhard

A team uses AWS CodePipeline with multiple stages: Source, Build, Test, and Deploy. The Test stage runs integration tests against a staging environment. Occasionally, the tests fail due to environment issues, not code issues. The team wants to automatically retry the Test stage up to two times if it fails, but not the Deploy stage. How can this be achieved?

A.Create a CloudWatch Events rule that triggers a Lambda function to retry the failed stage.
B.Configure the Retry setting in the Test stage's action configuration.
C.Enable the 'Retry on failure' option in the CodePipeline pipeline settings.
D.Use AWS Step Functions to orchestrate the pipeline and implement retries.
AnswerA

This is correct because CodePipeline emits Amazon CloudWatch Events/EventBridge events on stage state changes, including a 'FAILED' state for a stage. A rule can filter for `detail-type: 'CodePipeline Stage Execution State Change'` with `detail.state: 'FAILED'` and trigger a Lambda function that invokes the `RetryStageExecution` API, passing the `pipelineExecutionId` and `stageName` from the event. This automates the same retry a user would otherwise click, and can include backoff logic or retry counts within the Lambda handler.

Why this answer

The correct approach is to use Amazon EventBridge (formerly CloudWatch Events) to detect a stage failure in CodePipeline and trigger an AWS Lambda function that calls the RetryStageExecution API. This provides automatic retries without manual intervention. CodePipeline's built-in retry setting on a stage action is not automatic; it only allows manual retries via the console or API.

Option D (Step Functions) is a valid alternative but adds unnecessary complexity for this use case.

Exam trap

The trap is that candidates may mistakenly believe CodePipeline supports automatic per-stage retries through a built-in configuration, when in fact the retry setting only enables manual retries. Automatic retries require external services like EventBridge and Lambda.

How to eliminate wrong answers

Option A is wrong because creating a CloudWatch Events rule to trigger a Lambda function for retrying a failed stage is overly complex and not the native solution; CodePipeline already provides built-in retry capabilities at the stage level. Option C is wrong because there is no global 'Retry on failure' option in CodePipeline pipeline settings; retries must be configured per stage action, not pipeline-wide. Option D is wrong because using AWS Step Functions to orchestrate the pipeline and implement retries would add unnecessary complexity and cost, as CodePipeline natively supports stage-level retries without external orchestration.

Practice this question →
5
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 application is deployed to the instances using an in-place deployment. The instances are running Amazon Linux 2. What should the DevOps engineer check first?

A.Check the security group rules for the EC2 instances.
B.Check the application's port availability.
C.Verify that the AWS CodeDeploy agent is installed and running on each EC2 instance.
D.Verify that the IAM instance profile associated with the instances has the correct permissions.
AnswerC

Without the agent, the instance cannot receive deployment instructions.

Why this answer

The error message indicates that individual instances failed deployment, which is most commonly caused by the AWS CodeDeploy agent not running or not being installed on the EC2 instances. For an in-place deployment on Amazon Linux 2, the CodeDeploy agent must be installed and actively running to receive and execute deployment commands from the CodeDeploy service. If the agent is missing or stopped, the instance cannot participate in the deployment, leading to the 'too many individual instances failed' error.

Exam trap

The trap here is that candidates often jump to IAM permissions (Option D) as the first troubleshooting step, but the error message's reference to 'individual instances failed' directly points to the agent not running on the instances, which is a more immediate and common cause than permission issues.

How to eliminate wrong answers

Option A is wrong because security group rules control network traffic to/from the instances, but they do not affect the CodeDeploy agent's ability to communicate with the service or execute deployment scripts; the agent uses HTTPS outbound to the CodeDeploy endpoints, which is typically allowed by default. Option B is wrong because port availability relates to the application's ability to serve traffic after deployment, not to the deployment process itself; the error occurs during deployment, not after the application starts. Option D is wrong because while the IAM instance profile must have correct permissions for the agent to call CodeDeploy APIs, the error message specifically points to individual instance failures, which is more directly tied to the agent's presence and operational status; incorrect permissions would typically cause a different error (e.g., 'AccessDeniedException') rather than a generic instance failure.

Practice this question →
6
MCQmedium

An organization uses AWS CodePipeline with multiple stages: Source, Build, Test, and Deploy. The Test stage runs integration tests in CodeBuild. Recently, the pipeline failed because the Test stage took longer than expected, causing a pipeline execution timeout. The pipeline has a default timeout of 7 days. What is the MOST efficient way to set a maximum execution time for the Test stage without affecting other stages?

A.Create an AWS Lambda function that stops the pipeline if the Test stage exceeds 1 hour.
B.Set the pipeline execution timeout to 1 hour in the pipeline settings.
C.Use Amazon CloudWatch Events to detect when the Test stage runs for more than 1 hour and then stop the pipeline.
D.Modify the CodeBuild project's build timeout (e.g., 1 hour) in the buildspec or project configuration.
AnswerD

In the CodeBuild project configuration (or in the buildspec's timeout-in-minutes field), you can set a build timeout that applies specifically to the build used by the Test stage. When the build exceeds the configured timeout, CodeBuild automatically stops the build and the pipeline transitions to Failed, giving a proactive, stage-scoped limit without affecting the Deploy stage. This is the recommended way to prevent a test job from hanging indefinitely because the timeout is enforced by CodeBuild's execution manager.

Why this answer

The CodeBuild project's build timeout setting directly controls the maximum duration a build can run before it is stopped. By setting this timeout to 1 hour in the CodeBuild project configuration or buildspec, the Test stage will automatically fail if it exceeds that limit, without affecting the pipeline's overall timeout or other stages. This is the most efficient and targeted approach, as it leverages a native CodeBuild feature rather than adding external monitoring or changing pipeline-wide settings.

Exam trap

The trap here is that candidates may confuse the pipeline-level execution timeout with stage-level or action-level timeouts, assuming that adjusting the pipeline timeout is the correct way to limit a specific stage, when in fact CodeBuild's own timeout is the precise and efficient mechanism for controlling build duration.

How to eliminate wrong answers

Option A is wrong because creating an AWS Lambda function to stop the pipeline adds unnecessary complexity, cost, and maintenance overhead; it is not the most efficient solution when a native CodeBuild timeout exists. Option B is wrong because setting the pipeline execution timeout to 1 hour applies to the entire pipeline, not just the Test stage, which would cause the entire pipeline to fail if any stage (e.g., Source, Build, or Deploy) takes longer than 1 hour, even if they are functioning correctly. Option C is wrong because using Amazon CloudWatch Events to detect a long-running Test stage and stop the pipeline introduces additional latency, complexity, and potential race conditions; it is less efficient than directly configuring the CodeBuild project's timeout.

Practice this question →
7
Multi-Selecteasy

A company is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment is failing because the new instances are not passing the health checks. The team wants to automatically roll back the deployment if health checks fail. Which THREE steps should the team take?

Select 3 answers
A.Use a deployment configuration with a high minimum healthy host percentage.
B.Create a CloudWatch alarm based on the ELB health check metric.
C.Configure the deployment group to automatically roll back when a deployment fails.
D.Configure the Auto Scaling group to use an ELB health check with a sufficient grace period.
E.Store the deployment artifacts in an S3 bucket with versioning enabled.
AnswersB, C, D

Correct: Alarm can trigger rollback.

Why this answer

Creating a CloudWatch alarm based on the ELB health check metric allows you to monitor the health of instances in the Auto Scaling group. When the alarm triggers due to failed health checks, it can be used in conjunction with an automatic rollback configuration to revert the deployment to the previous revision. This ensures that unhealthy instances are detected early and the deployment is rolled back automatically, minimizing downtime.

Exam trap

The trap here is that candidates often think that simply enabling automatic rollback on deployment failure (Option C) is sufficient, but they miss that you must also configure a CloudWatch alarm (Option B) to detect health check failures that occur after the deployment completes, because a deployment can succeed initially but then fail health checks later.

Practice this question →
8
MCQhard

An organization uses AWS Elastic Beanstalk to deploy a web application. The deployment fails with a '502 Bad Gateway' error after the environment update. The health status shows 'Severe'. Investigation reveals that the application is not binding to the port that the nginx proxy expects. What is the most efficient way to diagnose and resolve this issue?

A.Rebuild the environment with a larger instance type to handle the load.
B.Use the Elastic Beanstalk console to update the environment's software configuration.
C.Review the application logs in CloudWatch Logs for error messages.
D.Check the application's listening port by viewing the nginx configuration files in the platform hooks and ensure the app listens on the expected port (e.g., 8080).
AnswerD

Elastic Beanstalk's nginx proxy forwards requests to the application on a specific port (usually 8080). If the app listens on a different port, it causes 502 errors.

Why this answer

The 502 Bad Gateway error in Elastic Beanstalk typically occurs when the nginx reverse proxy cannot forward requests to the application because the application is not listening on the expected port (default 8080). Checking the nginx configuration files in the platform hooks and verifying the application's listening port directly addresses the root cause, as the proxy expects the app to bind to a specific port. This is the most efficient diagnostic step because it targets the exact mismatch between the proxy and the application.

Exam trap

The trap here is that candidates assume a 502 error always indicates an application crash or resource exhaustion, leading them to check logs or scale up, rather than recognizing it as a proxy-to-application port mismatch that is best diagnosed by examining the nginx configuration and application binding.

How to eliminate wrong answers

Option A is wrong because increasing instance size addresses resource constraints (e.g., CPU/memory), not a port binding misconfiguration; a larger instance will still fail if the app doesn't listen on the expected port. Option B is wrong because updating software configuration via the console (e.g., environment properties) does not directly fix the application's listening port; the app must be coded to bind to the correct port. Option C is wrong because while CloudWatch Logs can show application errors, the most efficient first step is to check the nginx configuration and application port directly, as the 502 error is a proxy-level issue, not necessarily an application error.

Practice this question →
9
MCQmedium

A development team uses AWS CodeCommit as a source repository for their AWS CodePipeline. They want to automatically trigger a pipeline execution when a new branch is created. Which solution should they implement?

A.Create an S3 event notification to invoke the pipeline when a branch is created.
B.Use Amazon CloudWatch Events to trigger the pipeline on a CodeCommit 'Reference Created' event.
C.Configure a webhook in CodePipeline to detect branch creation events.
D.Set up a polling mechanism in CodePipeline to check for new branches every minute.
AnswerB

Amazon CloudWatch Events (now Amazon EventBridge) natively captures CodeCommit API events, including a 'Reference Created' event when a branch or tag is created. You can configure a rule that matches the repository name and reference type 'branch', then target it to the CodePipeline pipeline for automatic execution. This is the recommended push-based integration because it is serverless, near-real-time, and does not require any external endpoint or polling.

Why this answer

AWS CodePipeline can be configured to start execution automatically when a new branch is created in CodeCommit by using Amazon CloudWatch Events (now part of Amazon EventBridge) to listen for the 'Reference Created' event type. This event is emitted by CodeCommit whenever a new Git reference (such as a branch or tag) is created, and it can directly target a CodePipeline pipeline as a rule target, triggering a new execution without any custom polling or webhook setup.

Exam trap

The trap here is that candidates often confuse webhooks (which are for external Git providers) with native AWS event-driven triggers, leading them to incorrectly select Option C, or they mistakenly think S3 notifications can be used for CodeCommit events (Option A) due to a general familiarity with S3 event-driven architectures.

How to eliminate wrong answers

Option A is wrong because S3 event notifications cannot be generated by CodeCommit branch creation events; S3 events are specific to object-level operations in an S3 bucket, not to Git repository actions. Option C is wrong because CodePipeline webhooks are designed to listen for external events from third-party providers like GitHub or Bitbucket, not for native AWS CodeCommit events, and CodeCommit does not support outgoing webhooks to CodePipeline. Option D is wrong because CodePipeline does not have a built-in polling mechanism to check for new branches; polling would require a custom solution (e.g., a Lambda function) and is not a native feature of CodePipeline.

Practice this question →
10
MCQeasy

A development team uses AWS CodeBuild to compile a Java application. The build fails during the 'Install' phase with an error: 'Error: JAVA_HOME is not set'. How should the team fix this?

A.Set the environment variable 'JAVA_HOME' in the buildspec file's 'env' section.
B.Use the managed image 'aws/codebuild/standard:5.0' which has Java pre-installed.
C.Install Java in the pre_build phase using a command.
D.Use a custom Docker image that has Java pre-installed.
AnswerA

Setting JAVA_HOME in the buildspec's env section ensures the variable is exported into every build phase's shell before commands run. This resolves the 'invalid JAVA_HOME' error because Maven or Gradle translates this variable into the absolute path of the JDK installation, which is needed for compilation. It's the canonical fix and works regardless of which base image CodeBuild uses.

Why this answer

The error 'JAVA_HOME is not set' indicates that the build environment lacks the required environment variable pointing to the Java installation. In AWS CodeBuild, the buildspec file's 'env' section allows you to define environment variables, including 'JAVA_HOME', which can be set to the path of the Java runtime (e.g., '/usr/lib/jvm/java-11-openjdk-amd64'). This ensures the variable is available during the Install phase, resolving the error without altering the build image or adding installation steps.

Exam trap

The trap here is that candidates assume using a managed image with Java pre-installed automatically sets JAVA_HOME, but AWS CodeBuild images do not always export this variable by default, requiring explicit definition in the buildspec.

How to eliminate wrong answers

Option B is wrong because using a managed image like 'aws/codebuild/standard:5.0' does not guarantee that JAVA_HOME is set; while Java is pre-installed, the environment variable may not be defined by default, leading to the same error. Option C is wrong because installing Java in the pre_build phase is unnecessary if Java is already present, and it does not address the root cause—JAVA_HOME not being set; the variable must be explicitly defined. Option D is wrong because using a custom Docker image with Java pre-installed still requires setting JAVA_HOME in the buildspec or Dockerfile; otherwise, the variable may be missing, causing the same failure.

Practice this question →
11
MCQmedium

A company uses AWS CodePipeline with Amazon S3 as the source stage. The pipeline triggers on object creation events in the S3 bucket. The development team notices that the pipeline does not trigger when multiple files are uploaded simultaneously. What is the most likely cause?

A.Amazon S3 event notifications are not guaranteed to be delivered for bulk operations.
B.The S3 event notification filter is set to only include objects with a specific prefix or suffix that does not match the uploaded files.
C.CodePipeline does not support triggering from S3 event notifications when multiple files are uploaded simultaneously.
D.The S3 bucket versioning is not enabled, causing events to be lost.
AnswerB

Why this answer

Amazon S3 event notifications can be filtered by prefix and suffix. If the filter is configured to only match objects with a specific prefix or suffix (e.g., `images/` or `.zip`), and the uploaded files do not match that filter, the event notification will not be sent to CodePipeline, causing the pipeline not to trigger. This is the most likely cause when the pipeline fails to trigger on simultaneous uploads, as the filter configuration is a common misconfiguration.

Exam trap

The trap here is that candidates may incorrectly attribute the issue to a limitation of S3 event notifications or CodePipeline with bulk uploads, rather than recognizing that the most likely cause is a misconfigured event notification filter that excludes the uploaded files.

Why the other options are wrong

A

S3 event notifications are designed to deliver events for each object creation, though there may be occasional delays or duplicates.

C

CodePipeline supports S3 event notifications and can handle multiple triggers.

D

Versioning is not required for event notifications; events are sent regardless.

Practice this question →
12
MCQeasy

A development team uses AWS CodeBuild to compile a Java application and run unit tests. The build takes 30 minutes, but the team wants to reduce build time. The codebase has not changed significantly, and dependencies are stable. Which action would be MOST effective in reducing build time?

A.Configure CodeBuild to cache dependencies in an Amazon S3 bucket.
B.Move the build process to a local developer machine to avoid CodeBuild overhead.
C.Reduce the number of unit tests executed in the build phase.
D.Increase the compute type of the build environment to a larger instance.
AnswerA

Configure CodeBuild with cache.type set to S3 and specify an S3 bucket as cache.location, then declare the Java dependency directory (e.g., /root/.m2 for Maven) in the buildspec cache.paths. This creates a persistent, shared cache that is uploaded at the end of each build and downloaded at the start of the next, so dependencies are fetched from S3 instead of being downloaded one-by-one from public repositories on every run. By keying the cache appropriately (e.g., including a hash of the buildspec or source), you retain a valid cache while invalidating it when dependencies or build parameters change.

Why this answer

Caching dependencies in an Amazon S3 bucket allows CodeBuild to reuse previously downloaded Maven/Gradle dependencies across builds, eliminating the need to re-download them each time. Since the codebase and dependencies are stable, this directly reduces the build time by avoiding repeated network transfers of large artifact repositories.

Exam trap

The trap here is that candidates assume a larger compute instance always speeds up builds, overlooking that network-bound operations like dependency downloads are not significantly improved by CPU or memory upgrades.

How to eliminate wrong answers

Option B is wrong because moving the build to a local developer machine sacrifices consistency, scalability, and auditability, and does not address the core issue of dependency download overhead in CodeBuild. Option C is wrong because reducing unit tests compromises code quality and test coverage, and the question states the team wants to reduce build time without changing the codebase significantly — removing tests is not a valid optimization. Option D is wrong because increasing the compute type primarily accelerates CPU-bound tasks (compilation), but the bottleneck here is likely network-bound dependency downloads; a larger instance does not reduce the time spent downloading unchanged dependencies.

Practice this question →
13
MCQeasy

A company uses AWS Systems Manager Automation to patch EC2 instances. The automation document 'AWS-RunPatchBaseline' runs successfully but some instances are not patched because they are not managed by Systems Manager. What is the most likely reason?

A.The instances are running Windows Server 2012 or older.
B.The instances are in a VPC without internet access.
C.The instances do not have the AWS Systems Manager Agent (SSM Agent) installed and the required IAM role attached.
D.The automation document is not compatible with the instance's operating system.
AnswerC

The SSM Agent is the software component that executes Systems Manager requests on the instance, and the instance must also have an instance profile with IAM permissions to call Systems Manager APIs and download patch content. Without the agent or a role such as AmazonSSMManagedInstanceCore, the instance will not show up as a managed node and the automation cannot even target or initiate patching. This is the definitive prerequisite that is missing in this scenario.

Why this answer

Systems Manager Automation can only patch instances that are managed by Systems Manager. For an instance to be managed, it must have the SSM Agent installed and running, and it must have an IAM role that grants the necessary permissions (e.g., AmazonSSMManagedInstanceCore) to communicate with the Systems Manager service. Without these prerequisites, the instance is not registered as a managed node, so the automation document cannot target or patch it.

Exam trap

The trap here is that candidates may assume patching failures are due to network connectivity or OS compatibility, when the root cause is almost always the missing SSM Agent or missing IAM role that prevents the instance from being managed by Systems Manager.

How to eliminate wrong answers

Option A is wrong because Windows Server 2012 or older is still supported by Systems Manager Patch Manager as long as the SSM Agent is installed and the instance is managed; the OS version alone does not prevent management. Option B is wrong because instances in a VPC without internet access can still be managed by Systems Manager if they use a VPC endpoint (interface or gateway endpoint) for Systems Manager and Amazon S3, or if they use a proxy or NAT gateway; lack of internet access does not inherently block management. Option D is wrong because the 'AWS-RunPatchBaseline' document is compatible with both Windows and Amazon Linux operating systems; incompatibility is not the reason for instances being unmanaged.

Practice this question →
14
MCQhard

A company uses AWS CodeBuild to run unit tests as part of their CI/CD pipeline. The tests are memory-intensive and occasionally fail due to insufficient memory. The buildspec.yml file uses the default compute type. What is the most cost-effective solution to resolve the memory issue?

A.Use a custom build environment with the same compute type.
B.Enable local caching in the build project to reduce disk I/O.
C.Change the build project's compute type to a larger instance (e.g., from BUILD_GENERAL1_SMALL to BUILD_GENERAL1_MEDIUM).
D.Split the tests into multiple build projects and run them in parallel.
AnswerC

Larger compute types provide more memory.

Why this answer

Increasing the compute type (e.g., from BUILD_GENERAL1_SMALL to BUILD_GENERAL1_MEDIUM) directly provides more memory for the build environment, resolving the out-of-memory failures. This is the most cost-effective solution as it only increases resources for the specific build project that needs them, without requiring architectural changes or additional build projects.

Exam trap

The trap here is that candidates may confuse memory issues with disk I/O or think that parallelizing tests will reduce per-instance memory pressure, but in reality, each parallel build runs on its own instance with the same memory limit, so the failure persists and costs increase.

How to eliminate wrong answers

Option A is wrong because using a custom build environment with the same compute type does not increase memory; it only changes the base image or installed tools, leaving the underlying instance size unchanged. Option B is wrong because enabling local caching reduces disk I/O by reusing cached files, but does not address memory constraints; the tests fail due to insufficient RAM, not disk throughput. Option D is wrong because splitting tests into multiple build projects and running them in parallel would increase total memory usage and cost, as each project runs on its own instance, and does not solve the per-instance memory shortage.

Practice this question →
15
MCQmedium

A company is using AWS CodeBuild to run integration tests. The tests require access to an Amazon RDS instance in a private subnet. The CodeBuild project is configured with a VPC ID, subnet IDs, and security group IDs. However, the tests fail with a connection timeout. What is the MOST likely cause?

A.The security group attached to the RDS instance does not allow inbound traffic from the CodeBuild security group.
B.The CodeBuild project does not have internet access to download packages.
C.The CodeBuild project is not associated with a VPC.
D.The RDS instance is not publicly accessible and requires a NAT gateway.
AnswerA

Security group rules must allow traffic on the database port from the CodeBuild security group.

Why this answer

The most likely cause is that the security group attached to the RDS instance does not allow inbound traffic from the CodeBuild security group. CodeBuild runs inside the VPC using the specified security group, so it sends traffic to the RDS instance on port 3306 (or the appropriate database port). If the RDS security group's inbound rules do not explicitly permit traffic from the CodeBuild security group (or its CIDR), the connection is dropped, resulting in a timeout.

Exam trap

The trap here is that candidates often assume a NAT gateway or internet access is required for VPC-based resources, but the core issue is security group ingress rules, not network connectivity to the internet.

How to eliminate wrong answers

Option B is wrong because CodeBuild projects configured with a VPC can access the internet via a NAT gateway or VPC endpoints if needed, but the failure here is a connection timeout to RDS, not a package download issue. Option C is wrong because the question states the CodeBuild project is configured with a VPC ID, subnet IDs, and security group IDs, so it is associated with a VPC. Option D is wrong because RDS instances in private subnets do not need to be publicly accessible; CodeBuild can reach them directly via the VPC without a NAT gateway, as long as security group rules and network ACLs permit the traffic.

Practice this question →
16
MCQhard

An organization uses AWS CodePipeline to orchestrate deployments to multiple environments (dev, test, prod). Each environment uses a different AWS account. The pipeline uses cross-account actions with IAM roles. Recently, the pipeline failed at the deploy stage for the prod account with the error 'Access Denied' when assuming the cross-account role. The role ARN is correct and the trust policy allows the pipeline's service role. What is the MOST likely cause?

A.The EC2 instances in the prod account do not have an appropriate instance profile.
B.The pipeline's service role lacks the `sts:AssumeRole` permission for the cross-account role.
C.The cross-account role's permissions boundary denies the deploy action.
D.The pipeline's service role does not have permission to perform the deploy action in the prod account.
AnswerB

For cross-account deployments, the pipeline service role in the source account must contain a policy that explicitly grants the `sts:AssumeRole` action on the ARN of the destination account's cross-account role. This is in addition to the trust policy on the cross-account role that allows the service role to assume it. Without this permission, CodePipeline's attempt to switch into the production account fails with a 403 AccessDenied at the AssumeRole step, which is exactly the described symptom. This is the root cause of the deployment failure.

Why this answer

The pipeline's service role must have an `sts:AssumeRole` permission on the cross-account role to perform the role assumption. Even if the trust policy on the cross-account role allows the pipeline's service role, the pipeline's service role itself needs an IAM policy granting `sts:AssumeRole` for the cross-account role ARN. Without this permission, the `AssumeRole` API call fails with 'Access Denied', which is the exact error described.

Exam trap

The trap here is that candidates often focus on the cross-account role's trust policy or permissions, forgetting that the pipeline's service role also needs explicit `sts:AssumeRole` permission, which is a separate IAM policy requirement.

How to eliminate wrong answers

Option A is wrong because the error occurs during the cross-account role assumption, not during an EC2 instance action; instance profiles are irrelevant to CodePipeline cross-account deployments. Option C is wrong because a permissions boundary on the cross-account role would limit the maximum permissions of the assumed role, but the error is 'Access Denied' at the assumption step, not during the deploy action itself. Option D is wrong because the pipeline's service role does not directly perform deploy actions in the prod account; it assumes the cross-account role, and the cross-account role's permissions govern the deploy action.

Practice this question →
17
MCQhard

An organization uses AWS CloudFormation to manage infrastructure across multiple accounts using AWS Organizations. They want to enforce that all S3 buckets are encrypted with SSE-S3. A DevOps engineer creates a service control policy (SCP) to deny the creation of any S3 bucket without encryption. However, CloudFormation stack creation fails with an access denied error even when the template includes encryption. What is the most likely cause?

A.The CloudFormation template specifies SSE-KMS encryption, which is not allowed by the SCP.
B.The SCP is denying the s3:PutBucketPublicAccessBlock action, which is required for all bucket creation requests.
C.The SCP is incorrectly scoped to the management account instead of the member accounts.
D.The CloudFormation service role does not have permissions to create buckets in the target account.
AnswerA

Correct. SCPs are service control policies that set maximum permissions for all IAM principals in an account, and they can include conditions that deny S3 bucket creation when SSE-KMS is specified. If the organization's SCP only allows SSE-S3 encryption (or denies kms:GenerateDataKey or kms:CreateGrant), then any CloudFormation template that specifies SSE-KMS encryption for the bucket will be rejected with an AccessDenied error, regardless of the IAM service role or the target bucket configuration. This perfectly matches the scenario where the error occurs only when certain encryption settings are present in the template.

Why this answer

The SCP denies the creation of S3 buckets without encryption, but it specifically allows only SSE-S3 encryption. If the CloudFormation template specifies SSE-KMS encryption, the SCP will deny the request, causing an access denied error—even though encryption is present. This mismatch between the encryption type required by the SCP (SSE-S3) and what the template requests (SSE-KMS) is the most likely cause of the failure.

Exam trap

The trap is assuming that any encryption (SSE-S3 or SSE-KMS) satisfies the SCP requirement. However, SCPs can be very specific; if the SCP only allows SSE-S3, then using SSE-KMS will be denied. Candidates may overlook the distinction between encryption types.

How to eliminate wrong answers

Option A is wrong because SSE-KMS is a form of encryption; if the SCP denies bucket creation without encryption, specifying SSE-KMS would satisfy the encryption requirement, so it would not cause an access denied error. Option B is wrong because s3:PutBucketPublicAccessBlock is not required for all bucket creation requests; it is an optional action to block public access, and denying it would not prevent bucket creation—only the ability to set public access settings. Option D is wrong because the CloudFormation service role's permissions are separate from SCPs; if the role lacks permissions, the error would be an authorization failure, but the question explicitly states the SCP is the cause, and SCPs cannot be overridden by IAM roles—they act as a boundary, so the role's permissions are irrelevant if the SCP denies the action.

Practice this question →
18
MCQhard

A company is using AWS CodePipeline with multiple stages that include source, build, and deploy. The pipeline uses an Amazon S3 bucket as the source action. The team notices that the pipeline is not automatically starting when new files are uploaded to the S3 bucket. The S3 bucket has versioning enabled. What is the most likely reason?

A.The S3 bucket is the same bucket used for the deploy action.
B.The pipeline is configured to detect changes based on object key, but the uploaded file uses the same key as an existing object.
C.The S3 bucket is not configured to send Amazon SQS notifications to CodePipeline.
D.The S3 bucket does not have versioning enabled.
AnswerB

CodePipeline triggers only when the object key changes or a new version is created; overwriting with same key may not trigger if versioning is not combined with proper event filtering.

Why this answer

CodePipeline's S3 source action detects changes based on object key and ETag. When a file is uploaded with the same key as an existing object, even with versioning enabled, the ETag may not change if the content is identical, or the pipeline may not trigger if it only monitors for new keys. Versioning creates a new version ID, but CodePipeline's default detection relies on object key changes or ETag changes, not version ID changes, so uploading a file with the same key may not start the pipeline.

Exam trap

The trap here is that candidates assume versioning always triggers the pipeline, but CodePipeline's S3 source action relies on object key or ETag changes, not version ID changes, so uploading the same key with identical content may not start the pipeline.

How to eliminate wrong answers

Option A is wrong because using the same S3 bucket for source and deploy actions does not prevent the pipeline from starting; CodePipeline can use the same bucket for multiple stages without issue. Option C is wrong because CodePipeline does not require SQS notifications from the S3 bucket; it uses Amazon CloudWatch Events or S3 event notifications (via Amazon EventBridge) to detect changes, not SQS directly. Option D is wrong because the question states that versioning is enabled, so this is not the issue; even without versioning, the pipeline could still trigger on object changes, but versioning is not a prerequisite for triggering.

Practice this question →
19
MCQeasy

A DevOps team uses AWS CodePipeline to deploy a static website to Amazon S3. The pipeline has a source stage from CodeCommit, a build stage using CodeBuild that generates the website files, and a deploy stage that copies files to an S3 bucket. The team wants to add a manual approval step before the deploy stage. What should the engineer do?

A.Add an approval action in the pipeline stage before deploy
B.Use Amazon SNS to send a notification and rely on a Lambda function to resume
C.Add a CodeBuild action that waits for an SNS confirmation
D.Configure the S3 bucket to send an event to the pipeline after upload
AnswerA

An approval action is a native CodePipeline action type that deliberately pauses the execution at the end of the stage in which it is placed. When the pipeline reaches this action, it transitions to a 'Manual approval required' state and stops executing any subsequent stages, such as the deploy stage, until a user explicitly clicks Approve or Reject. This creates a true sign-off gate and is the only supported way to insert a human decision point directly into the pipeline flow before deployment.

Why this answer

AWS CodePipeline natively supports a manual approval action that can be added as a stage gate. By inserting an approval action in a stage immediately before the deploy stage, the pipeline will pause and require a designated approver to manually approve or reject the deployment, ensuring human oversight before files are copied to the S3 bucket.

Exam trap

The trap here is that candidates may confuse event-driven automation (SNS, Lambda, S3 events) with the need for a manual approval gate, overlooking that CodePipeline's built-in approval action is the simplest and most direct solution for human-in-the-loop control.

How to eliminate wrong answers

Option B is wrong because Amazon SNS alone cannot pause or resume a pipeline; a Lambda function triggered by SNS would need to call the CodePipeline API (e.g., PutApprovalResult) to resume the pipeline, but this adds unnecessary complexity and does not provide a native manual approval step. Option C is wrong because CodeBuild actions execute build commands and cannot wait for an SNS confirmation; CodeBuild has no built-in mechanism to pause for external signals, and attempting to do so would require custom polling or a blocking script, which is not a supported pattern. Option D is wrong because configuring the S3 bucket to send an event to the pipeline after upload would trigger the pipeline to start, not pause it; this does not introduce a manual approval step and would instead automate the deployment without human intervention.

Practice this question →
20
MCQeasy

A company uses AWS CodeBuild to run unit tests and package a Java application. The build process takes 15 minutes. The team wants to reduce build time by caching dependencies. Which approach should the engineer recommend?

A.Store the compiled dependencies in a separate CodeCommit repository and clone it during the build
B.Mount an Amazon EFS file system to the build container and persist the cache across builds
C.Use an Application Load Balancer in front of a private artifact repository
D.Configure CodeBuild to use Amazon S3 for cache storage and specify the cache directory in buildspec.yml
AnswerD

Configuring CodeBuild to use Amazon S3 for cache storage and specifying the cache directory in buildspec.yml is the native, recommended caching solution. Set the project's cache type to S3 with a designated bucket, then declare the dependency path—for Maven that is typically /root/.m2/repository—under cache.path in the buildspec. At the start of a build, CodeBuild downloads the cached files, and at the end it re-uploads them, so repeated runs skip re-resolving and re-downloading dependencies from Maven Central, substantially reducing build time and network egress.

Why this answer

CodeBuild natively supports Amazon S3 for cache storage, allowing you to persist dependency directories across builds. By specifying the cache type as S3 and the path to the dependency cache (e.g., /root/.m2 for Maven) in the buildspec.yml, subsequent builds can reuse previously downloaded dependencies, significantly reducing build time without additional infrastructure.

Exam trap

The trap here is that candidates may confuse CodeBuild's lack of persistent local storage with the ability to mount external file systems like EFS, or they may think that cloning a repository is an efficient caching mechanism, when in fact CodeBuild's native S3 cache is the simplest and most effective solution for dependency caching.

How to eliminate wrong answers

Option A is wrong because storing compiled dependencies in a separate CodeCommit repository and cloning them during each build adds network transfer and checkout overhead, which does not reduce build time and may even increase it. Option B is wrong because mounting an Amazon EFS file system to the build container is not supported by CodeBuild; CodeBuild does not allow persistent file system mounts across builds, and EFS is designed for concurrent access from multiple EC2 instances, not for CodeBuild's ephemeral containers. Option C is wrong because an Application Load Balancer in front of a private artifact repository addresses high availability and load distribution, not caching of dependencies within the build process; it does not reduce the time to download dependencies for each build.

Practice this question →
21
MCQhard

A DevOps team uses AWS CodePipeline with an S3 source action and CodeBuild as a build provider. The pipeline has a manual approval step before deployment. Recently, the team noticed that the pipeline automatically starts when a new object is uploaded to the S3 bucket, even if the object is not the source code. They want to ensure that the pipeline only triggers on changes to the source code directory. What is the MOST efficient solution?

A.Use Amazon CloudWatch Events to create a custom rule that matches the source code path and triggers the pipeline.
B.Enable versioning on the S3 bucket and configure the pipeline to use the latest version.
C.Configure the S3 event notification to use a prefix filter that matches the source code directory.
D.Disable the S3 trigger and manually start the pipeline after each code commit.
AnswerC

S3 event notifications natively support prefix and suffix filters, so you can create an s3:ObjectCreated:* notification whose prefix corresponds to the source code directory (for example, 'source/'). This scopes the event stream so CodePipeline is invoked only when objects are created under that specific path, while uploads to any other directory in the same bucket are ignored. This directly corrects the over-broad triggering behaviour at the storage layer.

Why this answer

S3 event notifications support prefix and suffix filters, allowing you to specify that only objects uploaded to a particular directory (e.g., 'source-code/') trigger the event. By configuring the S3 event notification with a prefix filter matching the source code directory, the pipeline will only start when a new object is uploaded to that specific path, ignoring uploads to other directories. This is the most efficient solution as it avoids unnecessary pipeline executions without adding extra components or manual intervention.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing CloudWatch Events (Option A) or versioning (Option B), not realizing that S3 event notifications already have built-in prefix filtering that directly solves the problem without extra services or configuration.

How to eliminate wrong answers

Option A is wrong because using Amazon CloudWatch Events to create a custom rule adds unnecessary complexity and cost; S3 event notifications already support prefix filtering natively, making a CloudWatch Events rule redundant. Option B is wrong because enabling versioning on the S3 bucket and configuring the pipeline to use the latest version does not prevent the pipeline from triggering on every object upload; versioning tracks object versions but does not filter by path, so the pipeline would still start for any upload. Option D is wrong because disabling the S3 trigger and manually starting the pipeline after each code commit eliminates automation entirely, which is inefficient and defeats the purpose of a CI/CD pipeline.

Practice this question →
22
MCQmedium

A DevOps team uses AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment fails with a 'HealthCheckFailed' error. The application is running, but the health check endpoint returns HTTP 500. What should the team do to resolve this issue?

A.Change the deployment configuration to use AllAtOnce to avoid health checks.
B.Increase the health check grace period in the Auto Scaling group.
C.Disable the health check in the CodeDeploy deployment configuration.
D.Modify the application to handle the health check endpoint correctly and return HTTP 200.
AnswerD

The only root-cause solution is to fix the application so the health check endpoint responds with HTTP 200 (or another configured success code) once the service is up. CodeDeploy and the associated load balancer rely on that HTTP status to determine whether an instance is healthy; a 500 response signals a failed deployment and triggers rollback. Once the endpoint returns 200, the health check passes, instances remain in service, and the deployment completes successfully.

Why this answer

The health check endpoint returns HTTP 500, indicating the application is not functioning correctly despite running. CodeDeploy uses the health check endpoint to verify the application is healthy after deployment; returning HTTP 200 is required for the deployment to succeed. The team must fix the application code to properly handle the health check endpoint and return a successful status.

Exam trap

The trap here is that candidates confuse CodeDeploy's deployment health check with Auto Scaling's health check grace period, thinking that increasing the grace period will allow the application more time to become healthy, but CodeDeploy's health check is immediate and not governed by that setting.

How to eliminate wrong answers

Option A is wrong because changing the deployment configuration to AllAtOnce does not bypass health checks; CodeDeploy still performs health checks after deployment, and a failed health check will cause the deployment to fail regardless of the deployment type. Option B is wrong because increasing the health check grace period in the Auto Scaling group only delays when Auto Scaling considers an instance unhealthy, but it does not affect CodeDeploy's own health check validation, which occurs immediately after deployment. Option C is wrong because CodeDeploy does not allow disabling health checks in the deployment configuration; health checks are a mandatory part of the deployment lifecycle to ensure application availability.

Practice this question →
23
MCQhard

A company uses AWS CodeCommit and wants to enforce that all commits to the 'main' branch are signed with a GPG key. Which steps should the DevOps engineer take to enforce this?

A.Create an IAM policy that denies git push actions unless the commit is signed.
B.Use the AWS CLI to verify commit signatures and reject pushes.
C.Enable CloudWatch Logs to monitor commits and trigger a Lambda to rollback.
D.Configure a pre-receive hook in CodeCommit to reject unsigned commits.
AnswerA

AWS CodeCommit integrates with IAM to evaluate policies at the time of a `git push`. By creating an IAM policy that uses the `codecommit:GitPush` action with a condition key `codecommit:IsSigned` set to `true`, you can deny pushes that are not signed. This enforces GPG signature verification at the IAM authorization layer, blocking unsigned commits before they reach the repository.

Why this answer

AWS CodeCommit integrates with IAM to evaluate policies at the time of a `git push`. By creating an IAM policy that uses the `codecommit:GitPush` action with a `ForAnyValue:StringLike` condition key `codecommit:References` set to `refs/heads/main` and a `Bool` condition on `codecommit:IsSigned` set to `true`, you can deny pushes that are not signed. This enforces GPG signature verification at the IAM authorization layer, blocking unsigned commits before they reach the repository.

Exam trap

The trap here is that candidates often assume CodeCommit supports pre-receive hooks like GitHub or GitLab, but AWS CodeCommit relies on IAM policies for branch-level enforcement, not server-side Git hooks.

How to eliminate wrong answers

Option B is wrong because the AWS CLI does not have a built-in command to verify commit signatures during a push; signature verification is a client-side GPG operation, and the CLI cannot intercept or reject pushes in real time. Option C is wrong because CloudWatch Logs can monitor commit events but cannot trigger a Lambda to rollback a commit that has already been accepted by CodeCommit; rollback would require manual intervention or a separate process, and this approach does not prevent the unsigned commit from being pushed. Option D is wrong because CodeCommit does not support pre-receive hooks; pre-receive hooks are a feature of self-managed Git servers like GitHub Enterprise or GitLab, not AWS CodeCommit.

Practice this question →
24
MCQmedium

An IAM policy is attached to a user who needs to manually start a CodePipeline execution. The pipeline uses an S3 bucket named 'my-artifact-bucket' for artifacts. The user reports that they cannot start the pipeline. Which action is missing from the policy?

A.iam:PassRole
B.codepipeline:ListPipelines
C.codepipeline:GetPipelineExecution
D.s3:PutObject
AnswerB

The user likely needs to list pipelines in the console to find the pipeline.

Why this answer

The user needs to manually start a CodePipeline execution, which requires the `codepipeline:StartPipelineExecution` action. However, the question asks which action is missing from the policy, and the correct answer is `codepipeline:ListPipelines` because the user cannot even see the pipeline to start it. Without `codepipeline:ListPipelines`, the AWS Management Console or CLI will not return the pipeline in the list, preventing the user from selecting it to start execution.

The other actions are either not directly required for starting a pipeline or are unrelated to the permission needed to list pipelines.

Exam trap

The trap here is that candidates often focus on the action needed to start the pipeline (`StartPipelineExecution`) and overlook the prerequisite `ListPipelines` action, which is required to discover the pipeline in the first place.

How to eliminate wrong answers

Option A is wrong because `iam:PassRole` is needed when a service (like CodePipeline) needs to assume a role to access resources, but the user is manually starting the pipeline, not configuring it; the pipeline already has its role assigned. Option C is wrong because `codepipeline:GetPipelineExecution` is used to retrieve details about a specific execution, not to list or start pipelines. Option D is wrong because `s3:PutObject` is required for the pipeline to write artifacts to the S3 bucket, but the user is only starting the pipeline, not uploading artifacts directly.

Practice this question →
25
MCQmedium

A development team uses AWS CodeCommit as a source control repository. A developer accidentally pushed a commit that contains sensitive information (e.g., AWS access keys) to the main branch. The team wants to remove the sensitive data from the repository history completely. Which action should the engineer take?

A.Use 'git filter-branch' to rewrite the repository history and remove the sensitive file
B.Delete the repository and create a new one, then force push the remaining branches
C.Use 'git revert' to create a new commit that undoes the changes
D.Create a new branch from the commit before the sensitive data was added and merge it to main
AnswerA

git filter-branch rewrites every commit in the repository's DAG, eliminating the sensitive blob from historical snapshots and changing commit SHAs. Once the rewritten history is force-pushed to CodeCommit, the file is unreachable via any prior commit, but all branch tips must be updated and team members must re-clone or rebase to avoid propagating the old history. This is the standard, targeted purging technique for leaked credentials.

Why this answer

'git filter-branch' (or the modern 'git filter-repo') rewrites the repository history by removing or replacing the sensitive file in every commit, effectively purging it from the entire Git history. This is the only native Git method that completely eliminates the sensitive data from all past commits, preventing anyone from retrieving it via 'git log' or by cloning the repository. After rewriting history, a force push to the remote CodeCommit repository is required to overwrite the remote branches.

Exam trap

The trap here is that candidates confuse 'git revert' (which adds a new commit but leaves the sensitive data in history) with 'git filter-branch' (which actually rewrites history to remove the data), leading them to choose a non-destructive but ineffective option.

How to eliminate wrong answers

Option B is wrong because deleting the repository and creating a new one, then force pushing remaining branches, does not remove the sensitive data from the existing repository's history on the remote; the old repository would still exist in CodeCommit's trash or backup, and the sensitive data would remain accessible. Option C is wrong because 'git revert' creates a new commit that undoes the changes of a previous commit, but the sensitive data remains in the commit history and can still be viewed with 'git log' or by checking out the old commit. Option D is wrong because creating a new branch from the commit before the sensitive data was added and merging it to main does not remove the commit containing the sensitive data from the history; the merge will still include the sensitive commit in the ancestry, and the data remains accessible.

Practice this question →
26
MCQhard

A DevOps engineer is designing a CI/CD pipeline for a microservices application running on Amazon ECS with Fargate. The team wants to use a blue/green deployment strategy to minimize downtime. Which combination of AWS services and configurations should be used to implement this?

A.Use Amazon ECS service with a rolling update deployment controller
B.Create two separate ECS services and use Route 53 weighted routing to shift traffic
C.Use AWS CloudFormation with a custom resource to swap target group weights
D.Use CodeDeploy with an ECS compute platform and an Application Load Balancer
AnswerD

CodeDeploy with an ECS compute platform natively manages blue/green deployments by creating a new task set, installing it into a preconfigured green target group, and then incrementally shifting the ALB's production listener weight from the original to the new target group based on a Canary or Linear deployment configuration. The service integrates with a specified AppSpec file to run pre- and post-traffic validation hooks, and you can attach CloudWatch alarms that trigger automatic rollback if the new version misbehaves. This is the purpose-built mechanism that owns the entire traffic-shifting lifecycle, from creating the replacement task set to deregistering the old one, without resorting to custom code.

Why this answer

CodeDeploy with an ECS compute platform natively supports blue/green deployments for ECS services by orchestrating traffic shifting between two target groups behind an Application Load Balancer. This approach minimizes downtime by gradually routing traffic from the 'blue' (current) task set to the 'green' (new) task set, with built-in rollback capabilities and lifecycle hooks for validation.

Exam trap

The trap here is that candidates often confuse blue/green with rolling updates (Option A) or assume that manual traffic routing via Route 53 (Option B) or CloudFormation custom resources (Option C) can achieve the same orchestrated, automated deployment with health checks and rollback that CodeDeploy provides natively.

How to eliminate wrong answers

Option A is wrong because a rolling update deployment controller in ECS replaces tasks incrementally without creating a separate environment for validation, which does not provide the zero-downtime traffic shifting characteristic of blue/green deployments. Option B is wrong because managing two separate ECS services with Route 53 weighted routing introduces DNS caching delays and lacks orchestrated traffic shifting, health checks, and rollback automation that CodeDeploy provides. Option C is wrong because AWS CloudFormation custom resources are not designed for real-time traffic shifting or deployment orchestration; they are intended for provisioning custom infrastructure logic, and swapping target group weights manually would not integrate with ECS deployment lifecycle hooks or automatic rollback.

Practice this question →
27
MCQhard

A company runs a critical application on Amazon EC2 instances behind an Application Load Balancer. The application is deployed using AWS CodeDeploy with an in-place deployment configuration. During a recent deployment, the deployment failed because the new application version caused a health check failure, and CodeDeploy did not automatically roll back. What should the engineer do to ensure automatic rollback on health check failure?

A.Set up an EC2 instance lifecycle hook to trigger a rollback script when the instance enters a pending state
B.Configure an Amazon SQS queue to monitor health checks and invoke a rollback Lambda function
C.Enable automatic rollback in the CodeDeploy deployment group and set up a CloudWatch alarm for the ALB health check
D.Modify the Auto Scaling group to replace unhealthy instances automatically
AnswerC

CodeDeploy can be configured to roll back when a CloudWatch alarm (e.g., based on health check metrics) is in ALARM state.

Why this answer

CodeDeploy can automatically roll back a deployment when a CloudWatch alarm, such as one monitoring ALB health check failures, enters the ALARM state. By enabling automatic rollback in the deployment group and associating the CloudWatch alarm, the deployment will revert to the previous version as soon as the health check fails, without manual intervention.

Exam trap

The trap here is that candidates often assume Auto Scaling group health checks or lifecycle hooks can handle deployment rollbacks, but they operate at the instance level and do not revert application code, whereas CodeDeploy's native automatic rollback with CloudWatch alarms is the correct, integrated solution.

How to eliminate wrong answers

Option A is wrong because EC2 instance lifecycle hooks are designed to pause an instance during launch or termination for custom actions, not to trigger rollbacks based on health check failures; they operate at the instance lifecycle level, not the deployment level. Option B is wrong because SQS queues are message brokers and cannot directly monitor health checks or invoke rollbacks; while a Lambda function could be triggered, this approach adds unnecessary complexity and is not the native, supported mechanism for automatic rollback in CodeDeploy. Option D is wrong because Auto Scaling group health checks replace unhealthy instances but do not revert the application version; they would launch a new instance with the same failing code, perpetuating the failure rather than rolling back the deployment.

Practice this question →
28
MCQhard

A company uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails during the 'ValidateService' lifecycle event. The CloudWatch Agent reports that the target process is running but the health check endpoint returns HTTP 503. The CodeDeploy agent logs show no errors. What is the most likely cause of the failure?

A.The Auto Scaling group is not healthy
B.The CodeDeploy agent is not installed on the instances
C.The application is not fully functional due to missing configuration files
D.The target process is not listening on the expected port
AnswerC

Process is running but health check fails, suggesting configuration issue.

Why this answer

The 'ValidateService' lifecycle event in CodeDeploy runs a health check against the application endpoint. A 503 HTTP status indicates the web server is running (the target process is up) but the application itself is not fully functional, often due to missing configuration files, environment variables, or dependencies. The CloudWatch Agent confirming the process is running and the CodeDeploy agent logs showing no errors further isolate the issue to the application layer, not the deployment infrastructure.

Exam trap

The trap here is that candidates may assume a running process (confirmed by CloudWatch Agent) means the application is fully functional, but the 503 status explicitly indicates the application layer is failing, not the process or network layer.

How to eliminate wrong answers

Option A is wrong because an unhealthy Auto Scaling group would cause the instance to be terminated or fail health checks at the EC2 level, not specifically result in a 503 from the application health check endpoint during CodeDeploy's ValidateService hook. Option B is wrong because if the CodeDeploy agent were not installed, the deployment would fail much earlier (e.g., during the 'DownloadBundle' or 'Install' events) and the agent logs would show errors or be absent, not report no errors. Option D is wrong because the CloudWatch Agent reports the target process is running, which implies the process is listening on its expected port; a port mismatch would typically cause a connection refused (e.g., ECONNREFUSED) or timeout, not an HTTP 503.

Practice this question →
29
MCQhard

An organization has a AWS CodePipeline that deploys a critical application. The pipeline uses a manual approval step before deploying to production. The team wants to ensure that only authorized users can approve the deployment, and that the approval action is logged for compliance. Which combination of actions should the team take? (Select TWO.)

A.Configure the approval action to invoke an AWS Lambda function that validates the approver's IAM role tags.
B.Enable AWS CloudTrail to log all approval API calls for auditing.
C.Use Amazon Simple Notification Service (SNS) to send approval notifications and allow any subscriber to approve.
D.Use AWS CodeCommit to manage approval permissions via repository policies.
E.Store approval logs in Amazon CloudWatch Logs for real-time monitoring.
AnswerA, B

This allows custom authorization based on tags.

Why this answer

AWS CodePipeline's manual approval action can be configured to invoke an AWS Lambda function that checks the approver's IAM role tags, ensuring only authorized users (e.g., those with a specific 'approver' tag) can approve. This provides fine-grained, custom authorization beyond basic IAM policies. Option B is correct because enabling AWS CloudTrail captures all approval API calls (e.g., PutApprovalResult) as audit logs, meeting compliance requirements for tracking who approved and when.

Exam trap

The trap here is that candidates often confuse CloudWatch Logs (for monitoring) with CloudTrail (for auditing), or mistakenly think CodeCommit can manage pipeline permissions, when in fact CodePipeline's approval actions require IAM-based or Lambda-based authorization, not repository policies.

How to eliminate wrong answers

Option C is wrong because using Amazon SNS to send approval notifications and allowing any subscriber to approve bypasses authorization controls; SNS does not enforce IAM-based approval permissions, and any subscriber could approve without validation. Option D is wrong because AWS CodeCommit is a source control service for managing Git repositories, not for managing approval permissions in CodePipeline; approval permissions are handled via IAM policies or Lambda functions, not CodeCommit repository policies. Option E is wrong because storing approval logs in Amazon CloudWatch Logs is for real-time monitoring, not for compliance auditing; CloudTrail is the correct service for logging API calls for auditing, as it provides immutable, long-term logs of all AWS API actions.

Practice this question →
30
MCQeasy

A company uses AWS CloudFormation to deploy infrastructure. They have a template that creates an Amazon EC2 instance and an Elastic IP address. The template uses the AWS::EC2::EIP resource. The team notices that when they delete the stack, the Elastic IP address is not released, leading to charges. They want to ensure that the Elastic IP is automatically released when the stack is deleted. What should they do?

A.Set the DeletionPolicy attribute to 'Retain' to keep the EIP
B.Create a custom resource to release the EIP before stack deletion
C.Set the DeletionPolicy attribute to 'Delete' on the EIP resource
D.Add a DependsOn clause to ensure proper order of deletion
AnswerC

Explicitly setting DeletionPolicy to 'Delete' on the EIP resource ensures that CloudFormation releases the Elastic IP when the stack is removed, preventing any accidental retention and associated charges. Although 'Delete' is the default policy, stating it explicitly documents the intent and guards against future changes to global defaults. This is the correct, native mechanism to guarantee the EIP is released upon stack deletion.

Why this answer

The default DeletionPolicy for AWS::EC2::EIP is 'Retain', meaning the Elastic IP address is preserved after stack deletion, leading to charges. To ensure it is automatically released, you must explicitly set the DeletionPolicy attribute to 'Delete' on the EIP resource. This overrides the default and causes the Elastic IP to be deleted upon stack deletion.

Option A (Retain) would keep the EIP, which is the default and would still incur charges. Option B (custom resource) is unnecessary. Option D (DependsOn) does not control deletion behavior.

Therefore, Option C is the correct solution.

Practice this question →
31
MCQhard

A team uses AWS CodePipeline to deploy a containerized application to Amazon ECS. The pipeline uses a source stage from CodeCommit, a build stage that builds a Docker image and pushes it to Amazon ECR, and a deploy stage that updates an ECS service. The team wants to add a manual approval step before the deploy stage to allow QA to verify the image. What is the BEST way to implement this?

A.Configure an AWS Lambda function in the pipeline that checks a DynamoDB table for approval status and pauses until approved.
B.Use an Amazon SNS topic to send a notification to QA, and have them manually trigger the deploy stage by clicking a link in the email.
C.Use Amazon CloudWatch Events to trigger a custom action that waits for an approval signal.
D.Add a manual approval stage in CodePipeline between the build and deploy stages, and configure SNS to notify approvers.
AnswerD

The native CodePipeline manual approval action is the correct pattern: it creates a gate that pauses the pipeline after the build stage and does not proceed to deploy until an approved or rejected decision is recorded. When you add the action, you configure an SNS topic for notifications, and approvers with the proper IAM policy respond through the console or CLI with `put-approval-result`. This integrated workflow provides explicit audit trails and automatically resumes only on approval, which is far more reliable than any external workaround. It is purpose-built to block stage transitions and supports both email SNS notifications and custom SNS topics for team alerting.

Why this answer

CodePipeline natively supports manual approval actions that pause the pipeline at a specified stage and wait for an approver to manually approve or reject the transition. By adding a manual approval stage between the build and deploy stages, the pipeline will automatically halt after the build completes, and you can configure Amazon SNS to notify the QA team via email or other endpoints when their approval is required. This approach requires no custom infrastructure, integrates directly with the pipeline's state machine, and provides a built-in audit trail of approvals.

Exam trap

The trap here is that candidates often over-engineer a solution by introducing custom polling, Lambda functions, or external triggers, when AWS CodePipeline already provides a fully managed, native manual approval action that handles pausing, notification, and resumption without any custom code.

How to eliminate wrong answers

Option A is wrong because using a Lambda function to poll a DynamoDB table for approval status introduces unnecessary complexity, latency, and custom code; CodePipeline already provides a native manual approval action that handles pausing and resuming the pipeline without custom polling logic. Option B is wrong because SNS notifications alone cannot pause the pipeline or trigger the deploy stage; clicking a link in an email cannot programmatically resume a CodePipeline execution without a custom webhook or API integration, and the pipeline would continue past the deploy stage immediately if no blocking mechanism is in place. Option C is wrong because CloudWatch Events can trigger actions based on pipeline state changes but cannot natively pause a pipeline and wait for an approval signal; the manual approval action in CodePipeline is the correct mechanism for inserting a human-in-the-loop gate.

Practice this question →
32
MCQmedium

Refer to the exhibit. A DevOps engineer runs the above commands. The build project 'my-project' uses an S3 bucket as source and another S3 bucket for artifacts. The build fails with an 'Access Denied' error when trying to download the source code. What is the most likely cause?

A.The encryption key is a KMS key that the role cannot access
B.The service role does not have s3:GetObject permission on the source bucket
C.The source type is S3, but the project expects CodeCommit
D.The source location is incorrect
AnswerB

The service role is the IAM role that CodePipeline assumes to perform actions on your behalf. To pull source artifacts from S3, the role must have an IAM policy allowing s3:GetObject (and typically s3:ListBucket) on the specified bucket and prefix. The error indicates the pipeline cannot download the object, which is a direct consequence of the role lacking this permission. Adding a policy statement with s3:GetObject on the source bucket ARN will resolve the stage failure.

Why this answer

The build project 'my-project' uses an S3 bucket as the source. When CodeBuild downloads source code from S3, the service role must have the s3:GetObject permission on the source bucket. The 'Access Denied' error indicates that the role lacks this permission, making option B the most likely cause.

Exam trap

The trap here is that candidates may confuse 'Access Denied' with other S3 errors like 'NoSuchKey' or 'BucketNotFound', or incorrectly attribute the error to KMS encryption when the error message does not reference it.

How to eliminate wrong answers

Option A is wrong because the error message does not mention KMS or encryption key issues; an 'Access Denied' for KMS would typically include a specific message about the key. Option C is wrong because the project is configured to use an S3 source, not CodeCommit, and the error is about access, not source type mismatch. Option D is wrong because an incorrect source location would result in a 'NoSuchKey' or '404' error, not an 'Access Denied' error.

Practice this question →
33
MCQeasy

A company uses AWS CodeCommit for source control. Developers frequently push large binary files, causing the repository size to exceed the recommended limit. What is the most efficient way to manage this situation?

A.Increase the repository size limit in CodeCommit settings.
B.Use Git LFS (Large File Storage) and configure it to store binaries in S3.
C.Periodically run a script to remove large files from the commit history.
D.Use S3 directly for storing binaries and reference them in code.
AnswerB

Git LFS solves the binary bloat problem by replacing each large file in the repository with a tiny text pointer, while the actual file content is stored in a separate, scalable LFS store—in this case, an S3 bucket you configure. During checkout, the Git LFS client retrieves the real file from S3 transparently, so developers see the full content without the repository itself growing. This keeps CodeCommit clones fast, avoids the 10 GB limit, and integrates smoothly with existing Git branching and merging workflows.

Why this answer

Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, while the actual binary content is stored in an external storage backend such as Amazon S3. This keeps the CodeCommit repository small and within recommended limits, and developers continue to use standard Git commands without performance degradation.

Exam trap

The trap here is that candidates assume increasing a service limit is always possible (Option A), but AWS CodeCommit enforces a hard 10 GB repository limit that cannot be raised, making Git LFS the only scalable solution.

How to eliminate wrong answers

Option A is wrong because CodeCommit does not allow increasing the repository size limit beyond the default 10 GB; the limit is a hard service quota and cannot be adjusted. Option C is wrong because periodically rewriting Git history to remove large files is disruptive, forces all developers to rebase or re-clone, and does not prevent future large file pushes. Option D is wrong because storing binaries directly in S3 and referencing them in code breaks the developer workflow—developers must manually manage S3 uploads and versioning, losing the seamless integration and version control that Git LFS provides.

Practice this question →
34
MCQhard

A company has a multi-account AWS environment with separate accounts for development, staging, and production. They want to implement a CI/CD pipeline that deploys to each account sequentially after manual approvals. Which setup allows cross-account deployment with CodePipeline?

A.Create an IAM role in the target account with permissions for the pipeline service role to assume, and use that role in the deployment action.
B.Create separate pipelines in each account and trigger them via SNS from a master pipeline.
C.Use CodePipeline with cross-account actions by specifying the target account ID and region.
D.Use a single pipeline in the management account with different stages for each account.
AnswerA

Create an IAM role in the target account with a trust policy that allows the CodePipeline service role in the originating account to assume it via sts:AssumeRole. Then configure the deployment action (e.g., ECS, CloudFormation, S3) to use that role's ARN so the pipeline can perform resource operations in the target account without long-lived credentials. This follows least privilege and avoids hard-coding keys, and it is the canonical pattern documented by AWS for cross-account CodePipeline deployments.

Why this answer

CodePipeline supports cross-account deployments by having the pipeline service role in the source account assume an IAM role in the target account. This role must have a trust policy allowing the pipeline service role to assume it, and the deployment action (e.g., CloudFormation, CodeDeploy) references that target account role. This enables sequential deployment to development, staging, and production accounts with manual approval gates between stages.

Exam trap

The trap here is that candidates confuse CodePipeline's cross-account support with a simple account ID parameter, when in reality it requires explicit IAM role assumption and trust policy configuration.

How to eliminate wrong answers

Option B is wrong because it creates separate pipelines in each account, which defeats the purpose of a single CI/CD pipeline and introduces complexity in managing cross-account triggers via SNS; CodePipeline does not natively support triggering pipelines in other accounts via SNS without additional custom logic. Option C is wrong because CodePipeline does not support specifying a target account ID and region directly in a cross-account action; cross-account actions require an IAM role in the target account, not just an account ID. Option D is wrong because a single pipeline in the management account cannot deploy directly to resources in other accounts without assuming roles; the management account is not automatically trusted by member accounts for deployment actions.

Practice this question →
35
MCQmedium

A company is using AWS CodeBuild to compile a Java application. The build takes over 30 minutes, causing timeouts. The team has already increased the build timeout to the maximum. Which action would MOST effectively reduce the build time?

A.Use a smaller instance type to reduce provisioning time.
B.Enable dependency caching in the buildspec file.
C.Use a larger compute type in CodeBuild.
D.Split the build into multiple parallel CodeBuild projects.
AnswerB

Caches downloaded dependencies across builds.

Why this answer

Enabling dependency caching in the buildspec file allows CodeBuild to reuse previously downloaded dependencies (e.g., Maven or Gradle artifacts) across builds, significantly reducing the time spent on dependency resolution and download. Since the build already times out at the maximum timeout, caching directly addresses the bottleneck of repeated dependency fetching, which is a common cause of long build times in Java applications.

Exam trap

The trap here is that candidates often assume increasing compute resources (larger instance type) always speeds up builds, but they overlook that dependency caching addresses the most common bottleneck in Java builds—repeated artifact downloads—which is not solved by raw compute power alone.

How to eliminate wrong answers

Option A is wrong because using a smaller instance type reduces compute resources (CPU and memory), which would likely increase build time, not decrease it, and provisioning time is negligible compared to the actual build execution. Option C is wrong because using a larger compute type increases CPU and memory, which can speed up compilation but does not address the root cause of repeated dependency downloads; the build may still timeout if dependency resolution dominates the build time. Option D is wrong because splitting the build into multiple parallel CodeBuild projects adds orchestration complexity and overhead, and without addressing the dependency caching issue, each parallel project would still suffer from the same slow dependency resolution, potentially leading to partial timeouts.

Practice this question →
36
MCQhard

A company uses multiple AWS accounts: one for development, one for testing, and one for production. They want to implement a CI/CD pipeline using AWS CodePipeline that deploys the same application to all three accounts. The source code is stored in a CodeCommit repository in the development account. The pipeline should first build the application, then deploy to development, then after approval, deploy to testing, and finally after another approval, deploy to production. The deployment uses AWS CodeDeploy to deploy to EC2 instances in each account. The pipeline will be created in the development account. Which configuration will allow the pipeline to deploy to the testing and production accounts?

A.Create IAM roles in the testing and production accounts that grant CodeDeploy permissions, and configure the pipeline to assume those roles using the CodePipeline cross-account action.
B.Establish VPC peering between the accounts and allow the pipeline to communicate directly with CodeDeploy in the other accounts.
C.Create IAM users in testing and production accounts with programmatic access, and configure the pipeline to use those credentials.
D.Use AWS Organizations to create a shared service and grant the pipeline full access to all accounts.
AnswerA

Cross-account roles are the standard way to allow a pipeline in one account to deploy to another.

Why this answer

The pipeline can assume IAM roles in the testing and production accounts to perform cross-account deployments. CodePipeline's cross-account action requires you to specify the ARN of an IAM role in the target account that has the necessary permissions for CodeDeploy. This is the secure and recommended method for cross-account access.

Option B is incorrect because VPC peering does not provide cross-account IAM permissions; it only allows network connectivity. Option C is incorrect because using IAM users with programmatic access is not a best practice for service-to-service authentication; roles are more secure and manageable. Option D is incorrect because AWS Organizations does not automatically grant cross-account access; you still need to configure IAM roles and trust policies.

Practice this question →
37
MCQeasy

An organization is using AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment fails because the target group is not configured correctly. Which CodeDeploy component is responsible for registering instances with the load balancer?

A.The CodeDeploy agent configuration
B.The deployment group configuration
C.The AppSpec file hooks section
D.The application revision bundle
AnswerB

The deployment group configuration holds the load balancer or target group settings for the deployment. During an in-place or blue/green deployment, CodeDeploy automatically registers healthy instances with the target group defined in this configuration, and deregisters them before traffic shifts. It is this centrally defined setting, not anything in the application files or on the instance, that governs elastic load balancing integration.

Why this answer

The deployment group configuration in AWS CodeDeploy specifies the target group or load balancer for the deployment. CodeDeploy automatically registers instances in the Auto Scaling group with the specified target group as part of the deployment process. The AppSpec file hooks section defines custom lifecycle event hooks for scripts, but instance registration is handled by the CodeDeploy service based on the deployment group settings, not by hooks.

Exam trap

Candidates often incorrectly attribute instance registration to the AppSpec hooks section because hooks can run custom scripts. However, registration with a load balancer is a built-in function of CodeDeploy that relies on the deployment group configuration, not on user-defined hooks.

How to eliminate wrong answers

Option A is wrong because the CodeDeploy agent configuration is a file on the instance that controls the agent's behavior (e.g., logging, proxy settings) and does not handle load balancer registration. Option B is wrong because the deployment group configuration does specify the target group and load balancer settings, but it is not a component that directly registers instances; it defines the target group ARN and the deregistration delay, while the actual registration is performed by CodeDeploy service based on that configuration. Option D is wrong because the application revision bundle contains the application files and the AppSpec file, but it does not directly handle load balancer registration; it is the source of the deployment artifacts.

Practice this question →
38
MCQhard

Refer to the exhibit. The deployment succeeded but the application fails. What is the MOST likely cause?

A.The CodePipeline deployment action uses the wrong cluster.
B.The new task definition has a misconfigured database connection string or security group.
C.The ECS service is not registered with a target group.
D.The database is not available in the same Availability Zone.
AnswerB

A database connection timeout to the database IP address strongly indicates the new task definition is passing an invalid connection string or is associated with a security group that blocks the database port. The application container is starting and attempting to open a TCP connection, but the destination either rejects or silently drops it — exactly what a bad host, port, or restrictive inbound rule produces. This is an application-level configuration defect in the task definition that does not prevent the task from launching, which is why the deployment can still be marked successful.

Why this answer

The most common cause of a deployment succeeding but the application failing is a misconfiguration in the new task definition, such as an incorrect database connection string or a security group that does not allow traffic to the database. CodePipeline can successfully deploy the new task definition to ECS, but if the application cannot connect to its backend services due to these configuration errors, the application will fail at runtime. This aligns with the scenario where the deployment pipeline reports success but the application itself is non-functional.

Exam trap

The trap here is that candidates often assume a successful deployment means the application is fully functional, but AWS separates the deployment of infrastructure (task definition, service update) from the application's runtime dependencies, so a misconfigured connection string or security group can cause application failure post-deployment.

How to eliminate wrong answers

Option A is wrong because if the CodePipeline deployment action used the wrong cluster, the deployment would likely fail or the task would not run on the intended cluster, but the question states the deployment succeeded, so the cluster must be correct. Option C is wrong because if the ECS service were not registered with a target group, the deployment would still succeed (the task would run), but the service would not receive traffic from the load balancer; however, the question does not mention a load balancer or traffic routing issue, and the application failure is more likely due to a backend connectivity problem. Option D is wrong because database availability in the same Availability Zone is not a strict requirement for ECS tasks; ECS tasks can connect to databases across AZs as long as network connectivity and security group rules allow it, and the failure is more likely due to misconfigured connection strings or security groups.

Practice this question →
39
MCQhard

An organization uses AWS CodePipeline to deploy a serverless application using AWS Lambda and Amazon API Gateway. The pipeline includes a manual approval action. The team wants to ensure that the approval email is sent to multiple approvers and that any one of them can approve or reject. How should the approval action be configured?

A.Specify multiple email addresses in the 'ApproverEmail' field of the approval action.
B.Set the 'Approvers' field in the approval action to a comma-separated list of IAM user ARNs.
C.Add multiple IAM users to the pipeline's service role.
D.Create an Amazon SNS topic with multiple subscribers, and configure the approval action to use that SNS topic ARN.
AnswerD

This is the correct approach because CodePipeline's manual approval action has an 'SNSTopicArn' configuration field that, when set, causes the pipeline to publish an approval notification to the specified SNS topic. Each email address (or other endpoint) subscribed to that topic receives the notification, and any of those subscribers—assuming they have the necessary IAM permissions—can review and approve or reject the action via the AWS console, CLI, or API. This design cleanly supports multiple approvers and also allows you to use other SNS protocols such as SMS or Lambda for custom notification flows.

Why this answer

AWS CodePipeline's manual approval action can be configured to send notifications through an Amazon SNS topic. By creating an SNS topic with multiple subscribers (e.g., email addresses), any one of the subscribers can receive the approval request and take action (approve or reject). This satisfies the requirement for multiple approvers where any single approver can act.

Exam trap

The trap here is that candidates often assume the 'ApproverEmail' field can accept multiple addresses or that IAM-based approvers can be listed directly, but AWS CodePipeline relies on SNS for multi-approver scenarios, not direct email or IAM lists.

How to eliminate wrong answers

Option A is wrong because the 'ApproverEmail' field in the approval action accepts only a single email address, not multiple; specifying multiple addresses would cause a validation error. Option B is wrong because the 'Approvers' field does not exist in the approval action configuration; CodePipeline uses SNS topics for notifications, not IAM user ARNs. Option C is wrong because adding IAM users to the pipeline's service role does not control who receives approval notifications; the service role defines permissions for the pipeline itself, not approval recipients.

Practice this question →
40
MCQeasy

A DevOps engineer is setting up a CI/CD pipeline for a Node.js application. The application must be built, tested, and deployed to an Amazon ECS cluster. The team wants to use AWS CodeBuild to run unit tests and package the application as a Docker image, and AWS CodePipeline to orchestrate the workflow. Which artifact type should CodeBuild output to be used by a subsequent CodePipeline action?

A.A Docker image pushed to Amazon ECR.
B.A zip file containing the application source code.
C.A tarball stored in Amazon S3.
D.A JSON file with the image details.
AnswerD

This is correct because the ECS deploy action in CodePipeline consumes an image definitions file, typically named imagedefinitions.json, formatted as a JSON array mapping each ECS container name to its image URI (for example, [{"name":"web","imageUri":"123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest"}]). CodeBuild generates this file as a pipeline artifact after pushing the image to ECR, and CodePipeline uses it to create/update the task definition and trigger the deployment. The file must be at the artifact root with the recognized name; any other JSON structure or filename will cause the deploy action to fail.

Why this answer

CodePipeline's ECS deploy action requires an input artifact containing an imagedefinitions.json file that specifies the image URI. CodeBuild should produce this JSON file as its output artifact, not merely push the image to ECR. The subsequent deploy action reads the JSON file to determine which image to use, so the correct artifact type is a JSON file with image details.

Exam trap

The trap is that candidates may think CodeBuild passes the Docker image itself as an artifact, but in reality, the artifact is a configuration file (imagedefinitions.json) that tells the ECS deploy action which image to use.

How to eliminate wrong answers

Option B is wrong because a zip file containing the application source code is not a valid artifact type for an ECS deploy action; the deploy action requires image details, not raw source code. Option C is wrong because a tarball stored in Amazon S3, while it can be an artifact, does not provide the image URI and tag information needed by CodePipeline's ECS deploy action; the deploy action specifically expects an imagedefinitions.json file, not a generic archive. Option D is wrong because a JSON file with image details is actually the correct format, but the option does not specify that it must be named imagedefinitions.json and be part of a build output artifact; without that specific file name and structure, the ECS deploy action will fail to parse the deployment details.

Practice this question →
41
MCQhard

A company has a monolith application that takes over an hour to build. The DevOps team wants to implement continuous integration using AWS CodeBuild. The build environment requires a large amount of dependencies that are rarely updated. Which strategy will MINIMIZE build time and cost?

A.Enable Amazon S3 cache for the CodeBuild project to reuse dependencies from previous builds.
B.Store the dependencies in an Amazon S3 bucket and download them at the start of each build.
C.Create a custom Docker image that includes all dependencies and use it as the build environment.
D.Use a larger compute type for the CodeBuild project to speed up the build.
AnswerC

Creating a custom Docker image that pre-installs all dependencies means those dependencies already exist inside the image's local file system when the CodeBuild container starts, so there is no download phase at all. The build can proceed directly to compilation, packaging, and testing, making the build time deterministic and dramatically shorter for a monolith. This image should be stored in Amazon ECR and updated whenever the dependency set changes, ensuring the build environment is both fast and consistent.

Why this answer

By pre-baking all rarely-updated dependencies into a custom Docker image, the build environment is ready instantly without any download or installation steps. This eliminates the overhead of fetching dependencies at build time, which is the primary bottleneck for a monolith with a large dependency set, and minimizes both build duration and cost by reducing compute time.

Exam trap

The trap here is that candidates often assume caching (Option A) or downloading from S3 (Option B) is sufficient, but they overlook that for rarely-updated dependencies, pre-building them into a custom image eliminates the dependency installation step entirely, which is the most time-consuming part of the build.

How to eliminate wrong answers

Option A is wrong because Amazon S3 cache in CodeBuild is designed for caching intermediate build artifacts (e.g., compiled objects) to speed up incremental builds, but it does not eliminate the need to download or install dependencies from scratch on a fresh build environment; the cache must be populated and restored, which still incurs network transfer time and storage costs. Option B is wrong because downloading dependencies from an S3 bucket at the start of each build still requires significant network I/O and time, especially for a large dependency set, and does not reduce the build duration as effectively as having them pre-installed in the environment. Option D is wrong because using a larger compute type (e.g., more vCPUs/memory) only accelerates the build steps themselves (compilation, testing) but does not address the bottleneck of installing dependencies; the dependency installation time remains largely unchanged, and larger instances cost more per minute, increasing overall cost without proportional time savings.

Practice this question →
42
MCQeasy

A DevOps engineer is setting up a CI/CD pipeline for a microservices application using AWS CodePipeline. The pipeline includes a Test stage that runs integration tests against a staging environment. The engineer wants to ensure that manual approval is required before deploying to production. Which action should be taken?

A.Configure a CodeCommit approval rule template to block the merge.
B.Use CloudWatch Events to send a notification and wait for a custom signal.
C.Set the pipeline to only run on manual invocation.
D.Add a manual approval action in the pipeline stage before production deployment.
AnswerD

Manual approval actions pause the pipeline until approved.

Why this answer

AWS CodePipeline supports a manual approval action that can be added to any stage. By placing this action in the stage immediately before the production deployment, the pipeline will pause and require an authorized user to manually approve the transition, ensuring that integration tests have passed before any production release occurs.

Exam trap

The trap here is that candidates may confuse repository-level approval mechanisms (like CodeCommit approval rules) with pipeline-level deployment approvals, or assume that manual invocation alone satisfies the requirement for a conditional approval step.

How to eliminate wrong answers

Option A is wrong because CodeCommit approval rule templates are used to enforce code review policies on pull requests within the repository, not to control deployment approvals in a pipeline. Option B is wrong because CloudWatch Events can trigger notifications but cannot natively pause a pipeline and wait for a custom signal; implementing such a wait would require a custom Lambda function and additional complexity, whereas CodePipeline provides a built-in manual approval action. Option C is wrong because setting the pipeline to only run on manual invocation would prevent automated triggers (e.g., from code pushes), but it does not add a conditional approval step before production deployment; the entire pipeline would run without any pause for manual review.

Practice this question →
43
MCQmedium

An IAM policy is attached to a user. The user is trying to push a commit to the 'main' branch of the 'MyRepo' repository. The push is denied. What is the most likely reason?

A.The user does not have permission to push to any branch.
B.The policy does not allow the 'codecommit:GitPush' action for the main branch.
C.The resource ARN is incorrect.
D.The condition key 'codecommit:References' is not correctly formatted for an array value.
AnswerD

StringEquals with an array is invalid; should use set operators.

Why this answer

The condition key 'codecommit:References' must be formatted as an array value when used in an IAM policy to restrict pushes to specific branches. If the policy uses a string value instead of an array (e.g., 'refs/heads/main' instead of ['refs/heads/main']), the condition fails to match, and the push is denied even if the user has the 'codecommit:GitPush' action allowed. This is a common misconfiguration in IAM policies for CodeCommit.

Exam trap

The trap here is that candidates often assume the denial is due to a missing action permission (Option B) or a generic resource ARN issue (Option C), overlooking the subtle requirement that the 'codecommit:References' condition key must be formatted as an array value to work correctly with branch-specific restrictions.

How to eliminate wrong answers

Option A is wrong because the push is denied only for the 'main' branch, not all branches, indicating a branch-specific restriction rather than a blanket denial. Option B is wrong because the policy likely does allow 'codecommit:GitPush' for the repository, but the condition key on the branch reference is misconfigured, causing the denial. Option C is wrong because an incorrect resource ARN would typically result in an 'AccessDenied' error for all actions on the repository, not just pushes to a specific branch, and the question implies the user can access the repo otherwise.

Practice this question →
44
MCQeasy

A DevOps engineer needs to automatically roll back a CodeDeploy deployment if the number of failed instances exceeds a threshold. Which deployment configuration should be used?

A.Configure the deployment group to ignore failed instances.
B.Set the minimum number of healthy instances in the deployment configuration to trigger automatic rollback.
C.Use a CloudWatch alarm to trigger a rollback.
D.Use a custom deployment configuration that fails the deployment if any instance fails.
AnswerB

CodeDeploy can automatically roll back based on health thresholds.

Why this answer

Setting the minimum number of healthy instances in the deployment configuration directly controls when CodeDeploy triggers an automatic rollback. When the number of healthy instances falls below this threshold during a deployment, CodeDeploy automatically stops the deployment and rolls back to the last known good state, meeting the requirement to roll back based on failed instance count.

Exam trap

The trap here is that candidates often confuse a deployment failure with an automatic rollback, assuming that failing the deployment inherently reverts changes, but CodeDeploy requires explicit rollback configuration (via minimum healthy hosts or CloudWatch alarms) to actually revert to a previous revision.

How to eliminate wrong answers

Option A is wrong because ignoring failed instances would prevent any rollback from occurring, which is the opposite of the requirement. Option C is wrong because while CloudWatch alarms can trigger a rollback, they are not the deployment configuration itself; they monitor external metrics (e.g., CPU utilization) rather than the number of failed instances during the deployment. Option D is wrong because a custom deployment configuration that fails the deployment if any instance fails does not trigger an automatic rollback; it only fails the deployment without reverting to a previous version.

Practice this question →
45
MCQmedium

A development team is using AWS CodeCommit to store source code and AWS CodePipeline to automate builds and deployments. The team wants to ensure that builds and tests are triggered only when code is pushed to specific branches, and that manual approval is required before deploying to production. Which CodePipeline configuration should the team implement?

A.Configure the source action to trigger on all branches and add a manual approval step before the build stage.
B.Configure the source action with a branch filter for main, and add a manual approval step before the build stage.
C.Use a branch filter on the build action to run only for the main branch, and add a manual approval step before the deploy stage.
D.Configure the source action with a branch filter for main, and add a manual approval step before the production deployment stage.
AnswerD

The source action's branch filter ensures the pipeline only starts when commits are pushed to main, preventing feature branch work from entering the pipeline. The manual approval step immediately preceding the production deployment stage provides a human gate before the final artifact is deployed, meeting the requirement to require approval for production releases while keeping lower environments automated. This arrangement minimizes unnecessary builds and accurately enforces change management only where needed.

Why this answer

CodePipeline source actions support branch filters that restrict which Git branches trigger the pipeline. By filtering on 'main', only pushes to that branch initiate the pipeline. Adding a manual approval step before the production deployment stage ensures that no code reaches production without explicit human sign-off, meeting both requirements precisely.

Exam trap

The trap here is that candidates may confuse where branch filters can be applied (source action only) and where manual approval should be placed (before the production deploy stage, not before build), leading them to select options that filter incorrectly or place approval at the wrong stage.

How to eliminate wrong answers

Option A is wrong because triggering on all branches would cause builds and tests for every push, including feature branches, which violates the requirement to trigger only on specific branches. Option B is wrong because adding the manual approval step before the build stage would require approval before any build runs, even for non-production branches, and does not align with the requirement for approval before deploying to production. Option C is wrong because branch filters cannot be applied to build actions in CodePipeline; branch filtering is a source action configuration, and placing the approval step before the deploy stage is correct, but the filter placement is invalid.

Practice this question →
46
Multi-Selectmedium

Which TWO steps are required to set up a cross-account CI/CD pipeline where the source stage is in Account A (CodeCommit) and the deploy stage is in Account B (ECS)? (Choose 2.)

Select 2 answers
A.Create an IAM role in Account B that the pipeline in Account A can assume for the deploy action.
B.Configure an AWS KMS key in Account B and share it with Account A for encrypting artifacts.
C.Update the CodePipeline service role in Account A to include a trust policy that allows assuming the role in Account B.
D.Create a resource-based policy on the CodeCommit repository in Account B that grants access to the CodePipeline service role in Account A.
E.Create an S3 bucket in Account B to store the artifacts and grant cross-account access.
AnswersA, C

Correct: The IAM role in Account B is what CodePipeline assumes for the deploy action in ECS.

Why this answer

For a cross-account CI/CD pipeline where the source stage (CodeCommit) is in Account A and the deploy stage (ECS) is in Account B, only two steps are required: 1) Create an IAM role in Account B that the pipeline in Account A can assume for the deploy action (Option A). 2) Update the CodePipeline service role in Account A to include a trust policy that allows assuming the role in Account B (Option C). You do not need a KMS key in Account B; if the artifact bucket in Account A is encrypted with a customer-managed AWS KMS key, the key is in Account A and its policy must grant Account B's role kms:Decrypt, but that is not one of the required setup steps in the options. Option D is incorrect because the CodeCommit repository is in Account A, not Account B.

Option E is incorrect because the pipeline artifact bucket should reside in Account A, not Account B.

Exam trap

The trap is that the question originally expected three steps, but for this setup only the cross-account IAM role and the CodePipeline service role trust update are required. Candidates may incorrectly add a target-account KMS key or S3 bucket.

Practice this question →
47
MCQeasy

A DevOps engineer is setting up an AWS CodePipeline to deploy a web application to an EC2 instance using AWS CodeDeploy. The deployment group uses an in-place deployment configuration. The pipeline's deploy stage fails with the error: 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The engineer checks the CodeDeploy logs on the instance and finds that the 'BeforeInstall' lifecycle hook script is failing. The script attempts to download a package from an Amazon S3 bucket that is encrypted with SSE-KMS. What is the MOST likely cause of the failure?

A.The EC2 instance does not have internet access to reach the S3 bucket.
B.The S3 bucket name is misspelled in the 'BeforeInstall' script.
C.The IAM role attached to the EC2 instance lacks the 'kms:Decrypt' permission for the AWS KMS key used to encrypt the S3 object.
D.The CodeDeploy agent does not have permissions to read from the S3 bucket.
AnswerC

In CodeDeploy, lifecycle hook scripts (such as BeforeInstall) run on the target instance and use the instance's IAM role, not the CodeDeploy service role. If the S3 object is encrypted with an AWS KMS customer-managed key, the script's `aws s3 cp` or `aws s3api get-object` call requires both s3:GetObject on the bucket/object and kms:Decrypt permission for that key. Even if s3:GetObject is allowed, lacking kms:Decrypt causes the S3 client to fail with an AccessDeniedException when it attempts to retrieve the plaintext, making the lifecycle hook exit non-zero and the deployment fail. This is the exact scenario that produces a script failure pointing to encryption authorization.

Why this answer

The error occurs because the EC2 instance's IAM role lacks the `kms:Decrypt` permission for the AWS KMS key used to encrypt the S3 object. When the `BeforeInstall` script attempts to download the package, the AWS SDK or CLI on the instance must decrypt the object using the KMS key. Without this permission, the download fails, causing the lifecycle hook to fail and the overall deployment to abort due to too many failed instances.

Exam trap

The trap here is that candidates often assume the CodeDeploy agent handles all S3 access, but the script runs under the instance's IAM role, and missing KMS permissions are a common oversight when using encrypted artifacts.

How to eliminate wrong answers

Option A is wrong because the EC2 instance can access S3 via a VPC endpoint or NAT gateway without requiring internet access; the error is specifically about decryption, not network connectivity. Option B is wrong because a misspelled bucket name would cause a 'NoSuchBucket' error, not a KMS-related decryption failure. Option D is wrong because the CodeDeploy agent itself does not directly read from S3; the script runs under the instance's IAM role, and the agent's permissions are separate from the script's S3 access.

Practice this question →
48
MCQmedium

A development team uses AWS CodeCommit for source control. They want to enforce that all commits include a JIRA issue key in the commit message. What is the MOST efficient way to achieve this?

A.Use Amazon CloudWatch Events to detect new commits and invoke a Lambda function to validate the commit message.
B.Implement a pre-commit hook in each developer's local repository.
C.Configure a branch policy on the repository that requires commit message format.
D.Create a CodeCommit trigger that invokes an AWS Lambda function on every push to validate commit messages.
AnswerD

A CodeCommit trigger can be set up to invoke an AWS Lambda function whenever a push event occurs, and the event payload includes the full commit list with metadata such as the commit message and author. The Lambda function can programmatically validate each commit message against a required format or regex, and then take action such as sending an alert or invoking a rollback if validation fails. This is a serverless, centrally managed approach that runs on every push and cannot be bypassed by developers, making it the correct solution.

Why this answer

CodeCommit triggers can invoke an AWS Lambda function on every push event, allowing real-time validation of commit messages against a required pattern (e.g., JIRA issue key). This serverless approach enforces the policy centrally without relying on client-side configurations, making it the most efficient and reliable method for a team using AWS CodeCommit.

Exam trap

The trap here is that candidates confuse CodeCommit branch policies (which enforce approval workflows and restrict direct pushes) with the ability to validate commit message format, but branch policies do not support message validation—only CodeCommit triggers with Lambda can perform custom validation on commit content.

How to eliminate wrong answers

Option A is wrong because Amazon CloudWatch Events can detect CodeCommit events, but invoking a Lambda function via CloudWatch Events adds unnecessary complexity and latency compared to using a native CodeCommit trigger, which is designed for this exact purpose. Option B is wrong because a pre-commit hook in each developer's local repository is client-side and can be bypassed or not configured by all developers, failing to enforce the policy centrally. Option C is wrong because CodeCommit branch policies can enforce approval rules and restrict direct pushes, but they do not support validating commit message format; that capability is not available in CodeCommit branch policies.

Practice this question →
49
Multi-Selecthard

A company uses AWS CloudFormation to deploy a multi-tier application. The stack creation fails with a 'CREATE_FAILED' error for a resource. The engineer wants to troubleshoot the issue. Which TWO steps should the engineer take? (Choose TWO.)

Select 2 answers
A.Use the 'describe-stack-events' AWS CLI command to view the events.
B.Review the CloudWatch Logs log group for the stack to find detailed error logs.
C.Check the 'ResourceStatusReason' field of the failed resource in the stack events.
D.Run 'delete-stack' to remove the failed stack and start over.
E.Use the 'describe-stacks' AWS CLI command to get the stack outputs.
AnswersA, C

The describe-stack-events AWS CLI command is the correct programmatic way to inspect the full event history of a stack, including each resource's CREATE_FAILED event followed by the overall stack rollback event. Each event object contains a ResourceStatusReason property with the detailed error thrown by the failed resource, along with the logical resource ID, physical resource ID, and timestamps. This command is ideal for automation because it returns the exact same failure information you would see in the CloudFormation console, allowing you to log or alert on the root cause.

Why this answer

The 'describe-stack-events' AWS CLI command retrieves all stack events, including the specific event for the failed resource. This event contains the 'ResourceStatusReason' field, which provides the detailed error message from CloudFormation explaining why the resource creation failed. Option C is correct because checking the 'ResourceStatusReason' field in the stack events directly reveals the underlying error.

Option B is incorrect because CloudFormation does not automatically create a CloudWatch Logs log group for stack errors; resource-specific logs are only available if the resource itself writes to CloudWatch. During a stack creation failure, there may be no such logs to review. Option D is incorrect because deleting the stack would lose the event history and prevent effective troubleshooting.

Option E is incorrect because 'describe-stacks' only returns stack outputs and status, not failure details.

Exam trap

The main trap is that candidates may incorrectly think that CloudFormation automatically creates a CloudWatch Logs log group for all stack errors (Option B), or prematurely delete the stack (Option D) instead of investigating the failure using stack events and the ResourceStatusReason field.

Practice this question →
50
MCQeasy

A team wants to automate the deployment of a serverless application using AWS SAM. They have a template.yaml file defining Lambda functions, an API Gateway, and a DynamoDB table. Which command should they use to build and deploy the application?

A.aws cloudformation deploy --template-file template.yaml
B.sam package --output-template-file packaged.yaml
C.sam build && sam deploy
D.sam deploy --guided
AnswerC

This is the correct non-interactive deployment sequence for an AWS SAM application in an automated pipeline. `sam build` prepares the application by installing dependencies, compiling code, and creating the deployment artifacts required for Lambda functions and layers. `sam deploy` then packages these artifacts, uploads them to S3, and uses AWS CloudFormation to create or update the stack, all without requiring manual intervention.

Why this answer

The correct command sequence is `sam build && sam deploy` because AWS SAM requires the `sam build` command to transform the SAM template into an AWS CloudFormation template with the necessary artifact packaging, and then `sam deploy` to create or update the stack. Option C is the only choice that performs both the build (which resolves local dependencies and prepares deployment artifacts) and the deployment step, which is essential for a serverless application defined in a SAM template.

Exam trap

The trap here is that candidates often confuse `sam deploy` with `aws cloudformation deploy` or assume `sam deploy --guided` can handle the entire workflow without a separate build step, not realizing that `sam build` is mandatory to transform SAM-specific resources into standard CloudFormation resources and to prepare deployment artifacts.

How to eliminate wrong answers

Option A is wrong because `aws cloudformation deploy --template-file template.yaml` directly uses the raw SAM template, which AWS CloudFormation cannot process without first being transformed by `sam build` or `sam package`; it would fail due to unsupported SAM-specific resources like `AWS::Serverless::Function`. Option B is wrong because `sam package` only uploads artifacts to S3 and generates a packaged template, but it does not deploy the stack; it must be followed by a deploy command. Option D is wrong because `sam deploy --guided` is an interactive mode that prompts for parameters and configuration but still requires the template to be built first (i.e., `sam build` must run before `sam deploy --guided`); running it alone without a prior build will fail.

Practice this question →
51
MCQeasy

A development team uses AWS CodeCommit to store source code and AWS CodePipeline to automate builds and deployments. The team wants to ensure that every commit to the main branch triggers a build and deployment to a test environment. Which action should be taken?

A.Create a CodeBuild project that watches the main branch and starts a pipeline.
B.Use AWS Lambda to poll the repository and start the pipeline on new commits.
C.Set up an Amazon CloudWatch Events rule that matches commits to the main branch and targets the CodePipeline.
D.Configure the source stage of the CodePipeline to use the CodeCommit repository and specify the main branch.
AnswerD

In CodePipeline, a source stage with a CodeCommit action automatically subscribes to repository events on the specified branch (e.g., main) and triggers a new pipeline execution whenever a commit is pushed. This is the standard, fully managed integration: CodePipeline creates the necessary event rule to detect the branch update and passes the commit ID and repository name as inputs to subsequent stages. By specifying the branch in the action configuration, you also get filtering on that branch only, making this the simplest and most reliable way to achieve continuous delivery from CodeCommit.

Why this answer

CodePipeline natively integrates with CodeCommit as a source action. By configuring the source stage to use the CodeCommit repository and specifying the main branch, the pipeline automatically triggers on every commit to that branch without any additional infrastructure or polling. This is the simplest and most reliable approach, as CodePipeline uses Amazon CloudWatch Events under the hood to detect changes.

Exam trap

The trap here is that candidates may overthink the solution and choose a more complex option (like Lambda polling or manual CloudWatch Events rules) instead of recognizing that CodePipeline's native source configuration already handles event-driven triggers automatically.

How to eliminate wrong answers

Option A is wrong because CodeBuild does not have a built-in 'watch' feature for branches; it can only be triggered by events or manual invocation, and creating a CodeBuild project to watch a branch would require custom polling logic, which is unnecessary. Option B is wrong because using Lambda to poll the repository is an anti-pattern; it introduces latency, cost, and complexity, whereas CodePipeline already provides event-driven triggers via CloudWatch Events. Option C is wrong because while a CloudWatch Events rule can trigger a pipeline, it is redundant and less direct; CodePipeline automatically creates the necessary CloudWatch Events rule when you configure the source stage with CodeCommit, so manually creating one is unnecessary and can lead to duplicate triggers or misconfiguration.

Practice this question →
52
MCQhard

A company uses AWS CodePipeline with a GitHub source action. They want to automatically start the pipeline when a pull request is merged to the main branch. However, the pipeline also starts on every push to any branch. How can they limit the pipeline to only trigger on push events to the main branch?

A.Use a Lambda function as a source action instead of GitHub.
B.Create a GitHub webhook manually and point it to a Lambda function that starts the pipeline only for main branch pushes.
C.Configure the source action's 'Branch' field to 'main' and set 'PollForSourceChanges' to false, and use a webhook with filters.
D.Add a condition in the pipeline's first stage to check the branch name.
AnswerC

This is the correct approach. Setting the source action's Branch field to 'main' and disabling PollForSourceChanges ensures that the pipeline uses the CodePipeline-managed GitHub webhook instead of legacy polling, preventing duplicate executions. The webhook is configured with event filters that only forward push events for refs/heads/main, so the pipeline starts only when the default/main branch is updated. This gives you native, real-time triggering without custom code and without starting pipelines for other branches.

Why this answer

It configures the source action to only respond to push events on the main branch by setting the 'Branch' field to 'main' and disabling polling ('PollForSourceChanges': false), while using a webhook with branch filters. This ensures that only pushes to the main branch trigger the pipeline, not pushes to any other branch.

Exam trap

The trap here is that candidates often think branch filtering must be done inside the pipeline stages (Option D) or via a custom Lambda (Options A and B), overlooking CodePipeline's native webhook branch filter configuration that prevents the pipeline from even starting on non-matching branches.

How to eliminate wrong answers

Option A is wrong because replacing the GitHub source action with a Lambda function adds unnecessary complexity and does not inherently solve the branch filtering issue; the Lambda would still need to implement branch filtering logic. Option B is wrong because manually creating a GitHub webhook to a Lambda function is an overengineered approach that bypasses CodePipeline's native webhook integration, which already supports branch filtering. Option D is wrong because adding a condition in the pipeline's first stage to check the branch name would still cause the pipeline to start on every push, wasting resources and potentially failing the stage, rather than preventing the trigger entirely.

Practice this question →
53
MCQmedium

Refer to the exhibit. A team uses this buildspec.yml file in AWS CodeBuild. After the build, they expect the artifacts to be placed in a folder structure, but all files are in the root of the output artifact. What is the reason?

A.The 'files' section only includes '**/*' which does not preserve paths.
B.The 'discard-paths' option is set to 'yes', which flattens the directory structure.
C.The 'base-directory' is not specified, so CodeBuild uses the root of the build output.
D.The 'name' property is missing, causing artifacts to be stored without structure.
AnswerB

In CodeBuild buildspec artifacts, setting discard-paths to 'yes' explicitly instructs CodeBuild to strip all directory information from the matched files. As a result, every file selected by the files glob is placed directly into the artifact root, losing any subdirectory hierarchy. This is the exact mechanism responsible for the observed flat output structure.

Why this answer

The `discard-paths` option in the `artifacts` section of a buildspec.yml file, when set to `yes`, explicitly flattens the directory structure. This means that even if the `files` glob pattern `**/*` matches files in subdirectories, they are all placed at the root of the output artifact, discarding their original relative paths. Without this setting (or when set to `no`), the directory hierarchy would be preserved.

Exam trap

The trap here is that candidates often assume the `files` glob pattern `**/*` automatically flattens the structure, but in CodeBuild, path flattening is controlled solely by the `discard-paths` boolean, not by the glob syntax itself.

How to eliminate wrong answers

Option A is wrong because the `files` section with `**/*` does preserve paths by default; it matches all files recursively while maintaining their relative directory structure unless `discard-paths` is explicitly set to `yes`. Option C is wrong because the `base-directory` is optional; if not specified, CodeBuild uses the root of the build output (the default `CODEBUILD_SRC_DIR`), which does not cause flattening—it simply means the artifact is created from the entire build output root. Option D is wrong because the `name` property is optional and only controls the artifact's filename (e.g., a zip or tar name), not the internal directory structure of the artifact; omitting it does not flatten paths.

Practice this question →
54
MCQmedium

A company uses AWS CodePipeline to deploy a microservices application to Amazon ECS. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (CodeDeploy). Recently, deployments have been failing intermittently during the deploy stage with the error: 'The service has reached its maximum number of running tasks.' How should a DevOps engineer resolve this issue?

A.Increase the memory reservation for the task definition
B.Update the ECS service configuration to increase the maximum number of tasks
C.Configure an Amazon ECS Service Auto Scaling policy to scale out
D.Increase the number of concurrent deployments allowed in CodeDeploy
AnswerB

This is the direct fix: the ECS service has an explicit maximum task count (specified via the service's `maximumPercent` in deployment configuration or the `MaxTasks` parameter) that is being exceeded. By increasing that maximum, you permit the service to scale out to the required number of running tasks. The error message specifically indicates that the service cannot add more tasks because this limit is hit, so adjusting the maximum resolves the root cause.

Why this answer

The error 'The service has reached its maximum number of running tasks' indicates that the ECS service's desired count or maximum tasks (if using a placement constraint) has been hit. Updating the ECS service configuration to increase the maximum number of tasks (or the desired count) allows the deployment to proceed by accommodating the new tasks during a rolling update. This directly resolves the capacity limit that CodeDeploy encounters when trying to launch new tasks.

Exam trap

The trap here is that candidates confuse ECS service task limits with CodeDeploy deployment limits or auto scaling policies, leading them to choose options that address scaling or concurrency rather than the explicit task count cap on the ECS service itself.

How to eliminate wrong answers

Option A is wrong because increasing memory reservation does not change the maximum number of tasks the service can run; it only affects resource allocation per task and may cause placement failures but does not address the task count limit. Option C is wrong because Amazon ECS Service Auto Scaling adjusts the desired count based on metrics like CPU/memory, but it does not override the hard limit on maximum tasks; the error occurs because the service already reached its configured maximum, and auto scaling cannot exceed that maximum. Option D is wrong because CodeDeploy's concurrent deployment limit controls how many deployments can run simultaneously across the pipeline, not the number of tasks within a single ECS service; the error is specific to the ECS service task capacity, not CodeDeploy's parallelism.

Practice this question →
55
MCQmedium

A DevOps team uses AWS CodePipeline to deploy a microservices application. The pipeline includes a CodeBuild project that runs unit tests. Recently, builds have been failing intermittently due to test timeouts. The team wants to improve the reliability of the pipeline without increasing the build timeout. Which action should the team take?

A.Increase the build timeout to the maximum allowed value of 8 hours.
B.Use AWS CodeDeploy to run the unit tests on EC2 instances with more CPU and memory.
C.Modify the unit tests to be non-flaky by adding retries for network calls.
D.Configure the CodeBuild project to run tests in parallel by using separate build environments or test splits.
AnswerD

CodeBuild supports batch builds and test splitting (e.g., dividing the test suite into shards and running them across multiple concurrent build environments), which can dramatically reduce wall-clock time and keep the build under the timeout threshold. With Amazon CodeBuild's batch configuration, you can define a buildspec that splits tests by file, directory, or using tools like pytest-xdist, and CodeBuild orchestrates concurrent execution. This directly addresses the root cause by parallelizing CPU-intensive work rather than extending the deadline or masking flaky tests.

Why this answer

Running unit tests in parallel using separate build environments or test splits directly addresses intermittent timeouts by reducing the total execution time without increasing the build timeout. This approach leverages CodeBuild's ability to run multiple build jobs concurrently, distributing the test load and improving pipeline reliability.

Exam trap

The trap here is that candidates may confuse increasing the timeout (Option A) as a valid fix for intermittent failures, when the correct approach is to optimize test execution time through parallelism rather than extending the timeout window.

How to eliminate wrong answers

Option A is wrong because increasing the build timeout to 8 hours does not fix the root cause of flaky test timeouts; it only masks the symptom and can lead to wasted compute costs and delayed feedback. Option B is wrong because using CodeDeploy to run unit tests on EC2 instances with more CPU and memory is an over-engineered solution that introduces additional infrastructure management overhead and does not inherently resolve intermittent timeouts caused by test flakiness or resource contention. Option C is wrong because adding retries for network calls only addresses one specific type of flaky test (network-related), but the problem statement indicates intermittent timeouts from test execution, not necessarily network failures; retries can also mask underlying issues without improving reliability.

Practice this question →
56
MCQmedium

A development team uses AWS CodeCommit for source control and AWS CodePipeline for CI/CD. The pipeline has a source stage that pulls from a CodeCommit repository, a build stage using AWS CodeBuild, and a deploy stage that uses AWS CodeDeploy to deploy to an EC2 Auto Scaling group. The team notices that the pipeline frequently fails at the deploy stage with the error 'The deployment failed because the deployment group's deployment configuration specifies a minimum healthy host count of 1, but 0 healthy hosts are available.' What is the MOST likely cause of this issue?

A.The IAM role for CodePipeline does not have sufficient permissions to access the CodeCommit repository.
B.The build artifacts are not being stored in an S3 bucket.
C.The EC2 instances are not registered with a Classic Load Balancer.
D.The CodeDeploy agent is not installed or is not running on the EC2 instances.
AnswerD

The CodeDeploy agent is a daemon installed on EC2 instances that handles deployment instructions, lifecycle events, and reporting instance status to the CodeDeploy service. Without a running agent, the service never receives a heartbeat or a success signal, so the instance is considered unhealthy and the deployment fails with an error like 'No healthy instances found'. This directly matches the symptom described, and verifying agent status with 'sudo service codedeploy-agent status' or checking /var/log/aws/codedeploy-agent/install.log is the first troubleshooting step. Installing or starting the agent on the tagged instances resolves the failure.

Why this answer

The error message indicates that the CodeDeploy deployment is failing because zero healthy hosts are available in the deployment group. The most common cause is that the CodeDeploy agent is not installed or not running on the EC2 instances, preventing them from reporting their health status to the CodeDeploy service. Without a healthy agent, the instances cannot execute the deployment lifecycle hooks, and CodeDeploy considers them unhealthy, leading to the failure.

Exam trap

The trap here is that candidates often confuse deployment failures caused by missing agents with network or load balancer issues, but the specific error about '0 healthy hosts' directly points to the agent not running or not reporting health, not to load balancer registration or pipeline permissions.

How to eliminate wrong answers

Option A is wrong because the IAM role for CodePipeline lacking permissions to access the CodeCommit repository would cause the source stage to fail, not the deploy stage. Option B is wrong because build artifacts not being stored in an S3 bucket would cause the build or source stage to fail, as CodePipeline requires artifacts to be passed between stages; the deploy stage error specifically relates to host health, not artifact storage. Option C is wrong because EC2 instances not being registered with a Classic Load Balancer is not a requirement for CodeDeploy to work; CodeDeploy can deploy to instances directly via tags or Auto Scaling groups, and the error is about host health, not load balancer registration.

Practice this question →
57
MCQhard

A company uses AWS CodeBuild to run integration tests as part of a pipeline. The tests require access to an Amazon RDS database. The RDS instance is in a private subnet with no public access. The CodeBuild project is configured with a VPC. Which additional configuration is necessary to ensure the build can connect to the database?

A.Add an IAM policy that grants the CodeBuild service role access to the RDS instance.
B.Configure the security group for the RDS instance to allow inbound traffic from the security group associated with the CodeBuild project.
C.Create a VPC endpoint for Amazon RDS.
D.Attach a NAT gateway to the private subnet.
AnswerB

The RDS instance's security group must have an inbound rule that allows TCP traffic on the database port (e.g., 3306, 5432) from the security group ID attached to the CodeBuild project's elastic network interface. This is the standard way to permit traffic between AWS resources within a VPC, because security group rules reference other security groups as sources. The CodeBuild project must also be configured with VPC settings (VPC ID, subnets, and security groups) so its ENI is placed in the same network context as the RDS instance, enabling the security group-to-security group allow.

Why this answer

The CodeBuild project is configured with a VPC, meaning it runs inside a private subnet and uses an elastic network interface (ENI) with an associated security group. To allow the build container to connect to the RDS instance, the RDS security group must have an inbound rule that permits traffic on port 3306 (or the appropriate database port) from the CodeBuild security group. This is a standard network-layer access control; no additional IAM or gateway is required for connectivity.

Exam trap

The trap here is that candidates confuse IAM permissions (which control API access) with network security group rules (which control traffic flow), leading them to select Option A, or they mistakenly think a VPC endpoint is needed for database connectivity when it is only for API calls.

How to eliminate wrong answers

Option A is wrong because IAM policies control authentication and authorization for AWS API calls, not network-level traffic; RDS security groups control inbound traffic at the network layer, and IAM does not open ports. Option C is wrong because a VPC endpoint for RDS is used to access the RDS API (e.g., to modify DB instances) from within a VPC without internet traffic, not to connect to the database engine itself; database connections use the database port, not the RDS API endpoint. Option D is wrong because a NAT gateway provides outbound internet access for private subnets, but the RDS instance is in the same VPC, so traffic between CodeBuild and RDS stays within the VPC and does not require internet access.

Practice this question →
58
MCQhard

A company runs a critical application on Amazon ECS with Fargate. They use blue/green deployments via AWS CodeDeploy. During a recent deployment, the new task set failed health checks and CodeDeploy automatically rolled back. However, the old task set also became unhealthy shortly after rollback. What could explain this?

A.The CloudWatch alarm that triggered the rollback also stopped the old task set.
B.CodeDeploy did not drain connections from the Application Load Balancer before terminating the old task set.
C.The ECS service auto-scaling policy reduced the desired count of the old task set during the deployment.
D.The new application version changed the database schema, which broke the old version after rollback.
AnswerD

When the new version applied a forward-only database schema migration, the schema changed irreversibly for the running environment. CodeDeploy rolled back the ECS task set to the old code, but that old code cannot understand the new schema, causing errors, failed health checks, and a broken application. This is the recognized cause: database changes are not automatically rolled back, so they break the previous version. The fix is to implement reverse migrations or use an expansion-contraction pattern.

Why this answer

A backward-incompatible database schema change (e.g., a column removal or renaming) applied by the new application version can corrupt or invalidate the data that the old version relies on. When CodeDeploy rolls back to the old task set, the old application cannot function correctly with the altered schema, causing it to fail health checks. This is a classic rollback failure scenario where the deployment changes shared state (the database) that persists beyond the task set lifecycle.

Exam trap

The trap here is that candidates assume rollback always restores full functionality, overlooking that shared mutable state (like a database schema) can persist across deployments and break the old version after rollback.

How to eliminate wrong answers

Option A is wrong because CloudWatch alarms that trigger a rollback do not stop the old task set; they only initiate the rollback process, which CodeDeploy handles by shifting traffic back to the original task set. Option B is wrong because CodeDeploy with ECS blue/green deployments uses the 'original' task set's listener rule weight to shift traffic back during rollback; it does not terminate the old task set until the deployment succeeds, and connection draining is handled by the ALB's deregistration delay, not by CodeDeploy. Option C is wrong because ECS Service Auto Scaling policies do not reduce the desired count of the old task set during a deployment; CodeDeploy manages the desired count of both task sets independently, and auto-scaling is suspended or operates on the active service, not on the old task set being preserved for rollback.

Practice this question →
59
MCQhard

A company uses AWS CloudFormation to manage infrastructure. The development team wants to promote changes from a development environment to a production environment using change sets. They need to ensure that the production stack is not updated if there are any changes to the stack's IAM policies. Which approach should the team use?

A.Enable drift detection on the production stack and compare with the development stack.
B.Create a ChangeSet from the updated template, review the changes for IAM modifications, and execute only if no IAM changes are present.
C.Use AWS CloudFormation StackSets to deploy to multiple accounts and use stack instance filters.
D.Use a custom resource in the template that checks for IAM changes and fails the update.
AnswerB

ChangeSets provide a preview of all changes, including IAM resource modifications.

Why this answer

AWS CloudFormation change sets allow you to review the proposed changes to a stack before executing them. By creating a change set from the updated template, the team can inspect the list of changes and specifically look for any modifications to IAM resources (e.g., AWS::IAM::Role, AWS::IAM::Policy). If the change set contains IAM-related changes, they can choose not to execute it, thereby preventing unintended updates to the production stack's IAM policies.

Exam trap

The trap here is that candidates may confuse drift detection (which is reactive) with change sets (which are proactive), or they may think that StackSets or custom resources are needed for multi-environment promotion, when in fact change sets provide a simple, native mechanism for reviewing and selectively applying updates.

How to eliminate wrong answers

Option A is wrong because drift detection compares the current state of a stack with its expected template configuration, but it does not prevent updates; it only reports differences after they occur. Option C is wrong because AWS CloudFormation StackSets are designed for deploying identical templates across multiple accounts and regions, not for reviewing or blocking changes based on IAM modifications in a single production stack. Option D is wrong because a custom resource that checks for IAM changes and fails the update would require complex custom logic and would not leverage the built-in change set review capability; it also risks breaking the update process entirely rather than providing a controlled review step.

Practice this question →
60
MCQhard

Refer to the exhibit. A CodeBuild project uses this buildspec. The build fails with the error: 'The runtime version specified is not supported in this environment.' What change should be made?

A.Add an install command to install Node.js 12 from source.
B.Remove the runtime-versions section and install Node.js manually.
C.Update the runtime-versions to nodejs: 14.
D.Change the build environment to use a custom image that includes Node.js 12.
AnswerC

Updating runtime-versions to nodejs:14 is the correct fix because the CodeBuild standard image likely no longer includes Node.js 12 after that version reached end-of-life or was deprecated from the managed environment. By specifying an actively supported runtime like Node.js 14, CodeBuild provisions the matching pre-installed runtime, eliminating the "run not available" error. This change is simple, declarative, and leverages CodeBuild's managed image updates without requiring manual installation or custom images.

Why this answer

The CodeBuild managed image for the specified environment (likely Ubuntu Standard 5.0 or similar) only supports Node.js runtime versions 14 and above. The error indicates that Node.js 12 is not available in the runtime-versions section of the buildspec for that environment. Updating to nodejs: 14 aligns with the supported runtime versions in the managed image, resolving the error without requiring custom images or manual installation.

Exam trap

The trap here is that candidates may assume they can install any Node.js version manually (Option A or B) without realizing that the runtime-versions section is validated against the managed image's pre-configured runtime manager, and the error is not about missing Node.js but about the version not being in the allowed list.

How to eliminate wrong answers

Option A is wrong because installing Node.js 12 from source via an install command would not override the runtime-versions section, and the build environment's runtime version validation occurs before the install phase, so the error would persist. Option B is wrong because removing the runtime-versions section and installing Node.js manually would still fail, as the build environment's default runtime (if any) might not match, and the error is triggered by the environment's lack of support for Node.js 12, not by the presence of the section. Option D is wrong because while using a custom image with Node.js 12 would work, it is an unnecessary and more complex solution compared to simply updating the runtime-versions to a supported version like nodejs: 14, which is the intended fix.

Practice this question →
61
MCQmedium

A team uses AWS CloudFormation to manage infrastructure. They have a stack that creates an Amazon RDS instance. During an update, the stack fails with 'CREATE_FAILED' for the DB instance resource, and the error message indicates 'The DB instance already exists.' What is the most likely cause?

A.An RDS instance with the same identifier already exists in the account and region.
B.The stack update is trying to replace the DB instance without a proper UpdateReplace policy.
C.The stack has a DeletionPolicy of Retain on the RDS instance.
D.The RDS instance has deletion protection enabled.
AnswerA

DB instance identifiers must be unique per region; if one exists, creation fails.

Why this answer

The error 'The DB instance already exists' indicates that CloudFormation is attempting to create a new RDS instance with a DB instance identifier that is already in use within the same AWS account and region. Since DB instance identifiers must be unique per account and region, the creation fails. This typically occurs when a stack update triggers a resource replacement (e.g., due to a property change that requires recreation) and the old instance was not deleted or its identifier is still reserved.

Exam trap

The trap here is that candidates often confuse 'DeletionPolicy' or 'deletion protection' with the root cause, but the error is specifically about a duplicate identifier during creation, not about deletion or retention policies.

How to eliminate wrong answers

Option B is wrong because CloudFormation does not have an 'UpdateReplace policy'; instead, it uses replacement behaviors based on the resource's 'RequiresRecreation' property, and the error here is about a duplicate identifier, not a missing policy. Option C is wrong because a 'DeletionPolicy' of 'Retain' would cause the old RDS instance to persist after stack deletion, but during an update replacement, CloudFormation creates the new instance before deleting the old one, leading to a duplicate identifier conflict — however, the error message specifically says 'already exists,' which is the direct cause, not the DeletionPolicy itself. Option D is wrong because deletion protection prevents the instance from being deleted via the AWS API, but it does not prevent CloudFormation from attempting to create a new instance with the same identifier; the error is about creation, not deletion.

Practice this question →
62
MCQmedium

A team is using AWS CloudFormation to manage infrastructure. They want to implement a change management process where any modifications to the stack must be reviewed and approved. Which feature should they use?

A.Change Sets
B.StackSets
C.Drift Detection
D.Stack Policy
AnswerA

Change Sets let you preview the exact changes CloudFormation will make to a stack before executing them. When you create a change set, CloudFormation compiles a list of actions (add/remove/modify resources) that you can review in JSON or summary form, and you can approve, edit, or delete it without touching live infrastructure. This makes them the ideal mechanism for an approval-based change workflow, because the set can be submitted to a reviewer who validates it before the stack update is actually run.

Why this answer

Change Sets allow you to preview how proposed changes to a CloudFormation stack will impact your running resources before you execute them. This enables a review-and-approve workflow because you can generate a change set, have a team member or automated process inspect the list of resource additions, modifications, or deletions, and then either execute or discard the change set. This directly supports the required change management process.

Exam trap

The trap here is that candidates confuse Stack Policies (which protect resources from accidental updates) with a change review mechanism, but Stack Policies do not provide a preview or approval step—they only block certain updates at execution time.

How to eliminate wrong answers

Option B is wrong because StackSets are used to deploy CloudFormation stacks across multiple accounts and regions, not to review or approve changes to a single stack. Option C is wrong because Drift Detection identifies whether a stack's actual resources have diverged from its template, but it does not provide a mechanism to preview or approve proposed modifications. Option D is wrong because a Stack Policy is a resource-level permission document that prevents accidental updates or deletions of specific stack resources, but it does not generate a preview of changes or enforce a review-and-approve workflow.

Practice this question →
63
MCQhard

A company is using AWS CodeDeploy with a blue/green deployment strategy for an Amazon ECS service. After a deployment, the new task set fails health checks, and CodeDeploy automatically rolls back to the original task set. However, the rollback fails because the original task set's desired count is set to 0. What is the most likely cause?

A.The original task set's desired count was set to 0 during the blue/green deployment and the rollback is unable to restore it because the original task definition is no longer available.
B.The original task set's health checks are failing.
C.The original task set's CloudFormation stack was deleted during the deployment.
D.The original task set was deregistered from the target group.
AnswerA

In a blue/green ECS deployment, CodeDeploy shifts traffic to the replacement task set and sets the original task set's desired count to zero. When a rollback triggers, CodeDeploy attempts to restore that original task set, but if its task definition revision was deregistered or replaced, ECS cannot recreate the task set. The missing task definition makes it impossible to satisfy the service's desired count, leaving the service at zero. This is why keeping the original task definition revision available is critical for successful rollbacks.

Why this answer

During a blue/green deployment on ECS, CodeDeploy sets the original (blue) task set's desired count to 0 after the new (green) task set is created and begins serving traffic. If the green task set fails health checks and triggers an automatic rollback, CodeDeploy attempts to restore the original task set's desired count to its previous value. However, if the original task definition has been deregistered or deleted (e.g., due to lifecycle policies or manual cleanup), the rollback cannot scale the original task set back up, causing the rollback to fail.

Exam trap

The trap here is that candidates assume the rollback fails because the original task set is unhealthy or deregistered from the target group, when in reality the root cause is the deletion of the original task definition, which CodeDeploy needs to recreate the task set during rollback.

How to eliminate wrong answers

Option B is wrong because the original task set's health checks are irrelevant — the original task set is not running (desired count is 0) and thus cannot fail health checks; the rollback failure is due to the inability to restore the task set, not health check failures. Option C is wrong because CloudFormation stacks are not involved in the CodeDeploy blue/green deployment process for ECS; the deployment is managed by CodeDeploy and ECS services, not CloudFormation stack deletion. Option D is wrong because deregistering the original task set from the target group would not prevent the rollback from scaling it up — the rollback fails because the original task definition is missing, not because of target group registration.

Practice this question →
64
MCQmedium

During a deployment using AWS CodeDeploy, the deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The deployment group is configured with a minimum healthy instances of 75%. What could be the cause?

A.The deployment configuration timeout is too short.
B.The CodeDeploy service role does not have sufficient permissions.
C.The instances are not running the CodeDeploy agent.
D.More than 25% of the instances failed the deployment.
AnswerD

A deployment configuration with a 25% failure margin means that the minimum healthy instances threshold is set to 75% (or the equivalent fleet percentage). CodeDeploy continuously monitors the health of each instance across lifecycle events; if more than one quarter of the instances fail or abort, the remaining healthy percentage drops below 75%, and CodeDeploy terminates the deployment to protect the service. The state becomes 'Failed' with a message about the minimum healthy instances threshold being breached.

Why this answer

The error message explicitly states that too many individual instances failed deployment and too few healthy instances are available. With a minimum healthy instances setting of 75%, the deployment fails when more than 25% of the instances in the deployment group fail their deployment. This is a built-in safety mechanism in AWS CodeDeploy to prevent cascading failures and ensure application availability.

Exam trap

The trap here is that candidates may confuse the 'minimum healthy instances' threshold with other deployment configuration settings like timeout values or agent health, when in fact the error message directly indicates that the threshold of 75% healthy instances was breached because more than 25% of instances failed.

How to eliminate wrong answers

Option A is wrong because a timeout that is too short would cause individual instance deployment failures, but the error message specifically points to the aggregate failure threshold being exceeded, not a timeout issue. Option B is wrong because insufficient permissions in the CodeDeploy service role would cause a different error, such as 'AccessDenied' or 'Unable to access the S3 bucket', not the specific healthy-instances threshold error. Option C is wrong because if instances were not running the CodeDeploy agent, they would appear as 'Unknown' or 'Not registered' in the deployment group, and the error would be about missing agents, not about too many failed instances relative to healthy ones.

Practice this question →
65
MCQeasy

A DevOps engineer is setting up an AWS CodeBuild project that needs to access resources in a VPC, such as an Amazon RDS database. The engineer has configured the CodeBuild project to run in the VPC. Which additional configuration is required for CodeBuild to pull the build Docker image?

A.Create a VPC peering connection to another VPC that has internet access.
B.Configure a VPC gateway endpoint for Amazon ECR.
C.Attach an internet gateway to the VPC and add a default route to it.
D.Create a VPC interface endpoint for Amazon ECR and configure the CodeBuild project to use it.
AnswerD

This is correct because interface endpoints (AWS PrivateLink) for Amazon ECR provide private connectivity from your VPC without requiring internet access. You need to create both the ECR API endpoint and the ECR Docker Registry (DKR) endpoint, and then configure the CodeBuild project to use the VPC, subnet, and security group associated with those endpoints. This allows the build to pull images and push to ECR securely over the AWS network.

Why this answer

When a CodeBuild project runs inside a VPC, it loses default internet access, so it cannot reach public endpoints like Amazon ECR (Docker Hub or ECR) to pull the build image. A VPC interface endpoint (powered by AWS PrivateLink) creates a private, highly available connection to Amazon ECR within the VPC, allowing CodeBuild to pull images without traversing the internet. This is the correct solution because it provides direct, secure access to ECR while keeping all traffic within the AWS network.

Exam trap

The trap here is that candidates often confuse gateway endpoints (which work only for S3 and DynamoDB) with interface endpoints (which are required for services like ECR, ECS, and API Gateway), leading them to incorrectly select option B.

How to eliminate wrong answers

Option A is wrong because VPC peering connects two VPCs but does not provide internet access or a route to Amazon ECR; it would only allow communication between the peered VPCs, not to external services. Option B is wrong because a VPC gateway endpoint is only supported for Amazon S3 and DynamoDB, not for Amazon ECR; ECR requires an interface endpoint (PrivateLink) for private connectivity. Option C is wrong because attaching an internet gateway and adding a default route would give the VPC internet access, but CodeBuild in a VPC does not automatically use that route for pulling images; it would require a NAT gateway or instance in a public subnet, and even then, it is less secure and more complex than using a VPC interface endpoint.

Practice this question →
66
MCQmedium

A development team is implementing a CI/CD pipeline using AWS CodePipeline. The pipeline has a Source stage connected to an Amazon S3 bucket, a Build stage using AWS CodeBuild, and a Deploy stage that deploys to an Amazon ECS cluster. The team notices that the pipeline fails intermittently during the Build stage with a 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE' error. What is the most likely cause?

A.The CodeBuild project is in a different AWS Region than the CodePipeline pipeline.
B.The CodeBuild project is configured to run in a VPC without a NAT gateway, and the build image is pulled from a public registry.
C.The S3 bucket where the source code is stored has a bucket policy denying access to the CodeBuild service role.
D.The CodeBuild project does not have enough memory or vCPU allocated.
AnswerB

Without a NAT gateway, the build container cannot access the public internet to pull the image.

Why this answer

The 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE' error in AWS CodeBuild indicates that the build environment cannot pull the specified Docker image from its registry. When a CodeBuild project is configured to run in a VPC without a NAT gateway, it lacks outbound internet access, which is required to pull images from public registries like Docker Hub or Amazon ECR public. This is the most likely cause because the error is intermittent (e.g., if the image is cached locally sometimes) and directly relates to network connectivity.

Exam trap

The trap here is that candidates often confuse VPC networking errors with permission or resource errors, overlooking that CodeBuild in a VPC without a NAT gateway blocks outbound traffic to public registries, which is a subtle but critical detail for the 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE' error.

How to eliminate wrong answers

Option A is wrong because CodePipeline and CodeBuild can operate across different AWS Regions without causing a 'BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE' error; the pipeline simply references the CodeBuild project by ARN, and cross-region pulls are handled by the build environment's network configuration, not the pipeline's region. Option C is wrong because an S3 bucket policy denying access to the CodeBuild service role would cause a 'SOURCE_STAGE' or 'DOWNLOAD_SOURCE' error, not a build container pull error, as the source artifact is fetched before the build stage begins. Option D is wrong because insufficient memory or vCPU would result in a 'BUILD_CONTAINER_MEMORY_LIMIT_EXCEEDED' or 'BUILD_TIMEOUT' error, not a container image pull failure.

Practice this question →
67
Multi-Selectmedium

A company uses AWS CodePipeline with multiple stages. The pipeline includes a Beta stage that deploys to a test environment and a Prod stage. The team wants to require manual approval before the Prod stage. Which TWO actions should be taken to implement this? (Choose TWO.)

Select 2 answers
A.Ensure that the IAM user or role performing the approval has codepipeline:PutApprovalResult permissions.
B.Use CloudWatch Events to trigger a Lambda function that requires manual sign-off.
C.Set the Prod stage to only run on manual invocation.
D.Add a manual approval action in the pipeline stage between Beta and Prod.
E.Configure a CodeCommit approval rule template to require approval before merging.
AnswersA, D

The approver needs permissions to submit the approval result.

Why this answer

The IAM user or role that performs the manual approval action in CodePipeline must have the `codepipeline:PutApprovalResult` permission. This permission allows the user to submit the approval or rejection result to the pipeline, which is required to advance the pipeline to the Prod stage. Without this permission, the approval action cannot be completed, and the pipeline will remain stuck.

Exam trap

The trap here is that candidates often confuse manual approval actions with other approval mechanisms like CodeCommit approval rules or Lambda-based automation, but CodePipeline's manual approval is a distinct action type that requires explicit IAM permissions and a human-in-the-loop step.

Practice this question →
68
MCQhard

A team uses AWS CodeBuild to run integration tests that require access to an Amazon RDS database. The database is in a private subnet. The CodeBuild project is configured to use a VPC. However, the builds are failing with a timeout connecting to the database. What could be the issue?

A.The CodeBuild project's VPC configuration does not include the subnet IDs where the database resides.
B.The security group for the CodeBuild project does not allow outbound traffic to the RDS database.
C.The security group for the RDS database does not allow inbound traffic from the security group assigned to the CodeBuild project.
D.The CodeBuild project does not have a route to the internet via an internet gateway, so it cannot reach the RDS endpoint.
AnswerC

This is the correct root cause because when CodeBuild runs in your VPC, it attaches the security group you specified to its ENI. For the build container to successfully connect to RDS, the database's security group must have an inbound rule that permits traffic on the database port from the source being the CodeBuild security group ID. If that rule is missing, all connection attempts will time out or be refused, regardless of other network configurations, making this the definitive security group misconfiguration to resolve.

Why this answer

The RDS database is in a private subnet and its security group must explicitly allow inbound traffic from the CodeBuild project's security group. Even though CodeBuild is configured with a VPC, the default security group rules deny all inbound traffic; without an inbound rule for the database port (e.g., 3306 for MySQL) from the CodeBuild security group, the connection is blocked, causing a timeout.

Exam trap

The trap here is that candidates often assume the issue is outbound traffic (Option B) or subnet configuration (Option A), but the real problem is the missing inbound rule on the database security group, which is a classic security group misconfiguration in VPC-connected services.

How to eliminate wrong answers

Option A is wrong because the CodeBuild project's VPC configuration does not need to include the subnet IDs where the database resides; it only needs to specify the VPC ID and the subnets where the build environment runs, and the database can be in a different subnet within the same VPC. Option B is wrong because security groups are stateful — if the CodeBuild project initiates outbound traffic, the return traffic is automatically allowed, so an explicit outbound rule is not required. Option D is wrong because the RDS database is in a private subnet and does not require internet access; CodeBuild can reach it via private IP within the VPC without an internet gateway.

Practice this question →
69
MCQhard

Refer to the exhibit. A DevOps engineer deploys this CloudFormation template. The EC2 instance launches, but the httpd service does not start. The engineer connects to the instance and finds that the user data script did not run. What is the most likely cause?

A.The UserData is not base64 encoded correctly
B.The AMI does not have yum installed
C.The tags prevent user data from executing
D.The AMI uses a different init system than systemd
AnswerB

The `yum` command is specific to RPM-based distributions that use YUM as the package manager, such as older Amazon Linux (AL1/AL2) or CentOS 7. If the AMI is based on Amazon Linux 2023, which uses `dnf`, or on Ubuntu/Debian, which uses `apt`, the `yum` binary will not be present. When the UserData script runs `yum` on such an AMI, the shell returns a 'command not found' error, preventing the installation and causing the deployment to fail.

Why this answer

The most likely cause is that the AMI does not have yum installed. The CloudFormation template's UserData script uses yum to install httpd, but if the AMI is based on a distribution that does not use yum (e.g., Amazon Linux 2023 uses dnf, or Ubuntu uses apt), the script will fail silently or not execute as intended. Since the script itself is valid and the instance launched, the failure is due to the package manager not being available, preventing the httpd service from starting.

Exam trap

The trap here is that candidates often assume the issue is with base64 encoding or the init system, but the real problem is a mismatch between the package manager used in the UserData script and the one available on the AMI.

How to eliminate wrong answers

Option A is wrong because the UserData is automatically base64 encoded by CloudFormation when passed as a string in the template, so encoding is not an issue. Option C is wrong because tags do not affect the execution of user data scripts; tags are metadata and have no impact on the instance's initialization process. Option D is wrong because the init system (systemd vs.

SysVinit) does not prevent user data from running; user data scripts are executed by cloud-init, which works regardless of the init system, and the script itself does not rely on systemd commands.

Practice this question →
70
MCQeasy

A team uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment strategy is Blue/Green. During a recent deployment, the new instances passed all health checks, but traffic was not routed to them. What is the most likely reason?

A.The target group associated with the Auto Scaling group is not properly configured to route traffic.
B.The deployment group is not configured to use a load balancer.
C.The Auto Scaling group's lifecycle hook failed to signal readiness.
D.The CodeDeploy agent on the new instances is not installed.
AnswerA

The target group tied to the Auto Scaling group acts as the traffic-routing endpoint for the load balancer. If its health check path, port, or timeout settings are misconfigured—or if it is not attached to the appropriate listener rule—the newly deployed instances will be registered but immediately marked unhealthy and deregistered, so no user traffic reaches them. CodeDeploy itself successfully completes its scripts, but the deployment outcome appears as a routing failure, not an instance-level failure.

Why this answer

In a Blue/Green deployment with CodeDeploy and an Auto Scaling group, traffic routing is handled by a load balancer target group. If the target group is not properly configured to route traffic to the new instances (e.g., missing or incorrect listener rules, deregistration delay, or health check thresholds), the instances may pass health checks but never receive traffic. This is the most likely cause because the deployment succeeded in provisioning and validating the new instances, but the load balancer did not forward requests to them.

Exam trap

The trap here is that candidates often assume health check success guarantees traffic routing, but in AWS, health checks only verify instance readiness; traffic routing depends on separate load balancer listener rules and target group associations.

How to eliminate wrong answers

Option B is wrong because if the deployment group were not configured to use a load balancer, CodeDeploy would not attempt to route traffic via a load balancer at all; the issue described is that traffic was not routed, implying a load balancer is present but misconfigured. Option C is wrong because a lifecycle hook failure would prevent the instance from completing its launch or termination process, typically causing the instance to remain in a 'Pending:Wait' state and fail health checks, not pass them. Option D is wrong because if the CodeDeploy agent were not installed, the deployment would fail during the Install phase on the new instances, and they would not pass health checks or reach the 'Succeeded' state.

Practice this question →
71
MCQeasy

A DevOps engineer is creating an AWS CloudFormation template to deploy a stack that includes an Amazon EC2 instance. The instance needs to be launched in a specific subnet. How should the engineer reference the subnet ID in the template?

A.Hardcode the subnet ID in the template.
B.Use a mapping (Mappings) to define the subnet ID based on the stack name.
C.Define a parameter (Parameters) of type AWS::EC2::Subnet::Id and reference it.
D.Use the Fn::GetAtt function to retrieve the subnet ID from a VPC resource.
AnswerC

Defining a parameter of type AWS::EC2::Subnet::Id lets the caller supply the actual subnet at stack creation or update, and CloudFormation validates that the value is a real subnet ID. Referencing it via Ref keeps the template portable across environments, and the parameter appears in the console or CLI for clear input.

Why this answer

Defining a parameter of type `AWS::EC2::Subnet::Id` allows the CloudFormation template to accept a subnet ID as input at stack creation or update time, making the template reusable across different environments without modification. This approach follows infrastructure-as-code best practices by avoiding hardcoded values and enabling parameterized deployments.

Exam trap

The trap here is that candidates often confuse Fn::GetAtt with the ability to retrieve any resource attribute from any stack, but Fn::GetAtt only works for resources defined in the same template and cannot fetch a subnet ID from an existing VPC resource unless that VPC resource itself outputs the subnet ID.

How to eliminate wrong answers

Option A is wrong because hardcoding the subnet ID makes the template environment-specific and non-portable, violating the principle of reusable infrastructure-as-code. Option B is wrong because Mappings are used to define static lookup tables based on keys like region or environment, not to dynamically accept user-provided subnet IDs; the stack name is not a reliable key for subnet selection. Option D is wrong because Fn::GetAtt retrieves attributes from resources defined within the same template, but if the VPC and subnet are not created in the same stack, there is no resource to reference; even if they were, Fn::GetAtt on a VPC resource returns VPC-level attributes (e.g., VpcId), not a subnet ID.

Practice this question →
72
MCQhard

A DevOps team is implementing a blue/green deployment strategy for a microservice running on Amazon ECS with AWS CodeDeploy. They want to shift 10% of traffic to the new task set for 5 minutes, then shift the remaining 90%. Which deployment configuration should they use?

A.CodeDeployDefault.ECSAllAtOnce
B.CodeDeployDefault.ECSLinear10PercentEvery1Minutes
C.CodeDeployDefault.ECSCanary10Percent5Minutes
D.Custom configuration with 10% initial traffic and 100% after 5-minute interval
AnswerC

The built-in deployment configuration CodeDeployDefault.ECSCanary10Percent5Minutes instructs CodeDeploy to initially route 10% of the load balancer's traffic to the new ECS task set (the green environment) while the remaining 90% continues to go to the blue task set. After a 5-minute waiting period, during which health checks and metrics can be evaluated, CodeDeploy automatically shifts the remaining 90% of traffic to green, completing the deployment. This two-step canary pattern exactly satisfies the requirement for a 10% initial shift with a 5-minute soak before the final 90% cutover.

Why this answer

The built-in configuration `CodeDeployDefault.ECSCanary10Percent5Minutes` shifts 10% of traffic to the new task set, holds for 5 minutes, then shifts the remaining 90%. This matches the requirement exactly. A custom configuration (D) is unnecessary and not a standard deployment configuration.

Exam trap

Candidates often confuse the canary and linear configurations. `CodeDeployDefault.ECSCanary10Percent5Minutes` shifts 10% instantly and then holds for 5 minutes before shifting the rest. The linear configuration, `CodeDeployDefault.ECSLinear10PercentEvery1Minutes`, shifts 10% every minute over 10 minutes without a hold.

How to eliminate wrong answers

Option A is wrong because CodeDeployDefault.ECSAllAtOnce shifts 100% of traffic to the new task set immediately, which does not match the 10% then 90% gradual shift requirement. Option B is wrong because CodeDeployDefault.ECSLinear10PercentEvery1Minutes shifts 10% of traffic every 1 minute until 100%, resulting in a linear progression over 10 minutes, not a 5-minute wait at 10% followed by a single 90% shift. Option C is wrong because CodeDeployDefault.ECSCanary10Percent5Minutes shifts 10% for 5 minutes and then automatically shifts the remaining 90% immediately after the 5-minute interval, which does not allow the 5-minute hold at 10% before the final shift as specified; it completes the deployment in one canary step.

Practice this question →
73
MCQhard

A DevOps engineer is reviewing the CodePipeline structure above. The pipeline fails during the Deploy stage with an error: 'The deployment group could not be found.' What is the most likely cause?

A.The pipeline is configured as a single-region pipeline, but the Deploy action is in a different region.
B.The source artifact is not accessible from us-west-2.
C.The CodeDeploy application does not exist in us-west-2.
D.The CodeBuild project is not configured to output artifacts.
AnswerA

In CodePipeline, every pipeline is bound to a single region. If a Deploy action references a CodeDeploy application in another region, it is treated as a cross-region action and must be explicitly configured with the Region property. Without that, the pipeline attempts to execute the action in us-east-1, where no deployment group exists, producing the 'Deployment group not found' error. The fix is to add the cross-region configuration or move the Deploy action to the same region.

Why this answer

The error 'The deployment group could not be found' indicates that CodePipeline is attempting to invoke a CodeDeploy deployment in a region where the specified deployment group does not exist. If the pipeline is configured as a single-region pipeline (e.g., in us-east-1) but the Deploy action references a deployment group in a different region (e.g., us-west-2), CodePipeline will fail because it cannot resolve the deployment group across regions in a single-region pipeline configuration. Cross-region actions require explicit cross-region action configuration in the pipeline structure.

Exam trap

The trap here is that candidates often confuse the error message 'deployment group could not be found' with the deployment group not existing at all (Option C), rather than recognizing it as a region mismatch issue where the deployment group exists but in a different region than the pipeline.

How to eliminate wrong answers

Option B is wrong because the source artifact's accessibility from us-west-2 would cause a different error, such as 'Artifact not found' or 'Access denied', not a deployment group not found error. Option C is wrong because if the CodeDeploy application did not exist in us-west-2, the error would be 'The application could not be found' or 'Application does not exist', not specifically about the deployment group. Option D is wrong because a CodeBuild project not configured to output artifacts would cause the pipeline to fail earlier in the Build stage or during artifact retrieval, not during the Deploy stage with a deployment group error.

Practice this question →
74
MCQmedium

A DevOps team uses AWS CodePipeline with a multi-branch strategy. The pipeline should deploy to production only from the 'main' branch, but run unit tests for all branches. How should the team configure the pipeline?

A.Configure the pipeline source stage to trigger on all branches, use branch-specific logic in the test stage, and add a manual approval step for production deployment only when the branch is 'main'.
B.Use an AWS Lambda function to check the branch name and invoke different CodePipeline executions for testing and deployment.
C.Create one pipeline with two source stages: one for 'main' and one for all other branches, each with its own test and deploy actions.
D.Create a separate pipeline for each branch, each with identical test and deploy stages.
AnswerA

Configuring the source stage to trigger on all branches is the recommended approach because CodePipeline natively supports branch filters on source actions, allowing a single pipeline to react to every branch push. Branch-specific logic can then be implemented in the test stage using environment variables or run-time conditions to vary test suites, while a manual approval action can be conditionally added to the deploy stage only when the branch is 'main'. This leverages built-in pipeline features, avoids duplication, and keeps the deployment workflow centralized and auditable, which is the most scalable and maintainable design.

Why this answer

AWS CodePipeline supports branch filtering in the source stage to trigger on all branches, and you can use a condition in the deploy stage (e.g., via a Lambda function or a manual approval step) to restrict production deployment to the 'main' branch only. This approach avoids duplicating pipelines while ensuring unit tests run for every branch, meeting the multi-branch strategy requirement efficiently.

Exam trap

The trap here is that candidates may think they need separate pipelines or multiple source stages to handle branch-specific logic, but CodePipeline's branch filtering and conditional actions (like Lambda checks or manual approvals) allow a single pipeline to handle all branches efficiently.

How to eliminate wrong answers

Option B is wrong because invoking separate CodePipeline executions via a Lambda function for testing and deployment adds unnecessary complexity and breaks the single-pipeline model; CodePipeline natively supports branch-based conditions without external orchestration. Option C is wrong because having two source stages in one pipeline is not supported—CodePipeline allows only one source stage per pipeline, and mixing branches in separate source stages would cause conflicts in artifact handling. Option D is wrong because creating a separate pipeline for each branch violates the DRY principle, increases maintenance overhead, and does not leverage CodePipeline's built-in branch filtering and conditional execution capabilities.

Practice this question →

Ready to test yourself?

Try a timed practice session using only SDLC Automation questions.

Start 20-question session