Examkin

Deployment

376 questions

All types376Multiple choice191Multiple select171Ordering14
Question 141Question →

A developer is configuring an Amazon ECS task definition to deploy a containerized application to AWS Fargate. The application needs a database password at startup. The password is saved as a secret in AWS Secrets Manager. The developer wants the Amazon ECS container agent to automatically retrieve the secret value and inject it as an environment variable into the container. Which configuration is required to achieve this?

Show answer & explanation

Answer: Associate an IAM policy that allows the secretsmanager:GetSecretValue action with the ECS task execution role, and reference the secret in the secrets section of the container definition.

Answer

Associate an IAM policy that allows the secretsmanager:GetSecretValue action with the ECS task execution role, and reference the secret in the secrets section of the container definition.
The correct option is correct because the Amazon ECS container agent is responsible for calling AWS Secrets Manager to retrieve the secret value before starting the container. To do this, the agent uses the permissions defined in the ECS task execution role. The developer must then map the secret to an environment variable inside the container definition's secrets section.

Step-by-Step Solution

1
Identify the role responsible for tasks executed by the ECS container agent.
The ECS task execution role is responsible for actions the ECS agent performs, such as pulling container images and fetching secrets.
Since the container agent is retrieving the secret and injecting it during task startup (rather than the application code itself calling Secrets Manager), the execution role must have the permission.
2
Determine the proper task definition section for injecting secrets as environment variables.
The secrets section of the container definition is used to map a secret source (like Secrets Manager) to an environment variable.
The standard environment block is only for plaintext environment variables, whereas the secrets block allows referencing secret ARNs for automatic resolution.

Key Concept

ECS Task Role vs. ECS Task Execution Role for Secret Injection
Question 142Question →

A developer is managing a web application infrastructure deployed via an AWS CloudFormation stack. The stack includes an Auto Scaling group of Amazon EC2 instances, which are configured using AWS::CloudFormation::Init metadata and helper scripts to install packages and start the application. During a stack update, the update fails and rolls back because the new instances do not signal success to the stack within the specified timeout. Additionally, the developer suspects that team members might have made manual configuration changes directly on the production EC2 instances. Which two actions should the developer take to troubleshoot the deployment failure and address the configuration drift? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Run drift detection on the CloudFormation stack to identify any out-of-band modifications made to the stack resources.; Inspect the /var/log/cfn-init.log and /var/log/cloud-init-output.log files on the EC2 instances to determine why the helper scripts failed to execute or signal success.

Answer

Running drift detection on the CloudFormation stack and inspecting the /var/log/cfn-init.log and /var/log/cloud-init-output.log files on the EC2 instances.
To troubleshoot a rolling deployment failure where the EC2 instances fail to signal success, the developer must inspect the helper script logs. The /var/log/cfn-init.log file captures the output and status of the cfn-init metadata execution, while /var/log/cloud-init-output.log captures the standard output and error of the user data script execution. Additionally, running drift detection is the standard way to identify out-of-band resource modifications without manual inspection or disrupting the stack.

Step-by-Step Solution

1
Diagnose the rollback by connecting to the EC2 instances and reviewing logs.
Checking /var/log/cfn-init.log and /var/log/cloud-init-output.log reveals the specific step where the helper scripts failed or why cfn-signal was not invoked.
When a stack update rolls back due to a timeout, it means the stack did not receive a success signal from the instances within the WaitCondition timeout, and these log files contain the helper script execution history.
2
Audit the stack for drift by executing the drift detection tool on the CloudFormation stack.
A drift status report identifying which resources have been modified outside of CloudFormation, including the specific properties that differ from the template.
This determines if manual changes made by team members are causing configuration differences, which must be resolved to align the infrastructure with the template.

Key Concept

Troubleshooting CloudFormation helper scripts and managing stack drift.
Question 143Question →

A developer is preparing to deploy a Node.js web application to an AWS Elastic Beanstalk environment. The deployment has two new requirements: it must securely retrieve a database password that is configured to rotate automatically, and it must install a custom security daemon package on the underlying Amazon EC2 instances during environment provisioning.

Which two actions should the developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager, and retrieve the secret programmatically in the application code.; Create a configuration file containing the package installation instructions and place it inside a directory named `.ebextensions` at the root of the application source bundle.

Answer

