View Full Amazon AWS Certified DevOps Engineer – Professional DOP-C02 Exam Dumps and Practice Test Dumps

 

Question 121. What pauses a CodePipeline stage for human review?

1. CodeBuild
   2. Manual approval
   3. CloudTrail
   4. CodeArtifact

Correct Answer: 2. Manual approval

Explanation:

A manual approval action pauses a CodePipeline stage until an authorized person reviews the change and approves or rejects it. This is useful when organizations require human verification before sensitive actions, such as production deployments, database changes, or infrastructure modifications. The approval can include a notification message and additional information that helps the reviewer understand what is being released. If the approval is granted, the pipeline continues to the next action. If it is rejected or times out, the pipeline does not proceed normally. Manual approvals therefore provide a controlled checkpoint within an automated delivery process.

Question 122. What happens when a CodePipeline action fails?

1. The failed action is normally marked unsuccessful
   2. The pipeline automatically deletes its artifacts
   3. All AWS resources are terminated
   4. The source repository is removed

Correct Answer: 1. The failed action is normally marked unsuccessful

Explanation:

When an action in CodePipeline fails, CodePipeline records the action as unsuccessful and prevents dependent downstream actions from proceeding normally. The failure information can be reviewed through the pipeline console or APIs to identify the service and operation that caused the problem. Teams can then correct the issue and retry the appropriate action or execution. The behavior depends on the action and pipeline configuration, but a failed action does not normally cause AWS resources or source repositories to be deleted. Understanding failure behavior is important when designing reliable pipelines that can recover from build, test, or deployment problems.

Question 123. Which CodeDeploy configuration updates all targets at once?

1. OneAtATime
   2. HalfAtATime
   3. AllAtOnce
   4. Linear

Correct Answer: 3. AllAtOnce

Explanation:

The CodeDeploy AllAtOnce deployment configuration attempts to deploy the new application revision to all targeted instances simultaneously. This approach can make deployments faster because the deployment does not intentionally preserve a portion of the fleet running the previous version. However, it also means that a deployment problem can affect a larger portion of the application fleet at the same time. Other deployment configurations, such as OneAtATime and HalfAtATime, control how many instances receive the revision during the deployment. The appropriate configuration depends on availability requirements, deployment speed, and the organization’s tolerance for deployment risk.

Question 124. What does OneAtATime mean in CodeDeploy?

1. All instances deploy simultaneously
   2. One instance is updated at a time
   3. Half the instances are updated
   4. Only Lambda functions are deployed

Correct Answer: 2. One instance is updated at a time

Explanation:

The OneAtATime deployment configuration updates instances individually during a CodeDeploy deployment. Instead of changing the entire fleet simultaneously, CodeDeploy processes one target at a time according to the deployment group’s configuration. This can help maintain availability because other instances may continue serving the previous application version while the current instance is being updated and validated. The trade-off is deployment speed because a large fleet can take considerably longer to update. This configuration is useful when gradual deployment is preferred and maintaining service availability during the rollout is an important requirement.

Question 125. What does HalfAtATime control in CodeDeploy?

1. The deployment batch size
   2. The S3 bucket size
   3. The Lambda memory allocation
   4. The CloudFormation stack size

Correct Answer: 1. The deployment batch size

Explanation:

The HalfAtATime deployment configuration controls how many instances CodeDeploy updates during each deployment batch. Approximately half of the targeted instances are updated during a deployment operation while the remaining instances can continue running the previous revision. This provides a balance between deployment speed and service availability. Compared with AllAtOnce, fewer instances are changed simultaneously, reducing the immediate scope of a potential deployment problem. Compared with OneAtATime, the deployment can complete more quickly because multiple instances are processed together. Selecting a deployment configuration should therefore consider both operational availability and acceptable deployment duration.

Question 126. What can automatically stop a failed CodeDeploy deployment?

1. Deployment alarms
   2. Route 53
   3. CodeArtifact
   4. S3 versioning

Correct Answer: 4. Deployment alarms

Explanation:

CodeDeploy can monitor CloudWatch alarms during a deployment and respond when configured alarm conditions enter an alarm state. This allows deployment health to be connected to application or infrastructure metrics such as error rates, latency, or unhealthy host counts. If the configured deployment alarm behavior detects a problem, CodeDeploy can stop or fail the deployment according to its configuration. This provides an automated safety mechanism that does not depend entirely on a person noticing a problem. Combining deployment alarms with rollback settings can help reduce the time required to recover from an unhealthy application release.

Question 127. What identifies EC2 instances for a CodeDeploy deployment group?

1. DNS names
   2. EC2 tags
   3. CloudWatch dashboards
   4. S3 object names

Correct Answer: 2. EC2 tags

Explanation:

