SDLC Automation practice questions

The pipeline has a failed execution that is blocking subsequent executions.

Why wrong: CodePipeline executions are fully concurrent by design; a failed execution does not place a lock or mutex on the pipeline or its stage. Although you can retry a failed action, the presence of a failed run never prevents a new execution triggered by a new commit from proceeding. In a multi-branch setup, each branch maintains its own independent execution history, so a failure in one branch has no blocking effect on another branch's pipeline run.

The pipeline is configured with a high frequency of changes, causing throttling from CodePipeline.

Why wrong: CodePipeline throttling is an API-level rate limit (for example, ThrottlingException on GetPipelineExecution or PutJobSuccessResult), not a deployment-group capacity limit. Even with a high frequency of branch commits, pipelines are designed to handle continuous delivery, and throttling would be rare and would surface as intermittent API errors, not as a persistent inability to start a deployment. A throttling error would affect the pipeline's ability to invoke or poll actions, but it would not be described as a deployment being blocked by an existing deployment.

A previous deployment is still in progress or frozen in the CodeDeploy deployment group.

Why wrong: CodeDeploy enforces a concurrency limit of one in-progress deployment per deployment group by default. If a previous deployment is still running, stopped mid-lifecycle, or frozen (for example, pending a rollback or waiting on a manual approval), the service refuses to start a new deployment and returns an error indicating that a deployment is already in progress. With a multi-branch strategy, two pipelines can try to deploy to the same group nearly simultaneously; the second pipeline's Deploy action will wait or fail because the deployment group is not available, not because of the pipeline itself.

Move the build process to a local developer machine to avoid CodeBuild overhead.

Why wrong: Moving builds to a developer machine destroys the reproducibility of a managed CI pipeline because local environments differ in JDK versions, environment variables, installed tools, and cached artifacts, leading to 'works on my machine' failures. It also eliminates centralized logging, IAM-based permissions, and audit trails, and it cannot scale across a team since one developer's local cache is not shared. This approach leaves the team without a consistent, compliant, or automated build process, and it does not solve the original dependency-download bottleneck for the pipeline.

Reduce the number of unit tests executed in the build phase.

Why wrong: Reducing the number of unit tests executed in the build phase targets the wrong bottleneck: the delay is caused by the build environment being ephemeral and downloading Maven dependencies from the internet, not by test execution time. Unit tests are typically fast, run in-memory, and are a critical quality signal; removing them gives negligible time savings while significantly lowering code coverage and weakening the CI gate. This approach degrades developer confidence and may violate organizational quality policies, making it an unacceptable way to optimize build duration.

Increase the compute type of the build environment to a larger instance.

Why wrong: Increasing the compute type of the build environment adds vCPUs and memory, which can speed up compilation and test execution, but the new larger instance still starts with an empty local cache and must make the same network requests to download all third-party dependencies. The dependency-fetch operation is bound by network latency and throughput to public repositories, not by CPU capacity, so larger compute does little or nothing to reduce the dominant cold-cache overhead. This solution also raises per-build cost, potentially eliminating the efficiency benefit that S3 caching would provide.

Use a Lambda function in the pipeline to check the branch name and fail if not allowed.

Why wrong: Implementing a custom Lambda function as a branch guard is brittle governance because the function and its invocation only exist inside the pipeline definition. Any developer with permissions to edit the pipeline can simply remove the Lambda action, alter its environment variables, or inject a different handler, effectively disabling the check. Moreover, the approach relies on parsing branch names from source action metadata, which is not a native enforcement point in CodePipeline's model—it is a scripted convention rather than a structural control.

Add a manual approval step in the pipeline and rely on the approver to verify the branch.

Why wrong: A manual approval step does not enforce separation of duties because CodePipeline does not automatically verify that the approver is someone other than the developer who committed the change. The approval action is just a gate that any IAM principal with the necessary pipeline and approver permissions can complete—including the same developer who pushed the branch. To make approval a real control, you must combine it with a distinct IAM role or group for approvers, which the pipeline structure itself does not enforce.

Tag the source artifacts with the branch name and use a condition in CodePipeline to allow only specific tags.

Why wrong: CodePipeline has no native support for conditional execution based on artifact tags—tags are resource metadata for cost allocation, permissions, or identification, not inputs to pipeline stage transitions. There is no IAM policy condition key that evaluates an artifact's tag to allow or deny a specific pipeline action. Even if you tagged artifacts with the branch name, the tag would be ignored during pipeline execution unless you built a custom Lambda to read it, which reintroduces the same modification and bypass risks found in Option 1. Thus, this is not a supported or reliable control mechanism in CodePipeline.

