CCNA Sdlc Automation Questions — Page 2 of 5

MCQeasy

Refer to the exhibit. The above IAM policy is attached to an IAM role used by a CI/CD pipeline. Which action is this policy allowing?

A.Start builds for any CodeBuild project in the account.

B.View details of any build in the account.

C.Start and view builds for the specified CodeBuild project.

D.Create and manage CodeBuild projects.

AnswerC

This is exactly what the policy authorizes: it includes the StartBuild action to begin a build and BatchGetBuilds to retrieve detailed information about those builds, with the Resource set to the specific CodeBuild project ARN shown in the exhibit. The policy therefore grants the minimum permissions needed to start and observe builds for only that one project.

Why this answer

The IAM policy grants `codebuild:StartBuild` and `codebuild:BatchGetBuilds` actions, which allow starting a build and viewing build details respectively. The `Resource` element restricts these permissions to the specific CodeBuild project `arn:aws:codebuild:us-east-1:123456789012:project/my-project`. Therefore, the policy allows starting and viewing builds for that single project, not any project in the account.

Exam trap

The trap here is that candidates see `codebuild:StartBuild` and `codebuild:BatchGetBuilds` and assume they apply to all projects, overlooking the resource ARN restriction that limits the policy to a single project.

How to eliminate wrong answers

Option A is wrong because `codebuild:StartBuild` is allowed only for the specified project ARN, not for all projects (`*`). Option B is wrong because `codebuild:BatchGetBuilds` is also scoped to the single project ARN, so it does not grant viewing details of any build in the account. Option D is wrong because the policy does not include actions like `codebuild:CreateProject` or `codebuild:UpdateProject`; it only covers starting and viewing builds.

Practice this question →

Multi-Selecthard

Which THREE actions can be performed using the AWS CLI for CodeDeploy? (Choose three.)

Select 3 answers

A.create-deployment

B.get-deployment

C.push-revision

D.list-deployment-groups

E.register-instance

AnswersA, B, D

The `aws deploy create-deployment` command is a valid, top-level CodeDeploy API operation that starts a new deployment for an application. You provide the application name, deployment group name, and a revision (for example, `--s3-location` or `--github-location`), and it returns a `deploymentId` that you can later query with `get-deployment`. This is the standard way to trigger a deployment from the CLI.

Why this answer

The `create-deployment` command is correct because it is the primary AWS CLI operation used to start a new deployment in CodeDeploy. It triggers the deployment of a revision (application code and configuration) to a specified deployment group, making it a core action for automating SDLC pipelines.

Exam trap

The trap here is that candidates may confuse `push-revision` with the valid `aws deploy push` command, or assume `register-instance` is a valid command when the actual command uses the longer `register-on-premises-instance` syntax, leading to incorrect selections.

Practice this question →

MCQhard

An organization uses AWS CodeBuild to compile a Java application. The buildspec.yml includes a pre_build phase that runs unit tests. Recently, the build started failing with 'NoClassDefFoundError' for certain test dependencies, even though the pom.xml includes them. The build environment uses an Amazon Linux 2 Docker image. What is the MOST likely cause?

A.The CodeBuild project has a cache that is corrupted or out of sync. Clear the build cache.

B.The S3 bucket for artifacts has incorrect permissions. Update the bucket policy.

C.The CodeCommit repository is not pulling the latest code. Add a webhook to trigger builds on push.

D.The build environment does not have Maven installed. Install Maven in the buildspec.

AnswerA

If the CodeBuild project is configured with a local dependency cache or an S3 cache that stores the Maven ~/.m2/repository, an interrupted download or a stale snapshot can leave cached JARs missing classes or mismatched with the declared POM versions. This directly produces NoClassDefFoundError at runtime because a class that existed during compilation is absent from the cached artifact on the classpath. Clearing the cache forces CodeBuild to re-resolve dependencies from their remote repositories, eliminating the corrupted or out-of-sync state.

Why this answer

The 'NoClassDefFoundError' for test dependencies that are declared in pom.xml indicates that the required JAR files are missing from the build environment at runtime. A corrupted or out-of-sync build cache in CodeBuild can cause previously downloaded Maven dependencies to be reused incorrectly, leading to missing classes even though the pom.xml specifies them. Clearing the cache forces a fresh download of all dependencies, resolving the mismatch.

Exam trap

The trap here is that candidates may assume the issue is a missing tool (Maven) or a code-pull problem, but the error specifically points to a dependency resolution failure, which is a classic symptom of a corrupted build cache in CI/CD pipelines.

How to eliminate wrong answers

Option B is wrong because incorrect S3 bucket permissions for artifacts would cause upload failures, not runtime class-loading errors like NoClassDefFoundError. Option C is wrong because the CodeCommit repository not pulling the latest code would result in building an outdated version of the source, not a missing dependency class; a webhook triggers builds on push but does not affect dependency resolution. Option D is wrong because the Amazon Linux 2 Docker image for CodeBuild includes Maven by default, and the build was previously succeeding, so Maven installation is not the issue.

Practice this question →

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 →

MCQeasy

A DevOps engineer needs to automate the creation of a CI/CD pipeline using infrastructure as code. Which AWS service is BEST suited to define and provision the pipeline resources?

A.AWS Elastic Beanstalk

B.AWS CodePipeline

C.AWS CloudFormation

D.AWS Service Catalog

AnswerC

AWS CloudFormation is the correct choice because it is a core infrastructure-as-code service that lets you define AWS resources, including CodePipeline pipelines, IAM roles, S3 buckets, and CodeBuild projects, in a declarative YAML or JSON template. A DevOps engineer can use CloudFormation to automate the creation of the entire CI/CD stack, ensuring version control, repeatability, and consistent environments across accounts or regions. CloudFormation also supports change sets and drift detection, making it a robust mechanism for provisioning and updating pipeline resources in a controlled, auditable way.

Why this answer

AWS CloudFormation is the correct choice because it is an infrastructure-as-code (IaC) service that allows you to define and provision AWS resources, including CI/CD pipeline components like CodePipeline, CodeBuild, and CodeDeploy, using declarative templates. This enables fully automated, repeatable, and version-controlled pipeline creation without manual intervention.

Exam trap

The trap here is that candidates confuse the CI/CD service itself (CodePipeline) with the IaC service used to provision it (CloudFormation), leading them to select the tool that runs the pipeline rather than the tool that defines the pipeline's infrastructure.

How to eliminate wrong answers

Option A is wrong because AWS Elastic Beanstalk is a PaaS service for deploying and scaling web applications, not for defining and provisioning CI/CD pipeline resources via IaC. Option B is wrong because AWS CodePipeline is a CI/CD service itself, but it is the resource being provisioned, not the tool to define and provision infrastructure as code. Option D is wrong because AWS Service Catalog is used to create and manage a catalog of approved IT services, not for authoring and deploying infrastructure as code templates for pipeline resources.

Practice this question →

MCQeasy

A development team uses AWS CodeStar to set up a continuous delivery pipeline for a web application. The application is deployed to an Elastic Beanstalk environment. After a successful deployment, the team wants to automatically run integration tests against the deployed application. What is the SIMPLEST way to achieve this?

A.Configure the Elastic Beanstalk environment to run integration tests after deployment via a custom platform hook.

B.Use Amazon CloudWatch alarms to trigger a Lambda function that runs the tests.

C.Add a post-deployment script in the CodeDeploy appspec file to run tests.

D.Add a test stage in CodePipeline after the deploy stage that uses CodeBuild to run integration tests.

AnswerD

Adding a test stage after the deploy stage in CodePipeline leverages CodeBuild to run integration tests against the live application. This is the simplest and most automated solution because CodePipeline natively supports test actions, and a build project can be configured with the test commands and reporting. If the tests fail, the pipeline stops and marks the execution as failed, preventing the change from progressing to subsequent environments. This pattern keeps deployment and validation isolated, adheres to CI/CD best practices, and requires no extra infrastructure or custom lifecycle scripts.

Why this answer

CodePipeline natively supports a test stage after the deploy stage, and using CodeBuild to run integration tests is the simplest and most integrated approach. This keeps the entire CI/CD workflow within CodePipeline without requiring external triggers, custom scripts, or platform hooks. CodeBuild can be configured to run tests against the deployed Elastic Beanstalk environment URL, and the pipeline will only proceed if the tests pass.

Exam trap

The trap here is that candidates may confuse Elastic Beanstalk with CodeDeploy and incorrectly assume a CodeDeploy appspec file (Option C) applies, or they may overcomplicate the solution by choosing CloudWatch alarms (Option B) instead of using the built-in pipeline stage.

How to eliminate wrong answers

Option A is wrong because Elastic Beanstalk custom platform hooks run during instance provisioning or deployment, not after the deployment is fully complete and the application is serving traffic; they are not designed for post-deployment integration testing. Option B is wrong because CloudWatch alarms are metric-based and not intended to trigger test execution; they would require additional custom logic and polling, adding unnecessary complexity. Option C is wrong because CodeDeploy appspec files are used for EC2/on-premises deployments, not for Elastic Beanstalk; Elastic Beanstalk does not use CodeDeploy, so this option is technically invalid.

Practice this question →

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 →

Multi-Selecteasy

A company uses AWS CodePipeline to deploy a static website to Amazon S3 and CloudFront. The pipeline currently uses CodeBuild to run tests and then deploys to an S3 bucket. The team wants to add a stage that invalidates the CloudFront cache after deployment. Which TWO actions achieve this?

Select 2 answers

A.Configure CodePipeline to directly invalidate CloudFront using a built-in action.

B.Create a CodePipeline stage with a deploy action to CloudFront.

C.Use CloudFront to automatically invalidate based on S3 events.

D.Use the AWS CLI command 'aws cloudfront create-invalidation' in a CodeBuild build step.

E.Add a Lambda function as a custom action in CodePipeline that calls the CloudFront invalidation API.

AnswersD, E

In a CodeBuild buildspec, you can run the AWS CLI command 'aws cloudfront create-invalidation --distribution-id <id> --paths "/*"' after the deployment step has completed. This is a standard CodeBuild action in the pipeline and requires an IAM role that allows cloudfront:CreateInvalidation, making it a simple and widely used way to invalidate the cache.

Why this answer

You can use the AWS CLI command 'aws cloudfront create-invalidation' in a CodeBuild build step to programmatically invalidate the CloudFront cache after deployment. This approach integrates seamlessly into the existing pipeline by adding a build action that runs the CLI command, ensuring the cache is cleared for updated objects in the S3 bucket.

Exam trap

The trap here is that candidates often assume CodePipeline has a built-in CloudFront invalidation action or that CloudFront automatically invalidates cache based on S3 events, but neither is true; you must explicitly trigger invalidation via the CLI, SDK, or a custom action.

Practice this question →

Multi-Selecthard

A DevOps team uses AWS CloudFormation with nested stacks. They are experiencing stack update failures because changes to a nested stack cause resource conflicts. Which THREE best practices should they follow to manage nested stack updates? (Choose THREE.)

Select 3 answers

A.Set the stack update to disable rollback to allow debugging of failures.

B.Apply a stack policy to prevent updates to critical resources in the nested stacks.

C.Use the resource import feature to bring existing resources under CloudFormation management.

D.Use AWS CloudFormation change sets to review changes before executing updates.

E.Use DependsOn to ensure nested stacks are updated in a specific order.

AnswersB, C, D

A stack policy is an IAM-like policy that specifically controls which update actions are permitted on resources within a given CloudFormation stack. When applied to each nested stack—not just the root stack—it can explicitly deny update, replace, or delete operations on critical resources, even if a change set or direct update attempts to modify them. This serves as an enforcement layer that complements change sets, which are only advisory, and ensures that accidental modifications are blocked at the resource level. Stack policies are the correct way to protect nested stack resources from unintended changes.

Why this answer

Applying a stack policy to nested stacks prevents updates to critical resources, avoiding conflicts during nested stack updates. Stack policies act as a guard to deny updates to specified resources, which is essential when changes to a nested stack might cause resource conflicts or unintended modifications. This best practice ensures that only intended changes are applied, reducing the risk of update failures.

Exam trap

The trap here is that candidates may think disabling rollback (Option A) or using DependsOn (Option E) can prevent or manage update conflicts, but these options do not address the root cause of resource conflicts in nested stacks; instead, stack policies, change sets, and resource import are the correct best practices for managing such conflicts.

Practice this question →

MCQhard

A company uses AWS CodePipeline with multiple stages: source, build, test, and deploy. The test stage takes 45 minutes to complete. Developers complain that the pipeline takes too long to provide feedback. The team wants to run tests in parallel across multiple environments. Which approach should be taken to reduce the pipeline execution time?

A.Increase the compute capacity of the test environment

B.Configure the test stage with parallel actions in CodePipeline

C.Use AWS CodeBuild batch builds with a single buildspec

D.Create multiple pipelines, each running a subset of tests

AnswerB

Configuring the test stage with parallel actions directly addresses the bottleneck by splitting the test suite into multiple independent actions within the same stage. CodePipeline executes actions that do not depend on one another concurrently, so the stage's total duration is the maximum of the parallel action times rather than the sum. This requires partitioning tests (for example, by service or module) and defining each action with its own CodeBuild project, and the pipeline waits for all parallel actions to succeed before proceeding.

Why this answer

AWS CodePipeline supports parallel actions within a stage, allowing multiple test environments (e.g., different OS or browser configurations) to run simultaneously. This reduces the overall pipeline execution time from the sum of sequential tests to the duration of the longest single test (45 minutes), provided the parallel actions are independent. By configuring the test stage with parallel actions, the team can achieve faster feedback without altering the underlying test logic or infrastructure.

Exam trap

The trap here is that candidates confuse parallel actions within a pipeline stage (which is a CodePipeline feature) with increasing compute resources or using batch builds, which address different bottlenecks (compute speed vs. parallel execution).

How to eliminate wrong answers

Option A is wrong because increasing compute capacity (e.g., larger CodeBuild instances) only speeds up individual test execution, but the test stage still runs sequentially; the 45-minute bottleneck remains if tests are not parallelized. Option C is wrong because CodeBuild batch builds are designed to run multiple builds in parallel across separate build environments, but they require a single buildspec and are typically used for building multiple artifacts or running matrix builds, not for orchestrating parallel test stages within a pipeline; the pipeline stage itself still runs sequentially unless parallel actions are explicitly configured. Option D is wrong because creating multiple pipelines introduces duplication, complexity, and potential resource contention, and does not inherently reduce the time for a single pipeline to complete; each pipeline would still run its own test stage sequentially, and the overall feedback loop for a single commit is not improved.