CodeDeploy deployment groups can identify EC2 instances using tags. A deployment group can specify tag keys and values that determine which instances belong to the deployment target set. This provides a flexible way to organize instances by application, environment, role, or other characteristics. For example, instances tagged with an environment value such as production can be targeted separately from development instances. Tag-based targeting reduces the need to maintain individual instance identifiers in deployment configurations and makes deployments easier to manage as the environment changes.

Question 128. What defines an EC2 CodeDeploy deployment target set?

1. Deployment group
   2. Buildspec
   3. Artifact
   4. Report group

Correct Answer: 1. Deployment group

Explanation:

A CodeDeploy deployment group defines the collection of deployment settings and targets associated with an application deployment. For EC2 or on-premises deployments, a deployment group can specify target instances through tags or other supported mechanisms, deployment configuration, load balancer settings, alarms, and rollback-related behavior. This allows different environments to use different deployment rules even when they belong to the same CodeDeploy application. For example, a production deployment group can use stricter monitoring and availability settings than a development deployment group. Deployment groups therefore provide the operational context in which a CodeDeploy revision is released.

Question 129. Which CodeDeploy hook runs before the application files are installed?

1. ValidateService
   2. ApplicationStart
   3. BeforeInstall
   4. AfterInstall

Correct Answer: 3. BeforeInstall

Explanation:

The BeforeInstall lifecycle hook runs before the application revision is installed on the target instance. It can be used to perform preparation tasks required before the new files are copied into place. For example, a script might stop an existing process, create a backup, prepare directories, or perform other environment preparation activities. CodeDeploy lifecycle hooks provide controlled points where custom scripts can execute during the deployment sequence. Using the appropriate hook ensures that each operation occurs at the intended stage. BeforeInstall is therefore specifically associated with preparation before installation of the new application revision.

Question 130. Which hook can verify an application after startup?

1. BeforeInstall
   2. DownloadBundle
   3. ApplicationStop
   4. ValidateService

Correct Answer: 4. ValidateService

Explanation:

The ValidateService lifecycle hook is commonly used to perform final validation after an application has been started. A script executed during this hook can check whether the service is responding correctly, whether an endpoint is available, or whether other basic application conditions are satisfied. If validation fails, CodeDeploy can treat the deployment as unsuccessful depending on the deployment configuration and lifecycle behavior. This provides an important verification point because a deployment can technically complete file installation while the application itself remains unhealthy. Post-deployment validation helps identify such problems before the release is considered successful.

Question 131. What limits the maximum duration of a CodeBuild build?

1. Build timeout
   2. S3 lifecycle policy
   3. IAM session duration
   4. ECR retention policy

Correct Answer: 1. Build timeout

Explanation:

AWS CodeBuild provides a build timeout that limits how long a build is allowed to run. If the build exceeds the configured timeout, CodeBuild stops the build and reports it as unsuccessful. This prevents stalled or unexpectedly long-running builds from consuming compute resources indefinitely. Timeout values should be selected according to the normal duration of the project’s compilation, testing, packaging, and related tasks. A timeout that is too short may terminate legitimate builds, while an excessively long value can delay detection of stuck processes. Monitoring historical build durations can help teams choose a suitable timeout.

Question 132. What determines the compute resources available to CodeBuild?

1. CodePipeline stage
   2. CodeBuild compute type
   3. CloudTrail trail
   4. IAM policy

Correct Answer: 2. CodeBuild compute type

Explanation:

The CodeBuild compute type determines the class of compute resources allocated to a build environment. Different compute configurations provide different levels of CPU, memory, storage, and other resources. Selecting an appropriate compute type is important because resource-intensive builds may require more capacity than small compilation or testing workloads. Using unnecessarily large resources can increase costs without providing meaningful benefits. Teams should consider build duration, dependency installation, compilation requirements, test execution, and packaging workloads when selecting the environment. The compute type can be configured as part of the CodeBuild project environment settings.

Question 133. What enables CodeBuild to access resources in a VPC?

1. VPC configuration
   2. CloudFront distribution
   3. Route 53 hosted zone
   4. CodeArtifact domain

Correct Answer: 1. VPC configuration

Explanation:

CodeBuild projects can be configured to run inside an Amazon VPC so that builds can communicate with private resources that are not directly accessible from the public internet. VPC configuration can specify the required subnets and security groups. This is useful when a build needs access to private databases, internal services, private endpoints, or other resources protected within the organization’s network. Network configuration must be designed carefully because the build environment may also need internet access for downloading dependencies. Appropriate routing, NAT configuration, security groups, and endpoint services may therefore be required.

Question 134. Where can CodeBuild store test results?

1. IAM policies
   2. Report groups
   3. CloudFormation stacks
   4. Deployment groups

Correct Answer: 2. Report groups