Store the database password in AWS Secrets Manager to be retrieved programmatically by the application, and place the configuration file inside the `.ebextensions` directory at the root of the application source bundle.
To securely manage a database password that needs automatic rotation, AWS Secrets Manager is the correct choice because it natively integrates with rotation schedules. To customize the EC2 instances (such as installing packages), configuration files must be stored in the `.ebextensions` folder located at the root of the application source bundle. Therefore, storing the password in Secrets Manager and placing the configuration file in `.ebextensions` at the root are the correct actions.

Step-by-Step Solution

1
Evaluate secret storage and rotation requirements.
Identify AWS Secrets Manager as the appropriate service because it natively supports automatic rotation, unlike Systems Manager Parameter Store.
Secrets Manager provides out-of-the-box secret rotation using AWS Lambda.
2
Evaluate how to customize EC2 instances with packages during deployment.
Determine that an Elastic Beanstalk configuration file (.config) must be placed in a directory named `.ebextensions`.
Elastic Beanstalk searches for configuration files specifically in this folder to apply customizations.
3
Verify directory location and naming constraints.
Confirm that the `.ebextensions` directory must be at the root level of the application source bundle with a leading period.
Incorrect naming (like `ebextensions`) or incorrect placement (like inside a `/src` directory) will cause Elastic Beanstalk to ignore the configurations.

Key Concept

AWS Elastic Beanstalk environment customization using `.ebextensions` and secure secret management with Secrets Manager vs Parameter Store.
Estimated Time:1m 30s
Question 144Question →

A developer is configuring a release pipeline in AWS CodePipeline. The developer wants to pause the pipeline before the deployment stage to allow a team lead to review the changes, and wants the team lead to receive an email notification when the pipeline is paused. Which configuration should the developer use to meet these requirements?

Show answer & explanation

Answer: Add a Manual Approval action to the pipeline before the deployment stage, and configure it with an Amazon Simple Notification Service (Amazon SNS) topic ARN.

Answer

Add a Manual Approval action to the pipeline before the deployment stage, and configure it with an Amazon Simple Notification Service (Amazon SNS) topic ARN.
The correct option adds a Manual Approval action directly into the pipeline stage before the deployment stage. By associating the action with an Amazon SNS topic ARN, CodePipeline automatically sends a notification to the subscribed email address of the team lead when the action runs, pausing the pipeline until the approval is granted or rejected.

Step-by-Step Solution

1
Identify the requirement to pause the pipeline and notify a reviewer.
The developer needs a mechanism to halt pipeline execution and send an email notification.
AWS CodePipeline provides a native action category called 'Approval' to pause the pipeline.
2
Select the correct action type and configuration details.
A Manual Approval action is added to a pipeline stage. It can be configured with an Amazon SNS topic.
The SNS topic publishes messages to its subscribers (such as email endpoints) to alert reviewers that an approval is pending.

Key Concept

AWS CodePipeline Manual Approval Actions
Estimated Time:45s
Question 145Question →

A developer is configuring a cross-account continuous delivery pipeline using AWS CodePipeline. The pipeline is created in a Tooling account (111111111111111111111111) and must deploy a serverless application to a Production account (222222222222222222222222) using AWS CloudFormation. The pipeline's deploy action is configured to assume an IAM role (`ProdDeployRole`) in the Production account. During execution, the pipeline fails at the CloudFormation deploy stage with an error stating that the pipeline service role is not authorized to perform `sts:AssumeRole` on `ProdDeployRole`.

Which action should the developer take to resolve this issue?

Show answer & explanation

Answer: Configure the trust policy of the target deployment role in the Production account to trust the CodePipeline service role ARN from the Tooling account, and grant the CodePipeline service role in the Tooling account permissions to perform assume role actions on the target role.

Answer

Configure the trust policy of the target deployment role in the Production account to trust the CodePipeline service role ARN from the Tooling account, and grant the CodePipeline service role in the Tooling account permissions to perform assume role actions on the target role.
For cross-account deployments in AWS CodePipeline, a role must be assumed in the destination account. This requires two configurations: the trust policy of the target role in the destination account must trust the pipeline's service role, and the pipeline's service role must have the permission to assume the target role. This establishes the necessary cross-account delegation.

Step-by-Step Solution