Set up an Amazon CloudWatch Events rule to monitor repository size and alert when it exceeds a threshold.

Why wrong: Setting up an Amazon CloudWatch Events rule to monitor repository size is purely reactive: it can only alert after a problematic push has already succeeded, leaving the large file stored in the repository. Additionally, CodeCommit does not expose a native repository-size CloudWatch metric, so you would need extra custom tooling just to make such a rule work. Even with alerting, the rule cannot prevent a developer from pushing a 50 MB+ file, so it fails the 'reject' requirement entirely.

Create an IAM policy that denies the `codecommit:GitPush` action if the file size exceeds 50 MB.

Why wrong: An IAM policy that denies codecommit:GitPush based on file size is impossible because IAM evaluates only the request context—principal, action, resource, and explicit condition keys such as source IP or MFA. There is no condition key like 'FileSize', and AWS would have to inspect the entire Git packfile during policy evaluation, which is not supported. Thus this option is both syntactically invalid and conceptually flawed, as IAM cannot see or judge file sizes.

Use a pre-receive hook in the repository to reject large files by generating an S3 pre-signed URL.

Why wrong: CodeCommit is a managed Git service and does not allow customers to install git server-side hooks (pre-receive, update, post-receive), so a pre-receive hook cannot be added to a CodeCommit repository. Furthermore, generating an S3 pre-signed URL is an unrelated mechanism used to upload objects to Amazon S3; in a Git push scenario it would not be invoked by the server and would not return a rejected status to the client. This option incorrectly combines Git hook mechanics with S3 upload preprocessing, and neither part works in a CodeCommit context.

Change the source stage to use AWS CodeCommit instead of S3.

Why wrong: Switching to CodeCommit is unnecessary and shifts the architecture rather than fixing the actual defect. CodeCommit also tracks branch tips, and if a commit is force-pushed or a branch is updated, similar consistency concerns can arise. The problem is the external system mutating the S3 object, not the source repository type, so this change does not address the root cause and introduces migration overhead.

Use server-side encryption with AWS KMS (SSE-KMS) on the S3 bucket.

Why wrong: SSE-KMS encrypts object data at rest and for transit, but it does not prevent overwrites or deletions. CodePipeline can decrypt objects if the pipeline role has kms:Decrypt permission, and encryption does not make an object immutable. The failure here is caused by the object being replaced or removed, not by an encryption or access issue, so KMS is unrelated to the root cause.

Increase the timeout for the deploy stage in the pipeline.

Why wrong: Increasing the deploy stage timeout only extends how long CodePipeline waits for deployment actions to complete; it cannot resurrect a missing or overwritten source object. The failure occurs in the source stage when the artifact cannot be fetched, so the deploy stage never receives valid input. This adjustment masks symptoms and wastes pipeline time without addressing the S3 object lifecycle problem.

Configure the pipeline to block subsequent stages if any build action fails.

Why wrong: In AWS CodePipeline, a stage is already gated: if any action in a stage fails, the pipeline execution stops and no later stages run, so this 'configuration' does not add value or change behavior. More importantly, intentionally blocking subsequent stages when any build fails would mean a successful microservice's artifact never reaches deployment, so teams lose the ability to release healthy services. This is therefore not a parallel-friendly design and would cause unnecessary cross-service dependencies.

Configure a single build action that sequentially builds all microservices.

Why wrong: A single build action that sequentially iterates over all microservices means each service waits for the previous one to finish, so the total build duration is the sum of all individual builds. If any microservice fails to compile or package, the action aborts and none of the remaining services are built, effectively halting the entire pipeline. This couples all services to one shared risk and defeats the purpose of microservice-level independence.

Add 'sts:AssumeRole' to the permissions policy of CodePipelineServiceRole.

Why wrong: Adding 'sts:AssumeRole' to the CodePipelineServiceRole permissions policy addresses only the ability to request credentials for the cross-account role. Once CrossAccountDeployRole is assumed, the effective permissions are determined by that role's identity-based policy and any permissions boundary, not by the pipeline role's permissions. The service role already has this permission in a properly configured pipeline, so it would not resolve the CodeDeploy authorization failure.

Create the deployment group in the production account again to reset permissions.