Explanation:

AWS CodeBuild report groups provide a mechanism for storing and organizing test reports generated by builds. A build can execute automated tests and produce results in supported report formats, which CodeBuild can associate with a report group. These reports help development and operations teams review test outcomes and track the results of automated validation. Report groups are separate from ordinary build artifacts because they are intended specifically for test and code-quality reporting. Integrating test reporting into the CI/CD process allows failed tests to be identified before an application is promoted to later deployment stages.

Question 135. How can CodeBuild artifacts be encrypted?

1. AWS KMS
   2. Amazon Route 53
   3. AWS WAF
   4. CloudWatch Logs

Correct Answer: 1. AWS KMS

Explanation:

AWS Key Management Service can be used to protect CodeBuild artifacts with encryption keys. When build artifacts are stored in supported AWS storage services, encryption helps protect the generated files from unauthorized access. KMS provides centralized control over encryption keys, including permissions governing which AWS principals can use the keys. In a CI/CD environment, this can be important because artifacts may contain compiled applications, deployment packages, configuration files, or other sensitive information. IAM permissions and KMS key policies must be configured consistently so that authorized pipeline components can encrypt and retrieve artifacts without granting unnecessary access.

Question 136. What contains repositories within a CodeArtifact domain?

1. Deployment groups
   2. Domains contain repositories
   3. CloudFormation stacks
   4. ECS clusters

Correct Answer: 2. Domains contain repositories

Explanation:

AWS CodeArtifact uses domains as organizational containers for repositories and package-management resources. A domain can contain multiple repositories, allowing an organization to structure packages according to development teams, environments, applications, or other logical requirements. Repositories can also be connected through upstream relationships so that packages can be obtained from other repositories or supported external sources. The domain provides a higher-level boundary for package management and can help organizations manage encryption and access consistently. Understanding the domain-and-repository hierarchy is important when designing CodeArtifact for multiple teams or accounts.

Question 137. What automatically scans ECR images when configured?

1. Scan on push
   2. StackSets
   3. CodePipeline approval
   4. CloudFormation drift detection

Correct Answer: 1. Scan on push

Explanation:

Amazon ECR supports image scanning that can evaluate container images for known software vulnerabilities. When scan-on-push is configured, an image is scanned when it is pushed to the repository. This allows vulnerability assessment to become part of the container publishing workflow rather than relying entirely on a later manual scan. Organizations can use scan findings to determine whether an image should continue through the deployment pipeline. ECR also provides enhanced scanning capabilities through Amazon Inspector for supported scenarios. Automated scanning is particularly useful in CI/CD environments where many container images may be built and published regularly.

Question 138. What identifies a specific ECR image content immutably?

1. Repository name
   2. Tag
   3. Image digest
   4. Registry alias

Correct Answer: 3. Image digest

Explanation:

An Amazon ECR image digest is a content-based identifier associated with a specific container image. Unlike a mutable tag, which can potentially be moved to another image, the digest represents the image content itself. This makes digests valuable when a deployment process needs to identify exactly which image version should run in an environment. CI/CD systems can record the digest used for a deployment, improving traceability and reproducibility. Image tags remain useful for human-friendly naming, but deployment systems that require strong version identification can reference the image by digest.

Question 139. What automatically adjusts ECS service task capacity?

1. ECS Service Auto Scaling
   2. CloudTrail
   3. CodeArtifact
   4. CloudFormation termination protection

Correct Answer: 1. ECS Service Auto Scaling

Explanation:

Amazon ECS Service Auto Scaling can automatically adjust the desired number of tasks for an ECS service based on configured scaling policies and metrics. For example, scaling can respond to CPU utilization, memory utilization, or other supported application indicators. When demand increases, the service can increase its desired task count, while lower demand can allow capacity to scale down. This helps applications respond to changing workloads without requiring operators to manually modify the task count. Effective scaling requires appropriate minimum and maximum capacity settings, scaling targets, and metrics that accurately represent the application’s workload.

Question 140. What defines how many ECS tasks can run during deployment?

1. CodeArtifact repository
   2. Deployment minimum and maximum percentages
   3. IAM permission boundary
   4. CloudTrail event selector

Correct Answer: 2. Deployment minimum and maximum percentages

Explanation:

Amazon ECS deployment configuration uses minimum healthy percent and maximum percent settings to control how many tasks can remain running and how many tasks may run during a service deployment. The minimum healthy percentage helps determine the minimum amount of desired capacity that should remain available while old tasks are replaced. The maximum percentage controls how much additional capacity can temporarily run during the deployment. These settings affect both deployment speed and resource usage. Choosing suitable values is important because overly restrictive settings may slow deployments, while higher temporary capacity can accelerate replacement at the cost of additional compute resources.