1
Inspect the trust relationship of the deployment role (ProdDeployRole) in the destination Production account.
Identify that the trust policy must explicitly allow the 'sts:AssumeRole' action for the IAM service role ARN of AWS CodePipeline in the source Tooling account.
Without this trust relationship, IAM prevents external entities (like the Tooling account service role) from assuming the role.
2
Examine the identity-based permission policy attached to the CodePipeline service role in the Tooling account.
Ensure there is a policy that allows the 'sts:AssumeRole' action on the target role ARN in the Production account.
The initiating service role must have explicit permission to perform the assume role operation on the external resource.
3
Verify that both policies are correctly applied and reference the correct ARNs.
The pipeline execution succeeds at the deploy stage, assuming the target role to deploy the resources.
Both trust and permission policies must align to allow cross-account access delegation.

Key Concept

Cross-account resource deployment using AWS CodePipeline and IAM assume role configurations.
Question 146Question →

A developer is maintaining a testing environment deployed via an AWS CloudFormation stack. To resolve a connectivity issue, the developer manually modifies the inbound port rules of an Amazon EC2 security group directly through the Amazon VPC Console. The developer now wants to identify the discrepancies between the live resource configurations and the definition in the original CloudFormation template. Which CloudFormation feature or action should the developer use to identify these configuration discrepancies?

Show answer & explanation

Answer: Use CloudFormation drift detection on the stack to identify which resources have been modified outside of CloudFormation.

Answer

Use CloudFormation drift detection on the stack to identify which resources have been modified outside of CloudFormation.
Running drift detection allows CloudFormation to compare the current status of the stack resources with the expected status defined in the stack template. It flags any resources that have been modified outside of CloudFormation management, providing a clear list of discrepancies.

Step-by-Step Solution

1
Identify that the developer made manual, out-of-band changes to a resource managed by a CloudFormation stack.
The resource is now in a state of configuration drift relative to the CloudFormation template.
Before performing any updates, the developer needs a way to compare the live infrastructure configuration with the template definition.
2
Evaluate the native features of AWS CloudFormation that support checking template compliance against actual resource state.
CloudFormation Drift Detection is the specific feature designed to detect discrepancies between the expected state (template) and the actual state.
This avoids having to manually audit each resource or risk stack update failures due to out-of-band configuration mismatches.

Key Concept

AWS CloudFormation Drift Detection
Question 147Question →

A developer is implementing a custom build and test action in AWS CodePipeline to integrate a proprietary security scanning tool. The scanning tool runs on an on-premises worker. The developer needs to configure the custom action and set up the worker to retrieve artifacts, perform the scan, and report the results back to the pipeline. What is the correct sequence of steps to configure this custom action workflow and execute it successfully?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with registering the custom action type, configuring it within the pipeline, polling for jobs from the custom worker, acknowledging the job to retrieve credentials and artifact locations, and finally reporting the success result after executing the scan.
The correct sequence begins with registering the custom action type in the AWS account, followed by defining it within the pipeline structure. During execution, the custom worker polls for the job, acknowledges the job to receive the required S3 locations and temporary credentials, performs the tasks, and reports the success result back to CodePipeline.

Step-by-Step Solution

1
Register the custom action type.
The custom action type is created and available for use in the AWS region.
Before a pipeline can reference a custom action, its schema and configuration requirements must be registered using the CLI or CloudFormation.
2
Add the custom action to the pipeline.
The pipeline configuration is updated to include the custom action in a stage.
The custom action must be declared in a stage so that CodePipeline knows when to execute it during the release process.
3
Poll for jobs from the custom worker.
The worker detects a scheduled custom action execution.
Unlike built-in actions, custom actions require an external worker to pull work requests from the CodePipeline service using PollForJobs.
4
Acknowledge the job.
The worker obtains job details, temporary security credentials, and artifact S3 locations.
The worker must notify CodePipeline that it is starting the job. The AcknowledgeJob API response provides the credentials and artifact paths.
5
Execute the task and report success.
The pipeline stage transitions to succeeded after the worker sends the PutJobSuccessResult.
The worker processes the input artifacts, uploads output artifacts to the artifact store, and updates CodePipeline with the final success status.

Key Concept

AWS CodePipeline Custom Actions and Worker Lifecycle APIs
Question 148Question →

An e-commerce company runs a production web application on AWS Elastic Beanstalk. The application is deployed across 1010 Amazon EC2 instances inside an Auto Scaling group behind an Application Load Balancer. A developer needs to configure a deployment strategy for a minor application update. The deployment must satisfy the following constraints:

