SDLC Automation practice questions

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

Why it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

Amazon S3 event notifications are not guaranteed to be delivered for bulk operations.

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

CodePipeline does not support triggering from S3 event notifications when multiple files are uploaded simultaneously.

Why it fails: CodePipeline supports S3 event notifications and can handle multiple triggers.

The S3 bucket versioning is not enabled, causing events to be lost.

Why it fails: Versioning is not required for event notifications; events are sent regardless.

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

Why it fails: 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 it fails: 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 it fails: 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.

Blue/Green: Deploy to a small subset first, then gradually.

Why it fails: This description is incorrect because Blue/Green does not shift a small portion of traffic and then gradually expand the share. Instead, it keeps two fully scaled, independent environments and performs a binary cutover—all at once—once the new environment is verified. Gradually routing increasing traffic to a small subset is the defining characteristic of a canary deployment, which is a separate strategy.

Rolling: Deploy to a separate environment and switch.

Why it fails: Rolling deployments never use a separate environment; they update the currently running instances in place, batch by batch, within the existing fleet. The process of deploying to a new environment and switching traffic describes Blue/Green, where a second environment is built and validated independently. Rolling's rollback similarly differs: it does not flip a route back but progressively replaces updated instances with the prior version.

Add a manual approval action in the test stage that requires a developer to confirm success

Why it fails: Manual approval is a human gate that pauses the pipeline, but it isn't a pass/fail mechanism. If a preceding test action fails, the pipeline execution stops immediately, so the approval action would never even be reached. Even if the test action succeeds, adding manual approval adds an unnecessary operational burden and doesn't prevent deployment—it simply requires a human to click Approve before the transition to deploy.

Set the test stage to retry on failure three times before allowing deploy to proceed

Why it fails: Configuring a retry count on the test action simply re-executes the same command or suite after a failure; it does not convert a failed test run into a success or into a condition that allows deployment. After all configured retries are exhausted, the action is marked failed and CodePipeline halts the execution before the deploy stage. Retry is useful for transient issues, but it never overrides the fundamental require-that-each-stage-succeeds behavior.

Configure the deploy stage to skip if the test stage fails using a condition

Why it fails: CodePipeline does not support conditional expressions or 'on failure, skip next stage' configuration. The execution engine evaluates stages in order and stops at the first failed action; there is no mechanism to make the deploy stage conditional on the test stage's outcome. To achieve a conditional deployment, you would need to restructure the pipeline (for example, using separate pipelines with event triggers or a custom Lambda-backed action that inspects test results) rather than using a built-in skip condition.

The VPC creation failed, so the subnet could not be created

Why it fails: The VPC was created successfully (CREATE_COMPLETE).

The CloudFormation service role does not have permission to create subnets

Why it fails: The error message does not indicate a permission issue; it says the subnet ID does not exist.

The subnet logical ID conflicts with an existing resource in the stack

Why it fails: There is no conflict; the error indicates the physical resource ID does not exist.

Configure a Git hook in the repository to reject unsigned commits.

Why it fails: This is incorrect because CodeCommit does not allow server-side Git hooks; any hook must be client-side. Configuring a hook in the repository would require server-side execution.

Use an IAM policy condition to deny pushes if the commit is not signed.

Why it fails: This is wrong because IAM policies cannot inspect commit content or signature status. They only control API-level access based on conditions like IP address or VPC endpoint, not commit metadata.

Enable the 'Require GPG signatures' option in the CodeCommit repository settings.

Why it fails: This is incorrect because CodeCommit does not have a 'Require GPG signatures' option in its repository settings. This feature exists in GitHub/GitLab but not in CodeCommit.

Configure the deployment group to ignore failed instances.

Why it fails: Ignoring failures would not meet the requirement.

Use a CloudWatch alarm to trigger a rollback.

Why it fails: CloudWatch alarms can trigger actions but not directly roll back CodeDeploy.

Use a custom deployment configuration that fails the deployment if any instance fails.

Why it fails: This would stop the deployment but not automatically roll back.

Give the target account's IAM role permission to encrypt with the KMS key.

Why it fails: Granting the target account's IAM role permission to encrypt with the KMS key reverses the direction of access. Encryption is performed using the source account's KMS key, and the target pipeline only needs kms:Decrypt and kms:GenerateDataKey to read artifacts. An encrypt-only permission fails to grant the required read access, and it does nothing to satisfy the key policy requirement that explicitly names the pipeline role.

Create a KMS key in the target account.

Why it fails: Creating a KMS key in the target account is ineffective for this setup because the artifact S3 bucket and its KMS key must reside in the source account, where the artifacts are encrypted. The target-account pipeline must be able to decrypt artifacts using the source account's key, not a new key in the target account. Even if you created a key in the target account, the source key policy would still need to include the pipeline role ARN, and the role would still need decrypt permissions on that source key.

The IAM user does not have list-projects permission.

