CCNA SDLC Automation Questions

AWS::AccountId is a true pseudo parameter that is resolved during template evaluation, providing a unique, numeric identifier for the current AWS account. When combined with a fixed prefix like 'mybucket-', the resulting bucket name is globally unique across all accounts and regions because each account has a distinct ID, satisfying S3's global namespace requirement. This approach is deterministic, readable, and avoids the circular dependency issues of resource attributes, making it a widely adopted best practice for naming resources.

Blue/green shifts traffic to a new fleet only after it passes health checks, so no traffic reaches unhealthy instances, and CodeDeploy automatic rollback reverts on failure. This satisfies the zero-traffic-to-unhealthy-instances and automatic rollback constraints while avoiding full in-place replacement cost.

When CloudFront fronts an S3 static website, edge locations serve cached objects until they expire or are invalidated. CodePipeline's S3 sync updates the origin, but CloudFront does not automatically know about those changes; it continues returning the old objects as long as they remain in the cache. To serve the new content, you must create a CloudFront invalidation for the changed paths (e.g., /*) or use versioned filenames to bypass the cache. This directly matches the symptom of a successful deployment that still shows stale content in the browser.

Fn::Sub is the correct choice because it performs variable and pseudo-parameter substitution on a string literal, allowing you to embed ${AWS::StackName} and other pseudo parameters like ${AWS::AccountId} directly into a bucket name. This creates a predictable, globally unique S3 bucket name that is automatically tied to the stack, eliminating the need to hardcode a name and reducing the risk of collisions when the stack is deployed in multiple environments.