* The environment must maintain exactly 100%100\% of its capacity (1010 instances) to handle traffic at all times during the update.
* The temporary cost overhead during the deployment process must be kept to a minimum.
* The update must be performed within the existing environment without creating a new environment or swapping CNAMEs.

Which Elastic Beanstalk deployment policy should the developer select?

Show answer & explanation

Answer: Rolling with additional batch

Answer

Rolling with additional batch
The deployment policy that meets all criteria is the one that adds an additional batch of instances before taking any offline, thereby maintaining the full environment capacity of ten instances during deployment. Since only one batch is provisioned at a time, the temporary cost overhead is minimized. Furthermore, the deployment is executed entirely within the existing environment.

Step-by-Step Solution

1
Evaluate the capacity constraint.
Since the application must maintain 100%100\% capacity (1010 instances) during the update, the policies 'All at once' and 'Rolling' are ruled out because they take instances out of service.
Eliminating options that reduce capacity helps narrow down choices to policies that add temporary instances.
2
Evaluate the cost overhead constraint.
Between 'Immutable' and 'Rolling with additional batch', the 'Rolling with additional batch' policy is more cost-efficient because it only launches a small, configurable batch of extra instances (e.g., 11 or 22), whereas 'Immutable' launches a duplicate set of 1010 instances (doubling the cost).
Comparing temporary cost resource provisioning determines the most cost-effective solution.
3
Evaluate the environment constraint.
The 'Rolling with additional batch' policy performs the update in-place within the existing Auto Scaling group and environment, avoiding CNAME swapping.
Ensures alignment with all environmental limits.

Key Concept

AWS Elastic Beanstalk deployment policies and their tradeoffs regarding capacity, deployment speed, rollback, and cost.
Estimated Time:1m 30s
Question 149Question →

A developer is setting up an automated release pipeline in AWS CodePipeline to handle application updates. Arrange the pipeline stages in the correct execution sequence, from the initial trigger to the final production release.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of stages is: first, the Source stage retrieves the source code; second, the Build stage compiles and tests the code; third, the Approval stage pauses the pipeline for verification; and finally, the Deploy stage deploys the artifacts to the target environment.
The correct sequence begins with the Source stage to retrieve raw source files, followed by the Build stage to compile and test the application, then the Approval stage to hold deployment for verification, and finally the Deploy stage to update the live environment.

Step-by-Step Solution

1
Identify the pipeline trigger and source retrieval.
The pipeline execution begins with the Source stage pulling code from the repository.
AWS CodePipeline must first fetch code to generate the primary input artifact.
2
Identify the compilation and test phase.
The Build stage runs to compile code and generate target artifacts.
Source code must be processed and verified before it can be validated or deployed.
3
Identify the manual gatekeeper phase.
The Approval stage pauses the pipeline execution.
An approval step is used to block automatic progression to deployment until verified.
4
Identify the final software release phase.
The Deploy stage deploys the compiled artifacts to the target environment.
The deploy stage runs as the final step in this delivery cycle to update the live application.

Key Concept

AWS CodePipeline execution flow and stage sequencing.
Question 150Question →

A developer is setting up an AWS CodePipeline to deploy a serverless application. The pipeline includes a deploy stage that triggers a custom AWS Lambda action to run database schema migrations. The Lambda action requires access to database credentials, and the pipeline itself must have permission to invoke the Lambda function. Which two of the following configuration steps should the developer perform to meet these requirements securely? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and retrieve them programmatically within the Lambda function.; Configure the trust policy of the IAM role associated with AWS CodePipeline to allow the codepipeline.amazonaws.com service principal to assume the role.

Answer

The correct steps are to store the database credentials in AWS Secrets Manager and to configure the trust policy of the IAM role associated with AWS CodePipeline to allow the CodePipeline service principal to assume the role.
Storing database credentials in AWS Secrets Manager is the correct practice because Secrets Manager encrypts the credentials at rest and supports automatic rotation. Additionally, the AWS CodePipeline service role requires a trust policy (also known as an assume role policy) that allows the CodePipeline service principal to assume the role in order to perform pipeline actions.

Step-by-Step Solution