Why wrong: Recreating the deployment group in the production account creates a new CodeDeploy resource configuration but does not modify any IAM policies or boundaries. The authorization error occurs during the deployment action when CrossAccountDeployRole attempts to invoke codedeploy APIs, which is controlled by IAM permission evaluation. Resetting the resource has no effect on the role's effective permissions, so the same failure will recur immediately.

Update the trust policy of CrossAccountDeployRole to include the DevOps account ID.

Why wrong: Updating the trust policy of CrossAccountDeployRole to include the DevOps account ID only governs which principals are allowed to assume the role, not what actions the role can perform after being assumed. Since CodePipeline is already assuming the role successfully and making CodeDeploy API calls, the trust policy is not the source of the failure. The denial is happening at the action level due to the permissions boundary, so adjusting the trust policy would have no impact.

The CodeBuild project is configured with a VPC that restricts access to external dependency repositories.

Why wrong: A CodeBuild project with a VPC configured to restrict access to external dependency repositories would typically cause consistent, build-wide failures — every dependency download or package install would hit network errors, not just specific tests. Such a misconfiguration would produce errors like 'unable to resolve dependency' or timeout errors during the install phase, which are deterministic. In contrast, the problem statement describes intermittent test failures while other phases succeed, so a network egress restriction cannot explain tests passing locally but failing in CodeBuild. VPC issues affect all builds equally, not a subset of test cases.

The CodePipeline has a timeout setting that causes the build to be terminated before tests complete.

Why wrong: A CodePipeline timeout (or CodeBuild build timeout) terminates the entire build process after a fixed duration, regardless of whether tests are passing or failing. Timeout misconfigurations cause consistent 'TIMED OUT' errors across every run, not occasional test assertion failures. Moreover, the default build timeout in CodeBuild is 60 minutes, which is generally sufficient for a standard test suite; if a timeout were the issue, you would not see flaky, intermittent test results that differ between runs. Therefore, a timeout setting is not a plausible cause for tests that fail non-deterministically in CodeBuild.

The CodePipeline is configured with a branch filter that only triggers on the 'main' branch.

Why wrong: A branch filter in the CodePipeline source action would prevent the pipeline from executing at all for 'develop' branch commits, leaving developers with no build or test results. The symptom of intermittent test failures implies builds are being triggered and running to completion — meaning the pipeline is actively executing. A branch filter is a binary gate: either the pipeline triggers or it doesn't — it cannot selectively cause individual tests to fail. Thus, this option explains a lack of pipeline runs, not flaky test outcomes.

The security group for the SonarQube server does not allow inbound traffic on port 9000 from the CodeBuild security group.

Why wrong: The scenario explicitly states that the SonarQube security group already allows inbound TCP traffic on port 9000 from the CodeBuild security group, so a missing or misconfigured rule cannot be the cause. Even if a security group did block the traffic, the connection would hang at the TCP handshake and time out, but that would contradict the given facts. Therefore, this answer is incorrect because the stated configuration eliminates this possibility.

The SonarQube server is using a self-signed certificate that CodeBuild does not trust.

Why wrong: A self-signed certificate would produce an SSL/TLS handshake failure, such as a certificate validation error or an 'unable to find valid certification path' message, not a low-level TCP timeout. The timeout indicates that the connection never reached the application layer, so certificate trust is irrelevant to this symptom. CodeBuild would only encounter certificate issues after a successful TCP connection and TLS negotiation, which did not occur here.

The CodeBuild project does not have internet access, so it cannot reach the SonarQube server.

Why wrong: Since the SonarQube server resides within the same VPC as the intended CodeBuild execution environment, the build container can reach it over the private network using the server's private IP, without any internet connectivity. CodeBuild only requires internet access when pulling dependencies or connecting to external services; VPC-to-VPC communication inside the same VPC is routed internally. Therefore, lacking internet access would not prevent reaching a same-VPC resource, and the real problem is the subnet configuration.

AWS CodeCommit

Why wrong: AWS CodeCommit is a fully managed source control service that hosts private Git repositories. It acts as the source stage in a CI/CD workflow, storing code and versioning it, but it does not orchestrate, build, or deploy anything. Its role is limited to repository management, so while it is part of the CI/CD ecosystem, it is not the CI/CD service itself.

AWS CodeBuild

Why wrong: AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs unit tests, and produces deployable artifacts. It focuses exclusively on the build phase, executing build commands in a managed environment, and does not manage the broader pipeline flow, such as triggering deployments or coordinating multiple stages. Therefore, it is a component used within a CI/CD pipeline, not the CI/CD orchestration service.

