Inspector<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. CodePipeline<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS CodePipeline is designed to automate the stages involved in releasing application changes, including source retrieval, building, testing, and deployment. A pipeline can connect services such as CodeCommit, Amazon S3, CodeBuild, CodeDeploy, and other supported actions into a controlled workflow. When a configured source change is detected, CodePipeline can automatically move artifacts through the defined stages. This reduces the need for manually coordinating releases and provides a repeatable delivery process. Teams can also add approvals, testing actions, deployment actions, and failure handling to control how changes progress through the pipeline.<\/span><\/p>\nQuestion 102. What defines an individual step in CodePipeline?<\/b><\/h3>\n\n- <\/b> Repository<\/span>
\n<\/span>2.<\/b> Artifact<\/span>
\n<\/span>3.<\/b> Action<\/span>
\n<\/span>4.<\/b> Environment<\/span><\/li>\n<\/ol>\nCorrect Answer: 3. Action<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An action represents an individual task performed within a CodePipeline stage. Examples include retrieving source code, running a CodeBuild project, deploying through CodeDeploy, invoking a Lambda function, or performing another supported operation. Actions are organized inside stages, and a stage can contain one or more actions that execute sequentially or in parallel depending on the configuration. Understanding the distinction between stages and actions is important when designing CI\/CD workflows. A stage represents a logical phase of the pipeline, while actions perform the specific operations required during that phase.<\/span><\/p>\nQuestion 103. Where can CodePipeline store artifacts?<\/b><\/h3>\n\n- <\/b> Amazon S3<\/span>
\n<\/span>2.<\/b> Amazon Route 53<\/span>
\n<\/span>3.<\/b> Amazon CloudFront<\/span>
\n<\/span>4.<\/b> Amazon DynamoDB<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Amazon S3<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon S3 is commonly used by CodePipeline as an artifact store for intermediate files exchanged between pipeline stages. Build outputs, packaged application files, and other artifacts can be stored in an S3 bucket and passed from one action to another. Using S3 provides durable storage and allows different pipeline services to access artifacts without requiring direct communication between every stage. Organizations can also apply security controls such as bucket policies, encryption, versioning, and access permissions. Proper artifact-store configuration is therefore an important part of designing a secure and reliable CI\/CD pipeline.<\/span><\/p>\nQuestion 104. What does CodeBuild produce after a successful build?<\/b><\/h3>\n\n- <\/b> IAM policies<\/span>
\n<\/span>2.<\/b> CloudWatch alarms<\/span>
\n<\/span>3.<\/b> Deployment groups<\/span>
\n<\/span>4.<\/b> Build artifacts<\/span><\/li>\n<\/ol>\nCorrect Answer: 4. Build artifacts<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS CodeBuild can produce build artifacts as output from a successful build process. These artifacts may include compiled binaries, packaged application files, deployment packages, configuration files, or other files required by later stages of a release workflow. The buildspec file determines which files or directories should be included as output. Artifacts can then be stored in Amazon S3 or passed to another service through CodePipeline. Separating source files from generated artifacts helps create a repeatable release process because downstream deployment stages can consume a defined build output rather than rebuilding the application independently.<\/span><\/p>\nQuestion 105. Where can CodeBuild obtain sensitive environment values?<\/b><\/h3>\n\n- <\/b> Amazon Route 53<\/span>
\n<\/span>2.<\/b> AWS Systems Manager Parameter Store<\/span>
\n<\/span>3.<\/b> Amazon CloudFront<\/span>
\n<\/span>4.<\/b> AWS Trusted Advisor<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. AWS Systems Manager Parameter Store<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeBuild can retrieve configuration values and sensitive parameters from AWS Systems Manager Parameter Store instead of placing those values directly inside source code or buildspec files. Parameter Store supports storing configuration data and secure string parameters, allowing access to be controlled through IAM permissions. CodeBuild can reference these values as environment variables during a build. This approach helps reduce the risk of accidentally exposing credentials or configuration information in source repositories. For secrets that require dedicated secret-management capabilities, AWS Secrets Manager can also be integrated into the build environment.<\/span><\/p>\nQuestion 106. Which file commonly defines CodeBuild commands?<\/b><\/h3>\n\n- <\/b> buildspec.yml<\/span>
\n<\/span>2.<\/b> appspec.yml<\/span>
\n<\/span>3.<\/b> template.json<\/span>
\n<\/span>4.<\/b> policy.xml<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. buildspec.yml<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The buildspec file defines how AWS CodeBuild should perform a build. It can specify phases such as installation, pre-build, build, and post-build, along with commands that should run during those phases. It can also define artifacts, environment variables, reports, and other build-related settings. By keeping build instructions in a version-controlled buildspec file, teams can make the build process repeatable and consistent across environments. CodeBuild reads the buildspec configuration when a build starts and executes the specified commands according to the defined sequence.<\/span><\/p>\nQuestion 107. What can CodeArtifact cache from an upstream repository?<\/b><\/h3>\n\n- <\/b> IAM roles<\/span>
\n<\/span>2.<\/b> CloudFormation stacks<\/span>
\n<\/span>3.<\/b> Software packages<\/span>
\n<\/span>4.<\/b> EC2 instances<\/span><\/li>\n<\/ol>\nCorrect Answer: 3. Software packages<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS CodeArtifact can use upstream repositories to obtain software packages that are not already available in a local repository. When a requested package is retrieved through an upstream connection, CodeArtifact can retain the package in the domain’s repository so that subsequent requests can be served from the managed repository. This reduces repeated external downloads and provides organizations with greater control over dependency consumption. CodeArtifact supports package formats used by several popular development ecosystems. Centralizing dependencies can also improve build consistency because development and CI\/CD environments can consume packages through a controlled organizational repository.<\/span><\/p>\nQuestion 108. What controls access to a CodeArtifact repository?<\/b><\/h3>\n\n- <\/b> IAM permissions<\/span>
\n<\/span>2.<\/b> Route 53 records<\/span>
\n<\/span>3.<\/b> CloudWatch dashboards<\/span>
\n<\/span>4.<\/b> ECR lifecycle rules<\/span><\/li>\n<\/ol>\nCorrect Answer: 4. IAM permissions<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS Identity and Access Management controls who can perform operations against CodeArtifact resources. IAM policies can allow or deny actions such as reading packages, publishing packages, obtaining authorization tokens, or managing repositories and domains. Permissions should follow the principle of least privilege so that developers, build systems, and deployment services receive only the access they actually require. CodeArtifact repository resource policies can also be used for cross-account access scenarios. Correctly designing these permissions is important because package repositories can contain proprietary software, internal libraries, and dependencies that should not be broadly accessible.<\/span><\/p>\nQuestion 109. What prevents overwriting an existing ECR image tag?<\/b><\/h3>\n\n- <\/b> CloudTrail<\/span>
\n<\/span>2.<\/b> ECR tag immutability<\/span>
\n<\/span>3.<\/b> CloudFormation<\/span>
\n<\/span>4.<\/b> AWS Config<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. ECR tag immutability<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon Elastic Container Registry supports tag immutability to prevent an existing image tag from being reused for a different image. This is valuable in CI\/CD environments because tags such as release identifiers can otherwise be moved to another image, making it difficult to determine exactly which image was deployed. With immutable tags enabled, an existing tag cannot simply be overwritten with a new image. Teams can therefore associate a tag with a specific image more reliably. Image digests provide an even stronger immutable identifier because the digest uniquely represents the image content.<\/span><\/p>\nQuestion 110. What controls repository-level ECR access?<\/b><\/h3>\n\n- <\/b> CloudWatch Logs<\/span>
\n<\/span>2.<\/b> AWS Config<\/span>
\n<\/span>3.<\/b> ECR repository policy<\/span>
\n<\/span>4.<\/b> CodeBuild report group<\/span><\/li>\n<\/ol>\nCorrect Answer: 3. ECR repository policy<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An Amazon ECR repository policy controls access to a particular container image repository. Repository policies are especially useful when access must be granted to principals in another AWS account or when repository-specific permissions need to be defined. IAM policies can also control ECR operations, so both identity-based and resource-based authorization may be relevant depending on the scenario. A well-designed repository policy should restrict access to the required principals and actions. For example, a deployment role may need permission to pull images while a CI role may require permissions to push new images.<\/span><\/p>\nQuestion 111. What determines how many ECS tasks a service should maintain?<\/b><\/h3>\n\n- <\/b> Desired task count<\/span>
\n<\/span>2.<\/b> Route 53 health checks<\/span>
\n<\/span>3.<\/b> CloudTrail events<\/span>
\n<\/span>4.<\/b> S3 lifecycle rules<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Desired task count<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The desired task count of an Amazon ECS service specifies how many task instances the service attempts to keep running. ECS continuously works toward maintaining that desired number by starting replacement tasks when appropriate and stopping excess tasks during service changes. Desired count can be configured manually or adjusted through service auto scaling. Maintaining an appropriate desired count is important for application availability and capacity. During deployments, ECS also uses deployment configuration settings to determine how many tasks can run during the transition between old and new task revisions.<\/span><\/p>\nQuestion 112. What checks whether an ECS task is ready for traffic?<\/b><\/h3>\n\n- <\/b> CloudTrail<\/span>
\n<\/span>2.<\/b> IAM Access Analyzer<\/span>
\n<\/span>3.<\/b> Load balancer health check<\/span>
\n<\/span>4.<\/b> CodeArtifact<\/span><\/li>\n<\/ol>\nCorrect Answer: 4. Load balancer health check<\/b><\/p>\n
Explanation:<\/b><\/p>\n
When an ECS service is integrated with an Elastic Load Balancing target group, load balancer health checks can determine whether registered tasks are healthy enough to receive traffic. The health check sends requests to the configured path and evaluates the response according to the target group’s settings. If a task repeatedly fails the health check, the load balancer can stop routing traffic to that target. ECS deployment behavior can also use target health information when replacing tasks. Proper health-check configuration helps prevent traffic from being sent to containers that have started but are not yet ready to serve requests correctly.<\/span><\/p>\nQuestion 113. What controls ECS blue\/green traffic shifting?<\/b><\/h3>\n\n- <\/b> AWS Config<\/span>
\n<\/span>2.<\/b> CodeDeploy<\/span>
\n<\/span>3.<\/b> Amazon Inspector<\/span>
\n<\/span>4.<\/b> AWS Backup<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. CodeDeploy<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS CodeDeploy can manage blue\/green deployments for Amazon ECS services by coordinating traffic movement between the existing task set and the replacement task set. This approach allows the new application version to be deployed separately before production traffic is shifted to it. Depending on the deployment configuration, traffic can be moved in stages or all at once. During the transition, health checks and deployment monitoring can help identify problems. If the deployment fails according to configured conditions, the previous environment can remain available while the deployment is stopped or rolled back.<\/span><\/p>\nQuestion 114. What happens to the previous ECS environment in blue\/green deployment?<\/b><\/h3>\n\n- <\/b> It becomes an IAM role<\/span>
\n<\/span>2.<\/b> It is always deleted immediately<\/span>
\n<\/span>3.<\/b> It becomes an S3 bucket<\/span>
\n<\/span>4.<\/b> It can remain available during deployment<\/span><\/li>\n<\/ol>\nCorrect Answer: 4. It can remain available during deployment<\/b><\/p>\n
Explanation:<\/b><\/p>\n
In an ECS blue\/green deployment, the existing environment can remain active while the replacement environment is created and validated. This separation provides a useful safety mechanism because production traffic can initially continue using the previous task set while the new version is tested. After successful validation and traffic shifting, the previous environment can eventually be terminated according to the deployment configuration. Keeping the old environment available during the transition supports faster recovery because the deployment process does not require rebuilding the previous version if a problem is detected.<\/span><\/p>\nQuestion 115. What reduces cold-start impact for Lambda functions?<\/b><\/h3>\n\n- <\/b> Provisioned concurrency<\/span>
\n<\/span>2.<\/b> CloudTrail<\/span>
\n<\/span>3.<\/b> S3 versioning<\/span>