IAM password policies<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Details about previous pipeline executions<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodePipeline execution history provides visibility into previous pipeline runs, including their status and the actions performed during each execution. This information is useful when investigating failed deployments, reviewing changes, or determining when a particular release passed through the pipeline. Operators can use execution details to identify which stage or action failed and then investigate the associated logs or artifacts. Historical execution information also supports operational auditing and troubleshooting because it provides context about how application changes moved through the delivery process. Reviewing execution history alongside CodeBuild logs, CodeDeploy events, CloudFormation events, and CloudWatch monitoring can provide a more complete understanding of deployment behavior.<\/span><\/p>\nQuestion 302. Which CodePipeline action can require human approval?<\/b><\/h3>\n\n- <\/b> Source<\/span>
\n<\/span>2.<\/b> Manual approval<\/span>
\n<\/span>3.<\/b> Build cache<\/span>
\n<\/span>4.<\/b> Artifact upload<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Manual approval<\/b><\/p>\n
Explanation:<\/b><\/p>\n
A CodePipeline manual approval action pauses a pipeline until an authorized person reviews the deployment and approves or rejects it. This can be useful before production deployments when an organization requires an explicit human review after automated testing has completed. For example, a pipeline might automatically build an application, execute tests, and deploy it to staging, then pause for approval before production. Manual approval should be used strategically because excessive manual intervention can reduce deployment automation. The approval stage can be accompanied by information about the change, test results, or deployment details so that the reviewer has appropriate context before deciding whether to continue the pipeline.<\/span><\/p>\nQuestion 303. What happens when a CodePipeline action fails?<\/b><\/h3>\n\n- <\/b> The failed action is marked unsuccessful<\/span>
\n<\/span>2.<\/b> All AWS accounts are deleted<\/span>
\n<\/span>3.<\/b> ECR images are automatically removed<\/span>
\n<\/span>4.<\/b> IAM policies are disabled<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. The failed action is marked unsuccessful<\/b><\/p>\n
Explanation:<\/b><\/p>\n
When a CodePipeline action fails, the action and associated pipeline execution are reported as unsuccessful according to the pipeline’s execution state. The failure prevents dependent downstream actions from proceeding as though the previous step had completed successfully. Operators can inspect the action details and associated service logs to determine the cause. For example, a failed CodeBuild action may require reviewing build logs, while a failed CloudFormation deployment may require examining stack events. Handling failures in this way provides a controlled quality gate within the pipeline. Automated retry, notification, rollback, or remediation mechanisms can then be added according to the requirements of the deployment architecture.<\/span><\/p>\nQuestion 304. Why should pipeline stages have clear dependencies?<\/b><\/h3>\n\n- <\/b> To ensure actions execute in the intended sequence<\/span>
\n<\/span>2.<\/b> To disable artifact storage<\/span>
\n<\/span>3.<\/b> To prevent CloudWatch metrics<\/span>
\n<\/span>4.<\/b> To eliminate testing<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. To ensure actions execute in the intended sequence<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Clear stage dependencies help ensure that a CI\/CD pipeline performs operations in the correct order. For example, application code should normally be built and tested before it is deployed, and infrastructure validation should occur before production changes are applied. CodePipeline stages provide logical boundaries for these operations and can establish a predictable progression through the release process. Clear dependencies also make troubleshooting easier because teams can identify where a release stopped and understand which previous conditions were satisfied. A well-structured pipeline can combine automated testing, security checks, artifact creation, deployment, validation, and approval while preventing later stages from consuming outputs that have not been successfully produced.<\/span><\/p>\nQuestion 305. What does CodeBuild’s buildspec file define?<\/b><\/h3>\n\n- <\/b> Build commands and related build configuration<\/span>
\n<\/span>2.<\/b> IAM trust relationships<\/span>
\n<\/span>3.<\/b> ECS load balancer rules<\/span>
\n<\/span>4.<\/b> CloudTrail retention<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Build commands and related build configuration<\/b><\/p>\n
Explanation:<\/b><\/p>\n
A CodeBuild buildspec file defines instructions and configuration used during a build. It can specify phases such as installation, pre-build, build, and post-build activities, along with commands that should be executed during those phases. A buildspec can also define artifacts, reports, environment variables, and other supported build settings. Keeping build instructions in a version-controlled buildspec helps make the build process repeatable and transparent because the instructions travel with the project source or can be supplied through supported configuration mechanisms. This is particularly useful in DevOps environments because the same automated build process can be reproduced across different executions without relying on undocumented manual steps.<\/span><\/p>\nQuestion 306. Which CodeBuild phase commonly runs unit tests?<\/b><\/h3>\n\n- <\/b> Build or post-build phase<\/span>
\n<\/span>2.<\/b> IAM phase<\/span>
\n<\/span>3.<\/b> Encryption phase<\/span>
\n<\/span>4.<\/b> Artifact deletion phase<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Build or post-build phase<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeBuild buildspec phases provide structured locations for executing different parts of the build process. Unit tests can commonly be executed during the build or post-build phase, depending on the project’s workflow and reporting requirements. The important objective is to ensure tests run automatically before an artifact is promoted to later deployment stages. If tests fail, the CodeBuild action should fail so that CodePipeline does not continue as though the application had passed validation. Automated testing provides an important quality gate because it catches functional regressions earlier in the release process. Test results can also be published through CodeBuild report groups for centralized visibility.<\/span><\/p>\nQuestion 307. What is the purpose of CodeBuild environment variables?<\/b><\/h3>\n\n- <\/b> Provide configuration values to build commands<\/span>
\n<\/span>2.<\/b> Create IAM users<\/span>
\n<\/span>3.<\/b> Replace ECR repositories<\/span>
\n<\/span>4.<\/b> Manage DNS zones<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Provide configuration values to build commands<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeBuild environment variables provide configuration values that can be accessed by commands executed during a build. They can be used for non-sensitive settings such as environment names, application options, region information, or build parameters. For sensitive values, CodeBuild can retrieve information from services such as AWS Systems Manager Parameter Store and AWS Secrets Manager rather than storing credentials directly in source code. This separation makes build configuration more flexible and supports different settings for development, testing, and production environments. Environment variables should still be handled carefully because values may potentially appear in logs if build commands print them. Sensitive information should never be unnecessarily exposed through build output.<\/span><\/p>\nQuestion 308. What is the benefit of using CodeBuild reports?<\/b><\/h3>\n\n- <\/b> Centralized visibility into test results<\/span>
\n<\/span>2.<\/b> Automatic creation of security groups<\/span>
\n<\/span>3.<\/b> ECS cluster scaling<\/span>
\n<\/span>4.<\/b> S3 bucket deletion<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Centralized visibility into test results<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeBuild reports provide structured visibility into test and code coverage results produced during builds. Rather than treating test output as unstructured log information, report groups allow results to be collected and reviewed in a more organized way. This helps development and operations teams identify failing tests, monitor quality, and evaluate changes over time. Reports can become an important part of a CI quality gate because a build can fail when required tests do not pass. When combined with CodePipeline, report results can help ensure that only successfully validated artifacts proceed to deployment. Effective reporting makes automated testing more useful because teams can quickly understand what failed instead of reviewing large build logs manually.<\/span><\/p>\nQuestion 309. What does an ECR repository URI identify?<\/b><\/h3>\n\n- <\/b> A container image repository location<\/span>
\n<\/span>2.<\/b> A CloudFormation stack policy<\/span>
\n<\/span>3.<\/b> A Lambda execution role<\/span>
\n<\/span>4.<\/b> A CloudWatch alarm<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. A container image repository location<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An Amazon ECR repository URI identifies the location of a container image repository and is commonly used by Docker clients, ECS task definitions, and deployment systems when referring to images stored in ECR. A complete image reference can include the repository URI along with a tag or digest. For example, a deployment may reference a specific image tag for convenience or an image digest when exact immutability is required. Correct repository configuration is essential in automated container pipelines because the build system must push images to the appropriate repository and deployment services must have permission to pull them. Cross-account deployments may additionally require suitable repository policies and IAM permissions.<\/span><\/p>\nQuestion 310. Why use ECR scan-on-push?<\/b><\/h3>\n\n- <\/b> To scan newly pushed container images for vulnerabilities<\/span>
\n<\/span>2.<\/b> To increase ECS desired count<\/span>
\n<\/span>3.<\/b> To create CloudFormation stacks<\/span>
\n<\/span>4.<\/b> To rotate IAM passwords<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. To scan newly pushed container images for vulnerabilities<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon ECR image scanning can identify known vulnerabilities in container images after they are pushed to a repository. Scan-on-push enables scanning to occur automatically when new images are uploaded, helping organizations integrate vulnerability detection into the container supply chain. The results can be reviewed and used as part of a CI\/CD quality or security process. Scanning should not be considered a complete container security solution because vulnerability databases and application-specific risks can change over time. Organizations should also use trusted base images, minimize unnecessary packages, protect repository access, and establish policies for addressing findings. Automated scanning is valuable because it detects potential issues early in the image lifecycle.<\/span><\/p>\nQuestion 311. What does ECS desired count specify?<\/b><\/h3>\n\n- <\/b> Number of tasks the service should maintain<\/span>
\n<\/span>2.<\/b> Number of IAM roles<\/span>
\n<\/span>3.<\/b> Number of CloudWatch dashboards<\/span>
\n<\/span>4.<\/b> Number of ECR repositories<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Number of tasks the service should maintain<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The ECS desired count specifies how many task instances an ECS service should attempt to keep running. ECS continuously works toward maintaining the desired number, subject to available capacity, scheduling constraints, health status, and deployment behavior. For example, a service with a desired count of five attempts to maintain five healthy task instances under normal conditions. Service Auto Scaling can modify the desired count in response to workload demand, while deployments temporarily adjust task placement as new revisions are introduced. Selecting an appropriate desired count is important for application availability and capacity. It should be considered alongside minimum and maximum deployment percentages, health checks, and scaling policies.<\/span><\/p>\nQuestion 312. What does an ECS container health check evaluate?<\/b><\/h3>\n\n- <\/b> Whether the container is functioning correctly<\/span>
\n<\/span>2.<\/b> Whether an IAM policy is valid<\/span>
\n<\/span>3.<\/b> Whether an S3 bucket is encrypted<\/span>
\n<\/span>4.<\/b> Whether a CloudFormation template is formatted<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Whether the container is functioning correctly<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An ECS container health check runs commands inside the container to determine whether the application is functioning according to the defined health criteria. The check can verify conditions such as whether a process is responding or whether an application endpoint is available. ECS uses the health information when determining whether a task is healthy and whether service scheduling actions may be necessary. Good health checks should test meaningful application readiness rather than simply verifying that a process exists. During deployments, reliable health checks are especially important because they help ECS distinguish a successfully started task from one that is technically running but unable to serve application traffic correctly.<\/span><\/p>\nQuestion 313. Why configure a load balancer health check for ECS tasks?<\/b><\/h3>\n\n- <\/b> To determine whether targets can receive traffic<\/span>
\n<\/span>2.<\/b> To create IAM policies<\/span>
\n<\/span>3.<\/b> To encrypt task definitions<\/span>
\n<\/span>4.<\/b> To store package dependencies<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. To determine whether targets can receive traffic<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Load balancer health checks determine whether registered ECS service targets are healthy enough to receive application traffic. The load balancer periodically sends requests to a configured health-check path or port and evaluates the response according to the configured criteria. Unhealthy targets can be removed from traffic distribution until they recover. This is especially important during rolling and blue\/green deployments because traffic should not be directed to tasks that have started but are not yet ready to serve requests. Health-check configuration should match the application’s actual readiness behavior. An overly strict check can cause healthy tasks to be removed, while an overly permissive check may fail to detect application problems.<\/span><\/p>\nQuestion 314. What does ECS capacity provider strategy influence?<\/b><\/h3>\n\n- <\/b> How tasks use configured capacity providers<\/span>
\n<\/span>2.<\/b> CloudTrail event retention<\/span>
\n<\/span>3.<\/b> KMS key rotation<\/span>
\n<\/span>4.<\/b> CodeArtifact package versions<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. How tasks use configured capacity providers<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An ECS capacity provider strategy determines how a service or task uses its configured capacity providers. Depending on the architecture, capacity providers can represent different compute capacity options, including EC2-based capacity or Fargate-related capacity. A strategy can specify how tasks should be distributed among the available providers according to configured base and weight values. This gives organizations more control over where service capacity is placed and can support flexible infrastructure designs. Capacity provider strategies are particularly useful when teams want to combine different compute options or integrate ECS service scaling with capacity management. Correct configuration helps maintain predictable application capacity while controlling infrastructure usage.<\/span><\/p>\nQuestion 315. What does Lambda reserved concurrency protect against?<\/b><\/h3>\n\n- <\/b> One function consuming excessive account concurrency<\/span>
\n<\/span>2.<\/b> CloudFormation template deletion<\/span>
\n<\/span>3.<\/b>