If the Maven local repository is overridden (e.g., via a custom settings.xml, the -Dmaven.repo.local flag, or a different user's home directory), the path declared in CodeBuild's cache section will not contain the downloaded dependencies. The build will then re-download artifacts every time because the restore phase puts files into a location Maven never reads. The fix is to ensure the cache path exactly matches the effective local repository path used by the Maven build.

Deregistering instances from the load balancer before deployment engages connection draining, allowing in-flight requests to finish before the instance is stopped. Combined with health check grace periods, users never reach a terminating instance, preventing 5xx errors and dropped connections during rolling or batch replacements. This is the core of a zero-downtime rolling update.

The PAT is the credential CodePipeline uses to authenticate to GitHub for API calls, including the initial webhook registration and every source-revision lookup (e.g., GetCommit, ListCommits). When the token expires, CodePipeline receives 401/403 responses, so webhook events cannot be processed successfully and the Source stage fails or is skipped, which matches the observed post-push behavior.

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

The failing command `./gradlew build` invokes Gradle's primary lifecycle task, which compiles all production and test sources and then executes the test suite. Any compilation error or failed test causes Gradle to abort with a non-zero exit code (typically 1), producing a 'BUILD FAILED' status. Since this failure occurs in the `build` phase and the exit code originates from the Gradle process itself, this is the direct and correct explanation.

The correct approach is to run the test command (for example, mvn test or gradle test) inside the build phase of the buildspec. CodeBuild executes each command in a shell where a non-zero exit code causes that phase to be marked failed and the overall build to be FAILED. Because Maven/Gradle test goals already return non-zero when tests fail, this single change ensures the build pipeline stops immediately. Any subsequent build phases, such as post_build artifact packaging, still run, but the final build status will reflect the failure.

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

If the Lambda execution role were missing ec2:CreateNetworkInterface or related ENI permissions, the Lambda service would fail to create an elastic network interface during function initialization, producing a different error such as 'InvalidParameterValueException' or a resource creation failure. This would prevent the function from running at all, rather than causing a timeout on the deployment's wait condition. Since the observed failure is a timeout, the role likely has the required ENI permissions, but the network route is missing.

Rolling deployment with a small batch size updates only a handful of instances at a time while the rest of the fleet continues serving live traffic, so the application remains available throughout the pipeline. AWS CodeDeploy moves the entire ASG to the new revision in incremental batches, and it uses health checks to verify each batch before proceeding; if a batch fails, the deployment is halted and can be rolled back. This is the correct choice when you need a zero-downtime update on an Auto Scaling group.

Increasing the Test stage timeout in the CodeBuild project is a pragmatic mitigation when network congestion intermittently causes dependencies or database connections to be slower than the default limit. CodeBuild has a default timeout of 60 minutes for a build, but the pipeline's stage timeout may be shorter, and network retries during peak usage can push a stage over its configured limit without an underlying configuration error. This accommodates transient network delays rather than masking a permanent misconfiguration, making it a valid, if not root-cause, fix.

CodeBuild should be used to build the Docker image because it can execute a buildspec that runs 'docker build' and then uses 'aws ecr put-image' or 'docker push' to store the image in ECR. This step is the pipeline's build stage, converting source code into an immutable container artifact tagged with a version or commit hash. Without this action, the pipeline would have no image to deploy, making it the essential first of the two required actions.

AWS CodePipeline is a fully managed continuous delivery service that can be configured with CodeCommit as a source action, automatically detecting new commits and triggering the pipeline execution. It supports path filters in the source action (e.g., requiring changes only in a specific folder) to avoid unnecessary runs. This makes it the native, event-driven orchestration service to start automated tests (via a CodeBuild build stage) exactly when developers push code.

AWS CodeDeploy natively supports blue/green deployments for ECS services when integrated with an Application Load Balancer. During deployment, CodeDeploy registers the new task set with a 'green' target group while the existing 'blue' task set remains registered with the original target group; the ALB listener's traffic is then shifted from blue to green using either a canary, linear, or all-at-once traffic-shifting configuration. CodeDeploy also runs lifecycle hooks (BeforeInstall, AfterInstall, etc.) and preserves the original task set for instant rollback if the deployment fails. This is the only option that provides immutable infrastructure and controlled traffic shifting, making it the correct answer.

AWS CodeDeploy with ECS blue/green deployment is the native AWS service that performs canary traffic shifting for an ECS service. It creates a replacement task set from a new task definition, shifts traffic through load balancer target group weights (for example, 10 percent initially), waits a specified interval, and then shifts the remaining traffic after validation. It also supports lifecycle hooks, CloudWatch alarm rollback, and automatic cleanup of the old task set, making it the complete answer for a canary deployment.

AWS KMS encryption for artifacts ensures that every source zip, build output, and deployment package stored in CodePipeline’s artifact bucket is encrypted with a customer-managed key using SSE-KMS (envelope encryption). This gives you granular control over who can decrypt artifacts via kms:Decrypt permissions on the key, and it provides a tamper-evident audit trail of key usage through AWS CloudTrail. Unlike default AWS-managed S3 encryption, a customer-managed KMS key lets you enforce key rotation, define cross-account access rules, and revoke access immediately in response to a threat, which directly protects sensitive artifacts at rest and during transit.

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

In-place deployments depend on the CodeDeploy agent polling the service on each instance; if it is absent or stopped, lifecycle events never execute, triggering the too-many-instances-failed error. Verifying the agent on every Amazon Linux 2 instance is therefore the first diagnostic step.

AWS CodeDeploy is the correct service for deploying the new task definition to Amazon ECS. It uses a blue/green deployment strategy when configured with the ECS deployment controller, allowing traffic to be shifted gradually from the old task set to the new one while monitoring health and supporting automatic rollbacks. CodeDeploy accepts a versioned task definition and an AppSpec file, making it the service that actually performs the deployment to ECS.

Configuring the build project to use a custom VPC is a best practice because it allows CodeBuild to securely access resources that are not publicly reachable, such as private Amazon RDS databases, internal load balancers, or AWS services via VPC endpoints. Without a VPC configuration, CodeBuild runs in AWS-managed compute and cannot resolve or connect to private IP addresses, forcing you to either expose those resources to the internet or use a NAT gateway with complex routing. By placing the build into a private subnet with proper security group rules, you can control both inbound and outbound traffic, ensuring the build only communicates with approved internal services and does not depend on the public internet.

A permissions boundary on CrossAccountDeployRole acts as an additional filter on the role's effective permissions, and if it does not explicitly allow CodeDeploy actions, those actions are denied even when the role's permissions policy grants them. Because the effective permission is the intersection of the identity-based policy and the boundary, the boundary must include all required codedeploy:* or specific actions. Adding or updating the boundary to allow CodeDeploy actions is the correct way to restore authorization in this cross-account deployment.

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

A bug in the new release that causes errors to accumulate over time fits the exhibit's steady upward slope perfectly. For example, a memory leak, unreleased file descriptor, or growing goroutine/thread count raises resource pressure with every additional request, so failure probability increases as a function of cumulative traffic. This pattern is distinct from an immediate fault because the defect is latent, and the error rate worsens as the application's internal state becomes progressively corrupted or exhausted.

The 'aws-sdk' package is a runtime dependency, and CodeBuild's npm install phase installs only the modules declared in package.json. If it is missing from the 'dependencies' section, npm will not fetch it, so your Node.js code cannot require it regardless of the environment. Adding it there ensures it is installed with the default dependency installation step, and pinning a version avoids unexpected updates.

AWS CodePipeline is the correct choice because it natively integrates with CodeCommit as a source action and automatically starts a pipeline execution on every push to the configured branch. It can then invoke test actions (e.g., CodeBuild or third-party test tools) in a defined stage, with options for parallel actions, approvals, and rollback—making it the standard CI/CD orchestrator for this use case.

AWS CodePipeline is a fully managed continuous delivery service that orchestrates the stages required to build, test, and deploy your application automatically. It includes a native CodeCommit source action that watches the repository for new commits and completes the deployment by invoking Elastic Beanstalk as a deployment provider, which creates and deploys a new application version to the environment. The service handles sequencing, failure handling, and manual approval gates without requiring custom glue code. Therefore, CodePipeline is the correct answer because it directly integrates the version control and deployment services in a single automated pipeline.

Enabling local caching in the CodeBuild project and specifying /root/.m2 as the custom cache location precisely tells CodeBuild to preserve and restore the Maven local repository onto the same build agent across runs. This way, already-downloaded JARs are reused and Maven won't fetch them again, dramatically reducing build time. This is the documented approach for caching Maven dependencies with CodeBuild.

AWS Systems Manager Parameter Store with the 'parameter-store' field in buildspec is correct because CodeBuild retrieves the SecureString value during build and injects it as an environment variable without ever displaying it in the build log. The value itself is encrypted with KMS and access is controlled by IAM, so this satisfies the requirement to keep secrets out of logs without additional steps.

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

CodeBuild reports a client error when it cannot retrieve source artefacts, and the build log shows an S3 access failure. Either the bucket 'my-bucket' is absent or the service role lacks s3:GetObject permission, so the build fails before compilation begins.

CodePipeline does not automatically poll an Amazon S3 source bucket for new objects unless the bucket has event notifications enabled to emit s3:ObjectCreated:* events to the pipeline. Without an Amazon CloudWatch Events rule or an S3 event notification configured to invoke the pipeline on object writes, the pipeline will only run manually or when explicitly started from the console, CLI, or SDK. This is the standard prerequisite for automatic triggering from an S3 source, and its absence explains why the pipeline remains idle after an upload.

CodePipeline can be configured to automatically start an execution when a push occurs to a branch (or tag) in a CodeCommit repository. The console sets up a CloudWatch Events rule that matches actions like reference creation or update, and the pipeline's source stage polls for that event; this is a built-in, first-class trigger mechanism for Git-based sources

In CodeBuild standard images, the runtime-versions section in the buildspec.yml is required to install and set up the desired runtime, such as Node.js. Without it, the image may not have Node.js pre-installed or may not be in the PATH. The error indicates that the node command is not found, which is resolved by specifying the runtime version.

This command is correct because it uses `aws cloudformation describe-stacks` to retrieve the stack's metadata, then JMESPath `Stacks[0].Outputs[?OutputKey=='BucketName'].OutputValue` filters the outputs array for the output whose `OutputKey` exactly equals `BucketName` and extracts its `OutputValue`. The `--output text` renders the result as plain text (the actual bucket name). This directly matches the exhibit, which shows the stack's outputs, and is the intended way to programmatically retrieve a CloudFormation output value.

AWS CodeDeploy is the native AWS service for performing canary deployments on Amazon ECS. It shifts a specified percentage of production traffic to the new task set (e.g., 10% for 5 minutes) while the old version continues to serve the rest, then gradually increases the new version's traffic until 100%. CodeDeploy orchestrates the entire traffic-shifting process using the AppSpec file, target groups, and optional LifecycleEventHooks such as BeforeAllowTraffic and AfterAllowTraffic, making it the correct choice for a microservices CI/CD pipeline requiring canary releases.

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

The `Deploy` stage action stores a literal `DeploymentGroupName` string that must exactly match the name of an existing deployment group in the target CodeDeploy application. This string is case-sensitive and cannot include trailing spaces or a mangled formatted name. When CodeDeploy receives the pipeline's `CreateDeployment` API call, it validates the deployment group against the application in the region; if no exact match exists, it returns the 'Deployment group not found' error. To resolve it, open the pipeline's Deploy stage action and compare the `DeploymentGroupName` value to the deployment group name shown in the CodeDeploy console.

Creating a separate pipeline per allowed branch makes the pipeline definition itself the security boundary. Only branches that have an explicitly defined pipeline can ever proceed through the release stages, so committing to an unauthorized branch simply does not trigger a deployment even if the code is structurally valid. The production pipeline includes a manual approval step, and because that pipeline sources solely from an approved branch (e.g., main), the approval verifies the intended deployable artifact rather than attempting to check a branch name at runtime. This isolation prevents accidental or malicious deployment from unapproved branches without relying on inline validation or easily modified Lambda actions.

This approach leverages CodePipeline's ability to trigger on all branches and dynamically create CloudFormation stacks per branch using the branch name as part of the stack name. A Lambda function triggered by CodeCommit branch deletion events can delete the corresponding stack. This automates stack lifecycle management with minimal overhead, as the pipeline and Lambda handle creation and deletion. It provides isolation and scalability across branches.

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

CodeDeploy is the AWS-native service designed for controlled software rollouts, and its canary deployment configuration is fully supported as a CodePipeline deploy action. For example, a configuration like Canary10Percent5Minutes shifts 10% of traffic to the new task set or instance fleet, waits five minutes, then shifts the remaining 90%, while monitoring health via lifecycle hooks. Because CodeDeploy owns the traffic-shifting logic, it automatically detects failures, stops the deployment, and can roll back to the previous version. This directly satisfies the requirement for a built-in canary strategy in the Deploy to Prod stage with no custom scripting.

The CloudFormation stack referenced by the CodePipeline deploy action already exists and remains in a failed state (e.g., ROLLBACK_COMPLETE, UPDATE_ROLLBACK_COMPLETE, or CREATE_FAILED). CloudFormation refuses to perform an update on a stack that has not successfully reached a stable state (CREATE_COMPLETE or UPDATE_COMPLETE), so the deploy action fails immediately. A failed stack must be deleted (if resource policy allows) or updated/remediated using a change set to move it back to a stable, updatable state before CodePipeline can retry.

The appspec.yml file controls the order and content of lifecycle events such as ApplicationStop, BeforeInstall, and AfterInstall. If the file is malformed, references a nonexistent script, or a referenced hook script exits with a non-zero status, CodeDeploy treats that instance as failed and reports 'ScriptFailed' or 'InvalidLifecycleEventName'. Because the deployment reaches the script execution stage and then errors, the appspec definition and its scripts are the most direct cause.

Although CodePipeline updates the S3 origin with the new static files, CloudFront edge locations continue to serve stale content until the cache TTL expires or an explicit invalidation is submitted. A CloudFront distribution does not automatically detect origin content changes; it caches objects based on the Cache-Control/Expires headers. Without creating an invalidation for '/*' (or for the changed paths) after the deployment, users will still see the previous version of the website, which matches the reported symptom. This is the only option that explains outdated content being served while the pipeline itself succeeds.

A CodeCommit trigger configured for push events can launch a Lambda function that inspects the incoming commits's metadata and calculates the size of each file. While native triggers are asynchronous, the Lambda can quickly delete the offending branch reference or tag, effectively rejecting the large-file push from a server-side governance perspective. This is the only option that applies custom validation logic that actually sees file content and can act to block the push, unlike IAM conditions, which cannot inspect Git payloads, or pre-receive hooks, which CodeCommit does not support.

`npm install` reads the `dependencies` and `devDependencies` fields in `package.json` and installs exactly the packages listed there. If lodash is not specified in that file, it will not be installed, and any subsequent `require('lodash')` or `import ... from 'lodash'` will throw `MODULE_NOT_FOUND`. A missing `package.json` would cause `npm install` to fail outright, but either way, the root cause is that lodash was not properly declared as a dependency.

The correct approach is to leverage CodeDeploy's rollback capability: configure the deployment group to automatically roll back on deployment failure (or on a CloudWatch alarm), which causes CodeDeploy to track the last known good revision. Triggering the rollback—either through the console's rollback action or by redeploying the previous successful revision—makes CodeDeploy deploy that good revision to the green fleet and shift traffic back to the original blue environment, restoring the known-good service. This is the only option that actively reverses the faulty deployment and restores live traffic, rather than merely affecting future instances or repeating the defect.

With the AllAtOnce deployment configuration, CodeDeploy targets every instance in the deployment group simultaneously, but if a failure occurs partway through, the deployment stops without rolling back unless you explicitly enabled automatic rollback. Instances that already received and ran the new revision keep it, while instances that were not yet updated remain on the old revision, yielding a mixed state across the fleet. This is exactly the situation that would leave some instances running the previous version and others running the new version.

AWS CloudFormation is the correct choice because it is a declarative Infrastructure as Code (IaC) service that can directly model and provision AWS resources, including AWS CodeCommit repositories. You define a repository in a CloudFormation template using the AWS::CodeCommit::Repository resource type, specifying properties such as RepositoryName and Code, and CloudFormation will create, update, and delete the repository as part of stack lifecycle management, making it ideal for automating resource creation.

The access denied error indicates the build's AWS credentials lack permission for ECR push operations. Granting ecr:InitiateLayerUpload along with the related push actions such as ecr:PutImage and ecr:UploadLayerPart on the specific repository authorizes the docker push and directly resolves the failure.

Amazon S3 is a fully supported source action in AWS CodePipeline. You can store a single zip file or a set of files in an S3 bucket, and CodePipeline detects changes when the object version changes or via Amazon CloudWatch Events. The bucket must have versioning enabled so that each upload creates a new source artifact, which is then downloaded and extracted in the Source stage for subsequent build and deploy actions.

SAM is the only option that natively pairs with CodePipeline for serverless deployments: the pipeline can run `sam build` and `sam package` in a CodeBuild stage, then use a CloudFormation change set via the `CreateReplaceChangeSet` action. By specifying a `ParameterOverrides` JSON file (e.g., `stageName`, `environment`, `vpcConfig`) on that action, each environment (dev, test, prod) reuses the same pipeline definition yet receives its own configuration without duplicating stages or using manual scripts. SAM also generates the Lambda function, event sources, and permissions as a CloudFormation template, so environment-specific values propagate consistently through `AWS::Serverless::Function` properties and `!Ref` parameters.

DependsOn is the correct CloudFormation mechanism to explicitly control resource creation order when there is no implicit dependency. Even though CloudFormation automatically creates a dependency when you use Ref or GetAtt in a resource property, there are cases where the Lambda function's IAM role ARN is substituted indirectly (e.g., via a parameter or a Fn::Sub in a string), so CloudFormation cannot infer the ordering. Adding DependsOn: IamRole to the Lambda function resource guarantees that the IAM role is fully created before the Lambda function is provisioned, preventing the deployment failure that occurs when Lambda tries to use a role that does not yet exist.

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

Configuring CodeBuild to use a VPC with a NAT gateway is the correct solution because it provides a deterministic, controlled egress path for outbound internet traffic. By running the build in private subnets behind a NAT gateway that routes via an Internet Gateway, the build environment can reliably pull layers from Docker Hub, install packages, and access private VPC resources. This overrides the default AWS-managed network's unpredictable connectivity and gives you proper security group and routing control, making the build network behavior explicit and dependable.

This is correct because CodeDeploy natively supports Lambda deployment with canary, linear, and all-at-once traffic-shifting strategies, letting you validate a new version before promoting it. CodeBuild runs automated tests first, then CodeDeploy updates the Lambda alias gradually, monitoring CloudWatch alarms for automatic rollback. This is the AWS-recommended managed deployment path for serverless applications.

Creating a custom Docker image that includes all required software and pushing it to Amazon ECR lets you reference that image in the CodeBuild project's environment, so CodeBuild launches build containers from a pre-baked image. This avoids repeated package installation on every run, significantly reducing build time and removing dependence on internet-accessible package repositories during the build. The image provides a deterministic and immutable toolchain, which improves reproducibility, and you can version the image (using tags or image digests) and update it via its own build pipeline for rolling upgrades.

SNS email subscriptions start in the 'Pending Confirmation' state; SNS sends an initial confirmation email to the endpoint and no notifications are delivered until the recipient clicks the link in that message. If the recipient never confirms, the subscription stays inactive, so even though CodePipeline publishes approval messages to the topic, SNS discards them for that unconfirmed endpoint. Therefore, confirming the subscription is the correct first troubleshooting step.

CloudFormation refuses to update any stack in a failed terminal state such as ROLLBACK_COMPLETE, because the stack's resources are in an inconsistent or partially provisioned state. The stack must be deleted and recreated (or, if applicable, brought back to a workable state via ContinueUpdateRollback for other rollback states) before an update operation can run.

CodeBuild placed in the VPC uses its own security group as the traffic source. If the RDS security group lacks an inbound rule permitting that CodeBuild security group on the database port, connections time out, matching the stem's VPC-configured constraint.

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

Security groups act as a virtual firewall at the instance level. By referencing the CodeBuild project's security group as a source in the RDS security group's inbound rule, you allow traffic specifically from the Elastic Network Interfaces (ENIs) that CodeBuild uses when it runs inside the VPC. This is the most direct and least-privileged way to permit the integration tests to reach RDS, because it avoids opening the database to CIDR ranges or the entire VPC. It also updates automatically if CodeBuild's IP addresses change, as long as the security group ID remains the same.

This is correct because Amazon EventBridge natively captures ECR image push events (e.g., the 'ECR Image Action' event type) and can directly target an AWS Lambda function. Lambda can then call CloudFormation's UpdateStack API, passing the new image URI as a parameter to the stack, thereby updating the infrastructure in an event-driven, serverless manner. This pattern is simple, requires no persistent compute, and integrates seamlessly with CloudFormation's parameter-based updates.

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

The AppSpec hooks section contains a location field that must point to a script actually present in the extracted application revision. During a lifecycle event, the agent resolves that path against the deployment archive's directory structure; if the file is not there—perhaps due to a typo, an absolute path instead of a relative one, or omitted from the bundle—the operating system returns ENOENT and CodeDeploy reports ScriptMissing. Fixing the AppSpec path to match the bundled script resolves the deployment.

CodeBuild only produces output artifacts if the project (or buildspec `artifacts` section) is configured to do so with a matching name. The pipeline's Build action expects an output artifact literally named 'BuildArtifact'; if the CodeBuild project defines a different artifact name, or omits artifact output entirely, the build may succeed but the pipeline's build stage will fail when resolving the expected artifact. This mismatch is the most common reason for a Build stage failure when the build logs show a successful build.

CodeBuild projects have a configurable 'Timeout' property (default 60 minutes) that caps the total time from build start to the last phase, including download, install, build, and post-build. When a build runs past this limit, CodeBuild forcibly terminates it and records a 'BUILD_TIMEOUT' error, which matches the scenario described. To resolve it, the DevOps team can increase the timeout in the CodeBuild project settings (via console, AWS CLI, or CloudFormation), setting it up to 480 minutes (8 hours) for standard builds. This directly addresses the root cause rather than masking a resource or syntax problem.

CodeDeploy's blue/green deployment with an Application Load Balancer is the correct solution because it provisions a completely new Auto Scaling group (the green environment) running the new revision and registers it with a new or existing target group. The ALB only shifts traffic to the green target group after all instances pass health checks, while the blue instances continue serving requests during the entire setup and validation. After a configurable wait time, the original blue ASG is terminated, ensuring no point where users have no service. This architecture provides true zero downtime because the old fleet remains fully operational until the new fleet is verified.

Running `npm ci` instead of `npm install` is the recommended fix because it performs a clean, lockfile-driven installation and never attempts to modify the global package cache, thus eliminating the permission conflict. The presence of a valid `package-lock.json` ensures that exact dependency versions are resolved and installed without npm calculating a new dependency tree, which can trigger hidden writes to system locations. This approach is purpose-built for CI/CD pipelines and greatly reduces the chance of inconsistent state or permission failures.

The CodeBuild managed build image is version-specific and does not include every language runtime; for example, the Amazon Linux 2 x86_64 standard image version 3.0 has Java, Python, Node.js, and Ruby, but no Go binary on its PATH. When the buildspec runs 'go build', the shell returns 'go: command not found' because the executable is simply not installed in the selected image. The correct remedy is to select an image that includes Go (such as a newer standard image with the Go runtime), add a runtime-versions entry for golang, or provide a custom Dockerfile that installs Go.

Local caching in CodeBuild persists declared dependency directories between builds on the same host, so package managers such as npm or Maven skip re-downloading. Specifying cache paths in buildspec.yaml directly cuts the 30-minute runtime without altering the pipeline structure.

AWS CloudFormation is the definitive Infrastructure-as-Code service that uses declarative JSON/YAML templates to provision and manage all resources in a stack, including EC2 instances, RDS databases, VPCs, and security groups as a single unit. Stack creation handles dependency ordering and rollback on failure, while stack deletion removes the complete set of resources, enabling reliable automation of ephemeral environments. The ability to set a deletion policy on resources like RDS allows you to control whether the database is retained or deleted, making cleanup predictable and safe.