Practice this question →

MCQhard

A company uses AWS Elastic Beanstalk to deploy a web application. The deployment fails with a '502 Bad Gateway' error. The developer checks the logs and sees that the application is running but returns errors. The environment uses a load balancer. What is the MOST likely cause?

A.The application source bundle is missing a required file.

B.The security group of the environment does not allow inbound HTTP traffic.

C.The environment's environment variables are misconfigured.

D.The application is not binding to the correct port or is crashing under load.

AnswerD

The correct answer is that the application is either listening on a different port than the one nginx is configured to forward to (typically the PORT environment variable set by Elastic Beanstalk), or it is crashing under load, causing the port to close and nginx to receive a connection refused. In either case, when nginx attempts to proxy the request to the application's localhost port, it fails to get a valid HTTP response and returns 502 Bad Gateway to the client. Monitoring memory usage, checking nginx error logs for 'connect() failed' lines, and confirming the application binds to 0.0.0.0 instead of 127.0.0.1 are key diagnostic steps.

Why this answer

A 502 Bad Gateway error from an Elastic Beanstalk environment with a load balancer typically indicates that the reverse proxy (nginx or Apache) is unable to communicate with the application process. Since the logs show the application is running but returning errors, the most likely cause is that the application is not binding to the correct port (expected port 8080 by default) or is crashing under load, causing the proxy to receive no valid response and return a 502.

Exam trap

The trap here is that candidates often confuse a 502 Bad Gateway with a security group or missing file issue, but the 502 specifically points to a communication failure between the proxy and the application process, not to external network access or deployment artifacts.

How to eliminate wrong answers

Option A is wrong because a missing required file in the source bundle would cause a deployment failure or a 500-series error from the application itself, not a 502 Bad Gateway from the load balancer. Option B is wrong because if the security group did not allow inbound HTTP traffic, the load balancer would not be able to forward requests to the instances, resulting in a 504 Gateway Timeout or connection refused, not a 502. Option C is wrong because misconfigured environment variables typically cause application-level errors (e.g., 500 Internal Server Error) or runtime failures, but the proxy would still receive a response from the application process; a 502 specifically indicates the proxy received an invalid or no response from the upstream.

Practice this question →

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 →

MCQmedium

A company uses AWS CloudFormation to manage infrastructure. They want to update a stack but need to ensure that critical database resources are not accidentally replaced during the update. What is the BEST way to protect these resources?

A.Use a CreationPolicy on the database resources.

B.Use a DeletionPolicy of Retain on the database resources.

C.Define a stack policy that denies updates to the database resources.

D.Set an UpdatePolicy with AutoScalingReplacingUpdate.

AnswerC

A stack policy is a JSON document applied to the entire stack that explicitly controls which update actions are permitted on which logical resources. By adding a Deny statement that targets the database resources (e.g., Deny on Update:Replace), CloudFormation will refuse to replace those resources during any stack update, preserving both data and availability. This is the precise, preemptive protection mechanism.

Why this answer

A stack policy explicitly defines which resources can be updated or replaced during a stack update. By applying a stack policy that denies update actions on the critical database resources, you prevent accidental replacement or modification without having to remove the resources from the stack. This is the most direct and robust method to protect specific resources during a CloudFormation update operation.

Exam trap

The trap here is that candidates often confuse DeletionPolicy (which only applies on stack deletion) with stack policies (which control update behavior), leading them to incorrectly select Option B as a safeguard during updates.

How to eliminate wrong answers

Option A is wrong because a CreationPolicy is used to wait for successful resource creation signals (e.g., from an EC2 instance or Auto Scaling group) before marking the stack creation as complete; it does not protect resources from being replaced during an update. Option B is wrong because a DeletionPolicy of Retain only protects the resource when the stack is deleted, not during a stack update; during an update, the resource can still be replaced or updated unless explicitly prevented by a stack policy. Option D is wrong because an UpdatePolicy with AutoScalingReplacingUpdate is specific to Auto Scaling groups and controls how rolling updates replace instances; it does not prevent the replacement of database resources.

Practice this question →

MCQhard

A company uses AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.' The deployment is set to 'AllAtOnce'. The application revision is a simple index.html. What is the most likely cause?

A.The CodeDeploy agent is not installed or running on the EC2 instances.

B.The IAM instance profile does not have permissions to download from Amazon S3.

C.The application revision is not a compressed archive.

D.The deployment configuration 'AllAtOnce' is incompatible with Auto Scaling groups.

AnswerA

The CodeDeploy agent is a prerequisite component that must be installed and actively running on every EC2 instance target. If it is absent, stopped, or unresponsive, the instance will never poll the CodeDeploy service for work, so the deployment will show that instance stuck in the 'Pending' state and ultimately fail from timeout. A key sign: there are no deployment-root directories or log entries under /opt/codedeploy-agent on the instance, meaning no agent process is alive to execute any deployment steps.

Why this answer

The error message indicates that too many instances failed deployment, which is typical when the CodeDeploy agent is not running on the EC2 instances. With an 'AllAtOnce' deployment, all instances are targeted simultaneously, so if the agent is missing on every instance, all will fail immediately, causing the overall deployment to fail. The simple index.html revision is not the issue; the agent is required to execute the AppSpec file and pull the revision from S3 or GitHub.

Exam trap

The trap here is that candidates often assume the error is due to S3 permissions or archive format, but the generic 'too many instances failed' message points to a fundamental agent connectivity issue, not a permissions or file format problem.

How to eliminate wrong answers

Option B is wrong because the IAM instance profile permissions to download from S3 would cause a different error (e.g., 'Failed to download revision' or 'AccessDenied'), not the generic 'too many instances failed' message. Option C is wrong because CodeDeploy supports non-archived revisions like a single index.html file when the deployment type is 'in-place' and the AppSpec file references it directly; a compressed archive is only required for bundled revisions. Option D is wrong because 'AllAtOnce' is fully compatible with Auto Scaling groups; it simply deploys to all instances at once and is a valid deployment configuration.

Practice this question →

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 →

Multi-Selecthard

Which THREE practices help ensure the security of a CI/CD pipeline that deploys to production? (Choose three.)

Select 3 answers

A.Integrate static code analysis and vulnerability scanning into the pipeline.

B.Require manual approval for all deployments to production.

C.Use IAM roles with least privilege for pipeline actions.

D.Store deployment credentials in the source repository for traceability.

E.Encrypt artifacts in transit and at rest using AWS KMS.

AnswersA, C, E

Automated static code analysis and vulnerability scanning detect security defects early in the development cycle, when they are cheapest to remediate. Tools like SAST identify insecure code patterns, while dependency scanners flag known CVEs in third-party libraries, preventing vulnerable code from ever being packaged into deployment artifacts. This 'shift-left' approach reduces the risk of production incidents.

Why this answer

Static code analysis and vulnerability scanning (option A) are essential for identifying security flaws early in the development lifecycle, preventing vulnerable code from reaching production. Integrating these tools into the CI/CD pipeline ensures that every commit is automatically checked against known vulnerabilities and coding standards, reducing the risk of deploying exploitable code.

Exam trap

The trap here is that candidates often confuse operational controls (like manual approval) with security controls, or mistakenly believe that storing credentials in the repository aids traceability, when in fact it creates a severe security risk.

Practice this question →

MCQmedium

A company is implementing a CI/CD pipeline using AWS CodePipeline. The source code is stored in an AWS CodeCommit repository. The pipeline must automatically start whenever a change is pushed to any branch. Which configuration is required?

A.Add a branch creation trigger in CodeCommit that starts the pipeline.

B.Create a CloudWatch Events rule that matches CodeCommit push events and targets the CodePipeline pipeline.

C.Create an SNS topic and subscribe the pipeline to it, then configure CodeCommit to publish to the topic on push.

D.Configure the pipeline to poll the CodeCommit repository every few minutes.

AnswerB

This is the correct approach: CodeCommit publishes push events to CloudWatch Events (Amazon EventBridge), and you create a rule that matches the 'codecommit' source with a 'Push' detail-type, then set CodePipeline as the target. The rule can optionally filter by branch using the 'referenceType' and 'referenceName' fields, enabling branch-specific automation. This event-driven method provides near-immediate pipeline execution and is the recommended best practice for triggering pipelines on code changes.

Why this answer

AWS CodePipeline can be triggered automatically by Amazon CloudWatch Events when a CodeCommit repository receives a push event. By creating a CloudWatch Events rule that matches the `codecommit:GitPush` event source and targets the pipeline, the pipeline starts automatically on any branch push without polling or manual intervention.

Exam trap

The trap here is that candidates often assume CodeCommit has a built-in trigger for CodePipeline (like Option A) or that SNS can directly trigger CodePipeline (like Option C), but AWS requires CloudWatch Events as the intermediary for event-driven pipeline starts.

How to eliminate wrong answers

Option A is wrong because CodeCommit does not support branch creation triggers that directly start a pipeline; triggers in CodeCommit are limited to invoking AWS Lambda functions or SNS notifications, not CodePipeline. Option C is wrong because while CodeCommit can publish to an SNS topic on push events, CodePipeline cannot be directly subscribed to an SNS topic as a trigger source; CloudWatch Events is the required integration. Option D is wrong because CodePipeline does not support polling CodeCommit repositories; it relies on event-driven triggers via CloudWatch Events or webhooks, not periodic polling.

Practice this question →

MCQhard

Refer to the exhibit. An IAM policy is attached to a CodeBuild service role. The CodeBuild project is used to build code from a CodeCommit repository and output artifacts to an S3 bucket. However, the build fails with an error: 'Unable to download source from CodeCommit'. What is the missing permission?

A.Permissions to read from the CodeCommit repository.

B.Permissions to create CloudWatch Logs for build output.

C.Permissions to decrypt the KMS key used to encrypt artifacts.

D.Permissions to write to the S3 artifact bucket.

AnswerA

To download source code from an AWS CodeCommit repository, the IAM role assumed by CodeBuild must include the codecommit:GitPull action (and typically codecommit:GitClone for TLS/SSH operations). Without this read permission, CodeBuild fails during the source download phase with an error such as 'Not authorized to perform codecommit:GitPull' because the service role cannot access the repository. Neither S3 nor CloudWatch permissions can substitute for the explicit CodeCommit read action, so this is the missing permission in the policy.

Why this answer

The error 'Unable to download source from CodeCommit' indicates that the CodeBuild service role lacks the necessary permissions to read the source code from the CodeCommit repository. CodeBuild uses the service role to interact with CodeCommit via Git, which requires the `codecommit:GitPull` action (or broader read permissions like `codecommit:Get*` and `codecommit:List*`). Without these permissions, the build process cannot clone or fetch the source code, causing the failure.

Exam trap

The trap here is that candidates often confuse the source download phase with the artifact upload phase, assuming the error is about S3 write permissions or KMS decryption, when the error message explicitly identifies the source download as the failing step.

How to eliminate wrong answers

Option B is wrong because CloudWatch Logs permissions are required for streaming build logs, but the error message specifically points to a source download failure, not a logging issue. Option C is wrong because KMS decrypt permissions are needed when artifacts are encrypted with a customer-managed KMS key, but the error is about downloading source code, not decrypting artifacts. Option D is wrong because S3 write permissions are required for uploading build artifacts, but the error occurs before any artifact output, during the source download phase.

Practice this question →

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 →

MCQhard

A DevOps engineer creates a CloudFormation stack with the above template. After creation, they want to update the Lambda function code by uploading a new zip file to the S3 bucket and updating the S3Key property. However, the stack update fails because the Lambda function is published as a version and the alias points to that version. What is the most likely reason for the update failure?

A.The AWS::Lambda::Version resource is immutable and cannot be updated.

B.The alias must be deleted before updating the function code.

C.The IAM role does not have permission to update the function.

D.The function code cannot be updated because the S3 bucket is in a different region.

AnswerA

