CCNA Sdlc Automation Questions

Enabling AWS CloudTrail records the PutApprovalResult API calls made through CodePipeline when an approver clicks Approve or Reject. CloudTrail logs the IAM principal or federated user identity, the timestamp, the source IP address, and the decision, providing an immutable audit trail that satisfies compliance and forensic needs. This is the correct answer because the company's explicit requirement is to know who approved the deployment and when.

Configuring the source stage to use Webhook change detection with a branch pattern, such as refs/heads/feature/*, makes the pipeline automatically respond to pushes on matching feature branches. This allows a single pipeline to serve multiple branches by filtering events based on the branch reference, without manual per-branch pipelines. The webhook sends an event to CodePipeline only when the push matches the pattern, enabling efficient and dynamic multi-branch execution.

Separating the build stage from the deploy stage ensures that a single immutable artifact—such as a Docker image or packaged JAR—is produced once and then promoted through environments (dev, staging, prod) without rebuilding. This eliminates configuration drift and makes the pipeline auditable, because the exact artifact tested can be deployed to production. It also enables independent validation and safe rollback: if a deployment fails, you can redeploy the previous artifact rather than re-running a build that may produce different output.

The Deploy stage is mandatory because it uses AWS CodeDeploy's ECS deployment type to shift traffic from the old to the new task definition. CodeDeploy references an AppSpec file and the task definition produced during the Build stage, then updates the ECS service with either rolling updates or blue/green traffic shifting. Without this stage, the built and pushed container image would never be run as an active service in ECS.

AWS CodeBuild supports test reporting through the 'reports' section in buildspec.yml. By specifying a report group and the path to the test results file (e.g., JUnit XML), CodeBuild can parse and display test results in the console. Additionally, if 'pytest' exits with a non-zero status on failure, the build fails automatically. This change provides visibility into test results and ensures failures are caught.

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

For a deployment to four instances, a minimum healthy hosts percentage of 75% requires that at least three instances remain available throughout the deployment. When two instances failed, the healthy count dropped to two (50%), which is below the required threshold, so CodeDeploy was forced to abort the deployment and mark it as failed. This is a classic example of the minimum healthy hosts guardrail catching a partial-failure scenario that other, fleet-wide issues would not produce.

This is the correct approach for a review-before-execution pipeline. The CHANGE_SET_REPLACEMENT action creates a new change set (or replaces an existing one) that captures the exact resource-level differences between the current stack and the proposed template, but it does not apply any changes. A subsequent manual approval step then gates the pipeline, allowing a human reviewer to inspect the change set in the CloudFormation console or via CLI. Only after approval does the CHANGE_SET_EXECUTE action run, which applies the previously created change set, ensuring that no stack modification occurs without explicit review and approval.

A single pipeline execution carries its own artifacts from source through deploy. If the approval is part of that execution, the deploy stage consumes the exact artifact built and tested earlier, so commits pushed after the test stage start a new execution that must itself pass testing and approval, leaving the original execution's artifact intact.

CodePipeline naturally executes independent actions within a stage in parallel unless you set explicit runOrder values or action dependencies. By configuring multiple build actions, each running a partitioned portion of the test suite (by module, service, or shard), the total test work is spread across concurrent CodeBuild projects. The stage completes when all parallel actions finish, so overall duration approaches the slowest shard's critical path rather than the sum of all tests, directly reducing feedback time.

AWS Lambda automatically writes all execution logs—including output from print() statements, exception stack traces, and custom log messages—to a dedicated CloudWatch Logs log group named /aws/lambda/<function-name>. When the stack update fails, the Lambda function's runtime error is recorded as a log event, which you can view in the CloudWatch Logs console to pinpoint the root cause. Be sure to check the log stream that matches the exact timestamp of the failed update, and remember that logs are retained based on the log group's retention policy.

Running a scanner such as Trivy or Anchore inside a CodeBuild stage before the Docker push enforces a shift-left security gate; if the scanner exits with a non-zero code on critical/high vulnerabilities, the build fails and the image never reaches ECR. This keeps the registry free of vulnerable images and ensures only approved artifacts are available for subsequent pipeline stages.

CodeDeploy deployment groups support a built-in automatic rollback option triggered by CloudWatch alarms. When you configure one or more alarms in the deployment group, CodeDeploy monitors them during the deployment (and during traffic shifting for blue/green) and, if any alarm enters the ALARM state, it automatically rolls back the deployment to the last known good revision. This is a native, first-class feature that tightly integrates with Amazon CloudWatch and requires no custom code or external services, making it the recommended and correct way to achieve automated rollback on detected failures.

Amazon EventBridge natively ingests ECR lifecycle events such as an image push or scan, publishing them as event objects. You can define a rule with an event pattern matching the aws.ecr source and ECR Image Action detail-type, then route that event to a Lambda function that calls the ECS CreateService or UpdateService API. This is the correct mechanism because it is event-driven and requires no polling or manual invocation.

CodeBuild evaluates each buildspec command's exit code; if the security scanner returns a non-zero exit status when vulnerabilities are found, the build phase will immediately fail. To guarantee this, invoke the scanner as the final command in the build phase or wrap its output so that any findings are translated into a non-zero exit code. Without this explicit exit-code enforcement, a scanner that always exits 0 would allow the pipeline to pass despite critical security findings.

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

AWS CodePipeline webhooks are the native, built-in mechanism for external systems to trigger pipeline executions via an HTTPS POST request. When you create a webhook, CodePipeline generates a dedicated URL and registers a secret token; the external service, such as an issue tracker or a third-party version control system, includes that token in its HTTP call so CodePipeline can verify the request and map the payload to the appropriate pipeline and input variables. This provides secure, bidirectional integration with external tools, enabling an issue tracker to start a pipeline when a pull request or issue is updated, and is the correct service for this scenario.

AllAtOnce is a predefined CodeDeploy deployment configuration that sets the minimum healthy instances to 0, causing the deployment to update every target instance simultaneously. This configuration is valid and useful when you accept full fleet downtime during deployment, such as in development environments or for infrastructure with elastic load balancer deregistration. It is one of the named configurations you can select directly in the AWS CodeDeploy console or CLI.

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

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

CloudFormation tracks the AWS::Lambda::Function Code property using the literal values of S3Bucket, S3Key, and optionally S3ObjectVersion. Uploading new code to a different S3 key—or to the same key with a new object version ID—makes one of those template properties change, so a stack update sees a diff and refreshes the Lambda function's code. This is the standard practice because CloudFormation does not automatically compare content hashes or ETags; it relies on explicit property changes. If you reuse the same key and do not specify a version (or S3 versioning is disabled), CloudFormation will not detect the update and the function continues running old code.

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

A manual approval action pauses the pipeline at the stage boundary, requiring a nominated approver to review and release the change before production deployment proceeds. This directly satisfies the stem's constraint that manual approval is required before deploying to production, without altering the Test stage or build artefacts.

A manual approval action in CodePipeline pauses the pipeline at that stage until an IAM user with approval permissions reviews and approves or rejects the promotion. This is the standard control gate between staging validation and production release, satisfying the requirement for a deliberate go/no-go decision before any prod traffic is changed.

Upgrading to BUILD_GENERAL1_MEDIUM is the correct fix because CodeBuild compute tiers directly define the memory and vCPU available to the build environment: GENERAL1_SMALL provides 3 GB, while GENERAL1_MEDIUM provides 7 GB. This increases the total addressable memory for the Maven JVM, native code, and metaspace, directly resolving the OutOfMemoryError without altering the application or its dependencies. It is also cost-effective because you only pay for builds that use the larger compute type, and the price increase is modest compared to the engineering effort of optimizing memory usage.

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

Amazon S3 event notifications are designed with at-least-once delivery semantics, meaning the same s3:ObjectCreated:Put event can be delivered more than once, especially during retries or internal service-side replication. Each delivered notification is seen by CodePipeline as a new source change, so a single object upload can start duplicate pipeline executions. Versioning is irrelevant to this behavior because the duplicate is a delivery-level retry, not a new object version.

Clearing a CodeBuild project's cache removes previously downloaded dependency artifacts, such as those stored in the local Maven repository (~/.m2) or in an S3 cache bucket. On the next build, Maven must reach out to remote repositories to re-download every JAR it needs, adding significant network and I/O time on top of the compile itself. Because the buildspec commands are unchanged, the only impact is that dependency resolution is no longer incremental, directly explaining the increased build duration.

The health check grace period for the Auto Scaling group is too short. When an Auto Scaling group launches a new instance, it waits for the health check grace period before evaluating the instance's EC2 health status. If this period expires before CodeDeploy has installed and started the application, the ASG may consider the instance unhealthy and terminate it, interrupting the deployment. This causes the deployment to fail on those instances, even though the CodeDeploy agent and IAM permissions are fine. The correct fix is to increase the ASG health check grace period to cover the full deployment duration, including bootstrapping and application startup.

CodePipeline automatically starts an S3 source only when the bucket is configured with an event notification that sends object-created events to the pipeline's trigger. Typically, this is implemented via an Amazon S3 event notification targeting an Amazon EventBridge rule, or via a CloudWatch Events rule that filters on the bucket's PUT operations. Without that configuration, uploading a new file to the bucket does not cause the pipeline to initiate, leaving it in a 'Succeeded' or previous state until a manual release is triggered. This exactly matches the reported symptom.

CodeArtifact acts as an intermediary upstream repository, caching packages from public registries such as npmjs, Maven Central, or PyPI. When CodeBuild first requests a dependency, CodeArtifact fetches it from the public source and stores a copy in your domain; subsequent builds retrieve the cached copy directly from CodeArtifact. This reduces external network round trips, minimizes build-time latency, and protects against upstream outages or sudden changes in public repositories.

This design completely addresses the SAM pipeline lifecycle: a CodeBuild stage runs `sam package`, which uploads the function code and dependencies to S3 and writes a packaged template that CloudFormation can parse. Each environment's deploy stage then runs `sam deploy` (or uses the packaged template with CloudFormation) under environment-specific parameters, and a manual approval action preceding each higher environment provides the required release gate. Because every stage is a separate CodePipeline stage, approvals are isolated and promotions are sequential, preventing any single action from accidentally deploying to all environments.

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

Adding an Approval stage to the CodePipeline with an SNS topic is the correct approach because the approval action pauses all subsequent stage transitions until a designated reviewer clicks Approve (or Reject) in the console or invokes PutApprovalResult. The SNS topic sends email or other notifications to the approver, and the pipeline resumes only after the approval token is returned. This provides a auditable, controlled human decision point that is natively supported by CodePipeline.

By adding a branchName filter to the event pattern of the CloudWatch Events (EventBridge) rule that invokes the pipeline, the rule only triggers when a push occurs on the main branch. This is the documented and precise way to restrict executions by branch while still capturing all relevant repository state changes. The filter is evaluated in the event pattern, so other branches don't initiate a pipeline run.

The policy grants 'codepipeline:StartPipelineExecution' with a Resource element of '*', so the service role can trigger a new execution for any pipeline in the AWS account, not just a single named pipeline. In IAM, an action with Resource '*' matches all ARNs for that service; thus, the permission is not scoped to a specific pipeline. This statement is correct because the action is explicitly allowed and the resource constraint is unlimited.

AWS CodePipeline is the correct choice because it is a fully managed continuous delivery service that orchestrates the entire release process, from source code changes to production deployment. It can automatically detect new commits in a repository (e.g., GitHub, CodeCommit, S3) and then trigger a series of sequential or parallel stages, such as build with CodeBuild, test, and deploy via CodeDeploy or a direct Lambda update. By modeling the Lambda deployment as a pipeline action, CodePipeline ensures that each new version is built, tested, and deployed automatically and consistently, with the ability to add manual approvals or rollback steps.

The SAM CanaryDeployment property, when paired with a DeploymentPreference such as 'Canary10Percent5Minutes', delegates to AWS CodeDeploy to manage a gradual traffic shift. CodeDeploy publishes a new Lambda version, then adjusts the alias's routing configuration to send only 10% of live invocations to the new version for a 5-minute observation period, and finally shifts the remaining 90% after the interval succeeds. It also supports CloudWatch alarm-based automatic rollback, making it the only option here that provides a managed, gradual, and rollback-capable canary release on Lambda.

Amazon S3 is a supported CodePipeline Source action that detects new uploads when versioning is enabled, either through CloudWatch Events or periodic polling. When a new object version is written to the designated bucket and key, CodePipeline starts a pipeline execution and downloads that object as the input artifact for downstream stages. This makes S3 a common choice for external tooling or third-party providers to drop build artifacts.

For a deployment to an Auto Scaling group, CodeDeploy must be able to adjust the group's desired capacity and update its configuration. autoscaling:UpdateAutoScalingGroup lets CodeDeploy modify min/max/desired values, while autoscaling:SetDesiredCapacity forces the group to scale to the exact instance count required for the deployment. Without these permissions, CodeDeploy cannot perform instance replacement or blue/green transitions, causing the deployment to fail.

This is the correct approach because it guarantees the 'latest' tag is only ever applied to an image that has successfully passed the defined security gate. In the post_build phase of CodeBuild, you can run a local container scanner (e.g., Trivy, Snyk, or Anchore) and only when the exit code indicates a pass do you execute `docker tag` to relabel the built image as `latest` followed by `docker push`. This ensures the 'latest' tag remains immutable and clean, with no vulnerable image ever being exposed under that tag during the build or scan window.

Change Sets in AWS CloudFormation generate a read-only summary of the exact resource-level actions (Update, Add, Remove) that would result from submitting a new template or parameters. They act as a dry-run, allowing the team to inspect the proposed modifications, identify resources that will be replaced, and evaluate potential downtime before executing the stack update. This review-and-approve capability makes Change Sets the ideal tool for implementing infrastructure as code with controlled change management.

CloudFormation performs template validation before any update action is taken, checking for well-formed JSON/YAML, resolving intrinsic functions, validating resource types and required properties. An invalid template will cause the UpdateStack API call to fail immediately with a ValidationError, leaving the stack's current status unchanged. This is a hard precondition that every direct update must satisfy.

Enabling S3 bucket versioning on the bucket that stores CodePipeline build artifacts preserves every object version, including each build output. When a deployment needs to roll back, you can retrieve a previous artifact version directly from S3 or point the pipeline stage to that exact version. Versioning is a prerequisite for using S3 as CodePipeline's default artifact store in a way that supports safe, reproducible rollbacks without losing prior builds.

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

In the buildspec.yaml, the artifacts section can set 'encryptionDisabled: false' and specify the desired KMS key ID via the 'kmsKeyId' setting (or similarly named property). This explicitly instructs CodeBuild to encrypt the output artifact using the specified customer-managed KMS key, ensuring server-side encryption at rest. This is the direct and reliable way to enforce SSE-KMS for build artifacts.

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

The deploy stage of CodePipeline assumes the CodePipeline service role when it interacts with S3, so that role must have an IAM policy allowing s3:PutObject on the target bucket. This permission enables the pipeline to upload the artifact archive and any extracted files to the bucket that hosts the static website. Without it, the deploy action fails with a permissions error even if other roles, such as CodeBuild's, happen to have access to the same bucket.

AWS CodePipeline is a fully managed continuous delivery service that automates the entire release process, from source through build, test, and deployment. It orchestrates the pipeline by connecting multiple stages, such as pulling code from CodeCommit, invoking CodeBuild, and triggering CodeDeploy, along with integrations for third-party tools like Jenkins or GitHub. This end-to-end automation makes it the central CI/CD service in AWS.

AWS CodePipeline integrates with AWS CodeDeploy to provide blue/green deployments for ECS. By setting the ECS deploy action to use the 'CODE_DEPLOY' deployment controller, you can specify a CodeDeploy application and deployment group configured for blue/green. CodeDeploy manages the traffic shift and can automatically roll back if health checks fail. This is the standard way to achieve blue/green with automatic rollback in CodePipeline.

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

CodeBuild first calls sts:AssumeRole to obtain temporary credentials for the service role, and this requires the role's trust policy to include codebuild.amazonaws.com as a trusted service principal. The permissions policy may be correct, but if the trust policy is missing or misconfigured, CodeBuild is not authorized to assume the role and the build fails before any repository action occurs. This is the classic cause when CLI output verifies the repository and the permissions policy, yet the build cannot start.

AWS CodePipeline is the fully managed continuous delivery service that models the entire release process as sequential stages (source, build, deploy) and manages transitions, artifacts, and approvals. For a SAM application, CodePipeline pulls source from a repository, invokes CodeBuild to run SAM CLI commands, and triggers a CloudFormation deployment through a deploy action. Its stage-based orchestration is exactly what the question's 'pipeline stages' refers to, making it the correct service to orchestrate the pipeline.

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

CodeCommit pushes are natively captured as events by Amazon EventBridge, which can be configured with a rule that matches the `codecommit:Push` event on a branch. That rule targets an AWS CodePipeline execution, and CodePipeline's deploy stage updates the Lambda function using either a CloudFormation stack or an AWS Lambda deploy action. This gives a fully managed, event-driven CI/CD workflow with no custom glue code, no polling, and no intermediate storage.

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

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

A manual approval step inserted immediately before the deployment stage forces each pipeline execution to pause until an operator explicitly approves it, thereby serializing (or batching) executions and reducing the burst of concurrent API calls that trigger service-side rate limits. This directly lowers the request rate to services like CodeDeploy or CloudFormation, though it introduces human latency and requires a mechanism to trigger approvals for each queued execution. It does not reduce the per-execution API calls but instead changes their temporal distribution to stay under the quota.

For CodeCommit-based pipelines, CodePipeline relies on an Amazon CloudWatch Events (EventBridge) rule that listens for repository state changes, such as a branch reference updated to a specific branch name. If this rule is absent or disabled, the webhook may exist but no events are routed to the pipeline, so pushes to the repository will not trigger a new execution. Configuring or restoring this rule is the required fix.

Modifying application_start.sh to check for the missing path before invoking the restart command directly addresses the root cause: the restart command (e.g., systemctl restart) is failing because its target binary or configuration file does not exist, causing a non-zero exit that fails the lifecycle hook. Adding a guard such as `if [ -f /path/to/binary ]; then systemctl restart app; else exit 1; fi` ensures the script handles missing dependencies gracefully and only attempts the restart when the prerequisite is actually present on the instance. This also makes the script more robust and idempotent so retries won't fail on the same missing file.

Running 'git pull --rebase' fetches the remote branch's new commits and replays your local commits one by one on top of that updated history, producing a linear, fast-forwardable branch. After the rebase, your local branch contains all remote commits, so the subsequent 'git push' is a clean fast-forward rather than a rejected non-fast-forward update. This synchronizes the branch without creating a merge commit or losing any work.

The AWS::ECS::Cluster resource provisions a logical ECS cluster, which is the fundamental grouping of container instances or Fargate capacity where tasks and services are launched. In CloudFormation, this is the correct resource to automate the creation of the ECS cluster itself, and you can additionally configure settings like cluster name, capacity providers, and default namespaces via this resource. It is the top-level construct that other ECS resources like services and task definitions reference.

The ecs:UpdateService action is the correct missing permission. During an ECS blue/green deployment, CodeDeploy instructs Amazon ECS to update the existing service with the new task definition, which creates a replacement task set and allows traffic shifting to proceed. The pipeline role must explicitly allow ecs:UpdateService for the target service so that the deployment action can perform this update. Without it, the pipeline fails with an access denied error at the deploy stage.

In a serverless CodePipeline, the CodeBuild project executes `sam deploy` and uses its IAM service role to make CloudFormation API calls; if that role's temporary STS credentials have expired or its policies lack `cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`, or `cloudformation:DescribeStacks`, CloudFormation returns an ExpiredTokenException or AccessDenied error with 'security token invalid' in the message. CodeBuild projects receive short-lived credentials for the build session, and if the build exceeds the role session duration or the role was modified mid-deploy, these credential failures surface in the deploy stage. This precisely matches the reported symptom.

The AWS CodePipeline console calls the ListPipelines API to populate the pipeline list. The attached policy, as shown, grants only StartPipelineExecution on a specific pipeline and lacks codepipeline:ListPipelines, which is a required permission for the console to display any pipelines. Without ListPipelines, the user sees an empty console even though they can trigger executions via the API or CLI. To fix this, an additional allow statement for codepipeline:ListPipelines on the `*` resource is necessary (the ListPipelines action does not support resource-level permissions).

AWS CodePipeline is purpose-built for continuous delivery and natively integrates CodeCommit as a source action with CodeBuild as a build action. The pipeline automatically subscribes to CodeCommit repository events (via Amazon EventBridge under the hood) so any push to the selected branch immediately triggers the build stage. This is the recommended, fully managed approach because it also provides artifact passing, stage sequencing, and optional manual approvals without requiring custom glue code.

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

The CodeDeploy agent writes detailed logs to /opt/codedeploy-agent/deployment-logs/codedeploy-agent-deployments.log, capturing script output, exit codes, and stack traces for each lifecycle event. Reviewing these logs on failed instances reveals whether the root cause is a missing dependency, a syntax error in an AppSpec script, or a permissions issue, enabling a targeted fix.

Attaching an IAM policy to the CodeBuild service role is the correct approach because CodeBuild assumes this role during the build and uses it to authorize ECR actions such as ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer. This gives the build project exactly the permissions it needs, following least privilege, without exposing static credentials in environment variables or source files. The service role is the native and secure identity for CodeBuild to interact with AWS resources like ECR.

Elastic Beanstalk environments monitor deployment health and can automatically roll back a failed deployment, leaving the environment in an UPDATE_ROLLBACK_IN_PROGRESS or UPDATE_ROLLBACK_FAILED state. While the environment is rolling back, it is in an unstable state and Elastic Beanstalk rejects new application version deployments, causing the CodePipeline deploy action to fail or remain stuck. This is a known operational issue where a previous failure cascades into blocking subsequent deployments until the rollback completes or is manually resolved.

CodeCommit's native pull request approval rules are the correct mechanism to block merging until a specified number of approvals (here, two) are received from authorized IAM principals. After the PR is approved and merged, CodePipeline can be triggered by the branch change, and a Lambda function can query the CodeCommit API (for example, `GetPullRequest` or `DescribePullRequestEvents`) to verify the approval state before the pipeline advances. Including a manual approval step in CodePipeline adds an additional human checkpoint between staging and production, which together with the approval rule satisfies both the two-approver requirement and the automated staging deployment.

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

The CodeBuild service role must include ecr:GetDownloadUrlForLayer and ecr:BatchGetImage, along with ecr:GetAuthorizationToken, to successfully pull a container image from Amazon ECR. BatchGetImage retrieves the image manifest, while GetDownloadUrlForLayer obtains the URLs for each layer, and both are required after CodeBuild calls GetAuthorizationToken to authenticate. Without these permissions, CodeBuild receives an AccessDenied exception and the security scan cannot start.

The 'base-directory' value in the artifacts block points to a path that CodeBuild expects to exist when it attempts to upload artifacts after the build phase completes. If your build commands generate output inside 'dist', for example, then specifying a base-directory like 'build' will cause an 'artifact base-directory does not exist' failure because that directory was never created or populated. CodeBuild does not automatically compile or copy files; it simply packages whatever is present under the specified path at that moment. Therefore this is the correct reason for the error, not an invalid pattern or runtime.