Why it fails: If the IAM user lacked the required `codebuild:ListProjects` permission, the AWS CLI would receive an `AccessDeniedException` from the CodeBuild API and print an error message to stderr (e.g., "An error occurred (AccessDeniedException) when calling the ListProjects operation"). The command produced an empty list rather than an error, which means the request was authorized and the IAM policy allowed the action. Therefore, a permission failure is not consistent with the observed output.

The AWS CLI is not configured with valid credentials.

Why it fails: Invalid or missing credentials would cause the CLI to fail before any API call is made, producing an error such as "Unable to locate credentials" or "ExpiredTokenException" in the output. Since the command ran and returned an empty result, the request was authenticated and the credentials were valid. The empty output indicates that the API call succeeded, not that authorization failed.

The region specified is incorrect.

Why it fails: The `--region` parameter is explicitly set in the command, overriding any configuration file, and CodeBuild is available in most regions. If the region were incorrect or unsupported, the CLI would throw an error such as `InvalidRegion` or `UnrecognizedClientException` because the service endpoint would not exist. The command did not produce a region-related error and returned an empty list, proving that the region was valid and accepted by the AWS service.

The runtime is not supported.

Why it fails: Python 3.9 is a fully supported runtime for AWS Lambda, so selecting it in the AWS::Lambda::Function Runtime property does not cause invocation or logging failures. AWS Lambda supports Python 3.9 as a valid runtime identifier, and unless that version is explicitly deprecated or unsupported in the region, Lambda will provision the runtime without issue. An unsupported runtime would typically produce an error during stack creation or a Runtime.InvalidEntrypoint runtime error, not a failure to write logs to CloudWatch Logs. Therefore, the runtime choice cannot explain the observed logging problem.

The Lambda execution role has a trust policy that is missing the lambda service.

Why it fails: For Lambda to assume the execution role, the role's trust policy must contain a service principal of lambda.amazonaws.com with the sts:AssumeRole action, which is present in the exhibit's trust policy. With that trust relationship properly defined, Lambda can assume the role when invoking the function. If the trust policy were missing the lambda service, you would see an error stating that the role cannot be assumed by Lambda, and the function invocation would fail before any code or logging step. Since the trust policy is correct, this is not the cause of the CloudWatch Logs write failure.

The Lambda function code is faulty.

Why it fails: The Lambda function code is not shown in the exhibit, and the described problem is specifically a CloudWatch Logs permission denial, which occurs before any user code is executed. Logging to CloudWatch Logs is handled by the Lambda runtime and the execution role; if the role lacks logs:CreateLogGroup, logs:CreateLogStream, or logs:PutLogEvents permissions, the runtime cannot even create a log stream, making the function code irrelevant to this diagnostic. Even defect-free code will fail to produce logs under these IAM conditions. Therefore, a faulty code path is not a plausible root cause for the logging failure.

Assign an IAM role that only allows signed API calls.

Why it fails: Attaching an IAM role with permissions that only allow 'signed API calls' is ineffective because IAM does not expose a condition key that checks Git commit signatures. IAM policies govern access to AWS APIs based on identity and context, but they cannot inspect the contents of the Git objects being pushed. A signed API call means the request is authenticated with valid credentials, not that the accompanying commits are signed, so this approach would not stop developers from pushing unsigned commits.

Use a pre-commit hook in the local repository.

Why it fails: A pre-commit hook runs only on the developer's local machine and can be easily bypassed with `git commit --no-verify` or by not installing the hook in the first place. Since hooks are not propagated to the CodeCommit repository, they cannot provide any server-side enforcement and are not a reliable compliance control. The hook may remind a developer to sign, but it cannot guarantee that every commit pushed to the remote is signed.

Set up a CloudWatch Events rule to reject unsigned commits.

Why it fails: CloudWatch Events (now Amazon EventBridge) delivers events after a change has already happened, so it has no ability to reject or block an unsigned push in real time. Even if a rule triggered on a push event, the commit would already be stored in the repository before any remediation action could run. EventBridge rules also lack access to the cryptographic verification required to determine whether a commit is signed, and they cannot deny the original API call. Enforcement must happen at the CodeCommit service layer, not via post-hoc event processing.

Use CloudFormation StackSets to manage approvals.

Why it fails: CloudFormation StackSets extend CloudFormation to provision and manage identical stacks across multiple accounts and AWS Regions, using self-managed or service-managed permissions. They handle the orchestration of cross-account deployments but have no built-in workflow for human approvals; any update to a stack set is executed directly by the user or pipeline invoking it. Thus StackSets address administrative scaling, not enforcing a pre-deployment review gate.

Use CloudFormation Stack Policies to prevent updates.

Why it fails: Stack policies are JSON documents attached to a CloudFormation stack that prevent update or deletion of protected resources, such as database instances, by denying actions during any stack update. They act as a defensive guardrail against accidental destructive changes, but they do not create an approval workflow or notify reviewers; any permitted update can proceed without human sign-off. Consequently, a stack policy cannot enforce a review-before-execute requirement.

Use CloudFormation Drift Detection to detect changes.