The AWS::Lambda::Version resource is immutable; once a Lambda version is published, its code and configuration are fixed and cannot be modified in place. CloudFormation therefore rejects any update attempt that alters existing AWS::Lambda::Version properties, reporting that the resource cannot be updated. To change the version, you must create a new version (e.g., by changing the logical ID or using SAM's AutoPublishAlias) and then redirect the alias. This is exactly why the stack update fails.

Why this answer

The AWS::Lambda::Version resource is immutable by design; once created, it cannot be updated or replaced. When a CloudFormation stack includes a Lambda version and an alias pointing to that version, any attempt to update the function code (e.g., by changing the S3Key property) triggers an update to the AWS::Lambda::Version resource, which CloudFormation cannot perform because versions are immutable. This causes the stack update to fail.

Exam trap

The trap here is that candidates assume CloudFormation can update any resource, but they overlook the immutable nature of Lambda versions, which causes the update to fail even when the alias is present.

How to eliminate wrong answers

Option B is wrong because the alias does not need to be deleted; the alias can be updated to point to a new version after the function code is updated, but the core issue is the immutability of the version resource. Option C is wrong because the IAM role permissions are not the cause of the failure; the error occurs at the CloudFormation resource level, not due to missing permissions. Option D is wrong because the S3 bucket region does not affect the ability to update the function code; cross-region S3 buckets are supported as long as the bucket name and key are correctly specified.

Practice this question →

Multi-Selectmedium

Which TWO AWS services can be used as sources in an AWS CodePipeline? (Choose two.)

Select 2 answers

A.AWS Lambda

B.AWS CodeCommit

C.AWS CloudFormation

D.Amazon S3

E.AWS CodeBuild

AnswersB, D

AWS CodeCommit is a fully managed source control service hosting private Git repositories, making it a first-class source provider in CodePipeline. When you attach a CodeCommit repository as the source stage of a pipeline, the pipeline automatically triggers on new commits to a selected branch, using CloudWatch Events or polling. Because CodeCommit stores versioned source code and supports branches and tags, it serves as a reliable source from which CodePipeline can pull artifacts for subsequent build and deploy stages.

Why this answer

AWS CodePipeline supports AWS CodeCommit and Amazon S3 as source stages. CodeCommit is a fully managed source control service that integrates natively with CodePipeline, allowing automatic pipeline execution on code changes. Amazon S3 can serve as a source when you upload a source bundle (e.g., a ZIP file) to an S3 bucket, and CodePipeline can poll the bucket for changes or use S3 event notifications to trigger the pipeline.

Exam trap

The trap here is that candidates often confuse services that can be used as actions (like Lambda, CodeBuild, or CloudFormation) with services that can be used as sources, leading them to select Lambda or CodeBuild as source options.

Practice this question →

MCQeasy

A development team uses AWS CodeCommit to store their application code. They want to enforce that all code changes to the main branch are reviewed and approved by at least one other team member before being merged. Which AWS service or feature should they use to implement this requirement?

A.AWS Identity and Access Management (IAM) policies

B.AWS CodePipeline manual approval action

C.AWS CodeCommit approval rule templates

D.AWS CodeCommit repository triggers

AnswerC

Approval rule templates in CodeCommit allow you to define the number of approvals required for a pull request to be merged. You can apply a template to a repository to enforce that at least one approval is needed before merging into the main branch. This directly meets the requirement for mandatory code review.

Why this answer

CodeCommit approval rule templates define the number of approvals required for a pull request to be merged. By applying a template to the repository, you can enforce that at least one approval is needed before merging into the main branch. This is the native feature for implementing mandatory code reviews in CodeCommit.

Exam trap

The trap here is confusing deployment approval (CodePipeline manual approval) with code review approval (CodeCommit approval rules), which serve different purposes.

Practice this question →

MCQmedium

A DevOps engineer wants to use AWS CodeDeploy to deploy an application to an Auto Scaling group. The deployment must ensure that only a certain percentage of instances are taken out of service at a time. Which deployment configuration supports this requirement?

A.CodeDeployDefault.OneAtATime

B.CodeDeployDefault.LambdaCanary10Percent5Minutes

C.CodeDeployDefault.AllAtOnce

D.CodeDeployDefault.LambdaLinear10PercentEvery1Minute

AnswerA

This is the right choice for minimizing risk during deployment to an EC2/ASG. It shifts traffic to one instance at a time, waiting for a successful deployment health check on that instance before proceeding to the next, so if something fails, only that instance is affected and deployment can be stopped before impacting the rest of the fleet. This is akin to a rolling update with a batch size of one, preserving overall availability.

Why this answer

CodeDeployDefault.OneAtATime is the correct deployment configuration because it ensures that only one instance in the Auto Scaling group is taken out of service at a time, which directly satisfies the requirement of limiting the percentage of instances removed during deployment. This configuration is designed for EC2/On-Premises deployments and uses a fixed number of instances (one) rather than a percentage, making it ideal for gradual, safe rollouts.

Exam trap

The trap here is that candidates often confuse deployment configurations designed for Lambda functions (like Canary and Linear) with those for EC2/On-Premises, or they mistakenly think AllAtOnce limits the percentage of instances taken out of service, when in fact it takes all instances out at once.

How to eliminate wrong answers

Option B is wrong because CodeDeployDefault.LambdaCanary10Percent5Minutes is a deployment configuration for AWS Lambda functions, not for EC2/On-Premises deployments to an Auto Scaling group; it shifts 10% of traffic to the new version and then waits 5 minutes before shifting the remaining 90%. Option C is wrong because CodeDeployDefault.AllAtOnce deploys to all instances simultaneously, which would take all instances out of service at once, violating the requirement to limit the percentage removed at a time. Option D is wrong because CodeDeployDefault.LambdaLinear10PercentEvery1Minute is also a Lambda-specific configuration that increments traffic by 10% every minute, and it does not apply to EC2/On-Premises deployments with Auto Scaling groups.

Practice this question →

Multi-Selectmedium

A DevOps engineer is designing a CI/CD pipeline for a microservices architecture. The pipeline must ensure that only code that passes security scanning can proceed to deployment. Which TWO actions should the engineer take? (Choose TWO.)

Select 2 answers

A.Use Amazon CloudWatch Events to trigger a rollback if vulnerabilities are found after deployment.

B.Add a security scanning stage in the pipeline after the build stage and before the deploy stage.

C.Use AWS CodeDeploy to perform security scanning during deployment.

D.Configure the pipeline to run security scanning only in the deploy stage.

E.Configure the pipeline to fail if the security scanning stage returns a non-zero exit code.

AnswersB, E

Placing a security scanning stage immediately after the build stage and before the deploy stage makes the scan a quality gate on the immutable artifact itself, so deployment only proceeds when the artifact is clean. Tools like Amazon Inspector, Trivy, SonarQube, or Snyk can run in a CodeBuild action within CodePipeline to produce reports and block promotion. This 'shift-left' approach catches vulnerabilities while remediation is cheapest and before any environment is provisioned or exposed.

Why this answer

Integrating a security scanning stage after the build stage and before the deploy stage ensures that only code that has passed security checks proceeds to deployment. This aligns with the principle of shifting security left in the CI/CD pipeline, preventing vulnerable artifacts from reaching production environments.

Exam trap

The trap here is that candidates often confuse post-deployment monitoring (CloudWatch Events) with pre-deployment gating, or mistakenly think AWS CodeDeploy can perform security scanning, when in fact it only handles deployment orchestration.

Practice this question →

100

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 →

101

MCQmedium

An organization uses AWS CodePipeline to deploy a web application. The pipeline includes a test stage that runs integration tests using AWS CodeBuild. The tests are flaky and sometimes fail due to external dependencies. The team wants to automatically retry failed tests before marking the stage as failed. How should this be achieved?

A.Add a manual approval step after the test stage.

B.Use Amazon CloudWatch Events to listen for test failures and trigger a new pipeline execution.

C.Configure the CodeBuild project to automatically retry the build on failure.

D.Create a second pipeline that triggers only on test failures.

AnswerC

CodeBuild projects support an automatic retry configuration that re-runs a failed build when the build action is executed by CodePipeline. By setting a retry limit (up to 10 attempts) and an optional execution timeout, the CodeBuild service itself retries the exact same build spec, allowing flaky integration tests to succeed on a subsequent attempt without any pipeline-level changes. The build action in CodePipeline reports a single success/failure status based on the final attempt, so a successful retry lets the stage pass without re-running earlier source or build stages. This is the only option that provides an automatic, stage-local retry mechanism for the build, directly addressing the flaky tests.

Why this answer

AWS CodeBuild natively supports automatic retries on build failure through the 'auto retry limit' configuration. By setting this limit (e.g., 3), CodeBuild will automatically re-run the build if it fails, which directly addresses flaky tests without requiring additional pipeline stages or external event handling. This keeps the retry logic within the same pipeline execution, ensuring that the test stage only fails after exhausting all retry attempts.

Exam trap

The trap here is that candidates may overcomplicate the solution by thinking they need external event-driven retries (Option B) or separate pipelines (Option D), when CodeBuild's built-in retry configuration directly solves the problem with minimal overhead.

How to eliminate wrong answers

Option A is wrong because adding a manual approval step after the test stage does not retry failed tests; it only pauses the pipeline for human intervention, which does not automate the retry process and introduces unnecessary delay. Option B is wrong because using Amazon CloudWatch Events to trigger a new pipeline execution on test failures would start a completely separate pipeline run, not retry the current stage within the same execution, leading to duplicate work and potential race conditions. Option D is wrong because creating a second pipeline that triggers only on test failures is overly complex and redundant; it does not retry the test stage in the original pipeline and would require additional orchestration to manage state between pipelines.

Practice this question →

102

Multi-Selectmedium

A company is implementing a CI/CD pipeline using AWS CodePipeline. The pipeline has a source stage from GitHub, a build stage using AWS CodeBuild, and a deploy stage using AWS Elastic Beanstalk. The team wants to ensure that the pipeline only proceeds if the code quality checks pass and unit tests are successful. Which TWO actions should be taken?

Select 2 answers

A.Add a test stage in the pipeline with a CodeBuild action that runs code quality and unit tests.

B.Add a manual approval step before the deploy stage.

C.Modify the buildspec file of the build stage to include test commands and fail on test failures.

D.Configure the source stage to use an S3 bucket and add a test action.

E.Use AWS CloudFormation to create a test environment and run tests.

AnswersA, C

Adding a dedicated test stage in CodePipeline with a CodeBuild action is the canonical pattern for automated validation: after the source is retrieved and built, the pipeline invokes a CodeBuild project whose buildspec runs code quality checks and unit tests. Because the stage fails the pipeline if any test exits non-zero, this creates an explicit quality gate that must pass before the build artifact proceeds to deployment, and CodePipeline's stage boundaries give you clear visibility into test results and execution history.

Why this answer

Adding a dedicated test stage with a CodeBuild action allows the pipeline to explicitly run code quality checks and unit tests as a separate, visible step. This ensures the pipeline only proceeds to deployment if these tests pass, as CodeBuild can be configured to fail the action on non-zero exit codes from test commands. Option C is also correct because modifying the buildspec file in the existing build stage to include test commands and setting the build to fail on test failures integrates quality gates directly into the build process, which is a common and valid approach for enforcing test success before deployment.

Exam trap

The trap here is that candidates may think a manual approval step (Option B) or infrastructure provisioning (Option E) can enforce test quality gates, but neither actually executes or validates test results automatically within the pipeline.

Practice this question →

103

Multi-Selectmedium

Which TWO AWS services can be used to implement a blue/green deployment for an application running on Amazon EC2 instances?

Select 2 answers

A.AWS CloudFormation

B.AWS CodeDeploy

C.AWS Elastic Beanstalk

D.AWS OpsWorks

E.AWS CodeBuild

AnswersB, C

AWS CodeDeploy is the correct choice because it provides a native blue/green deployment model for EC2/On-Premises and AWS Lambda workloads. During a blue/green deployment, CodeDeploy automatically provisions a new replacement fleet (green), registers it with the load balancer, and shifts traffic incrementally from the original fleet (blue) to the green fleet, with options for automatic rollback if deployment fails. Its built-in deployment lifecycle hooks and traffic-routing controls make it a fully managed service purpose-built for this strategy.

Why this answer

AWS CodeDeploy (Option B) is correct because it natively supports blue/green deployments for Amazon EC2 instances by allowing you to provision a new set of instances (the green environment), deploy the new application revision to them, and then shift traffic from the old (blue) environment to the new one. This is achieved through integration with an Elastic Load Balancer (ELB) or Auto Scaling groups, where CodeDeploy manages the lifecycle of instances and traffic routing during the deployment process.

Exam trap

The trap here is that candidates often confuse AWS CloudFormation (which can define the infrastructure for blue/green deployments) with the actual deployment service that orchestrates the traffic shift, leading them to select CloudFormation instead of CodeDeploy or Elastic Beanstalk.

Practice this question →

104

MCQeasy

Refer to the exhibit. A DevOps engineer created a CloudFormation stack that includes a Lambda function. The stack creation failed and rolled back. The error message for the Lambda function says 'Resource creation cancelled'. What is the most likely cause?

A.The Lambda function's IAM role does not have sufficient permissions.

B.The Lambda function's code is missing from the S3 bucket.

C.The stack rollback was triggered due to a failure in another resource, and the Lambda creation was cancelled.

D.The Lambda function creation timed out.

AnswerC

CloudFormation creates stack resources in parallel where no dependencies exist, and a failure in any resource triggers an automatic rollback that cancels all other in-progress resource creations. When the Lambda function's AWS::Lambda::Function resource is cancelled in this way, CloudFormation marks it as CREATE_FAILED with the reason 'Resource creation cancelled' — even though the Lambda service never reported an error. The root cause lies in a different resource that failed first, so you must inspect the full stack event list to identify the original failure.

Why this answer

CloudFormation creates resources in a specific order, and if a dependency fails or another resource fails, CloudFormation cancels the creation of subsequent resources and initiates a rollback. The error 'Resource creation cancelled' indicates that the Lambda function was never actually attempted to be created; instead, its creation was aborted due to a failure in a preceding or parallel resource. This is a standard CloudFormation behavior when a stack operation is interrupted by a failure in another resource.

Exam trap

Candidates often confuse 'Resource creation cancelled' with a resource-specific failure (e.g., insufficient permissions), but this error indicates CloudFormation cancelled the resource due to a failure in another resource during stack creation.

How to eliminate wrong answers

Option A is wrong because insufficient IAM permissions would cause a different error, such as 'API: iam:PassRole' or 'AccessDenied', not 'Resource creation cancelled'. Option B is wrong because missing code in the S3 bucket would result in an error like 'Unable to fetch code from S3' or '404 Not Found', not a cancellation message. Option D is wrong because a timeout would produce a 'Resource timed out' error, not 'Resource creation cancelled', and CloudFormation would wait for the timeout period before failing.

Practice this question →

105

MCQeasy

A startup is using AWS CodePipeline to deploy a Python web application to AWS Elastic Beanstalk. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild), and a deploy stage (Elastic Beanstalk). The build stage runs unit tests and creates a deployable zip file. The deploy stage uses the Elastic Beanstalk deploy provider. Recently, the deploy stage started failing with the error: 'The API call 'elasticbeanstalk:CreateApplicationVersion' failed with status 403.' The CodePipeline service role has the following permissions: 'elasticbeanstalk:DescribeApplications', 'elasticbeanstalk:DescribeEnvironments', 'elasticbeanstalk:UpdateEnvironment'. What should the DevOps engineer do to resolve the issue?

A.Change the deploy provider to use CodeDeploy instead of Elastic Beanstalk

B.Add 's3:PutObject' permission to the CodePipeline service role to allow it to upload the zip file to S3

C.Add the 'elasticbeanstalk:CreateApplicationVersion' and 'elasticbeanstalk:DeleteApplicationVersion' permissions to the CodePipeline service role

D.Update the Elastic Beanstalk environment's service role to allow CodePipeline to deploy

AnswerC

When CodePipeline deploys to Elastic Beanstalk, its service role must be allowed to call the Elastic Beanstalk APIs `CreateApplicationVersion` and `DeleteApplicationVersion`. The `CreateApplicationVersion` action registers a new application version from the source artifact, while `DeleteApplicationVersion` lets the pipeline remove old versions—both are essential for a successful deployment. Without these permissions, the deploy action receives an `AccessDenied` (403) error. Adding them to the CodePipeline service role directly resolves the failure because the role is the identity CodePipeline assumes when making API calls on your behalf.

Why this answer

The 403 error on elasticbeanstalk:CreateApplicationVersion indicates the CodePipeline service role lacks that specific IAM action. Elastic Beanstalk's deploy provider calls CreateApplicationVersion to register the new application revision, and it also calls DeleteApplicationVersion during cleanup of old revisions. Adding both permissions to the CodePipeline service role resolves the authorization failure without changing the pipeline architecture.

Exam trap

DOP-C02 often tests whether candidates can distinguish between the CodePipeline service role (the caller) and the Elastic Beanstalk environment service role (the resource) — candidates frequently pick the environment role fix when the 403 is actually about the caller's permissions.

How to eliminate wrong answers

