Skill 3.3.2: Configure and troubleshoot AWS CodeBuild, AWS CodeCommit, AWS CodeDeploy, AWS CodePipeline, and AWS CodeConnections

Question	Answer & Explanation
### Question 1 - CodePipeline & CodeConnections for External Git A machine learning engineering team is building an automated CI/CD pipeline using AWS CodePipeline to orchestrate the deployment of a custom generative AI application. The team's source code and training scripts are hosted in a self-hosted GitHub Enterprise Server instance on-premises. Security policies strictly prohibit the use of long-lived static credentials, such as Personal Access Tokens (PATs), inside the pipeline definition or AWS Secrets Manager for source authentication. Which approach should the team use to configure the pipeline's source stage to meet these security requirements? Select ONE. - A) Use AWS CodeCommit to mirror the GitHub Enterprise repository and trigger the pipeline on commits to CodeCommit. - B) Create an AWS CodeConnections resource configured for GitHub Enterprise Server and use it as the source action in CodePipeline. - C) Configure an AWS Lambda function to periodically poll the GitHub Enterprise Server and start the pipeline execution. - D) Store a GitHub PAT in AWS Secrets Manager and reference it in the CodePipeline source stage using a parameter store variable.	Correct Answer: B Correct Option Analysis: - B is Correct: AWS CodeConnections (formerly CodeStar Connections) provides a secure, managed integration between AWS CodePipeline and third-party Git repositories like GitHub Enterprise Server. It establishes an OAuth or GitHub App-based connection without requiring static tokens, satisfying the strict security policy. Distractor Analysis: - A is Incorrect: Mirroring the repository to AWS CodeCommit adds unnecessary operational overhead and does not directly address the requirement to use GitHub Enterprise as the source of truth without managing duplicate codebases. - C is Incorrect: Configuring a polling Lambda function introduces custom infrastructure, increases maintenance overhead, and is an anti-pattern when native trigger mechanisms exist. - D is Incorrect: Storing a Personal Access Token in Secrets Manager directly violates the stated security policy prohibiting long-lived static credentials. > Key Takeaway: AWS CodeConnections is the native, secure way to link CodePipeline to external Git providers (GitHub, GitLab, Bitbucket) without managing static credentials.
### Question 2 - CodeBuild Caching for ML Dependencies An AI team is using AWS CodeBuild to compile a custom Docker container image for SageMaker inference and run unit tests on the Python inference script. The build process currently takes over 20 minutes because it re-downloads Python dependencies (e.g., PyTorch, transformers) from the public PyPI repository during every build execution. The team must reduce the build time to improve developer productivity with the least operational overhead. Which configuration in the `buildspec.yml` or CodeBuild project settings will most effectively reduce the build duration? Select ONE. - A) Increase the instance type of the CodeBuild environment to compute-optimized (`c5.large`). - B) Enable local caching in CodeBuild using the `LOCAL_DOCKER_LAYER_CACHE` and `LOCAL_CUSTOM_CACHE` modes. - C) Store the dependencies in an Amazon S3 bucket and manually download them in the `install` phase of the buildspec. - D) Use AWS CodeArtifact to proxy the PyPI repository and configure CodeBuild to pull packages from CodeArtifact.	Correct Answer: B Correct Option Analysis: - B is Correct: CodeBuild supports local caching modes. `LOCAL_CUSTOM_CACHE` allows caching of arbitrary directories (like `.cache/pip`), and `LOCAL_DOCKER_LAYER_CACHE` caches Docker layers. By enabling these, CodeBuild reuses previously downloaded dependencies and built layers, drastically reducing build times without additional infrastructure. Distractor Analysis: - A is Incorrect: While a larger instance might execute build commands slightly faster, the bottleneck is network download time for large ML libraries. Upgrading the instance does not solve the latency of downloading dependencies. - C is Incorrect: Manually managing an S3 bucket for dependencies introduces significant operational overhead and scripting complexity. - D is Incorrect: While CodeArtifact improves availability and security for package management, it still requires pulling packages over the network during the build, which may not reduce build times as effectively as local caching for subsequent builds. > Key Takeaway: Use CodeBuild's `LOCAL_CUSTOM_CACHE` and `LOCAL_DOCKER_LAYER_CACHE` to skip redundant downloads and Docker layer builds, significantly accelerating CI/CD pipelines for heavy ML dependencies.
### Question 3 - CodeDeploy for ECS Canary Deployments A company is deploying an ML inference application as a containerized service on Amazon ECS using AWS Fargate. They are using AWS CodePipeline and AWS CodeDeploy for the deployment phase. The engineering team wants to ensure that if the new model causes an increase in 5xx errors, the deployment automatically rolls back to the previous task definition without manual intervention. Which TWO actions must the team take to configure this automated rollback? (Select TWO) - A) Configure a CloudWatch alarm on the `ECSService` 5xx error metric. - B) Configure the CodeDeploy deployment group to use the `CodeDeployDefault.ECSAllAtOnce` deployment configuration. - C) Configure an Amazon EventBridge rule to trigger a Lambda function that manually stops the deployment. - D) Enable the auto-rollback configuration in the CodeDeploy deployment group and associate the CloudWatch alarm. - E) Enable the auto-rollback configuration in the CodePipeline deployment stage and associate the CloudWatch alarm.	Correct Answers: A and D Correct Option Analysis: - A is Correct: CodeDeploy relies on Amazon CloudWatch Alarms to detect deployment failures. An alarm must be configured to monitor the relevant error metric (e.g., 5xx errors from the ALB or ECS service). - D is Correct: The auto-rollback feature must be explicitly enabled in the CodeDeploy deployment group or deployment configuration, and the CloudWatch alarm created in Option A must be linked to it. If the alarm trips during the baking period, CodeDeploy automatically rolls back to the last known good task definition. Distractor Analysis: - B is Incorrect: `CodeDeployDefault.ECSAllAtOnce` shifts all traffic immediately, defeating the purpose of a canary deployment which allows time for monitoring and rollback before full traffic shift. - C is Incorrect: Triggering a custom Lambda function to stop a deployment is overly complex and lacks the native rollback capabilities of CodeDeploy. - E is Incorrect: Automated rollback for ECS deployments is configured within AWS CodeDeploy (the deployment provider), not directly in the AWS CodePipeline deployment stage settings. > Key Takeaway: For CodeDeploy automated rollbacks, you must configure a CloudWatch Alarm and explicitly link it to the auto-rollback configuration within the CodeDeploy deployment group.
### Question 4 - Cross-Account CodePipeline Deployments A centralized MLOps team operates a "Tools" AWS account containing all source repositories in AWS CodeCommit. The ML engineering teams work in separate "Staging" and "Production" accounts. A CodePipeline in the Tools account must deploy a SageMaker inference endpoint to the Production account. Security policies mandate least-privilege access and require that the pipeline artifacts be encrypted. Which combination of steps is required to allow the CodePipeline in the Tools account to successfully trigger a deployment in the Production account? (Select TWO) - A) Create a customer-managed KMS key in the Tools account and grant the Production account's IAM role `kms:Decrypt` and `kms:GenerateDataKey` permissions. - B) Configure the CodePipeline cross-account deployment by creating an IAM role in the Production account that the Tools account's CodePipeline action can assume. - C) Set up a VPC Peering connection between the Tools account and the Production account to allow CodePipeline API calls. - D) Enable AWS STS in the Production account and create an inline policy in the Tools account CodePipeline role to allow `sts:AssumeRole` to the Production account. - E) Configure the CodePipeline source stage to use AWS CodeConnections to access the CodeCommit repository cross-account.	Correct Answers: A and B Correct Option Analysis: - A is Correct: When CodePipeline passes artifacts cross-account, the artifact bucket in the Tools account must be encrypted with a customer-managed KMS key. The key policy must allow the cross-account IAM role in the Production account to decrypt the artifacts. - B is Correct: A cross-account IAM role must be created in the Production account with permissions to create SageMaker resources. The CodePipeline service role in the Tools account assumes this role to perform the deployment action. Distractor Analysis: - C is Incorrect: VPC Peering is for network-level routing of private IP traffic. CodePipeline and SageMaker API calls operate over public AWS endpoints and are authenticated via IAM, not network peering. - D is Incorrect: While `sts:AssumeRole` is required, relying on inline policies is a bad practice compared to explicit trust policies on the cross-account role. Furthermore, STS is a global service and does not need to be "enabled" in the account. - E is Incorrect: AWS CodeCommit does not require AWS CodeConnections. CodePipeline natively integrates with CodeCommit in the same account; CodeConnections is for external third-party Git providers. > Key Takeaway: Cross-account CodePipeline deployments require a customer-managed KMS key on the artifact bucket with cross-account permissions, and an IAM role in the target account that the pipeline assumes.
### Question 5 - Troubleshooting CodeBuild ECR Push A developer is troubleshooting an AWS CodeBuild project that builds a Docker image for a custom SageMaker training algorithm. The build fails during the `docker push` command to Amazon ECR. The CodeBuild service role has the `AmazonEC2ContainerRegistryPowerUser` policy attached, and the network is configured with VPC endpoints for ECR. The error message is `denied: Your authorization token has expired.` What is the most likely cause of this failure, and how can it be resolved? Select ONE. - A) The CodeBuild environment does not have internet access via a NAT Gateway, preventing ECR authentication. - B) The CodeBuild project is using a custom Docker image that lacks the AWS CLI pre-installed. - C) The Docker daemon inside CodeBuild needs to be authenticated to the ECR registry using the `aws ecr get-login-password` command before the push. - D) The ECR repository policy does not explicitly grant `ecr:BatchCheckLayerAvailability` to the CodeBuild service role.	Correct Answer: C Correct Option Analysis: - C is Correct: Even with the correct IAM role, the Docker client itself must authenticate with the ECR registry before it can push images. This is done by running `aws ecr get-login-password --region <region> \| docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com` in the `pre_build` or `build` phase of the `buildspec.yml`. Distractor Analysis: - A is Incorrect: Because the network uses VPC endpoints for ECR, public internet access via a NAT Gateway is not required for the push to succeed. - B is Incorrect: CodeBuild managed images come with the AWS CLI installed. Even if a custom image is used, the failure would be a command not found error, not an expired authorization token error. - D is Incorrect: The `AmazonEC2ContainerRegistryPowerUser` policy already includes `ecr:BatchCheckLayerAvailability`. The error is specifically about Docker client authentication, not IAM permissions. > Key Takeaway: IAM permissions authorize the AWS API calls, but the Docker daemon requires explicit login via `aws ecr get-login-password` to authenticate Docker client operations like push and pull.
### Question 6 - CodeCommit Source Triggers A data science team updates their feature engineering scripts in an AWS CodeCommit repository. They want an AWS CodePipeline to trigger automatically whenever a new branch is merged into the `main` branch. The pipeline should then execute an AWS Step Functions state machine that runs a SageMaker Processing job. Which configuration meets this requirement with the least operational overhead? Select ONE. - A) Create an Amazon CloudWatch Events (EventBridge) rule that triggers on CodeCommit repository state changes and directly starts the Step Functions execution. - B) Configure a CodeCommit notification rule to send an Amazon SNS message, which triggers a Lambda function to start the Step Functions. - C) Use AWS CodePipeline with a source stage configured for the CodeCommit repository and an action stage to invoke Step Functions. - D) Set up a cron job on an Amazon EC2 instance to poll the CodeCommit repository for changes and trigger Step Functions.	Correct Answer: C Correct Option Analysis: - C is Correct: AWS CodePipeline natively integrates with AWS CodeCommit as a source provider. It automatically detects changes to the specified branch (e.g., `main`) and can natively invoke AWS Step Functions as a deployment or action stage. This requires no custom code or event handling. Distractor Analysis: - A is Incorrect: While EventBridge could trigger Step Functions directly, it bypasses AWS CodePipeline, which the scenario explicitly requires the team to use for orchestration. - B is Incorrect: Using SNS and Lambda to act as glue between CodeCommit and Step Functions introduces unnecessary custom code and operational overhead compared to native CodePipeline actions. - D is Incorrect: Running a polling EC2 instance is a significant anti-pattern, highly inefficient, and introduces massive operational overhead. > Key Takeaway: CodePipeline natively detects CodeCommit branch changes and can directly invoke Step Functions, providing an event-driven, low-overhead orchestration path for MLOps workflows.
### Question 7 - Pipeline Manual Approval for Model Registry A machine learning team is using AWS CodePipeline to orchestrate the promotion of a trained model from a staging environment to production. After the training job completes, the model is registered in the SageMaker Model Registry in the staging account. Before the model is deployed to a SageMaker endpoint in the production account, a human reviewer must manually verify the model's evaluation metrics and approve the release. How can the MLOps engineer configure this workflow to ensure a reliable, auditable manual gate? Select ONE. - A) Add a manual approval action to the CodePipeline between the staging and production deployment stages, sending an Amazon SNS notification to the reviewer. - B) Configure an AWS Lambda function to query the SageMaker Model Registry and send an email; the reviewer replies to the email to trigger the production stage. - C) Create an Amazon EventBridge rule that triggers the production deployment only when the model's status in the Model Registry is manually changed to "Approved". - D) Use AWS CodeDeploy to manage the deployment and require a manual validation step in the CodeDeploy AppSpec file.	Correct Answer: A Correct Option Analysis: - A is Correct: AWS CodePipeline has a built-in "Manual approval" action that can be inserted between stages. This action pauses the pipeline and can publish an SNS notification to alert reviewers. The reviewer approves or rejects the release directly in the CodePipeline console, providing an auditable, native gate. Distractor Analysis: - B is Incorrect: Configuring email replies to trigger pipeline execution is not natively supported, insecure, and highly error-prone. - C is Incorrect: While the Model Registry has an approval status, relying on it to trigger CodePipeline natively is complex and bypasses the pipeline's built-in manual approval workflow which provides the required auditing natively. - D is Incorrect: CodeDeploy AppSpec files define deployment configurations and lifecycle hooks, not manual approval gates for human verification. > Key Takeaway: The AWS CodePipeline Manual Approval action is the native, auditable mechanism for enforcing human gates between pipeline stages.
### Question 8 - CodeDeploy EC2 Rolling Deployments An AI company is deploying a legacy ML model to a fleet of Amazon EC2 instances using AWS CodeDeploy. The instances are part of an Auto Scaling group. The team needs to ensure that the deployment causes no downtime and that new instances are launched with the new application revision while old instances are replaced gradually, maintaining the fleet's overall compute capacity. Which CodeDeploy deployment configuration should the engineer select? Select ONE. - A) `CodeDeployDefault.AllAtOnce` - B) `CodeDeployDefault.EC2Canary10Percent5Minutes` - C) `CodeDeployDefault.OneAtATime` - D) `CodeDeployDefault.LambdaCanary10Percent5Minutes`	Correct Answer: C Correct Option Analysis: - C is Correct: For EC2 instances in an Auto Scaling group, the `CodeDeployDefault.OneAtATime` configuration ensures that only one instance is taken offline, updated, and brought back online before the next instance is processed. This maintains the capacity of the fleet and ensures zero downtime. Distractor Analysis: - A is Incorrect: `CodeDeployDefault.AllAtOnce` takes all instances offline simultaneously, resulting in complete application downtime. - B is Incorrect: `CodeDeployDefault.EC2Canary10Percent5Minutes` is used for in-place deployments on EC2, but Canary deployments for EC2 require a load balancer and shift traffic rather than replacing capacity. `OneAtATime` is the standard safe rolling update for ASG. - D is Incorrect: Lambda deployment configurations cannot be applied to EC2 targets. > Key Takeaway: When deploying to EC2 instances in an Auto Scaling group, `CodeDeployDefault.OneAtATime` guarantees high availability by maintaining fleet capacity during the rolling update.
### Question 9 - Troubleshooting CodeConnections Pending Status An engineer has created an AWS CodeConnection to link an AWS CodePipeline with a GitLab repository. However, the source stage of the pipeline remains in a "Pending" status and does not retrieve any source code. The IAM roles, bucket policies, and VPC configurations are verified to be correct. What is the most likely reason for this failure, and how can it be resolved? Select ONE. - A) The CodePipeline service role lacks permissions to access the CodeConnection; update the role policy to include `codeconnections:UseConnection`. - B) The CodeConnection requires a manual OAuth handshake from the AWS Management Console to establish the connection with GitLab. - C) The CodePipeline source stage must be updated to use a Webhook instead of a CodeConnection for GitLab. - D) The CodeConnection is in a different AWS Region than the CodePipeline; recreate the connection in the correct Region.	Correct Answer: B Correct Option Analysis: - B is Correct: When an AWS CodeConnection is created, it enters a `PENDING` status until an administrator clicks the "Update pending connection" button in the AWS Management Console to complete the OAuth handshake with the third-party provider (e.g., GitLab). Until this is done, the pipeline cannot fetch code. Distractor Analysis: - A is Incorrect: If the role lacked permissions, the pipeline would fail with an authorization error, not remain pending pending the connection handshake. - C is Incorrect: Webhooks were the older method for GitHub integrations; CodeConnections is the modern, recommended way to integrate CodePipeline with external Git providers without webhooks. - D is Incorrect: While resources must be in the same region, the scenario does not indicate a region mismatch, and the most common cause of a pending connection is the uncompleted OAuth handshake. > Key Takeaway: AWS CodeConnections requires a one-time manual OAuth authorization via the AWS Console to transition from `PENDING` to `AVAILABLE` before pipelines can access the repository.
### Question 10 - Secure Secrets in CodeBuild During the build stage of a CI/CD pipeline, an AWS CodeBuild project runs integration tests for an LLM-based chatbot. The tests require calling an external third-party API to evaluate the chatbot's responses, and the API key is stored in AWS Secrets Manager. The project environment uses a `buildspec.yml` file. How should the engineer configure the CodeBuild project to securely pass the API key to the build environment without exposing it in the logs? Select ONE. - A) Reference the secret in the `buildspec.yml` using the `secrets-manager` parameter in the `env` section and use the variable in the test scripts. - B) Manually inject the API key as a plaintext environment variable in the CodeBuild project console. - C) Fetch the secret using the AWS CLI inside the `build` phase and export it, ensuring the `no_logs` flag is set. - D) Store the API key in AWS Systems Manager Parameter Store as a `String` type and reference it as a plaintext environment variable.	Correct Answer: A Correct Option Analysis: - A is Correct: CodeBuild natively integrates with AWS Secrets Manager via the `buildspec.yml`. By defining the secret ARN under the `env` -> `secrets-manager` section, CodeBuild securely injects the secret value as an environment variable during runtime. CodeBuild automatically masks these values in logs, preventing leakage. Distractor Analysis: - B is Incorrect: Manually injecting secrets as plaintext environment variables in the console is insecure, lacks version control, and may expose the secret in logs. - C is Incorrect: Writing custom AWS CLI commands to fetch secrets adds unnecessary scripting and risks accidentally printing the secret to stdout, which could be logged. - D is Incorrect: While Parameter Store can be used, storing sensitive API keys as a `String` type is insecure compared to a `SecureString`, and using Secrets Manager is the best practice for API keys and credentials. > Key Takeaway: CodeBuild's `secrets-manager` mapping in the `buildspec.yml` securely injects secrets as environment variables and automatically masks them in CloudWatch logs.