1
Identify the correct storage service for database credentials.
AWS Secrets Manager is chosen for credential storage.
Secrets Manager encrypts credentials at rest and supports automatic rotation, meeting security requirements.
2
Configure permissions for CodePipeline execution.
The trust policy of the CodePipeline service role is configured to allow the codepipeline.amazonaws.com service principal to assume the role.
This trust relationship is necessary for CodePipeline to assume the role and execute the deployment steps.

Key Concept

AWS CodePipeline Custom Actions and IAM Roles
Question 151Question →

A developer is deploying a web application with a database backend using an AWS CloudFormation stack. The developer wants to ensure that the database credentials are managed securely and that the stack resources do not become inconsistent due to manual configurations. Which of the following actions should the developer take to achieve this? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and retrieve them in the template using dynamic references.; Update the database and application configurations by modifying the CloudFormation template and performing a stack update rather than making manual changes.

Answer

Store the database credentials in AWS Secrets Manager and retrieve them using dynamic references, and update stack configurations by modifying the CloudFormation template and performing a stack update.
The correct options are to store database credentials in AWS Secrets Manager and reference them using dynamic references, and to perform configuration updates via CloudFormation template updates rather than manual console changes. This ensures credential security and maintains the stack integrity as the source of truth.

Step-by-Step Solution

1
Identify the secure storage mechanism for credentials.
AWS Secrets Manager is chosen to store database credentials securely.
Storing credentials in Secrets Manager with dynamic references prevents plaintext exposure in templates.
2
Determine the correct method for modifying stack resources.
Modify the CloudFormation template and perform a stack update instead of making manual changes.
This prevents configuration drift and ensures the template remains the single source of truth.

Key Concept

CloudFormation configuration drift management and secure parameter reference.
Question 152Question →

A developer is configuring a task definition to run a microservice on Amazon ECS using the AWS Fargate launch type. The microservice application code needs to send messages to an Amazon SQS queue. How should the developer grant the application code the required SQS permissions?

Show answer & explanation

Answer: Assign the permissions to the IAM role specified in the taskRoleArn parameter of the task definition.

Answer

Assign the permissions to the IAM role specified in the taskRoleArn parameter of the task definition.
The correct option is the one specifying the use of the taskRoleArn parameter. When deploying containers on Amazon ECS, the Task Role (taskRoleArn) grants the containerized application permissions to make API requests to other AWS services like Amazon SQS. The AWS SDK inside the container automatically retrieves temporary credentials associated with this role.

Step-by-Step Solution

1
Identify the resource requiring credentials.
The application code running inside the ECS container needs to interact with Amazon SQS.
This determines whether the task agent permissions or the application permissions are needed.
2
Distinguish between ECS Task Role and ECS Task Execution Role.
The Task Role (taskRoleArn) is designed for the application inside the container, whereas the Task Execution Role (executionRoleArn) is for the ECS agent itself.
Choosing the correct role ensures the application can retrieve temporary credentials for SQS.
3
Select the appropriate parameter in the task definition.
Apply the IAM policy with SQS write permissions to the IAM role specified by taskRoleArn.
This secures the containerized application without exposing static credentials or misconfiguring agent roles.

Key Concept

ECS Task Role vs. ECS Task Execution Role
Estimated Time:45s
Question 153Question →

A software engineer is setting up a new build configuration in AWS CodeBuild for a web application. The engineer wants CodeBuild to automatically find the build commands and phases without specifying a custom path in the build project settings.

Where should the build specification file be placed by default, and what must it be named?

Show answer & explanation

Answer: In the root of the source directory, named buildspec.yml

Answer

In the root of the source directory, named buildspec.yml
The correct answer is the option stating that the file must be placed in the root of the source directory and named buildspec.yml. AWS CodeBuild expects the build specification file to be in the root directory and named buildspec.yml by default, unless a custom file name or location is overridden in the build project settings.

Step-by-Step Solution

1
Identify the default build specification file naming convention for AWS CodeBuild.
The file must be named buildspec.yml.
AWS CodeBuild looks specifically for a file named buildspec.yml by default.
2
Determine the default directory location for this file within the source repository.
The file must be placed in the root of the source directory.
CodeBuild fails to locate the build phases if the file is placed in a subdirectory unless a custom path is configured.

Key Concept

AWS CodeBuild default buildspec location and naming convention
Estimated Time:45s
Question 154Question →