Why it fails: Drift Detection compares the live state of a stack's resources against the expected template configuration, flagging differences for later reconciliation. It is a monitoring and auditing function that runs on demand or as part of an event-driven process, and it does not intercept or gate upcoming deployments. Because drift detection operates after resources are changed, it cannot serve as an approval mechanism for planned updates.

Use CloudFormation Change Sets to review and manually execute changes.

Why it fails: CloudFormation Change Sets let you view a summary of the changes a stack update would make—including resource additions, modifications, and deletions—without actually applying them. You then must explicitly execute the change set to apply those changes, providing a manual checkpoint where a user can inspect and decide. While this is a form of manual approval, it is inherently a single-user action without a separate approval step; anyone with CloudFormation execution permission can execute the change set, so it does not enforce an independent reviewer.

iam:PassRole

Why it fails: Not required for the user.

codepipeline:GetPipelineExecution

Why it fails: Not required to start execution.

s3:PutObject

Why it fails: Starting a pipeline does not require S3 PutObject.

Use a CreationPolicy on the DB instance.

Why it fails: A CreationPolicy is used to wait for a signal before considering a resource created, not for updating or avoiding downtime.

Use a stack policy to prevent replacement of the DB instance.

Why it fails: A stack policy can prevent updates but does not allow the modification to happen, failing to meet the requirement.

Use an UpdatePolicy with AutoScalingRollingUpdate.

Why it fails: An UpdatePolicy with AutoScalingRollingUpdate is only applicable to Auto Scaling groups, not RDS instances.

The user is not in the correct IAM group.

Why it fails: IAM group membership is irrelevant here because the policy is attached directly to the user, and IAM combines all applicable policies—direct and group-based—before evaluating access. A user does not need to belong to a group to receive permissions; groups are only an administrative convenience for managing multiple users' policies. The actual failure is caused by insufficient resource-level scoping for GitPush, not by the user's group assignment. Therefore, misdiagnosing the issue as a lack of group membership is incorrect.

The user does not have GitPull permission on the repository.

Why it fails: GitPull is explicitly allowed in the policy on a wildcard resource or on the repository, so the user has the necessary permission to pull from the repository. Pull and push are separate CodeCommit IAM actions, and allowing GitPull on all resources does not grant GitPush on any branch. In fact, the user's inability to push is not due to missing GitPull permission because the policy already covers that action. This option is wrong because GitPull permission is present and unrelated to the push failure.

The policy must include codecommit:CreateRepository action.

Why it fails: codecommit:CreateRepository is a management-plane action required only when creating a new repository, but the repository already exists in the exhibit. GitPush is a data-plane operation on an existing repository and its branches; it does not call the CreateRepository API. Granting CreateRepository would not add the branch-level resource permission that GitPush requires, so the policy would still deny the push. Hence, this option is incorrect because the repository exists and creation is not a prerequisite for pushing.

Increase the --max-items value to a larger number.

Why it fails: Increasing `--max-items` only raises the maximum number of items returned in a single API call, but it does not consume or use the `NextToken` that was already returned. Because the service has already indicated there are more results via the `'abc123'` token, simply asking for a larger page size will not fetch the next page—it will still return the first page (up to the new limit) from the beginning. Furthermore, many AWS services enforce hard upper limits on page size, so even a large `--max-items` value may not be sufficient to retrieve all deployments in one call and does not solve the pagination problem.

Run the command without --max-items to get all deployments.

Why it fails: Running the command without `--max-items` does not automatically retrieve all deployments; the AWS CLI still applies a default page size (often 100 or a service-specific default) and returns only the first page. The CLI's paginator does not automatically follow `NextToken` unless you explicitly provide `--starting-token` in subsequent calls or use a higher-level pagination loop in your script. Therefore, omitting `--max-items` leaves you with the same problem: you still get only a subset, and the `'abc123'` token remains unused.

Use the --no-paginate option.

Why it fails: The `--no-paginate` flag tells the AWS CLI to disable its built-in client-side pagination, meaning it will not automatically append `--starting-token` to follow `NextToken` even if it appears in the output. However, the underlying AWS service still imposes its own page size limit (respecting `--max-items` if provided), so the response will still be truncated to one page. This option actually makes the situation worse: the CLI will not expose a `NextToken` for you to use, so you lose the ability to paginate at all, and you certainly do not get all deployments.

Use Amazon CloudWatch to monitor the build and automatically restart it if it times out.

Why it fails: Incorrect. Using Amazon CloudWatch to restart a timed-out build does not increase resources or change the timeout. It merely retries with the same limitations.

Use AWS Lambda instead of CodeBuild, as it can run up to 15 minutes.

Why it fails: Incorrect. AWS Lambda has a maximum execution time of 15 minutes and limited memory/CPU compared to CodeBuild. It is not designed for integration tests that require large resources and long runtimes.

Modify the buildspec.yml file to include 'compute-type' and 'timeout-in-minutes' overrides.

Why it fails: Incorrect. The buildspec.yml does not support a 'compute-type' field or a 'timeout-in-minutes' override for compute resources. Compute type is a project-level setting, and timeout overrides are only available via environment variables or the project configuration, not in buildspec.yml.