Option A is wrong because switching to CodeDeploy does not address the missing IAM permission and would require re-architecting the deployment target, which is unnecessary. Option B is wrong because the error is an Elastic Beanstalk API authorization failure, not an S3 upload failure — CodeBuild already handles artifact upload, and adding s3:PutObject would not grant the missing elasticbeanstalk action. Option D is wrong because the Elastic Beanstalk environment's service role governs what the environment can do (e.g., access EC2, S3), not what CodePipeline can call on the Elastic Beanstalk API; the caller's identity is the CodePipeline service role.

Practice this question →

106

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 →

107

MCQhard

A company uses AWS CodeCommit as a source repository and wants to enforce that all commits are signed using GPG keys. The DevOps team configures a pre-receive hook in CodeCommit to validate commit signatures. However, the hook rejects all commits even when valid GPG signatures are present. What is the most likely cause?

A.The GPG key is not registered with the IAM user's profile.

B.CodeCommit does not support pre-receive hooks.

C.The hook script has a syntax error.

D.The repository is not configured to require signed commits.

AnswerB

This is correct. CodeCommit is a managed Git service that does not expose a file system or a server-side Git hooks directory, so Git's pre-receive hook scripts are not supported. Instead, CodeCommit offers repository triggers (SNS/Lambda) and notification rules, which are evaluated after the push is accepted. Therefore, any apparent pre-receive hook failure cannot actually occur in CodeCommit.

Why this answer

AWS CodeCommit does not support pre-receive hooks. Pre-receive hooks are a feature of self-managed Git repositories (e.g., GitHub Enterprise, GitLab, or on-premises Git servers) that run on the server before accepting a push. CodeCommit uses IAM policies and repository-level settings (such as requiring signed commits via the 'git push --signed' flag) to enforce commit signing, not server-side hooks.

Therefore, any attempt to configure a pre-receive hook in CodeCommit will fail, causing all commits to be rejected.

Exam trap

The trap here is that candidates confuse CodeCommit with self-managed Git platforms (like GitHub or GitLab) that support pre-receive hooks, leading them to assume CodeCommit also supports this feature, when in fact CodeCommit uses a different enforcement mechanism (repository-level settings and IAM policies).

Why the other options are wrong

While GPG key must be associated with the IAM user, the issue is that CodeCommit doesn't support pre-receive hooks.

Even if the script is correct, CodeCommit does not execute pre-receive hooks.

CodeCommit does not have a built-in setting to require signed commits; the hook is the intended mechanism, but it's not supported.

Practice this question →

108

MCQmedium

A company runs a standard AWS CodePipeline with a CodeCommit source and a CodeBuild build stage. Compliance requires that every source revision be built with a buildspec that is immutable and shared across all pipelines in the organization; developers must not be able to change build instructions by editing files in the source repository. Which approach enforces this requirement with the least operational overhead?

A.Move the buildspec into an Amazon S3 object and use the S3 object URL in the CodeBuild project's source configuration.

B.Create a separate CodeCommit repository that holds only buildspec.yml and add it as a second source action with a lower runOrder than the application source.

C.Store the buildspec.yml in the CodeCommit repository and protect the branch with an approval rule template that requires senior approval.

D.Configure the CodeBuild project to use an inline buildspec defined in the project, and reference that project from every pipeline stage.

AnswerD

An inline buildspec is stored as part of the CodeBuild project configuration, not in the source repository, so source edits cannot change build instructions. Pipelines that reference this project inherit the same immutable definition, satisfying the shared and immutable requirement with no extra repository controls or per-pipeline duplication.

Why this answer

Storing the buildspec inline in the CodeBuild project makes build instructions part of the project definition rather than the source tree, so source repository changes cannot affect them. Because pipelines reference the same CodeBuild project, the definition is shared and consistent across the organization, which satisfies both immutability and low operational overhead without per-repository controls.

Exam trap

The trap here is assuming that protecting the source branch with approvals makes the buildspec immutable, when the buildspec is still source-controlled content that can change on any branch or via a merge.

Practice this question →

109

Multi-Selecthard

Which THREE components are required to set up a fully automated CI/CD pipeline for a static website hosted on Amazon S3 using AWS CodePipeline? (Choose THREE.)

Select 3 answers

A.An AWS CodeBuild project to run build commands (e.g., minification)

B.An Amazon CloudFront distribution for content delivery

C.An AWS CodeCommit repository to store the website source code

D.An S3 bucket configured for static website hosting as the deployment target

E.An AWS Lambda function to invalidate CloudFront cache

AnswersA, C, D

CodeBuild is the required compute stage in a static website pipeline: it pulls the source from CodeCommit, executes build commands such as minification, Sass compilation, or image optimization, and outputs the production-ready artifacts to a staging location. Without a build project, the pipeline would simply copy raw source files, missing any transformation needed for the final site. CodeBuild integrates directly with CodePipeline and writes artifacts to S3, making it the only component explicitly running build commands.

Why this answer

AWS CodeBuild is required to execute build commands such as minification, bundling, or transpilation of static website assets before deployment. In a fully automated CI/CD pipeline, CodeBuild processes the source code from the repository and produces the deployable artifacts that are then uploaded to the S3 bucket.

Exam trap

The trap here is that candidates often confuse optional performance enhancements (CloudFront) or cache invalidation mechanisms (Lambda) as mandatory pipeline components, when the question specifically asks for the three required components to set up a fully automated CI/CD pipeline for a static website hosted on S3.

Practice this question →

110

MCQmedium

Refer to the exhibit. An IAM policy is attached to a CodePipeline service role. When the pipeline tries to start a CodeBuild project, it fails with an 'AccessDenied' error. The CodeBuild project uses a different service role (arn:aws:iam::123456789012:role/CodeBuildServiceRole2). What is the MOST likely cause?

A.The policy has a condition on the s3 actions that is not satisfied.

B.The policy does not allow codebuild:StartBuild for the specific project.

C.The policy does not allow s3:GetObject on the artifact bucket.

D.The policy only allows iam:PassRole for a specific role ARN, but the CodeBuild project uses a different role.

AnswerD

The pipeline role's policy scopes `iam:PassRole` to a single resource ARN, so CodePipeline cannot hand CodeBuildServiceRole2 to CodeBuild. Starting a build requires passing the project's service role; the mismatched ARN triggers AccessDenied. Broadening the resource to the intended role ARN resolves it.

Why this answer

When CodePipeline starts a CodeBuild project, it must pass the CodeBuild service role to CodeBuild using iam:PassRole. If the pipeline's service role policy only allows iam:PassRole for a specific role ARN (e.g., CodeBuildServiceRole1) but the CodeBuild project is configured with a different role (CodeBuildServiceRole2), the PassRole action will be denied, causing an AccessDenied error. This is the most likely cause because the error occurs at the start of the build, and the policy explicitly restricts the role that can be passed.

Exam trap

DOP-C02 often tests the iam:PassRole permission and its role in service-to-service delegation; candidates may overlook that the pipeline role needs explicit PassRole permission for the specific CodeBuild service role, leading to AccessDenied errors.

How to eliminate wrong answers

Option A is wrong because the error is about starting the CodeBuild project, not about S3 actions; S3 conditions would affect artifact retrieval or storage, not the StartBuild call. Option B is wrong because if the policy lacked codebuild:StartBuild permission, the error would occur, but the question implies the policy is attached and the failure is due to role passing; also, the policy might allow StartBuild but not PassRole. Option C is wrong because missing s3:GetObject would cause failures when downloading artifacts, not when starting the build.

Practice this question →

111

MCQhard

Refer to the exhibit. An IAM policy is attached to a role used by a CI/CD system. The policy is intended to allow starting the pipeline 'MyPipeline' from the same account. However, the CI/CD system receives an 'AccessDenied' error when trying to start the pipeline. What is the problem?

A.The Allow statement does not specify the correct pipeline ARN.

B.The policy needs an additional Allow for 'codepipeline:GetPipeline' to start the pipeline.

C.The role does not have permission to pass the policy to the CI/CD system.

D.The Deny statement with the 'aws:SourceAccount' condition denies access if the condition key is not present in the request.

AnswerD

This Deny statement uses a condition key such as aws:SourceAccount with an operator like StringNotEquals, which evaluates as true when the key is missing from the request context. Because an explicit Deny overrides all Allow statements, the request is denied whenever the expected source account is not present in the request. This is the precise cause of the AccessDenied error.

Why this answer

The Deny statement with the `aws:SourceAccount` condition key denies access unless the request includes that condition key. When the CI/CD system assumes the role and makes a `StartPipelineExecution` API call, the request context does not automatically include the `aws:SourceAccount` key unless explicitly added by the caller. Since the condition is not satisfied, the Deny statement applies, resulting in an 'AccessDenied' error even though the Allow statement grants the necessary action.

Exam trap

The trap here is that candidates overlook the explicit Deny statement with a condition key, assuming the Allow statement alone is sufficient, and instead focus on missing permissions or incorrect ARNs, not realizing that an explicit Deny with an unsatisfied condition will block access regardless of any Allow.

How to eliminate wrong answers

Option A is wrong because the pipeline ARN in the Allow statement is specified as 'arn:aws:codepipeline:us-east-1:123456789012:MyPipeline', which is the correct format and matches the pipeline name 'MyPipeline'. Option B is wrong because `codepipeline:GetPipeline` is a read-only action and is not required to start a pipeline; the required action is `codepipeline:StartPipelineExecution`, which is already allowed. Option C is wrong because the policy is attached to the role, not passed to the CI/CD system; the role itself is assumed by the CI/CD system, and there is no 'pass policy' permission issue here.

Practice this question →

112

MCQmedium

A company uses AWS CodeBuild to compile Java applications. The builds often fail due to insufficient memory. The buildspec currently specifies 'compute-type: BUILD_GENERAL1_SMALL'. What is the most cost-effective solution to resolve the memory issues without changing the build logic?

A.Change the compute-type to 'BUILD_GENERAL1_MEDIUM' or 'BUILD_GENERAL1_LARGE' in the buildspec.

B.Enable Amazon S3 caching for the build artifacts to reduce memory usage.

C.Split the build into multiple parallel CodeBuild actions in the pipeline, each compiling a subset of the code.

D.Set the environment variable 'MEMORY_OVERPROVISION=2' in the buildspec.

AnswerA

Upgrading the compute type in the buildspec—from the default BUILD_GENERAL1_SMALL (3 GB memory) to BUILD_GENERAL1_MEDIUM (7 GB) or BUILD_GENERAL1_LARGE (15 GB)—is the correct fix because CodeBuild's compute-type property directly controls the memory and vCPU allocated to the build container. Java compilation through Maven or Gradle is memory-intensive, and a small instance can easily cause the JVM or compiler daemon to run out of heap space. Selecting a larger general-purpose tier gives the build process a proportionally larger heap and OS memory, resolving the OOM without changing application code.

Why this answer

The most direct and cost-effective way to resolve insufficient memory in AWS CodeBuild is to increase the compute type to a larger size (e.g., BUILD_GENERAL1_MEDIUM or BUILD_GENERAL1_LARGE), which provides more memory without altering the build logic. This change incurs additional cost only when builds run, and it avoids unnecessary complexity or invalid approaches.

Exam trap

The trap here is that candidates may think caching or parallelism can solve memory issues, but neither addresses the fundamental lack of memory per build instance, and the fabricated environment variable 'MEMORY_OVERPROVISION' is designed to lure those who guess at undocumented features.

How to eliminate wrong answers

Option B is wrong because enabling Amazon S3 caching for build artifacts reduces build time by reusing cached dependencies, but it does not increase the available memory during the build process, so it cannot resolve out-of-memory errors. Option C is wrong because splitting the build into multiple parallel CodeBuild actions does not increase the memory per build instance; each action still runs on the same compute type with the same memory limit, and the compilation of a single subset may still fail if it requires more memory than the small instance provides. Option D is wrong because there is no such environment variable as 'MEMORY_OVERPROVISION' in AWS CodeBuild; this is a fabricated option that does not exist in the CodeBuild documentation.

Practice this question →

113

MCQeasy

A development team wants to automate infrastructure provisioning using AWS CloudFormation. Which tool is specifically designed to manage CloudFormation templates as part of a deployment pipeline?

A.AWS CodePipeline

B.AWS CodeCommit

C.AWS CodeBuild

D.AWS CodeDeploy

AnswerA

AWS CodePipeline is a fully managed continuous delivery service that orchestrates the entire release workflow, from source through build to deployment. As an orchestration engine, it can directly invoke AWS CloudFormation actions to provision or update infrastructure stacks at any stage. It supports custom actions, manual approval gates, and seamless integration with other AWS services, making it the correct choice for automating infrastructure provisioning as part of a CI/CD pipeline.

Why this answer

AWS CodePipeline is the correct answer because it is a fully managed continuous delivery service that allows you to model, visualize, and automate the steps required to release your infrastructure changes. You can integrate CloudFormation as a deployment action within a pipeline stage, enabling the automated creation, update, or deletion of stacks based on template changes committed to a source repository.

Exam trap

The trap here is that candidates often confuse AWS CodeDeploy (which deploys application code) with CloudFormation (which provisions infrastructure), leading them to select CodeDeploy instead of recognizing that CodePipeline is the service that orchestrates the entire deployment pipeline including CloudFormation actions.

How to eliminate wrong answers

Option B (AWS CodeCommit) is wrong because it is a source control service for storing Git repositories, not a pipeline orchestrator; it cannot execute CloudFormation templates or manage deployment stages. Option C (AWS CodeBuild) is wrong because it is a fully managed build service that compiles source code, runs tests, and produces artifacts, but it does not orchestrate multi-stage pipelines or directly deploy CloudFormation stacks. Option D (AWS CodeDeploy) is wrong because it automates code deployments to compute services like EC2 or Lambda, but it is not designed to manage infrastructure provisioning via CloudFormation templates.

Practice this question →

114

Multi-Selecteasy

Which TWO actions should a DevOps engineer take to ensure that an AWS CodeBuild project can access a private Amazon S3 bucket to download build artifacts? (Choose two.)

Select 2 answers

A.Generate an access key and secret key for the CodeBuild project to use in the buildspec

B.Add a bucket policy that explicitly allows access from the CodeBuild project's IAM role ARN

C.Configure the CodeBuild project to run in a VPC with an S3 VPC endpoint

D.Attach an IAM role to the CodeBuild project with s3:GetObject permissions for the bucket

E.Make the S3 bucket publicly readable

AnswersB, D

Adding a bucket policy that explicitly grants the CodeBuild project's IAM role ARN the s3:GetObject action is a resource-based policy approach. It complements the identity-based policy attached to the role and ensures S3 evaluates the permission grant directly, which is required when the bucket account enforces resource policies or when the bucket resides in a different account. This explicit allow on the bucket side removes any dependency on implicit same-account authorization and is a secure, scoped way to permit object retrieval.

