IAM Access Analyzer<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Pipeline triggers<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodePipeline triggers allow a pipeline execution to start automatically when defined source events occur. This supports continuous integration and delivery by reducing the need for developers or operators to manually start the pipeline after every source change. Depending on the source provider and configuration, triggers can respond to events such as changes to a branch or other supported repository activity. Automated triggering should be combined with appropriate testing and validation stages so that a source change does not automatically reach production without quality controls. Properly designed triggers help create a responsive CI\/CD workflow while still allowing teams to control which repository events should initiate deployments.<\/span><\/p>\nQuestion 242. What does CodePipeline use to pass output between stages?<\/b><\/h3>\n\n- <\/b> Security groups<\/span>
\n<\/span>2.<\/b> Artifacts<\/span>
\n<\/span>3.<\/b> Route tables<\/span>
\n<\/span>4.<\/b> IAM passwords<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Artifacts<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodePipeline uses artifacts to transfer output from one action or stage to another during a pipeline execution. An artifact can contain source files, compiled application packages, deployment templates, configuration files, or other data required by downstream actions. For example, a CodeBuild action can produce a packaged application as an output artifact that a later CodeDeploy or CloudFormation action consumes. Artifact stores provide the underlying storage mechanism, while pipeline action configuration determines how artifacts are produced and consumed. Proper permissions and encryption should protect these artifacts because they may contain application code, deployment information, or other sensitive data used throughout the delivery process.<\/span><\/p>\nQuestion 243. Which CodeBuild setting limits how long a build can run?<\/b><\/h3>\n\n- <\/b> Cache mode<\/span>
\n<\/span>2.<\/b> Report group<\/span>
\n<\/span>3.<\/b> Timeout<\/span>
\n<\/span>4.<\/b> Artifact identifier<\/span><\/li>\n<\/ol>\nCorrect Answer: 3. Timeout<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The CodeBuild timeout setting defines the maximum amount of time a build is allowed to run before CodeBuild terminates it. This protects CI environments from builds that become stuck because of failed commands, unavailable dependencies, infinite loops, or other unexpected conditions. The timeout should be configured according to the normal duration of the project’s build and test process. Setting it too low could terminate legitimate long-running builds, while setting it excessively high could allow failed builds to consume compute resources unnecessarily. Monitoring build duration over time can help teams choose a suitable timeout and identify changes in build performance that may require optimization.<\/span><\/p>\nQuestion 244. What does a CodeBuild report group organize?<\/b><\/h3>\n\n- <\/b> IAM users<\/span>
\n<\/span>2.<\/b> Test reports<\/span>
\n<\/span>3.<\/b> ECS capacity<\/span>
\n<\/span>4.<\/b> S3 buckets<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Test reports<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeBuild report groups organize test and code coverage reports generated during build execution. A build can execute automated tests and produce results in supported report formats, which CodeBuild can associate with a report group. This provides a structured way to collect and review test outcomes across builds rather than treating every report as an isolated file. Report groups are useful in CI\/CD pipelines because they help teams monitor test quality and identify failures before deployment. They can also support longer-term analysis of test results and coverage trends. Properly configured reporting makes automated testing more visible and actionable within a continuous delivery workflow.<\/span><\/p>\nQuestion 245. What does CodeArtifact provide to CI\/CD workflows?<\/b><\/h3>\n\n- <\/b> Managed package repositories<\/span>
\n<\/span>2.<\/b> EC2 instance backups<\/span>
\n<\/span>3.<\/b> DNS routing<\/span>
\n<\/span>4.<\/b> Container orchestration<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Managed package repositories<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS CodeArtifact provides managed repositories for software packages and dependencies used by applications and build systems. It supports common package formats and allows organizations to centralize dependencies rather than relying entirely on public package sources. CodeArtifact can be integrated with CodeBuild and other development tools so that builds retrieve approved package versions from controlled repositories. This can improve dependency management, availability, and security while providing administrators with better visibility into package usage. Organizations can also configure upstream repositories so that packages can be obtained from external sources and cached within CodeArtifact. This makes CodeArtifact useful for creating more controlled and repeatable software supply chains.<\/span><\/p>\nQuestion 246. Why use CodeArtifact upstream repositories?<\/b><\/h3>\n\n- <\/b> To increase Lambda concurrency<\/span>
\n<\/span>2.<\/b> To cache packages from external repositories<\/span>
\n<\/span>3.<\/b> To create ECS clusters<\/span>
\n<\/span>4.<\/b> To configure CloudTrail<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. To cache packages from external repositories<\/b><\/p>\n
Explanation:<\/b><\/p>\n
CodeArtifact upstream repositories allow a CodeArtifact repository to obtain packages from another repository, including supported public package sources. When a requested package is not already available locally, CodeArtifact can retrieve it through the configured upstream relationship and make it available for subsequent use. This creates a caching layer that can reduce repeated dependency downloads from external sources. It can also provide organizations with greater control over dependency access and make builds more consistent. Teams should still establish appropriate package governance and version controls because caching a package does not automatically guarantee that the dependency is safe or suitable for production use.<\/span><\/p>\nQuestion 247. What does an ECR lifecycle policy help control?<\/b><\/h3>\n\n- <\/b> Removal of older or unused images<\/span>
\n<\/span>2.<\/b> Lambda request routing<\/span>
\n<\/span>3.<\/b> CloudFormation stack outputs<\/span>
\n<\/span>4.<\/b> IAM session duration<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Removal of older or unused images<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon ECR lifecycle policies help automatically manage the retention of container images in a repository. Organizations often accumulate many image versions as CI\/CD pipelines build and publish new releases. Keeping every image indefinitely can increase storage costs and make repositories harder to manage. Lifecycle rules can identify images according to criteria such as age or image count and expire images that are no longer required. Teams should design these rules carefully so that images still needed for rollback, audit, or compliance are not removed prematurely. Lifecycle management is therefore an important part of maintaining efficient and manageable container registries in automated deployment environments.<\/span><\/p>\nQuestion 248. What does an ECR repository policy control?<\/b><\/h3>\n\n- <\/b> CloudWatch metric periods<\/span>
\n<\/span>2.<\/b> Access to an ECR repository<\/span>
\n<\/span>3.<\/b> Lambda memory allocation<\/span>
\n<\/span>4.<\/b> CloudFormation drift detection<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Access to an ECR repository<\/b><\/p>\n
Explanation:<\/b><\/p>\n
An Amazon ECR repository policy is a resource-based policy that controls access to a specific ECR repository. It can be used to grant permissions to AWS accounts, IAM principals, or supported AWS services according to the required access model. Repository policies are particularly useful in multi-account environments where a centralized account stores container images while workloads in other accounts need permission to pull them. Permissions should be scoped as narrowly as practical, granting only the repository actions required by the consuming workload. Repository policies work alongside IAM permissions and other AWS security controls, so the complete authorization model should be reviewed when troubleshooting or designing cross-account image access.<\/span><\/p>\nQuestion 249. What does ECS Service Auto Scaling adjust?<\/b><\/h3>\n\n- <\/b> Number of running tasks<\/span>
\n<\/span>2.<\/b> KMS key policies<\/span>
\n<\/span>3.<\/b> CloudFormation parameters<\/span>
\n<\/span>4.<\/b> S3 object versions<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Number of running tasks<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon ECS Service Auto Scaling adjusts the desired number of running tasks for an ECS service based on configured scaling policies and metrics. This allows a service to respond automatically to changing application demand. Scaling policies can use metrics such as CPU utilization, memory utilization, or custom CloudWatch metrics depending on the architecture. Increasing task count can provide additional application capacity during periods of higher demand, while reducing task count can lower resource consumption when demand decreases. Auto Scaling should be configured with suitable minimum and maximum capacity values so that the service remains responsive without consuming unnecessary resources. Health checks and deployment settings should also be considered when scaling production services.<\/span><\/p>\nQuestion 250. Which ECS setting controls how many extra tasks may run during deployment?<\/b><\/h3>\n\n- <\/b> Desired count<\/span>
\n<\/span>2.<\/b> Maximum healthy percentage<\/span>
\n<\/span>3.<\/b> Health check grace period<\/span>
\n<\/span>4.<\/b> Task execution role<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Maximum healthy percentage<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The ECS maximum healthy percentage determines the upper limit on the percentage of the desired number of tasks that can be running during a service deployment, subject to the deployment controller and scheduling behavior. This setting influences how many additional tasks ECS can start while replacing existing tasks. A higher maximum can allow a deployment to launch replacement tasks more quickly, potentially improving deployment speed but temporarily increasing resource usage. It should be considered together with minimum healthy percentage, which controls how many tasks must remain healthy during deployment. These settings allow teams to balance availability, deployment speed, and compute capacity during rolling service updates.<\/span><\/p>\nQuestion 251. What does the ECS minimum healthy percentage influence?<\/b><\/h3>\n\n- <\/b> Number of KMS keys<\/span>
\n<\/span>2.<\/b> Minimum healthy tasks maintained during deployment<\/span>
\n<\/span>3.<\/b> Number of ECR repositories<\/span>
\n<\/span>4.<\/b> CloudTrail retention<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. Minimum healthy tasks maintained during deployment<\/b><\/p>\n
Explanation:<\/b><\/p>\n
The ECS minimum healthy percentage controls the lower limit of healthy tasks that ECS should maintain during a rolling service deployment, expressed as a percentage of the service’s desired count. This helps determine how aggressively ECS can stop old tasks while starting new ones. A higher minimum percentage places greater emphasis on maintaining running capacity during deployment, which can reduce service disruption but may require additional compute resources. A lower percentage can permit more aggressive replacement and potentially reduce deployment duration, but it may temporarily reduce available capacity. The setting should therefore be selected based on application availability requirements and the amount of spare capacity available.<\/span><\/p>\nQuestion 252. Which ECS deployment controller supports CodeDeploy blue\/green deployments?<\/b><\/h3>\n\n- <\/b> CODE_DEPLOY<\/span>
\n<\/span>2.<\/b> EXTERNAL_ONLY<\/span>
\n<\/span>3.<\/b> Route53<\/span>
\n<\/span>4.<\/b> CloudFormation<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. CODE_DEPLOY<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Amazon ECS supports deployment controllers including the ECS rolling deployment controller and the CODE_DEPLOY controller. The CODE_DEPLOY controller enables ECS services to use AWS CodeDeploy for blue\/green deployment workflows. In a blue\/green deployment, a new task set can be launched separately from the currently running environment, allowing traffic to be shifted under controlled conditions. This approach can support validation, gradual traffic movement, and automated rollback when integrated with appropriate monitoring. CodeDeploy can coordinate traffic shifting through the configured load balancer and deployment strategy. This provides more controlled release management than simply replacing tasks within a traditional rolling deployment.<\/span><\/p>\nQuestion 253. What does Lambda alias routing enable?<\/b><\/h3>\n\n- <\/b> Sending traffic between function versions<\/span>
\n<\/span>2.<\/b> Creating ECR repositories<\/span>
\n<\/span>3.<\/b> Encrypting CloudTrail logs<\/span>
\n<\/span>4.<\/b> Scaling EC2 instances<\/span><\/li>\n<\/ol>\nCorrect Answer: 1. Sending traffic between function versions<\/b><\/p>\n
Explanation:<\/b><\/p>\n
AWS Lambda aliases provide stable names that can point to specific published function versions. An alias can also use weighted routing to distribute a portion of invocation traffic between two versions. This capability supports controlled deployment strategies such as canary releases, where a small percentage of traffic is initially sent to a new version while the majority continues using the existing version. Teams can monitor errors, latency, and other metrics before increasing traffic to the new version. Aliases also help applications avoid directly referencing changing version numbers. When combined with automated alarms and deployment tooling, Lambda alias routing supports safer and more controlled function releases.<\/span><\/p>\nQuestion 254. Why publish a new Lambda function version during deployment?<\/b><\/h3>\n\n- <\/b> To modify an immutable published version<\/span>
\n<\/span>2.<\/b> To create a stable, immutable code snapshot<\/span>
\n<\/span>3.<\/b> To remove all aliases<\/span>
\n<\/span>4.<\/b> To disable CloudWatch metrics<\/span><\/li>\n<\/ol>\nCorrect Answer: 2. To create a stable, immutable code snapshot<\/b><\/p>\n
Explanation:<\/b><\/p>\n
Publishing a Lambda function version creates an immutable snapshot of the function code and configuration that can be referenced independently from the continuously changing unpublished <\/span>$LATEST<\/span> version. This is important for controlled deployments because an alias can point to a specific published version and remain stable while new code is prepared. Deployment systems can then shift traffic between published versions instead of directing production traffic to changing development code. Using versions also makes rollback easier because a previous known-good version can be selected again. This versioning model works particularly well with aliases, weighted routing, canary deployments, and automated monitoring.<\/span><\/p>\nQuestion 255. What does AppConfig’s hosted configuration store provide?<\/b><\/h3>\n\n- <\/b> A managed location for configuration data<\/span>
\n<\/span>2.<\/b> A replacement for IAM<\/span>
\n<\/span>3.<\/b>