AWS CodeDeploy

Why wrong: AWS CodeDeploy is a fully managed deployment service that automates the release of applications to environments like Amazon EC2, AWS Lambda, or on-premises instances. It handles the deployment stage, including rolling updates and traffic shifting, but it does not manage the source, build, or test stages of a CI/CD workflow. Because its scope is limited to deploying artifacts, it is not the overarching CI/CD service.

Enable ECR 'Scan on Push' and configure CodePipeline to deploy only if the scan result is clean.

Why wrong: ECR Scan on Push only records findings after the image is pushed, and CodePipeline has no native action to parse scan results or conditionally block a deployment. A 'clean' gate would still require a custom Lambda or CodeBuild step to query findings, so this approach never provides a push-time safety barrier and adds post-hoc complexity.

Use AWS Lambda to scan the image after push and automatically roll back if vulnerabilities are found.

Why wrong: Scanning with Lambda after push is reactive and unsafe because the image is already in the registry and may have been deployed by the time findings are available. ECR offers no 'undo push' to roll back an image, and Lambda would need complex Docker image layer parsing to enumerate vulnerabilities, making it both fragile and operationally late.

Use AWS Security Hub to scan images in ECR and block deployment.

Why wrong: AWS Security Hub is an aggregation and post-discovery service, not a scanner or a policy enforcement point; it can collect Inspector findings for ECR images but has no ability to block a deployment or deny a Docker image. Relying on Security Hub to 'block' anything requires integrating with other services and still lacks the deterministic pre-push failure control that a CI/CD scanner provides.

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

Why wrong: The absence of a GPG key from an IAM user's profile affects commit signing, not server-side hook execution. CodeCommit uses IAM to associate public GPG keys so clients can sign commits, but because CodeCommit never runs pre-receive hooks, a missing GPG key cannot produce a pre-receive hook error. Even if commit signing is required, hook processing is not part of the push path.

The hook script has a syntax error.

Why wrong: A syntax error in a hook script would only be relevant if the repository ran the script, but CodeCommit has no pre-receive hook execution. Hook scripts are not uploaded to the repository, so there is no script to be rejected. This explanation incorrectly assumes that CodeCommit behaves like a self-managed Git server, such as an EC2 instance hosting a bare Git repository with hooks enabled.

The repository is not configured to require signed commits.

Why wrong: CodeCommit does integrate with IAM to support GPG-signed commits, but the repository itself does not have a built-in 'require signed commits' toggle that can enforce signatures before a push lands. Enforcing signed commits would typically be done with a client-side hook or an external IAM condition, not a server-side pre-receive hook. Since CodeCommit does not support pre-receive hooks, repository signing configuration is irrelevant to the reported failure.

Amazon ECS Service Auto Scaling

Why wrong: Amazon ECS Service Auto Scaling only adjusts the desired task count of an existing service based on CloudWatch metrics or target tracking policies. It continuously runs the same task set and image, so it can scale capacity up or down but cannot direct a controlled percentage of traffic to a new application version. Because it has no traffic-shifting or task-set replacement capability, it cannot implement a canary deployment.

Amazon Route 53 weighted routing

Why wrong: Amazon Route 53 weighted routing shifts traffic at the DNS layer between independent endpoints, such as separate load balancers or service names, not between task sets inside a single ECS service. Using it would require running two fully separate ECS services or environments and would suffer from DNS TTL caching, making precise, fast traffic shifting impractical. It cannot manage task set health, integrate with ECS deployment events, or roll back atomically, so it is not a valid ECS canary deployment mechanism.

AWS App Mesh with traffic shifting

Why wrong: AWS App Mesh traffic shifting uses virtual routers and virtual node weights to gradually send a percentage of HTTP/gRPC traffic to a different version of a service. However, this requires an Envoy sidecar mesh and only controls traffic routing; it does not orchestrate the ECS task set lifecycle, health check integration, or automatic rollback. While it can complement a deployment, App Mesh alone cannot replace the deployment control plane that CodeDeploy provides, so it is not the best answer here.

Use a CloudFormation action in CodePipeline with action mode 'CREATE_UPDATE' and include a manual approval step before the action.

Why wrong: Using CREATE_UPDATE in a CodePipeline CloudFormation action applies the template changes immediately during the pipeline run, without generating a separate reviewable change set. While adding a manual approval step before it can pause the pipeline, the approval happens before the change set is even created, so reviewers cannot inspect the exact modifications that will be applied. This negates the whole purpose of a change set review workflow, because the approval is not tied to a specific, diffable set of changes. Consequently, the pipeline either fails to provide the required pre-execution visibility or forces you to approve blindly before CloudFormation computes what will change.