Why this answer

A bucket policy can explicitly grant access to the CodeBuild project's IAM role ARN, allowing the CodeBuild service to download objects from the private S3 bucket. This is a common method to cross-account or service-specific access without making the bucket public.

Exam trap

The trap here is that candidates often confuse network-level controls (VPC endpoints) with IAM permissions, thinking that a VPC endpoint alone is sufficient to grant access to S3, when in fact IAM policies or bucket policies are still required.

Practice this question →

115

MCQhard

A DevOps engineer is designing a CI/CD pipeline for a microservices architecture. The pipeline must deploy to Amazon ECS using blue/green deployments. The team wants to automatically roll back if the new deployment fails health checks. Which combination of AWS services and configurations should the engineer use?

A.Use AWS CodeDeploy with an ECS compute platform, configure a CloudWatch alarm for health checks, and enable automatic rollback.

B.Use AWS CloudFormation with a custom resource to perform blue/green deployment.

C.Use AWS Elastic Beanstalk with blue/green environment swapping.

D.Use AWS CodePipeline with ECS deployment action and manual approval for rollback.

AnswerA

CodeDeploy with the ECS compute platform natively orchestrates blue/green deployments by shifting traffic between the original and replacement ECS task sets using a load balancer target group. You can associate CloudWatch alarms with the deployment and enable automatic rollback so that if health checks or custom metrics fail, CodeDeploy reverts traffic to the original task set without manual intervention. This is the only option that combines native ECS support, health monitoring, and automated rollback.

Why this answer

AWS CodeDeploy with an ECS compute platform natively supports blue/green deployments for Amazon ECS, including automatic rollback triggered by CloudWatch alarms. By configuring a CloudWatch alarm based on ECS service health checks (e.g., ELB target group health), CodeDeploy can automatically revert to the original blue task set if the new green deployment fails, meeting the requirement for zero-touch rollback.

Exam trap

The trap here is that candidates may assume CodePipeline's ECS action supports automatic rollback, but it only provides a deployment action without native health check monitoring or rollback logic, requiring additional custom steps or manual intervention.

How to eliminate wrong answers

Option B is wrong because AWS CloudFormation does not natively support blue/green deployments for ECS; custom resources would require significant custom code and lack built-in health check rollback integration. Option C is wrong because AWS Elastic Beanstalk is a PaaS service for web applications, not designed for microservices on ECS, and its blue/green environment swapping does not integrate with ECS task definitions or service health checks. Option D is wrong because AWS CodePipeline with an ECS deployment action does not support automatic rollback; manual approval for rollback contradicts the requirement for automatic rollback on health check failure.

Practice this question →

116

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

Enabling automatic rollback in the deployment group, combined with a CloudWatch alarm on the ALB health check, lets CodeDeploy detect the failed health check and revert to the last known-good revision automatically, satisfying the requirement for rollback without manual intervention.

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 →

117

MCQhard

A team uses AWS CodePipeline to deploy a serverless application using AWS SAM. The pipeline includes a build stage that runs 'sam build' and a deploy stage that runs 'sam deploy'. The deployment fails with an error: 'The security token included in the request is invalid.' What is the MOST likely cause?

A.The build stage did not produce the correct output artifact.

B.The SAM template has a syntax error.

C.The IAM role used in the deploy stage does not have permission to assume the CloudFormation execution role.

D.The 'sam deploy' command is missing the '--capabilities' parameter.

AnswerC