A developer is updating a serverless application where traffic is routed to an AWS Lambda function. The developer needs to update the function version using AWS CodeDeploy so that 10%10\% of the traffic is routed to the new version for a 1010-minute trial period, after which all remaining traffic is routed to the new version. Which AWS CodeDeploy deployment configuration meets this requirement?

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent10Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent10Minutes
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes shifts 10%10\% of the traffic to the new Lambda version immediately, waits for a 1010-minute interval to monitor for errors or alarms, and then shifts the remaining 90%90\% of the traffic to the new version.

Step-by-Step Solution

1
Analyze the traffic routing requirements.
The requirements specify shifting a small portion (10%10\%) of traffic initially, holding it for a trial period (1010 minutes), and then shifting the remaining traffic (90%90\%) all at once.
This matches a canary deployment pattern rather than a linear or all-at-once deployment pattern.
2
Identify the correct AWS CodeDeploy deployment configuration prefix for AWS Lambda.
The configuration must start with the prefix 'CodeDeployDefault.Lambda'.
CodeDeploy uses specific prefixes depending on the compute platform (Lambda, ECS, or EC2/On-Premises).
3
Select the configuration that matches Canary 10%10\% with a 1010-minute interval.
CodeDeployDefault.LambdaCanary10Percent10Minutes fits this description exactly.
The 'Canary10Percent10Minutes' suffix routes 10%10\% of traffic to the new version and then routes the rest after 1010 minutes.

Key Concept

AWS CodeDeploy configurations for AWS Lambda support Canary deployments (shifting a percentage of traffic for a set time before shifting the rest) and Linear deployments (shifting equal increments of traffic at regular intervals).
Question 155Question →

A developer needs to update a production web application hosted on AWS Elastic Beanstalk. The application runs on multiple Amazon EC2 instances behind an Application Load Balancer. The deployment must satisfy the following criteria:
- There must be zero application downtime.
- The environment must maintain 100%100\% of its provisioned capacity throughout the deployment process to handle high traffic.
- The deployment must support a fast and clean rollback mechanism with minimal impact if any issues occur.
- Double-allocation cost is acceptable for the duration of the deployment.

Which two Elastic Beanstalk deployment policies should the developer select to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Immutable; Rolling with additional batch

Answer

Immutable and Rolling with additional batch
The Immutable deployment policy satisfies the constraints by deploying the new version to a temporary Auto Scaling group, ensuring full capacity is maintained during health checks and allowing an instant rollback if needed. The Rolling with additional batch policy also meets the criteria by launching a new batch of instances first to maintain 100%100\% capacity before updating the existing instances in batches.

Step-by-Step Solution

1
Analyze the capacity requirement
The requirement specifies that 100%100\% of the provisioned capacity must be maintained throughout the deployment. This rules out the standard Rolling policy, which takes instances out of service, and the All at once policy, which takes all instances out of service.
Maintaining full capacity is a strict constraint to handle high traffic without performance degradation.
2
Analyze the downtime and rollback requirements
The Immutable deployment policy launches a separate, temporary Auto Scaling group, meaning the existing environment runs at full capacity until the new version passes health checks. Rollback is immediate (terminating the new Auto Scaling group). The Rolling with additional batch policy launches a new batch first to maintain capacity before rolling the update through the existing instances, ensuring zero downtime.
Both policies satisfy the capacity and zero-downtime requirements by allocating additional temporary resources during the update.
3
Evaluate the non-native option
Linear 10% every 10 minutes is a CodeDeploy-specific configuration and cannot be selected as an Elastic Beanstalk deployment policy.
Only native Elastic Beanstalk deployment policies can be configured within the Elastic Beanstalk console or CLI.

Key Concept

AWS Elastic Beanstalk deployment policies and their impact on environment capacity, downtime, and rollbacks.
Question 156Question →

A developer is configuring a continuous delivery pipeline using AWS CodePipeline in Account A. The pipeline needs to deploy a serverless application to Account B using AWS CloudFormation. The developer has created a deployment IAM role in Account B with the required permissions to create and manage the application resources. However, when the pipeline runs, the CloudFormation deployment stage fails with an Access Denied error. Which of the following configurations will resolve this issue?

Show answer & explanation

Answer: Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role in Account A to assume it, and configure the CloudFormation action in Account A's pipeline to use this cross-account role.