Use an AWS Lambda function to create a change set and trigger a manual approval via SNS.

Why wrong: Although a Lambda function could invoke CreateChangeSet and then publish a message to an SNS topic for manual approval, this bespoke approach lacks the native lifecycle management and error handling that CodePipeline’s built-in CloudFormation action provides. You would need to write custom code to poll for change set creation status, manage the approval token or callback, handle retries, and then execute the change set only after approval. This adds significant operational complexity, introduces potential failure points outside of AWS’s managed pipeline services, and does not integrate with CodePipeline’s native approval action for a simple, auditable gated workflow. The design also makes it harder to track pipeline progress and rollbacks compared to using the purpose-built CloudFormation action modes.

Use a CloudFormation action with action mode 'CREATE_UPDATE' and set the 'Review' flag to true.

Why wrong: There is no 'Review' flag on a CloudFormation action in CodePipeline. The CREATE_UPDATE action mode always applies changes immediately upon execution and does not support a built-in review step that pauses after generating a change set. Even if you tried to combine it with an approval action, the approval would occur before the stack update, not after a change set is prepared for inspection, so reviewers would not see the exact planned changes. This option is invalid because it references a nonexistent configuration parameter and does not achieve the required separation between change set creation and execution. The only correct way to insert a human review between change computation and application is to use the dedicated change set action modes.

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

Why wrong: AWS CodeDeploy is a deployment service, not a build or testing service. It has no mechanism to watch a repository, compile code, or start a build when a commit arrives; instead, it deploys an already-built artifact to targets such as EC2, Lambda, or ECS. Attaching CodeDeploy to a repository confuses deployment with continuous integration because lifecycle hooks run during deployment, not as a pre-merge CI gate.

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

Why wrong: AWS CloudFormation is an infrastructure-as-code service that provisions and manages AWS resources; it is not a continuous integration tool and has no repository listener or built-in test runner. You could use CloudFormation to create supporting CI resources, such as a CodeBuild project or CodePipeline, but the stack itself does not run tests or react to commits. Claiming CloudFormation alone triggers builds on every push confuses resource provisioning with the actual build/test execution layer.

AWS CodeDeploy for deploying the SAM application.

Why wrong: AWS CodeDeploy is a fully managed deployment service that automates application deployments to EC2 instances, on-premises servers, or Lambda functions, but it does not orchestrate pipeline stages. A SAM application is actually deployed by packaging the template and then updating an AWS CloudFormation stack with the 'sam deploy' command. While CodeDeploy can be integrated for Lambda traffic shifting, it is not the service that runs the overall SAM CI/CD pipeline.

AWS CodeCommit to build the SAM application.

Why wrong: AWS CodeCommit is a managed Git-based source control service that stores repository code; it provides no runtime environment or build engine to execute commands such as 'sam build' or 'sam package'. Building and packaging a SAM application requires a compute environment with the SAM CLI installed, which is exactly what AWS CodeBuild build containers offer. Therefore, CodeCommit's sole role is acting as the source repository, not as the build tooling.

Configure the CodeCommit repository to disable events for all branches except main.

Why wrong: CodeCommit does not provide a configuration setting to disable repository events on a per-branch basis; push events are emitted globally for all branches. Even if such a setting existed, it would not integrate with the pipeline's event rule, leaving the trigger unaffected. The correct approach is to filter at the CloudWatch Events rule level, not at the repository level.

Modify the pipeline's source stage to use a branch name filter, which will ignore events from other branches.

Why wrong: The pipeline's source stage specifies a particular repository and branch to pull from, but it does not act as a filter on incoming trigger events; CodePipeline ignores events for the branch defined in the source configuration and simply proceeds when any event activates it. There is no 'ignore events from other branches' concept within the source action. Branch-level triggering must be controlled by the event rule's pattern, not the source configuration.

Use a Lambda function as a source action to check the branch before starting the build.

Why wrong: Using a Lambda function as a source action is an unnecessarily heavy pattern: the Lambda would have to perform custom checks and then return source revisions, and you would still need an event rule to invoke it. Moreover, a Lambda source action cannot be triggered directly by CodeCommit events; it is typically polled by CodePipeline. Branch filtering belongs in the event rule, not in custom runtime code.