CodePipeline's CloudFormation deploy action uses a service role to issue `sts:AssumeRole` for the CloudFormation execution role specified in the pipeline configuration. If the service role's policy lacks `sts:AssumeRole` permission on that execution role (or the execution role's trust policy does not allow the service role), the STS call fails with 'AccessDenied' or an invalid-token indication because the temporary credentials cannot resolve the requested role. This precisely matches the reported error, making it the root cause.

Why this answer

The error 'The security token included in the request is invalid' typically occurs when the IAM role used by CodePipeline in the deploy stage lacks the necessary trust relationship or permissions to assume the CloudFormation execution role. In AWS SAM deployments via CodePipeline, the deploy action uses a specified IAM role to call CloudFormation, and if that role cannot assume the CloudFormation service role (or the CloudFormation role itself is misconfigured), the security token becomes invalid. This is a common misconfiguration when the pipeline's IAM role does not include the 'sts:AssumeRole' permission for the CloudFormation execution role ARN.

Exam trap

The trap here is that candidates often confuse IAM permission errors with template syntax or missing parameters, but the specific 'security token invalid' error points directly to an STS trust or assumption failure, not to CloudFormation validation or artifact issues.

How to eliminate wrong answers

Option A is wrong because the build stage not producing the correct output artifact would cause a different error, such as 'Artifact not found' or a missing file error, not an invalid security token. Option B is wrong because a SAM template syntax error would result in a CloudFormation validation error (e.g., 'Template format error') or a 'sam build' failure, not a security token error. Option D is wrong because missing the '--capabilities' parameter would cause a CloudFormation error like 'Requires capabilities: [CAPABILITY_IAM]', not an invalid security token error.

Practice this question →

118

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

A running process with an HTTP 503 health endpoint indicates the application started but cannot serve requests, typically because required configuration files are absent. The CodeDeploy agent logs no errors, confirming the failure is application-level, not deployment-mechanism-level.

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 →

119

MCQeasy

A company deploys an AWS CloudFormation stack that creates an Auto Scaling group and a launch template. The team wants every code change merged to the main branch to automatically update the stack, and they want to be able to roll back to the previous stack state if the update fails. Which combination of services should they use?

A.Amazon EventBridge with a rule that matches CodeCommit events and targets an AWS Step Functions state machine that calls cloudformation update-stack.

B.AWS CodeCommit with a repository trigger that invokes an AWS Lambda function to call cloudformation create-stack.

C.AWS CodePipeline with a CodeCommit source and a CloudFormation deploy action configured to create or update the stack.

D.AWS CodeBuild with a buildspec that runs the AWS CLI cloudformation deploy command and ignores failures.

AnswerC

CodePipeline can trigger on commits to the main branch through the CodeCommit source action, and the CloudFormation deploy action performs create or update semantics on the stack. CloudFormation automatically rolls back to the previous stack state if the update fails, satisfying both the automation and rollback requirements natively.

Why this answer

The requirement is automated deployment on main branch commits plus automatic rollback on failure. CodePipeline with a CodeCommit source and a CloudFormation deploy action provides both: the source action triggers on branch changes, and the deploy action creates or updates the stack with CloudFormation's built-in rollback on failure, requiring minimal custom code.

Exam trap

The trap here is choosing a custom orchestration with Lambda or Step Functions when the native pipeline and CloudFormation deploy action already provide triggering and rollback.

Practice this question →

120

MCQmedium

A development team uses AWS CodePipeline with multiple stages including source, build, and deploy. The pipeline uses an Amazon S3 source action that triggers on changes to a specific bucket. Recently, the pipeline stopped triggering automatically. The IAM role for CodePipeline has the necessary permissions. What is the most likely cause?

A.The IAM role for CodePipeline does not have s3:GetObject permission.

B.The S3 bucket policy denies access to CodePipeline.

C.The S3 bucket does not have event notifications configured.

D.AWS CloudTrail is not configured to deliver S3 data events to CloudWatch Logs.

AnswerD

CodePipeline uses Amazon EventBridge rules that match S3 object-created events recorded by AWS CloudTrail as data events. For these events to reach EventBridge, CloudTrail must be enabled to log S3 data events for the source bucket and deliver them to a CloudWatch Logs log group; the EventBridge rule then forwards matching events to the pipeline. If CloudTrail is not configured to deliver S3 data events to CloudWatch Logs, the pipeline's trigger remains silent even though the source code changes, causing the pipeline to appear stalled or never start. This is the root cause, as the IAM role, bucket policy, and S3 event notifications are all in order.

Why this answer

CodePipeline's S3 source action does not rely on S3 event notifications to trigger pipeline executions. Instead, it uses Amazon CloudWatch Events (now Amazon EventBridge) to detect changes to the S3 bucket. For this to work, AWS CloudTrail must be configured to deliver S3 data events (specifically `PutObject` API calls) to CloudWatch Logs, which then generates the event that triggers the pipeline.

Without CloudTrail data event logging, CodePipeline cannot detect object uploads, even if the IAM role has proper permissions.

Exam trap

The trap here is that candidates assume S3 event notifications are required for CodePipeline triggers, but AWS actually uses CloudTrail and EventBridge, so the correct answer focuses on CloudTrail configuration rather than S3 notifications.

How to eliminate wrong answers

Option A is wrong because `s3:GetObject` permission is required for CodePipeline to read the source artifact during the source stage, but the issue is about the pipeline not triggering automatically, not about failing to retrieve objects. Option B is wrong because a bucket policy denying access would cause a permission error when CodePipeline tries to access the bucket, but the question states the IAM role has necessary permissions, and the pipeline stopped triggering, not failing on access. Option C is wrong because S3 event notifications are not used by CodePipeline's S3 source action; CodePipeline uses CloudTrail and EventBridge for change detection, so missing event notifications would not prevent automatic triggers.

Practice this question →

121

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 →

122

MCQmedium

You are a DevOps engineer for a company that uses AWS CodePipeline to deploy a microservice to Amazon ECS with Fargate. The pipeline has a source stage (CodeCommit), a build stage (CodeBuild) that builds a Docker image and pushes it to Amazon ECR, and a deploy stage that uses an ECS task definition update. Recently, the deploy stage started failing intermittently with the error 'The task definition does not have a compatibilities attribute set correctly.' The task definition is generated dynamically during the build stage and uses the 'FARGATE' launch type. The error occurs only when a new task definition revision is created. You suspect the issue is related to how the task definition is generated. Upon reviewing the buildspec, you see that the task definition JSON is created using environment variables for the image URI. What is the MOST likely cause and solution?

A.The task definition is missing the 'executionRoleArn' field, which is required for Fargate.

B.The task definition JSON does not include the 'requiresCompatibilities' field with the value '["FARGATE"]'.

C.The task definition specifies 'networkMode' as 'bridge', but Fargate requires 'awsvpc'.

D.The task definition does not specify 'cpu' and 'memory' values, which are required for Fargate.

AnswerB

The `requiresCompatibilities` array must explicitly contain the value `"FARGATE"` so that ECS can verify the task definition is eligible to launch on Fargate. When this field is missing, any attempt to run the task with `launchType: FARGATE` produces an `InvalidParameterException` stating that the task definition is not compatible with the requested launch type. This field is an explicit declaration independent of networkMode, CPU, or memory, and is the exact missing piece that triggers the complaint about compatibility.

Why this answer

The 'requiresCompatibilities' attribute must be explicitly set to 'FARGATE' for Fargate tasks. Option A is incorrect because the error is about compatibilities, not execution role. Option C is incorrect because network mode should be 'awsvpc', but that is not the error.

Option D is incorrect because CPU and memory values are required but would cause a different error.

Practice this question →

123

Multi-Selectmedium

A DevOps team is designing a CI/CD pipeline for a containerized application. Which THREE components are essential for a complete pipeline? (Choose three.)

Select 3 answers

A.AWS CodeDeploy

B.Artifact storage

C.Amazon CloudWatch

D.Build and test automation

E.Source control repository

AnswersB, D, E

Artifact storage is the durable, versioned repository that holds the output of the build stage, such as Docker images in Amazon ECR or packages in S3, until the deployment stage consumes them. Without this component, builds are ephemeral and you cannot reliably reproduce a release, roll back to a known-good version, or audit exactly what was deployed. In a container context, the image registry is a distinct stateful service that integrates with IAM and image scanning, making it a non-negotiable pipeline component.

Why this answer

Artifact storage (Option B) is essential because a complete CI/CD pipeline must store build outputs (e.g., Docker images, JAR files) in a durable, versioned repository. Without artifact storage, subsequent deployment stages cannot reliably retrieve the exact build artifact that passed testing, breaking traceability and rollback capabilities. Services like Amazon ECR or S3 serve this role, ensuring immutability and consistent delivery across environments.

Exam trap

The trap here is that candidates confuse 'deployment service' (CodeDeploy) with a pipeline component, or mistake monitoring (CloudWatch) as essential, when the question specifically asks for the three core stages that form a complete pipeline: source, build/test, and artifact storage.

Practice this question →

124

MCQeasy

A company uses AWS CodePipeline with multiple stages: Source, Build, Test, Deploy. The Test stage runs integration tests using AWS CodeBuild. If the Test stage fails, what happens to the pipeline execution?

A.The pipeline continues to the next stage but marks the Test stage as failed.

B.The pipeline execution stops and the status is set to 'Failed'.

C.The pipeline skips the Test stage and proceeds to Deploy.

D.The pipeline automatically retries the Test stage up to three times.

AnswerB

This is correct. When any action in the Test stage fails, CodePipeline immediately transitions the entire pipeline execution to the Failed status, and no later stages run. The execution history preserves the failure details for inspection, but you must resolve the root cause and retry the failed action or start a new execution manually; the pipeline does not recover on its own.

Why this answer

In AWS CodePipeline, by default, if a stage (such as Test) fails, the pipeline execution immediately stops and the overall pipeline status is set to 'Failed'. This is because CodePipeline treats each stage as a sequential gate; a failure in any stage blocks progression to subsequent stages unless explicitly configured otherwise (e.g., with a 'Blocker' or 'Manual Approval' action). Option B correctly describes this default behavior.

Exam trap

The trap here is that candidates may confuse the default behavior with optional features like automatic retries or stage skipping, assuming CodePipeline behaves like a CI/CD tool that allows failures to pass through (e.g., Jenkins with 'unstable' status) or automatically retries failed jobs.

How to eliminate wrong answers

Option A is wrong because CodePipeline does not continue to the next stage after a failure; it halts execution and marks the pipeline as 'Failed', not just the stage. Option C is wrong because CodePipeline does not skip a failed stage; it stops entirely, preventing the Deploy stage from running. Option D is wrong because CodePipeline does not automatically retry a failed stage; retry behavior must be explicitly configured using the 'Retry' feature in the pipeline settings or via manual intervention.

Practice this question →

125

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 →

126

MCQhard

Refer to the exhibit. An IAM policy is attached to a user. The user tries to push a commit to the 'develop' branch of 'MyRepo' using Git. What is the outcome?

A.The push is denied only if the user is pushing to the 'main' branch.

B.The push succeeds because the Allow statement grants GitPush.

C.The push is denied because the user is not pushing to the 'main' branch.

D.The push is denied because the Deny statement blocks all GitPush actions.

AnswerC

This is correct because the Deny statement is scoped to any branch reference that is not `main`. When the user pushes to a branch like `develop`, the condition `StringNotEquals` on `codecommit:References` evaluates to true, causing an explicit Deny that blocks the `GitPush` action. Under IAM's evaluation logic, an explicit Deny overrides the earlier Allow, so the push is denied. A push to `main` would not trigger the Deny and would be allowed, confirming the condition is the decisive factor.

Why this answer

The policy allows GitPull and GitPush on the repo, but denies GitPush when the reference is not 'refs/heads/main'. Since the user is pushing to 'develop', the condition is met, and the Deny applies. An explicit Deny overrides any Allow, so the push is denied.

Practice this question →

127

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 →

128

MCQhard

A CodeDeploy deployment group is configured as shown in the exhibit. During a deployment, the deployment fails because the instances are not found. What is the MOST likely reason?

A.The deployment configuration 'CodeDeployDefault.AllAtOnce' is not compatible with in-place deployments

B.The EC2 instances do not have the tag 'Environment' with value 'Production'

C.The service role ARN is incorrect and does not have the necessary permissions

D.The load balancer 'my-alb' is not registered with the instances

AnswerB

The deployment group's Amazon EC2 tag group is configured with key 'Environment' and value 'Production', and CodeDeploy identifies target instances solely by this tag filter. If no running instance carries both the exact key and value, CodeDeploy cannot discover any targets and the deployment fails with a 'No instances found' error before any other step executes. Therefore, the missing tag is the root cause of the failure.

Why this answer

The exhibit shows the deployment group is configured to match EC2 instances with the tag 'Environment' set to 'Production'. If the instances do not have this exact tag key-value pair, CodeDeploy cannot find them during the deployment, causing the failure. The error 'instances are not found' directly points to a tag mismatch, not to permissions or load balancer issues.

Exam trap

The trap here is that candidates often confuse 'instances not found' errors with permission or load balancer issues, but the error is a direct result of tag mismatch, which is the most common cause in CodeDeploy tag-based deployments.

How to eliminate wrong answers

Option A is wrong because 'CodeDeployDefault.AllAtOnce' is a valid deployment configuration that deploys to all instances simultaneously and is fully compatible with in-place deployments; the error is about instances not found, not about configuration incompatibility. Option C is wrong because an incorrect service role ARN or insufficient permissions would typically result in an 'access denied' or 'permission error', not an 'instances not found' error. Option D is wrong because the load balancer 'my-alb' not being registered with instances would cause health check or routing issues, but the deployment would still find the instances; the error specifically states instances are not found, indicating a tag or filter mismatch.

Practice this question →

129

MCQhard

A company uses AWS CodeBuild to compile and test code. The buildspec.yaml includes a pre_build phase that runs 'aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com'. The build fails with 'Error: Cannot connect to the Docker daemon'. What is the most likely cause?

A.The CodeBuild project does not have privileged mode enabled.

B.The region specified does not match the ECR repository region.

C.The Docker login command syntax is incorrect.

D.The AWS CLI is not installed in the CodeBuild environment.

AnswerA

In CodeBuild, Docker commands require access to a Docker daemon, but the default build environment runs as an unprivileged container without the necessary kernel capabilities (e.g., CAP_SYS_ADMIN) to start or use Docker. When privileged mode is not enabled, any Docker command such as `docker build` or `docker push` fails with permission errors or 'Cannot connect to the Docker daemon' because the daemon cannot run inside the container. Setting `PRIVILEGED_MODE=true` in the CodeBuild project environment (or via `PrivilegedMode: true` in infrastructure as code) is mandatory for Docker-based builds that need to build and push images to Amazon ECR.

Why this answer

The error 'Cannot connect to the Docker daemon' indicates that the Docker daemon is not running or inaccessible within the CodeBuild build environment. CodeBuild runs Docker commands inside a container that does not have a Docker daemon by default. To execute Docker commands (such as docker login or docker build), the CodeBuild project must be configured with privileged mode enabled, which grants the container elevated permissions to run its own Docker daemon.

Without privileged mode, any attempt to interact with the Docker daemon will fail.

Exam trap

The trap here is that candidates may focus on the AWS CLI or ECR authentication syntax, missing that the fundamental issue is the Docker daemon not being available, which is a CodeBuild-specific configuration requirement for running Docker commands.

How to eliminate wrong answers

Option B is wrong because if the region did not match the ECR repository, the error would be an authentication or repository not found error (e.g., 'Error: Cannot locate repository'), not a Docker daemon connection error. Option C is wrong because the Docker login command syntax is correct: 'aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com' is the standard AWS ECR authentication pattern. Option D is wrong because the AWS CLI is pre-installed in all CodeBuild managed images; if it were missing, the error would be 'aws: command not found', not a Docker daemon error.

Practice this question →

130

MCQhard

A company uses AWS CodeCommit for source control and wants to enforce that all commits to the main branch are signed. The DevOps team has configured Git commit signing using GPG keys. However, some developers are able to push unsigned commits to main. What should the engineer do to enforce signed commits?

A.Set the 'requireSignedCommits' parameter in the repository configuration to 'true'.

B.Configure branch protection rules in IAM to deny push access to main unless the commit is signed.

C.Use an AWS CodeCommit trigger with an AWS Lambda function that validates commit signatures and rejects unsigned commits.

D.Create a repository policy that denies git push actions unless the condition 'codecommit:References' and 'codecommit:SourceIp' match.

AnswerC

CodeCommit triggers invoke a Lambda function asynchronously when a reference is updated, and that Lambda can inspect the pushed commit objects using the Git command line or the CodeCommit API to verify GPG signatures. Although the trigger fires after the push is initially accepted, the Lambda can delete or restore the branch reference to its previous commit via the UpdateRef API, effectively rejecting the unsigned commit and preserving repository integrity. This is the practical way to enforce signed commits because CodeCommit itself has no native, built-in signed-commit enforcement.

Why this answer

AWS CodeCommit does not natively support a 'require signed commits' setting like GitHub or GitLab. To enforce signed commits, you must use a CodeCommit trigger that invokes an AWS Lambda function to validate the GPG signature of each commit pushed to the main branch. The Lambda function can parse the commit object, verify the signature using the developer's public key, and reject the push by returning an error if the commit is unsigned or the signature is invalid.

Exam trap

The trap here is that candidates assume AWS CodeCommit has a built-in 'require signed commits' toggle like GitHub or GitLab, but AWS CodeCommit requires a custom serverless solution (Lambda trigger) to enforce this, and the exam tests your ability to recognize when native features are absent.

How to eliminate wrong answers

Option A is wrong because AWS CodeCommit does not have a 'requireSignedCommits' parameter in its repository configuration; this setting exists in GitHub, not in CodeCommit. Option B is wrong because IAM policies cannot inspect the content of a commit (such as whether it is signed) — IAM evaluates permissions based on the action and resource, not the commit payload. Option D is wrong because a repository policy with 'codecommit:References' and 'codecommit:SourceIp' conditions can restrict pushes based on branch reference or source IP address, but it cannot validate commit signatures.

Practice this question →

131

MCQeasy

A DevOps team wants to run unit tests in parallel across multiple build environments using AWS CodeBuild. Which build specification configuration allows this?

A.Use multiple build phases in the buildspec file.

B.Configure multiple artifacts in the buildspec.

C.Define a batch build with multiple builds.

D.Set environment variables to run multiple commands concurrently.

AnswerC

A batch build lets you define multiple builds that CodeBuild schedules on separate compute environments, running them concurrently up to the configured max batch size or parallelization limit. Each build in the batch can have its own buildspec override, environment variables, or input source, making it ideal for sharding unit tests across workers. This is the intended AWS mechanism for executing independent unit tests in parallel.

Why this answer

AWS CodeBuild supports batch builds, which allow you to define a build project that runs multiple builds in parallel. By specifying a batch configuration in your buildspec file (using the `batch` section), you can run unit tests across multiple build environments simultaneously, improving test execution speed and resource utilization.

Exam trap

The trap here is that candidates confuse sequential build phases with parallel execution, or assume that environment variables or multiple artifacts can achieve parallelism, when only the batch build feature in CodeBuild provides true parallel builds across multiple environments.

How to eliminate wrong answers

Option A is wrong because multiple build phases (e.g., install, pre_build, build, post_build) run sequentially within a single build, not in parallel across multiple environments. Option B is wrong because configuring multiple artifacts in the buildspec defines output files from a single build, not parallel execution across environments. Option D is wrong because setting environment variables to run multiple commands concurrently does not enable parallel builds across separate environments; it only runs commands sequentially within the same build container.

Practice this question →

132

MCQmedium

A DevOps engineer is creating a CodePipeline service role. The above IAM policy is attached to the role. The pipeline fails when trying to download artifacts from the S3 bucket. What is the issue?

A.The Resource for S3 actions should be the bucket ARN, not the object ARN.

B.The policy is missing s3:ListBucket permission on the bucket.

C.The CodeDeploy actions require a specific resource ARN instead of '*'.

D.The Action list is missing s3:GetObjectVersion.

AnswerB

The policy is missing s3:ListBucket permission on the bucket. CodePipeline requires the ability to list the contents of the S3 artifact bucket in order to enumerate source objects, determine which artifacts are present, and trigger the pipeline correctly. s3:ListBucket is a bucket-level action, so its Resource must be the bucket ARN (arn:aws:s3:::bucket-name), not the object ARN. Without this permission, the pipeline will fail during the source stage with an access denied error, even though GetObject is present, because the service cannot discover which objects to fetch.

Why this answer

The pipeline fails because the IAM policy grants s3:GetObject on the object ARN but lacks s3:ListBucket on the bucket ARN. CodePipeline's S3 artifact download action first calls ListBucket to verify the bucket exists and the object key is accessible before performing the GetObject call. Without s3:ListBucket, the initial validation fails, causing the pipeline to error out even though GetObject is allowed.

Exam trap

The trap here is that candidates assume only s3:GetObject is needed for downloading artifacts, overlooking that CodePipeline's S3 action internally requires s3:ListBucket to resolve the object location before retrieval.

How to eliminate wrong answers

Option A is wrong because the Resource for S3 actions should be the object ARN (arn:aws:s3:::bucket-name/*) for GetObject, not the bucket ARN; using the bucket ARN would incorrectly grant access to the bucket itself rather than the objects. Option C is wrong because CodeDeploy actions can use '*' as the Resource ARN when the policy is attached to a service role that is scoped to a specific deployment group or application via the pipeline's configuration, and the issue here is S3 permissions, not CodeDeploy. Option D is wrong because s3:GetObjectVersion is only needed when retrieving a specific version of an object (e.g., versioned buckets), and the question does not indicate versioning is enabled; the missing permission is s3:ListBucket, not GetObjectVersion.

Practice this question →

133

MCQmedium

A company uses AWS CodeCommit as a Git repository and CodeBuild for continuous integration. The buildspec.yml file includes steps to run unit tests and package the application. The team wants to ensure that only code from the main branch is deployed to production. They have set up a CodePipeline that triggers on changes to any branch. The pipeline includes a build stage that runs CodeBuild, and then a deploy stage that deploys to production. The team noticed that code from feature branches is being deployed to production accidentally. The team wants to modify the pipeline to prevent this. What is the MOST effective solution?

A.Use IAM policies to restrict developers from pushing to the main branch.

B.In the CodePipeline source stage, configure the branch filter to only allow the main branch to trigger the pipeline.

C.Add a manual approval step before the deploy stage and require approval from a senior engineer.

D.Modify the CodeBuild project to only build the main branch by specifying the branch in the source configuration.

AnswerB

Configure the CodeCommit source action in the pipeline to specify 'main' as the Branch name; CodePipeline then only initiates an execution when a new commit is pushed to that exact branch. This branch filter is applied at the source stage before any build or deploy action runs, preventing resource consumption for non-main branches. It is the standard, supported mechanism for branch-scoped pipeline behavior in CodePipeline.

Why this answer

The most effective fix is to configure the CodePipeline source stage with a branch filter that only allows the main branch to trigger the pipeline. This prevents feature-branch commits from ever entering the pipeline, stopping the accidental production deployment at the source rather than downstream.

Exam trap

DOP-C02 often tests the confusion between fixing a problem at the source stage versus adding downstream gates — candidates pick manual approval or IAM restrictions when the cleanest fix is the pipeline source branch filter.

How to eliminate wrong answers

Option A is wrong because restricting developers from pushing to main does not prevent feature-branch code from triggering the pipeline — it addresses a different problem and doesn't stop the accidental deployment. Option C is wrong because a manual approval step adds a human gate but still allows feature-branch code to reach the deploy stage pending approval, which is not the most effective prevention. Option D is wrong because modifying the CodeBuild project's source configuration is a build-level workaround; the pipeline source stage is the correct control point, and CodeBuild branch filtering is less reliable than pipeline-level filtering.

Practice this question →

134

MCQeasy

A development team uses AWS CodeBuild to run unit tests on every commit to the develop branch. The tests take a long time because they download dependencies each time. What should the team do to reduce build time?

A.Enable the local cache feature in CodeBuild.

B.Store dependencies in Amazon Elastic File System (EFS) and mount it during builds.

C.Increase the compute type of the build environment.

D.Use multiple builds in parallel for the same commit.

AnswerA

Enabling the local cache feature in CodeBuild stores resolved dependencies (e.g., Maven, pip, npm packages) in a local directory or an S3-backed bucket between builds. On subsequent builds, CodeBuild restores this cache instantly, eliminating the need to re-download and re-resolve packages. This directly reduces the network I/O bottleneck that dominates unit-test build time, especially for frequently executed builds, and is the correct way to speed up dependency-heavy pipelines.

Why this answer

Enabling the local cache feature in CodeBuild allows the build environment to cache dependencies, such as Maven or npm packages, in a local directory that persists across builds. This avoids re-downloading unchanged dependencies on every commit, significantly reducing build time. The cache can be stored in an S3 bucket or locally on the build instance, and is automatically restored at the start of each build.

Exam trap

The trap here is that candidates often confuse caching with storage solutions like EFS or with scaling compute resources, failing to recognize that the core issue is repetitive network-bound dependency downloads, which only a cache mechanism can mitigate.

How to eliminate wrong answers

Option B is wrong because mounting an Amazon EFS filesystem adds network latency and does not inherently cache dependencies; it would still require downloading dependencies to the EFS volume initially, and the mount overhead can increase build time. Option C is wrong because increasing the compute type (e.g., more vCPUs or memory) does not reduce the time spent downloading dependencies; it only speeds up CPU-bound or memory-bound tasks, not network I/O. Option D is wrong because running multiple builds in parallel for the same commit does not reduce the time for a single build; it would run redundant tests and waste resources without addressing the dependency download bottleneck.

Practice this question →

135

MCQmedium

An organization uses AWS CodePipeline with a multi-branch strategy. They want to run unit tests on every push to any branch, but only deploy to production on pushes to the 'main' branch. What is the most efficient way to achieve this?

A.Configure a single pipeline with a source action that triggers on all branches, then use a 'branch' condition on the deployment stage to only proceed if the branch is 'main'.

B.Use a single pipeline with a source action that triggers on all branches, and deploy to a test environment for all branches, then promote to production manually.

C.Create separate pipelines for each branch, each with its own test and deploy stages.

D.Use a single pipeline with a source action that only triggers on the 'main' branch, and run tests in a separate system.

AnswerA

This option uses a single CodePipeline execution triggered by all branch updates, and then applies a stage condition such as #{SourceVariables.BranchName} == 'main' on the deployment action. Test and build stages still run for every branch, but non-main branches are skipped at the deployment stage, so no production release occurs for feature branches. This minimizes pipeline infrastructure, reduces maintenance, and keeps the automation fully managed inside the pipeline.

Why this answer

AWS CodePipeline supports a single pipeline with a source action configured to trigger on all branches (e.g., using a webhook event filter for 'refs/heads/*'). You can then add a 'branch' condition on the deployment stage using a Lambda function or a manual approval action that checks the branch name, ensuring only pushes to 'main' proceed to production. This approach avoids duplicating pipelines while still running unit tests on every push.

Exam trap

The trap here is that candidates often think they need separate pipelines per branch (Option C) or a manual promotion step (Option B), but AWS CodePipeline supports branch filtering natively via webhook event patterns and custom conditions, making a single pipeline the most efficient choice.

How to eliminate wrong answers

Option B is wrong because it suggests deploying to a test environment for all branches and then manually promoting to production, which does not automatically restrict production deployment to only the 'main' branch and introduces unnecessary manual steps. Option C is wrong because creating separate pipelines for each branch is inefficient and harder to maintain, especially as the number of branches grows, and it violates the principle of using a single pipeline for multi-branch strategies. Option D is wrong because it runs tests in a separate system outside CodePipeline, which breaks the unified CI/CD workflow and does not leverage CodePipeline's built-in multi-branch triggering capabilities.

Practice this question →

136

MCQmedium

A team uses AWS CodeDeploy to deploy a web application to an Auto Scaling group. The deployment fails with the error 'The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available, or some instances in your deployment group are experiencing problems.' The team checks the logs and finds that the application installation script fails on some instances due to missing dependencies. What is the BEST long-term solution?

A.Create a custom AMI that includes all dependencies and use it in the Auto Scaling group.

B.Use an Elastic Load Balancer health check to automatically replace failed instances.

C.Modify the CodeDeploy AppSpec file to run the installation script as root.

D.Implement a retry mechanism in the deployment script to install dependencies again.

AnswerA

Creating a custom Amazon Machine Image (AMI) that has all required runtime dependencies pre-installed and using it in the Auto Scaling group is the most robust fix. When instances launch from this golden AMI, the operating system and packages are already present, so the CodeDeploy deployment only needs to place and start the application code. This eliminates runtime failures caused by dependency installation errors and guarantees consistency across newly launched instances.

Why this answer

Creating a custom AMI that includes all dependencies ensures that every instance launched in the Auto Scaling group has the required software pre-installed. This eliminates the root cause of the deployment failure—missing dependencies—by baking them into the machine image, making deployments consistent and reliable. It is the best long-term solution because it avoids runtime dependency installation failures and reduces deployment time.

Exam trap

The trap here is that candidates often choose a retry mechanism or health check fix, thinking they can handle transient failures, but the question specifies 'missing dependencies'—a persistent issue that requires a proactive, image-based solution rather than reactive or permission-based fixes.

How to eliminate wrong answers

Option B is wrong because an Elastic Load Balancer health check only detects and replaces unhealthy instances after they fail, but it does not prevent the deployment failure caused by missing dependencies; it is a reactive measure, not a long-term fix. Option C is wrong because running the installation script as root does not resolve missing dependencies; it only changes the execution user, and dependency installation failures are typically due to missing packages, not permission issues. Option D is wrong because implementing a retry mechanism in the deployment script only retries the same failing dependency installation, which will continue to fail if the dependencies are not available in the instance's package repositories or are not properly configured; it does not address the underlying missing dependency problem.

Practice this question →

137

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 →

138

Multi-Selectmedium

Which of the following are valid strategies for implementing continuous integration in AWS? (Choose two.)

Select 2 answers

A.Configure AWS CodeBuild to automatically run tests when a pull request is created in CodeCommit.

B.Set up AWS CodeDeploy to trigger a build every time a commit is pushed to a repository.

C.Use AWS CodePipeline with a source stage that polls CodeCommit for changes and triggers a build stage.

D.Use AWS CloudFormation to create a stack that runs tests every time a new commit is pushed.

AnswersA, C

Using AWS CodeBuild with CodeCommit as a source, you can configure pull request filters so a test build starts automatically when a PR is created, before the branch is merged. The buildspec can run unit tests and integration tests against the PR source revision, then post status back to CodeCommit. This event-driven behavior is a canonical continuous integration practice because it validates every proposed change quickly without waiting for a scheduled pipeline.

Why this answer

AWS CodeBuild can be configured to automatically run tests when a pull request is created in CodeCommit using a webhook or event rule. This enables continuous integration by validating code changes before merging, ensuring that only tested code is integrated into the main branch.

Exam trap

The trap here is confusing deployment services (CodeDeploy) and infrastructure provisioning (CloudFormation) with CI build triggers, leading candidates to select options that sound plausible but lack the specific capability to initiate a build or run tests.

Why the other options are wrong

CodeDeploy is for deployment, not building or testing.

CloudFormation is for infrastructure as code, not for running tests.

Practice this question →

139

MCQeasy

A company uses AWS CodeBuild to build a Docker image and push it to Amazon ECR. The buildspec.yml includes a 'post_build' phase command to tag the image. The build fails with 'unauthorized: authentication required'. What must be done to resolve this?

A.Add 'ecr:InitiateLayerUpload' and 'ecr:CompleteLayerUpload' permissions to the CodeBuild service role.

B.Use the 'docker login' command with AWS CLI in the build phase.

C.Install the AWS CLI in the CodeBuild build environment.

D.Create a new IAM user with ECR permissions and store the keys in CodeBuild environment variables.

AnswerA

The AWS CodeBuild service role is the IAM identity that supplies temporary credentials to the build container. Pushing a Docker image to Amazon ECR requires calling the ECR API operations InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload, and PutImage, so the role must explicitly allow those actions. Without these permissions, even a successfully authenticated docker login will fail when the push actually attempts to upload the image layers. Granting the policy to the service role is the secure, minimal-change fix.

Why this answer

The error 'unauthorized: authentication required' indicates that CodeBuild's IAM role lacks the necessary permissions to push the Docker image to Amazon ECR. The correct resolution is to add the specific ECR permissions 'ecr:InitiateLayerUpload' and 'ecr:CompleteLayerUpload' to the CodeBuild service role, as these are required for the Docker push operation to upload image layers. Without these permissions, the ECR API rejects the push even if other permissions like 'ecr:GetAuthorizationToken' are present.

Exam trap

The trap here is that candidates often assume the 'unauthorized' error is due to missing 'ecr:GetAuthorizationToken' or a need to run 'docker login', but the real issue is the absence of specific layer upload permissions required for the push operation.

How to eliminate wrong answers

Option B is wrong because 'docker login' with AWS CLI is not needed in CodeBuild; CodeBuild automatically authenticates to ECR using the instance's IAM role when the AWS CLI is configured, and manual login is redundant and can cause conflicts. Option C is wrong because the AWS CLI is already pre-installed in CodeBuild's standard build environments (e.g., Amazon Linux 2), so installing it again does not resolve the missing IAM permissions. Option D is wrong because creating a new IAM user and storing keys in environment variables is an anti-pattern; it introduces long-term credentials that must be rotated and violates the principle of least privilege, whereas the correct approach is to grant the necessary permissions directly to the CodeBuild service role.

Practice this question →

140

MCQmedium

A company stores its application source in an AWS CodeCommit repository. The security team requires that all code changes be reviewed and approved by at least one other developer before being merged into the `main` branch. A DevOps engineer needs to enforce this policy and prevent direct pushes to `main`. Which combination of actions should the engineer take?

A.Configure an Amazon EventBridge rule that triggers an AWS Lambda function to revert any direct push to `main` and send a notification.

B.Enable branch protection on `main` in the CodeCommit console and configure an approval rule that requires one approver.

C.Use AWS CodePipeline to automatically reject any commit to `main` that does not have an approved pull request, and notify the security team.

D.Create an IAM policy that denies `codecommit:GitPush` to the `main` branch for all developers, and require pull requests via a repository approval rule template.

AnswerD

IAM policies can restrict Git push operations to specific branches using the `codecommit:References` condition key. Denying `codecommit:GitPush` to `refs/heads/main` prevents direct pushes. Additionally, approval rule templates enforce pull request approvals. Together, they meet both requirements: no direct pushes and mandatory review.

Why this answer

To prevent direct pushes to a specific branch in CodeCommit, an IAM policy must deny the `codecommit:GitPush` action for that branch reference. This is done using the `codecommit:References` condition key. To require approvals before merging, an approval rule template can be applied to the repository, mandating a minimum number of approvals.

Together, these native features enforce both aspects of the security policy without custom code.

Exam trap

The trap here is assuming CodeCommit has a branch protection toggle like other Git services, when it actually relies on IAM policies for push restrictions.

Practice this question →

141

MCQmedium

A development team uses AWS CodeCommit and AWS CodePipeline for CI/CD. They notice that a pipeline execution failed due to a code review rejection in the 'Approve' stage. The pipeline is configured with a manual approval action. What is the most likely cause of the failure?

A.The IAM role for the pipeline does not have permission to invoke the approval action.

B.The CodeCommit repository has a branch policy that prevents direct commits.

C.An authorized user logged in to the CodePipeline console and rejected the approval request.

D.The pipeline is not configured with a CloudWatch Events rule to trigger the approval.

AnswerC

When a manual approval action is reached, an authorized IAM user sees a Review button in the CodePipeline console and can choose Approve or Reject. Selecting Reject transitions the pipeline execution to a failed state with a status of 'Rejected', and any reviewer comment is recorded in the execution history. This is the only mechanism that directly causes a rejection.

Why this answer

A manual approval action in CodePipeline explicitly requires a human reviewer to approve or reject the pipeline execution. If the pipeline failed due to a 'code review rejection,' the most direct cause is that an authorized user logged into the CodePipeline console and clicked the 'Reject' button on the approval request. This is the only mechanism by which a manual approval action can result in a rejection.

Exam trap

The trap here is that candidates may confuse the manual approval action with automated checks or permissions issues, overlooking that the only way a manual approval action results in a rejection is through explicit human action in the console or API.

How to eliminate wrong answers

Option A is wrong because the IAM role for the pipeline does not need permission to 'invoke' the approval action; the approval action is manual and relies on user authentication, not pipeline role permissions. Option B is wrong because a CodeCommit branch policy that prevents direct commits would block pushes to the repository, but it does not affect the manual approval stage in CodePipeline, which occurs after the source and build stages. Option D is wrong because CloudWatch Events rules are used to trigger pipeline executions automatically (e.g., on source changes), but they are not required for the manual approval action to function; the approval stage is triggered by the pipeline execution itself.

Practice this question →

142

MCQmedium

A company uses AWS CodeCommit for source control. Developers work on feature branches and create pull requests to merge into the 'develop' branch. The company wants to enforce that all commits to the 'develop' branch are signed. Which AWS service or feature should be used to enforce this policy?

A.Use Amazon CloudWatch Events to trigger a Lambda function that verifies commit signatures and reverts unsigned commits.

B.Create an approval rule template in CodeCommit that requires commits to be signed and associate it with the 'develop' branch.

C.Use AWS Key Management Service (KMS) to create a signing key and require developers to use it.

D.Configure an IAM policy that denies 'git push' unless the commit is signed.

AnswerB

Incorrect. Approval rule templates only require approvals from specified users; they do not verify commit signatures or enforce signing.

Why this answer

AWS CodeCommit natively supports enforcing signed commits. You can create an approval rule template with the 'Require commit signing' condition and associate it with the 'develop' branch. This ensures that any commit to the branch must be signed with a valid GPG key, and unsigned commits are rejected.

Option A is incorrect because using CloudWatch Events and Lambda to revert unsigned commits is not a native enforcement mechanism and is unnecessary. Option C is incorrect because KMS is not used for Git commit signing. Option D is incorrect because IAM policies cannot inspect commit signatures.

Exam trap

The trap is that candidates may think CodeCommit lacks native support for signed commits and resort to a custom Lambda-based solution. In reality, CodeCommit approval rule templates can enforce commit signing directly.

How to eliminate wrong answers

Option A is wrong because CloudWatch Events and Lambda can react to events but cannot enforce a policy at the git push level; reverting unsigned commits after they are pushed is reactive and violates the requirement to enforce signing. Option C is wrong because AWS KMS provides signing keys but does not enforce commit signing policies in CodeCommit; developers could still push unsigned commits. Option D is wrong because IAM policies cannot inspect the content of a git push (such as whether a commit is signed); they only control API-level permissions, not commit metadata.

Practice this question →

143

MCQhard

A company uses AWS CodeBuild to run integration tests. The tests require access to an RDS database in a private subnet. CodeBuild runs in a VPC but the build times out waiting for the database connection. What is the MOST likely cause?

A.CodeBuild cannot access resources in a private subnet unless it uses a NAT gateway.

B.The CodeBuild service role does not have rds:Connect permission.

C.The CodeBuild project's security group outbound rules do not allow traffic to the RDS security group on port 3306 (or appropriate port).

D.The RDS instance is in a different subnet CIDR than CodeBuild's subnet.

AnswerC

Correct: When CodeBuild is attached to a VPC, the build container uses an elastic network interface with the project's security group. The outbound rules on that security group must explicitly allow TCP traffic to the RDS security group on the database port (e.g., 3306 for MySQL or 5432 for PostgreSQL). If the outbound rule is missing, the packets are silently dropped, causing a timeout even though the RDS inbound rule and IAM role are correct. Since security groups are stateful, the response path is automatically allowed once the inbound rule on RDS accepts the request, but the initial outbound allowance is still required.

Why this answer

CodeBuild's security group outbound rules must explicitly allow traffic to the RDS security group on the database port (e.g., 3306 for MySQL). Even though CodeBuild runs in a VPC, if the outbound rules are too restrictive, the build agent cannot establish a TCP connection to the RDS instance, causing a timeout. The security group acts as a virtual firewall for the CodeBuild ENI, and without a matching outbound rule, packets are dropped.

Exam trap

The trap here is that candidates often assume IAM permissions (like rds:Connect) control network access, but RDS network access is governed solely by security groups and VPC routing, not IAM.

How to eliminate wrong answers

Option A is wrong because CodeBuild can access resources in a private subnet directly when it is launched in the same VPC; a NAT gateway is only needed for outbound internet access, not for VPC-internal traffic. Option B is wrong because IAM permissions like rds:Connect do not exist; RDS access is controlled by security group rules and database credentials, not IAM actions for network connectivity. Option D is wrong because subnets with different CIDRs can still communicate within the same VPC via the VPC router, as long as route tables and security groups permit the traffic.

Practice this question →

144

MCQhard

A company uses AWS CloudFormation to manage infrastructure. They want to deploy a stack that creates an Amazon RDS DB instance. The database password must be stored securely and rotated automatically. Which approach meets these requirements?

A.Hardcode the password in the CloudFormation template and use a NoEcho parameter.

B.Use AWS Key Management Service (KMS) to encrypt the password and pass it as a parameter.

C.Store the password in AWS Systems Manager Parameter Store and reference it using a dynamic reference.

D.Store the password in AWS Secrets Manager and enable automatic rotation. Reference the secret in the template using a dynamic reference.

AnswerD

AWS Secrets Manager offers native automatic rotation through a configured Lambda function, allowing the password to be rotated on a schedule independent of CloudFormation. Referencing the secret with a dynamic reference such as {{resolve:secretsmanager:MySecret:SecretString:password}} retrieves the current value at deployment time without embedding plaintext or ciphertext in the template. This combines secure storage, versioning, managed rotation, and clean CloudFormation integration, which makes it the correct choice.

Why this answer

AWS Secrets Manager provides built-in capabilities for automatic password rotation, which is a requirement. By storing the password in Secrets Manager and referencing it in the CloudFormation template using a dynamic reference (e.g., `{{resolve:secretsmanager:secret-id:SecretString:password}}`), the password is never exposed in the template or parameter logs, and rotation can be configured without updating the stack. This approach meets both security and automation requirements.

Exam trap

The trap here is that candidates confuse AWS Systems Manager Parameter Store with AWS Secrets Manager, assuming both support automatic rotation, but only Secrets Manager provides native rotation capabilities for RDS credentials.

How to eliminate wrong answers

Option A is wrong because hardcoding the password in the template, even with NoEcho, still exposes the password in the template source code and does not support automatic rotation. Option B is wrong because passing the password as a parameter, even if encrypted with KMS, does not enable automatic rotation and the plaintext value may be logged in AWS CloudTrail or parameter history. Option C is wrong because AWS Systems Manager Parameter Store does not support automatic rotation of secrets; it is a parameter store, not a secrets manager with rotation capabilities.

Practice this question →

145

MCQmedium

A company uses AWS CodeBuild to compile and test code. The build takes 30 minutes, but the team wants to reduce build time by caching dependencies. Which approach should be used?

A.Remove unnecessary dependencies from the build specification.

B.Store dependencies in an S3 bucket and download them before each build.

C.Use AWS CodeArtifact to store dependencies and pull them during build.

D.Enable local caching in the build project configuration.

AnswerD

Enabling local caching in the CodeBuild project configuration is the officially supported way to reuse dependencies across builds. You set a cache type that includes LOCAL_CUSTOM (or use the combined LOCAL option in newer versions) and define a cache directory—for example, /root/.m2 for Maven or /root/.npm for npm—so CodeBuild saves that directory after one build and restores it at the start of the next. This avoids re-downloading or recompiling unchanged dependencies, significantly reducing build time while requiring no custom scripting or external services.

Why this answer

AWS CodeBuild's local caching feature allows you to cache intermediate build artifacts (such as dependencies) in a local directory on the build instance, which persists across builds for the same build project. This eliminates the need to re-download dependencies from external sources for every build, significantly reducing build time. The cache is stored in a Docker volume or S3 bucket, but the key benefit is that it is automatically managed by CodeBuild without manual download steps.

Exam trap

The trap here is that candidates may confuse caching with simply storing artifacts externally (like S3 or CodeArtifact) and fail to recognize that CodeBuild's local caching is the only option that eliminates the download overhead by persisting dependencies on the build instance itself.

How to eliminate wrong answers

Option A is wrong because removing unnecessary dependencies from the build specification is a good practice but does not address caching of existing dependencies; it reduces the total amount of dependencies but does not speed up the download of those that remain. Option B is wrong because storing dependencies in an S3 bucket and downloading them before each build still incurs network transfer time and does not leverage CodeBuild's built-in caching mechanism; it is a manual workaround that adds complexity and latency. Option C is wrong because AWS CodeArtifact is a managed artifact repository service for storing and retrieving packages, but it does not inherently cache dependencies on the build instance; using it still requires a download step during each build, which does not reduce build time as effectively as local caching.

Practice this question →

146

Multi-Selecteasy

A DevOps engineer is setting up a CI/CD pipeline for a Python application using AWS CodePipeline. The pipeline includes a build stage with CodeBuild and a deploy stage that runs an AWS CLI command to update a Lambda function. Which THREE steps are necessary to ensure the pipeline can update the Lambda function? (Choose 3)

Select 3 answers

A.Store the AWS CLI command in the buildspec file or as a separate script in the source repository.

B.Grant the CodePipeline service role permission to pass the CodeBuild IAM role to CodeBuild.

C.Configure a CloudWatch Events rule to trigger the pipeline when the Lambda function is updated.

D.Create an IAM role for CodeBuild that includes permissions to invoke 'lambda:UpdateFunctionCode'.

E.Use AWS CodeDeploy instead of the AWS CLI to update the Lambda function.

AnswersA, B, D

The AWS CLI command that updates the Lambda function must be defined in the buildspec file or in a script committed to the source repository. CodeBuild executes the buildspec during the build phase, so placing the command there ensures it is run as part of the pipeline after the artifact is produced. Keeping it in source control also makes the deployment step reproducible, auditable, and versioned alongside the application code.

Why this answer

The AWS CLI command to update the Lambda function must be defined in the buildspec file or as a script in the source repository so that CodeBuild can execute it during the deploy stage. This ensures the pipeline has the exact command to run, and it becomes part of the version-controlled build specification.

Exam trap

The trap here is that candidates might think a CloudWatch Events trigger is needed to initiate the update, but the pipeline itself is the orchestrator; the real requirement is proper IAM permissions and command definition within the buildspec.

Practice this question →

147

MCQmedium

Refer to the exhibit. A DevOps engineer sees the following error when trying to update a CloudFormation stack: 'Stack [arn:aws:cloudformation:us-west-2:123456789012:stack/MyStack/abc123] is in ROLLBACK_COMPLETE state and can not be updated.' What should the engineer do to proceed?

A.Run 'aws cloudformation continue-update-rollback' to finish the rollback and then update.

B.Modify the stack's template and try the update again.

C.Use the 'aws cloudformation resume-update' command to resume the update.

D.Delete the stack and create a new one with the updated template.

AnswerD

The `ROLLBACK_COMPLETE` state is terminal: the stack still exists in CloudFormation, but the failed create or update operation has rolled back, leaving no functional infrastructure from that attempt. CloudFormation will not accept `update-stack` or change-set execution from this state, so the only supported recovery path is to delete the stack and create a new one using the updated template. Recreating the stack provides a clean, deterministic provisioning pass and avoids inconsistent resource states.

Why this answer

When a CloudFormation stack reaches the ROLLBACK_COMPLETE state, it means the stack creation or update failed and the rollback has finished, leaving the stack in a terminal state. CloudFormation does not allow updates or rollback continuation on stacks in this state. The only supported action is to delete the stack and create a new one with the corrected template, as stated in the AWS documentation.

Exam trap

The trap here is that candidates confuse ROLLBACK_COMPLETE with ROLLBACK_IN_PROGRESS or UPDATE_ROLLBACK_FAILED, assuming they can resume or continue the rollback, but AWS explicitly prevents any operation on a stack in a terminal rollback state.

How to eliminate wrong answers

Option A is wrong because the 'continue-update-rollback' command is only valid for stacks in the UPDATE_ROLLBACK_FAILED or ROLLBACK_IN_PROGRESS states, not ROLLBACK_COMPLETE. Option B is wrong because modifying the template and retrying the update will still fail, as CloudFormation rejects any update attempt on a stack in ROLLBACK_COMPLETE state. Option C is wrong because there is no 'resume-update' command in the AWS CLI; the correct command for resuming an update is 'continue-update-rollback', which is not applicable here.

Practice this question →

148

MCQhard

Refer to the exhibit. A CodeBuild project uses this buildspec.yml to build and push a Docker image to Amazon ECR. The build fails at the pre_build phase with the error 'Error: Cannot perform an interactive login from a non TTY device'. What is the MOST likely issue?

A.The AWS_DEFAULT_REGION environment variable is not set in CodeBuild.

B.The CodeBuild project's IAM role does not have permission to call ecr:GetAuthorizationToken.

C.The buildspec.yml is missing the 'docker login' command.

D.The Docker daemon is not running on the CodeBuild instance.

AnswerB

The build's `aws ecr get-login-password` command makes an ECR Authorization API call that requires the `ecr:GetAuthorizationToken` permission on the build project's service role. If that IAM policy is missing or doesn't allow the action, the CLI exits with an `AccessDeniedException` and no password is returned, causing the subsequent `docker login` to fail with invalid or empty credentials. This is the classic cause of ECR login failures in CodeBuild.

Why this answer

The error 'Cannot perform an interactive login from a non TTY device' occurs when the `docker login` command is invoked without receiving the password via stdin. In the buildspec, `aws ecr get-login-password` is used to retrieve the password and pipe it to `docker login`. If the CodeBuild project's IAM role lacks the `ecr:GetAuthorizationToken` permission, this command fails silently or returns an error, causing `docker login` to fall back to interactive mode.

Since CodeBuild runs in a non‑interactive environment, it throws the TTY error. Option B is correct because the missing permission prevents the password retrieval, leading to the login failure. Options A, C, and D do not directly cause this specific error.

Practice this question →

149

MCQmedium

A company uses AWS CodePipeline with a source stage from GitHub (via CodeStar Connections). The pipeline has a build stage using AWS CodeBuild and a deploy stage using AWS CodeDeploy. The team wants to ensure that a new pipeline execution starts automatically whenever a pull request is merged into the main branch. Which configuration change should be made to meet this requirement?

A.Enable the 'Poll for source changes' option on the source action and set the poll interval to 1 minute.

B.Create an Amazon EventBridge rule that monitors GitHub pull request merge events and invokes the pipeline via a Lambda function.

C.Add a manual approval action before the source stage that triggers the pipeline when a pull request is merged.

D.Configure the CodeStar Connection to use a webhook that triggers the pipeline on push events to the main branch.

AnswerD

CodeStar Connections automatically create webhooks for GitHub repositories. When a push event occurs on the configured branch (e.g., main), the webhook triggers the pipeline. Merging a pull request results in a push to the main branch, so the pipeline starts. This is the intended and supported integration for GitHub sources in CodePipeline.

Why this answer

For GitHub sources, CodePipeline uses CodeStar Connections, which create webhooks. When a pull request is merged, a push event to the target branch occurs, and the webhook automatically starts the pipeline. This is the native, recommended method.

Polling is not supported for connections, and custom EventBridge rules or manual approvals do not provide automatic triggering.

Exam trap

The trap here is assuming that polling or manual approvals are required to detect merges, when CodeStar Connections already provide webhook-based automatic triggering.

Practice this question →

150

MCQhard

A company is using AWS CodeCommit with multiple repositories. Developers are required to create pull requests for all changes, and the pull request must be associated with a JIRA issue key (e.g., PROJ-123) in the commit message. A DevOps engineer needs to enforce this policy automatically. Which approach meets the requirement with minimal operational overhead?

A.Store JIRA keys in an S3 bucket and configure a CloudWatch Events rule to check commits

B.Create a CodeCommit trigger that invokes an AWS Lambda function to validate the pull request description and reject if missing JIRA key

C.Use AWS CodeBuild to run a validation script during the build phase

D.Require developers to install a pre-commit hook script locally

AnswerB

A CodeCommit trigger can be configured for pull-request events such as pullRequestCreated or pullRequestSourceBranchUpdated, invoking a Lambda function asynchronously. The Lambda parses the pull request description with a regex for a JIRA key such as [A-Z]+-[0-9]+, and if the key is missing it calls the CodeCommit API UpdatePullRequestStatus with status CLOSED to reject the PR and posts a comment explaining the failure. Because the logic runs in AWS managed services on every qualifying pull request event, enforcement is centralized and cannot be bypassed by individual developers.

Why this answer

CodeCommit triggers can invoke an AWS Lambda function on pull request events (e.g., created or updated). The Lambda function can parse the pull request description or commit messages for a JIRA key pattern (e.g., regex `[A-Z]+-\d+`) and, if missing, automatically reject the pull request by updating its status or adding a comment. This serverless approach enforces the policy without requiring any changes to developer workflows or additional infrastructure, minimizing operational overhead.

Exam trap

The trap here is that candidates may choose Option C (CodeBuild) because they assume build-time validation is sufficient, but they overlook that CodeBuild runs after the pull request is merged, not before, making it ineffective for pre-merge enforcement.

How to eliminate wrong answers

Option A is wrong because storing JIRA keys in an S3 bucket and using a CloudWatch Events rule to check commits is overly complex and indirect; CloudWatch Events cannot directly inspect commit messages within a repository, and this approach would require custom polling logic and lack native integration with pull request lifecycle events. Option C is wrong because AWS CodeBuild runs during the build phase, which occurs after a pull request is merged or a commit is pushed, so it cannot reject a pull request before it is accepted; it would only catch violations post-merge, failing the policy requirement to enforce before changes are merged. Option D is wrong because requiring developers to install a pre-commit hook locally is not enforceable centrally; developers can bypass or omit the hook, leading to inconsistent policy application and increased operational overhead for maintenance and updates.

Practice this question →