Answer

Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role in Account A to assume it, and configure the CloudFormation action in Account A's pipeline to use this cross-account role.
The correct option correctly configures cross-account authorization. AWS CodePipeline supports executing actions in another account by assuming a role created in that account. The role in the target account must trust the CodePipeline service role to perform the 'sts:AssumeRole' action, and the pipeline action configuration must specify the target role ARN.

Step-by-Step Solution

1
Modify the trust policy of the IAM role in Account B (target account) to add a trust relationship allowing the 'sts:AssumeRole' action for the CodePipeline service role ARN from Account A.
The IAM role in the target account is now allowed to be assumed by the CodePipeline service role in the source account.
This establishes cross-account trust required for secure delegation of authority.
2
Update the CodePipeline action configuration in the deployment stage in Account A to reference the IAM role ARN from Account B under the 'RoleArn' parameter.
CodePipeline is configured to assume the target account role when executing the CloudFormation action.
This instructs CodePipeline to use the trusted target account role's temporary credentials for deployment.

Key Concept

Cross-account deployments in AWS CodePipeline require configuring IAM trust policies that allow the pipeline service role to assume a target deployment role in the destination account.
Estimated Time:1m 30s
Question 157Question →

An organization wants to run a microservice on Amazon ECS using the AWS Fargate launch type. The containerized application needs to publish events to an Amazon SNS topic. Additionally, the Amazon ECS container agent must download the Docker image from a private Amazon ECR repository. Which of the following configurations are required in the task definition to support this deployment? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Specify a Task Role in the task definition that grants the containerized application permission to publish to the Amazon SNS topic.; Specify a Task Execution Role in the task definition that allows the Amazon ECS container agent to pull the image from Amazon ECR.

Answer

To configure this deployment successfully, the task definition must specify a Task Role that grants the containerized application permission to publish to Amazon SNS, and a Task Execution Role that allows the Amazon ECS container agent to pull the container image from Amazon ECR.
The ECS Task Role is assumed by the containerized application itself, allowing the code to make API calls to AWS services such as publishing messages to an Amazon SNS topic. The ECS Task Execution Role is assumed by the ECS agent to perform tasks on behalf of the container registry and logging services, such as pulling the image from Amazon ECR before the container starts.

Step-by-Step Solution

1
Identify the permissions needed by the application code running inside the container (publishing to Amazon SNS).
Determine that these application-level permissions must be associated with the ECS Task Role.
The Task Role is used by the containerized application to access AWS resources after the container starts.
2
Identify the permissions needed by the Amazon ECS container agent (pulling the Docker image from Amazon ECR).
Determine that these agent-level permissions must be associated with the ECS Task Execution Role.
The Task Execution Role is used by the ECS container agent to execute tasks like pulling images and writing logs before the container code runs.

Key Concept

Delineation between the ECS Task Role (used by the application container to interact with AWS services) and the ECS Task Execution Role (used by the ECS agent to perform container lifecycle tasks like pulling images or sending logs).
Question 158Question →

A developer is managing a web application infrastructure deployed via an AWS CloudFormation stack. The stack includes an Amazon RDS DB instance and an Amazon ECS service. The developer needs to update the database master password to a new value and configure the ECS tasks to retrieve this password securely. During the update attempt, the stack update fails because another team member manually modified the database security group rules directly in the Amazon VPC console to debug a connection issue. Which combination of actions should the developer take to resolve the update failure and secure the password? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Run drift detection on the CloudFormation stack, identify the differences in the database security group, and manually revert the security group rules in the VPC console to match the template definition before retrying the update.; Update the CloudFormation template to reference the database password using the {{resolve:secretsmanager:db-password}} dynamic reference, allowing ECS tasks to retrieve the password securely at runtime.

Answer

Run drift detection on the CloudFormation stack to identify changes and manually revert the security group rules in the VPC console. Additionally, update the template to use the AWS Secrets Manager dynamic reference for the database password.
To fix a stack update blocked by out-of-band modifications, the developer must first identify the drift and manually revert the changes in the console to match the template. To secure the database password, the developer should use the AWS Secrets Manager dynamic reference, which securely resolves the secret during resource creation and runtime without exposing it in plaintext.

Step-by-Step Solution