Increase the size of the Auto Scaling group to ensure more instances are available.

Why wrong: Increasing the Auto Scaling group's desired capacity adds more instances, but those instances will use the same launch template, user data, and deployment scripts that already failed. The failure is not caused by insufficient capacity, so scaling out merely replicates the identical error across additional resources, increasing the blast radius without addressing the underlying issue.

Change the deployment configuration to 'CodeDeployDefault.AllAtOnce' to bypass the error.

Why wrong: Changing to CodeDeployDefault.AllAtOnce alters the deployment strategy by removing the failure threshold and launching the revision on every instance simultaneously, but it does not modify the AppSpec scripts or environment that caused the failure. Instead of bypassing the error, this configuration can turn a single-instance failure into a fleet-wide outage, so it is not a valid troubleshooting action.

Redeploy the application using a different revision.

Why wrong: Redeploying a different revision blindly assumes the current revision is defective, but the failure often stems from the deployment configuration, lifecycle script, or agent state rather than the artifact itself. Without first examining the agent logs to confirm a revision-specific defect, this approach wastes time and may repeat the same failure, while potentially introducing new compatibility issues.

Add an Approval action in the Test stage before the Test build action.

Why wrong: Placing an Approval action in the Test stage before the Test build action is incorrect because CodePipeline's Approval action pauses the entire stage when reached, which would block automated tests from running until a manual review is completed. This contradicts the intended workflow of allowing tests to validate the artifact before a human sign-off. The approval should be a distinct stage after successful testing, not co-located with build/test logic, so this option fails to gate promotion correctly.

Add a Lambda function in the pipeline that triggers a rollback if the Deploy stage fails.

Why wrong: Adding a Lambda function in the pipeline that triggers a rollback if the Deploy stage fails is incorrect because CodePipeline stops the execution when any action in a stage fails, so a Lambda action cannot run in response to that failure within the same pipeline flow. Although you could use Amazon CloudWatch Events to detect the pipeline execution failure and invoke an external Lambda for custom remediation, that Lambda is not part of the pipeline and cannot be configured as a conditional failure handler. The option as described conflates event-driven external automation with native pipeline error handling.

Configure the pipeline's Deploy stage to have a 'Rollback' action that runs on failure.

Why wrong: CodePipeline has no 'Rollback' action type, and actions do not run 'on failure' within the Deploy stage; a failed action immediately marks the stage and execution as failed. Rollback must be delegated to the deployment service, such as CodeDeploy's automatic rollback, or implemented externally via CloudWatch Events and Lambda. Configuring a nonexistent in-stage rollback action would be invalid and would not meet the requirement.

AWS CodeBuild

Why wrong: AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces build artifacts, but it does not provide version control. It requires source code to be pulled from a repository such as CodeCommit, S3, or GitHub, and then executes build commands in a temporary environment. The act of managing commits, branches, and history is outside CodeBuild's responsibility; it only consumes code from a source-control service.

AWS CodeDeploy

Why wrong: AWS CodeDeploy automates the deployment of application code to EC2 instances, Lambda, or on-premises servers, but it does not manage source repositories. It relies on revision locations, such as S3 buckets or GitHub, and coordinates rollout strategies like blue/green or in-place updates. While deployment is a critical SDLC automation stage, the service that holds and versions the code itself is CodeCommit, not CodeDeploy.

AWS CodePipeline

Why wrong: AWS CodePipeline is a continuous delivery service that orchestrates the build, test, and deployment stages of an SDLC pipeline, but it does not store or version source code. It references source locations as pipeline stages and passes artifacts between actions, relying on services like CodeCommit for actual source control. CodePipeline’s value is in coordinating the flow from commit to release, not in acting as the repository; that distinction belongs to CodeCommit.

AWS CloudFormation

Why wrong: AWS CloudFormation is an infrastructure-as-code service that provisions and manages AWS resources through declarative templates, but it does not manage application source code or version control. While it automates environment creation, it operates at the infrastructure layer, not the SDLC source-control layer. Its purpose is to eliminate manual resource provisioning, not to store or track code changes.

Amazon EventBridge

Why wrong: Amazon EventBridge is a serverless event bus that routes events from sources to targets, enabling event-driven architectures, but it has no role in source control or CI/CD execution. It does not store code, build artifacts, or deployment definitions; it merely reacts to state changes. Even when used to trigger pipelines, the actual source-control function is performed by a separate service like CodeCommit, not by EventBridge.