1
Initiate drift detection on the target CloudFormation stack.
The stack status reveals that the database security group has drifted from its template-defined state due to manual rules modifications.
Identifying the specific resources that have drifted is necessary to resolve conflicts before executing stack updates.
2
Manually revert the database security group rules in the VPC console back to the values specified in the CloudFormation template.
The security group configuration aligns perfectly with the template definition, and the drift status returns to IN_SYNC.
Resolving the drift state allows CloudFormation to execute updates without encountering resource state conflicts.
3
Modify the CloudFormation template to reference the database password from AWS Secrets Manager using the dynamic reference format.
The template uses the dynamic lookup expression to retrieve the credential securely at deployment and runtime.
This avoids hardcoding sensitive credentials in plaintext templates or parameters, meeting security compliance requirements.

Key Concept

Handling resource drift and managing secrets securely using dynamic references in AWS CloudFormation.
Estimated Time:2m 0s
Question 159Question →

A developer is planning an update for a non-critical internal application deployed on AWS Elastic Beanstalk. Because the application has low usage, the developer wants to minimize deployment duration and is comfortable with the environment's capacity being temporarily reduced or offline during the update. Which two Elastic Beanstalk deployment strategies will result in a temporary reduction of active instance capacity during the deployment? (Select TWO).

Select all that apply

Show answer & explanation

Answer: All-at-once; Rolling

Answer

All-at-once and Rolling
The correct strategies are All-at-once and Rolling. The All-at-once strategy deploys the update to all instances at the same time, which temporarily takes all instances out of service and reduces active capacity to zero. The Rolling strategy updates the environment in batches, taking one batch of instances out of service at a time, which temporarily reduces the overall active capacity of the environment.

Step-by-Step Solution

1
Analyze the capacity behavior of each Elastic Beanstalk deployment strategy.
Identify how each strategy handles active instances during an update.
The requirement specifies selecting strategies that temporarily reduce the active instance capacity of the environment.
2
Evaluate which strategies take existing instances out of service without pre-provisioning replacement capacity.
All-at-once takes all instances out of service simultaneously. Rolling takes a subset (batch) of instances out of service at a time.
Both of these strategies deploy directly to existing instances in-place, leading to a temporary reduction in capacity.
3
Verify that the remaining strategies maintain 100% capacity.
Rolling with additional batch, Immutable, and Traffic splitting all provision new instances before taking old ones out of service to maintain full capacity.
Confirming these strategies are incorrect because they preserve full capacity during deployment.

Key Concept

Understanding the impact of AWS Elastic Beanstalk deployment strategies on environment capacity and instance count.
Question 160Question →

An application team is configuring AWS CodeBuild to compile and package a Java application. The build process requires a buildspec file to define the build phases and must retrieve a database connection string stored in AWS Systems Manager Parameter Store. Which of the following actions should the developer take to meet these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Place the buildspec.yml file in the root directory of the application source code.; Reference the database connection string under the parameter-store mapping of the env sequence in the buildspec file.

Answer

Place the buildspec.yml file in the root directory of the application source code, and reference the database connection string under the parameter-store mapping of the env sequence in the buildspec file.
The correct options are placing the buildspec.yml in the root directory of the source code and referencing the database connection string under the parameter-store mapping in the env sequence. By default, CodeBuild automatically looks for buildspec.yml at the root level of the source directory. To securely load secrets or configuration details from Systems Manager Parameter Store during the build, the developer must declare them under 'parameter-store' in the 'env' section of the buildspec, which maps the Parameter Store keys to environment variables in the build environment.

Step-by-Step Solution

1
Determine the default location of the build configuration file.
Confirm that the buildspec.yml file should be placed in the root directory of the source code.
AWS CodeBuild looks for the buildspec.yml file at the root of the source directory by default unless overridden in the project configuration.
2
Determine how to retrieve parameter values from AWS Systems Manager Parameter Store inside the buildspec file.
Declare the parameters under the parameter-store block in the env sequence of the buildspec file.
This allows CodeBuild to automatically fetch the values from Systems Manager Parameter Store and expose them as environment variables during the build phases.

Key Concept

AWS CodeBuild configuration requires the buildspec.yml file to be placed in the root of the source code by default, and Systems Manager Parameter Store variables must be declared under the parameter-store mapping in the env block.
PreviousPage 8 / 19Next
Deployment Practice Questions — AWS Certified Developer - Associate — Page 8 | Examkin