Examkin

Deployment

376 questions

All types376Multiple choice191Multiple select171Ordering14
Question 21Question →

A developer is configuring a continuous release pipeline in AWS CodePipeline for a web application. The pipeline must include a manual approval stage before deploying the application to production, which should notify the operations team. Additionally, the subsequent build and deployment stage in AWS CodeBuild requires a database API key that must be rotated automatically every 30 days. Which combination of steps should the developer perform to meet these requirements securely? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create an Amazon SNS topic, subscribe the operations team's email addresses, and associate the SNS topic ARN with the manual approval action in CodePipeline.; Store the database API key in AWS Secrets Manager, enable automatic rotation, and retrieve the secret in the CodeBuild buildspec file using the Secrets Manager integration.

Answer

Create an Amazon SNS topic, subscribe the operations team's email addresses, and associate it with the manual approval action; and store the database API key in AWS Secrets Manager with automatic rotation enabled, retrieving it during the build phase.
To satisfy the requirements, the developer must use an Amazon SNS topic subscribed to the operations team's email addresses and link it to the manual approval action. For the secret requiring rotation, storing the key in AWS Secrets Manager with automatic rotation enabled satisfies the 30-day rotation requirement and can be securely retrieved by CodeBuild at runtime.

Step-by-Step Solution

1
Determine the mechanism to notify the operations team of manual approvals in CodePipeline.
Identify Amazon SNS as the supported service for manual approval action notifications.
CodePipeline manual approval actions natively integrate with Amazon SNS to publish notification messages.
2
Evaluate secret storage options for the database API key requiring automatic rotation.
Select AWS Secrets Manager as the appropriate service for secret rotation.
Secrets Manager provides native automatic rotation capabilities, unlike Systems Manager Parameter Store.
3
Configure the build execution step to retrieve the secret securely.
Reference the Secrets Manager secret dynamically inside the buildspec.yml file.
Retrieving the secret at runtime prevents hardcoding sensitive credentials in source code or project settings.

Key Concept

AWS CodePipeline manual approvals and secure secret rotation integration with CodeBuild
Question 22Question →

A developer is configuring an AWS CodeBuild project to package a web application. The build process requires retrieving a database connection string from AWS Systems Manager Parameter Store and using a custom IAM role to allow CodeBuild to write the build logs to an Amazon CloudWatch Logs log group. During the first build run, the build fails immediately before the install phase with an error stating that CodeBuild is not authorized to assume the service role. Additionally, the application fails to build because the connection string path is being treated as a literal string rather than retrieving the actual database connection string value. Which of the following actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the trust policy of the custom IAM role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.; In the buildspec.yml file, define the database connection string environment variable under the parameter-store mapping in the env section.

Answer

To resolve these issues, the developer must update the trust policy of the custom IAM role to allow the AWS CodeBuild service principal to assume the role, and define the parameter under the parameter-store mapping in the buildspec.yml file.
The correct actions are updating the trust policy of the custom IAM role to trust the codebuild.amazonaws.com service principal and defining the Parameter Store variables under the parameter-store block of the env section in the buildspec.yml. This allows CodeBuild to assume the service role and resolve the parameter path into the actual connection string value.

Step-by-Step Solution

1
Inspect and update the trust relationship of the custom IAM role.
The IAM role's trust policy is configured to trust 'codebuild.amazonaws.com', allowing CodeBuild to successfully assume the role.
CodeBuild needs explicit assume role permissions in the trust policy of any custom service role it uses.
2
Update the environment variable section of the buildspec.yml.
The database connection string is placed under the 'parameter-store' mapping within the 'env' section of the buildspec.
Placing the variable under 'parameter-store' instructs CodeBuild to fetch the actual value from Systems Manager Parameter Store instead of treating the path as a static string.

Key Concept

AWS CodeBuild IAM service role trust relationships and environment variable retrieval from Systems Manager Parameter Store.
Question 23Question →

A developer is configuring a blue/green deployment for an Amazon ECS service using AWS CodeDeploy. The deployment must execute a validation Lambda function after the test traffic is routed to the replacement task set but before the production traffic is shifted. Additionally, the developer must ensure that AWS CodeDeploy has the necessary permissions to execute the deployment steps and update the Application Load Balancer listeners. Which of the following configurations must the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the AppSpec file, specify the validation Lambda function under the AfterAllowTestTraffic hook in the Hooks section.; Configure the trust policy of the CodeDeploy service IAM role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

In the AppSpec file, specify the validation Lambda function under the AfterAllowTestTraffic hook in the Hooks section, and configure the trust policy of the CodeDeploy service IAM role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.
The correct configurations involve using the AfterAllowTestTraffic hook in the ECS AppSpec file to trigger the validation Lambda function after test traffic routing, and configuring the CodeDeploy service IAM role trust policy to allow codedeploy.amazonaws.com to assume the role. These steps ensure CodeDeploy has the authority to orchestrate the deployment and execute verification tests at the correct stage.

Step-by-Step Solution

1
Determine the correct CodeDeploy AppSpec lifecycle hook for validating an Amazon ECS blue/green deployment before production traffic is shifted.
Identify that AfterAllowTestTraffic is the designated hook that runs validation tests after the test traffic is routed to the new task set.
This hook provides a window to verify the health and behavior of the new version using test traffic before exposing it to live production users.
2
Examine the IAM configurations required for CodeDeploy to assume a service role and manage ECS and ALB resources.
Identify that the CodeDeploy service IAM role must have a trust policy configured with the codedeploy.amazonaws.com principal and the sts:AssumeRole action.
This trust policy allows the AWS CodeDeploy service to securely assume the role and perform administrative actions on behalf of the developer.

Key Concept

AWS CodeDeploy for Amazon ECS uses a specific set of lifecycle hooks in the AppSpec file (such as AfterAllowTestTraffic) and requires an IAM service role with a trust policy for the codedeploy.amazonaws.com service principal.
Question 24Question →

A developer is updating a critical serverless API hosted on AWS Lambda using AWS CodeDeploy. The deployment must meet the following requirements:

- Direct only 10%10\% of the production traffic to the new Lambda function version initially.
- Route all remaining traffic to the new version after a 1010-minute monitoring window.
- Roll back the deployment automatically if any error metrics exceed the normal threshold.

Which of the following configuration options should the developer select to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Specify CodeDeployDefault.LambdaCanary10Percent10Minutes as the deployment configuration.; Configure CloudWatch alarms in the CodeDeploy deployment group to monitor error metrics and trigger automatic rollbacks.

Answer

To meet the requirements, the developer must select the Canary 10 percent 10 minutes deployment configuration to manage the traffic routing, and configure CloudWatch alarms on the CodeDeploy deployment group to handle automatic rollbacks on error metrics.
The correct configuration is achieved by using the Canary 10 percent 10 minutes deployment strategy and configuring CloudWatch alarms in the CodeDeploy deployment group. The canary strategy ensures the new version receives 10%10\% of the traffic initially, and shifts the remaining traffic after 1010 minutes. The CloudWatch alarms enable CodeDeploy to monitor the error metrics and perform an automated rollback to the previous version if thresholds are breached.

Step-by-Step Solution

1
Analyze the traffic shifting pattern.
The requirements specify routing 10%10\% of the traffic first, waiting 1010 minutes, and then routing the remaining 90%90\%. This corresponds to a canary deployment strategy with a 1010-minute interval.
Identifying the shift pattern helps filter out linear strategies and incorrect canary intervals.
2
Select the correct predefined AWS CodeDeploy configuration.
Choose the configuration named CodeDeployDefault.LambdaCanary10Percent10Minutes.
This matches the target behavior of a 10%10\% shift followed by a 1010-minute pause before complete routing.
3
Identify the mechanism for automated rollback.
CodeDeploy deployment groups can be associated with CloudWatch alarms (such as Lambda invocation errors).
If an alarm triggers during the deployment, CodeDeploy detects it and automatically executes a rollback to the original Lambda version.

Key Concept

AWS Lambda Canary Deployment and Automated Rollbacks using CodeDeploy
Estimated Time:1m 30s
Question 25Question →

A developer is deploying a containerized microservice to Amazon ECS using the AWS Fargate launch type. The application code inside the container must read messages from an Amazon SQS queue, decrypt the message payloads using an AWS KMS key, and write results to an Amazon DynamoDB table. Additionally, the task definition specifies that the database password, stored as a secure string in Systems Manager Parameter Store, should be injected as an environment variable at startup. The container image is pulled from a private Amazon ECR repository.

Which of the following configurations are required to establish the correct IAM permissions for this deployment? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the ECS Task Role with a trust policy for the ecs-tasks.amazonaws.com service principal, and attach a policy that allows the application code to read from the SQS queue, write to the DynamoDB table, and decrypt SQS payloads using the KMS key.; Configure the ECS Task Execution Role with a trust policy for the ecs-tasks.amazonaws.com service principal, and attach a policy that allows the container agent to pull from Amazon ECR, write to Amazon CloudWatch Logs, and retrieve the database password from Systems Manager Parameter Store.

Answer

Configure the ECS Task Role with a trust policy for the ecs-tasks.amazonaws.com service principal, and attach a policy that allows the application code to read from the SQS queue, write to the DynamoDB table, and decrypt SQS payloads using the KMS key; and configure the ECS Task Execution Role with a trust policy for the ecs-tasks.amazonaws.com service principal, and attach a policy that allows the container agent to pull from Amazon ECR, write to Amazon CloudWatch Logs, and retrieve the database password from Systems Manager Parameter Store.
To establish the correct IAM permissions, the ECS Task Role and the ECS Task Execution Role must be configured with the appropriate trust policies and permissions. The ECS Task Role is used by the application code running inside the container; therefore, it must be granted permissions to read from the SQS queue, write to the DynamoDB table, and decrypt the SQS payloads using the KMS key. The ECS Task Execution Role is used by the ECS container agent to perform actions on behalf of the task before the container starts; therefore, it must be granted permissions to pull the container image from the private Amazon ECR repository, write log streams to Amazon CloudWatch Logs, and retrieve the database password from Systems Manager Parameter Store to inject it as an environment variable.

Step-by-Step Solution

1
Distinguish between infrastructure actions (ECS agent) and application actions (running code).
The application code reads from SQS, decrypts payloads, and writes to DynamoDB. The ECS agent pulls the Docker image, handles container logs, and pulls secrets to inject as environment variables at startup.
This separation determines whether a permission belongs to the Task Role or the Task Execution Role.
2
Assign the application permissions to the ECS Task Role and configure its trust policy.
Create an IAM role that trusts 'ecs-tasks.amazonaws.com' and attach a policy with permissions for SQS, DynamoDB, and KMS decryption.
The containerized application assumes this role at runtime to authenticate its AWS SDK client requests.
3
Assign the infrastructure/agent permissions to the ECS Task Execution Role and configure its trust policy.
Create an IAM role that trusts 'ecs-tasks.amazonaws.com' and attach a policy with permissions for ECR pulling, CloudWatch Logs writing, and Systems Manager Parameter Store reading.
The ECS container agent uses this role during container provisioning and startup phases.

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role in AWS Fargate
Estimated Time:2m 30s
Question 26Question →

A developer is configuring an AWS CodeDeploy deployment group for a critical serverless application. To minimize the blast radius of potential failures, the developer needs a strategy that shifts traffic to the new AWS Lambda function version gradually over time. If any CloudWatch alarms are triggered during the deployment, CodeDeploy must immediately roll back all traffic to the original version.

Which of the following CodeDeploy deployment configuration types will satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Canary configurations; Linear configurations

Answer

The correct configurations are Canary configurations and Linear configurations.
Canary and Linear configurations are the two native AWS CodeDeploy deployment configuration types that support gradual traffic shifting for serverless applications. Canary configurations route a portion of traffic to the new version, wait for a specified period, and then route the rest. Linear configurations shift traffic in equal increments at regular intervals. If a CloudWatch alarm triggers during either deployment, CodeDeploy immediately routes 100% of the traffic back to the original version by updating the Lambda alias.

Step-by-Step Solution

1
Analyze the requirements from the scenario: gradual traffic shifting to minimize blast radius and immediate rollback capability using CloudWatch alarms.
Identified that the solution must support shifting a fraction of traffic to the new version of the AWS Lambda function first, and instantly routing 100% of traffic back to the old version upon failure.
This narrows the choices to CodeDeploy deployment configurations designed for AWS Lambda traffic shifting.
2
Evaluate the available AWS CodeDeploy configurations for serverless deployments against the requirements.
Canary configurations (e.g., Canary10Percent5Minutes) shift a portion of traffic initially, while Linear configurations (e.g., Linear10PercentEvery1Minute) shift traffic incrementally. Both types support immediate rollback via alias re-pointing.
These two configuration types are the only native CodeDeploy options for AWS Lambda that shift traffic gradually.

Key Concept

AWS CodeDeploy Traffic Shifting Configurations for AWS Lambda
Question 27Question →

A developer is configuring an Amazon ECS task definition to deploy a containerized application on AWS Fargate. The application is configured to stream logs to Amazon CloudWatch using the `awslogs` log driver, and it retrieves a database password from AWS Secrets Manager by referencing the secret in the container definition's environment variables. Inside the container, the application code uses the AWS SDK to write processed reports to an Amazon S3 bucket.

Which of the following IAM configurations must the developer apply to allow the task to run and successfully perform all of these operations?

Show answer & explanation

Answer: Attach an IAM policy with s3:PutObject permissions to the ECS Task Role, and attach policies with logs:CreateLogStream, logs:PutLogEvents, and secretsmanager:GetSecretValue permissions to the ECS Task Execution Role. Configure the trust policy of both roles to trust the ecs-tasks.amazonaws.com service principal.

Answer

Attach an IAM policy with s3:PutObject permissions to the ECS Task Role, and attach policies with logs:CreateLogStream, logs:PutLogEvents, and secretsmanager:GetSecretValue permissions to the ECS Task Execution Role. Configure the trust policy of both roles to trust the ecs-tasks.amazonaws.com service principal.
The correct answer properly separates the runtime application permissions (S3 upload) into the Task Role and the container agent's operational permissions (CloudWatch logs and Secrets Manager retrieval) into the Task Execution Role. It also correctly specifies the ecs-tasks.amazonaws.com service principal in the trust policy of both roles to allow Amazon ECS to assume them.

Step-by-Step Solution

1
Differentiate between the permissions needed by the application runtime and those needed by the ECS agent.
The application code needs S3 permissions, which requires the ECS Task Role. The ECS container agent needs CloudWatch Logs and Secrets Manager permissions to set up the container, which requires the ECS Task Execution Role.
Splitting these permissions correctly conforms to the principle of least privilege and allows both the agent and application to execute successfully.
2
Verify the correct trust relationship service principal for ECS task roles.
Both roles must specify the ecs-tasks.amazonaws.com service principal in their trust policy.
This allows the ECS service to assume these roles on behalf of the tasks running on AWS Fargate.

Key Concept

Differentiating between the ECS Task Role and the ECS Task Execution Role is critical when deploying containerized applications. The Task Role is assumed by the application code inside the container to make AWS API calls, whereas the Task Execution Role is assumed by the Amazon ECS container agent to perform setup operations like pulling images, writing logs to CloudWatch, and reading environment variables from Systems Manager Parameter Store or Secrets Manager.
Question 28Question →

A developer is deploying a containerized application to Amazon ECS using the AWS Fargate launch type. The application is packaged in a Docker image stored in a private Docker Hub repository. During task initialization, the Amazon ECS agent must pull this image using credentials stored in AWS Secrets Manager. Once running, the application code must publish messages to an Amazon SQS queue. Which combination of IAM configurations should the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach a policy to the ECS task execution role that allows the secretsmanager:GetSecretValue action on the secret containing the private registry credentials.; Attach a policy to the ECS task role that allows the sqs:SendMessage action on the Amazon SQS queue.

Answer

To configure this setup correctly, the developer must attach the secretsmanager:GetSecretValue permission to the ECS task execution role to allow the ECS agent to retrieve the private registry credentials, and attach the sqs:SendMessage permission to the ECS task role to allow the application code to write to the SQS queue.
The correct configurations involve assigning the registry credentials access to the ECS task execution role and assigning SQS permissions to the ECS task role. The ECS task execution role is assumed by the ECS agent to perform actions such as pulling the container image and pulling secrets from Secrets Manager. The ECS task role is assumed by the application running inside the container, granting it permissions to interact with AWS resources like SQS.

Step-by-Step Solution

1
Determine the role required for container image pull authentication.
The ECS container agent handles pulling the image from the private registry during task initialization, which requires accessing the secret credentials. This requires the ECS Task Execution Role.
Permissions needed by the ECS daemon/agent (such as pulling images and reading secrets to start containers) must be defined in the Task Execution Role.
2
Determine the role required for SQS message publishing.
The application code running inside the container performs the SQS operations once the container starts. This requires the ECS Task Role.
Permissions needed by the containerized application code itself (such as interacting with AWS APIs like DynamoDB, S3, or SQS) must be defined in the Task Role.
3
Select the two correct configuration steps.
Assign secrets retrieval to the task execution role, and assign SQS send message permission to the task role.
This correctly maps permissions based on which entity (the ECS agent vs. the application code) performs each action.

Key Concept

ECS Task Role vs. Task Execution Role
Question 29Question →

A developer is using AWS CodeDeploy to perform an in-place deployment of a new application revision to an Amazon EC2 Auto Scaling group that currently contains 66 running instances. The deployment must satisfy the following constraints:

* A minimum of 33 instances must remain healthy and serve traffic at all times during the deployment process.
* The deployment must complete as quickly as possible while adhering to the healthy host constraint.

Which two CodeDeploy configurations can the developer use to meet these requirements?

Select all that apply

Show answer & explanation

Answer: The default deployment configuration CodeDeployDefault.HalfAtATime; A custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of 5050

Answer

The developer can use the default deployment configuration CodeDeployDefault.HalfAtATime or a custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of 5050.
The correct options are the default configuration that updates half of the instances at a time, and a custom configuration specifying a minimum of 50%50\% fleet health. For a fleet of 66 instances, keeping a minimum of 33 healthy instances requires maintaining at least 50%50\% health. The default configuration that accomplishes this in the fewest steps is the one that updates half the fleet at a time, completing in two batches. Alternatively, a custom configuration using a fleet percentage of 5050 achieves the exact same balance of speed and availability.

Step-by-Step Solution

1
Determine the minimum healthy host percentage and count required.
The target is 33 healthy instances out of 66, which represents exactly 50%50\% of the fleet.
This establishes the boundary conditions for the deployment configurations.
2
Evaluate the default configuration options against speed and capacity constraints.
CodeDeployDefault.HalfAtATime meets the requirement by updating 33 instances at a time (22 steps total). CodeDeployDefault.OneAtATime is too slow (66 steps), and CodeDeployDefault.AllAtOnce violates the healthy instances constraint.
To select the correct predefined deployment configuration.
3
Evaluate custom configuration parameters to match the target threshold.
A custom configuration with minimumHealthyHosts of type FLEET_PERCENT set to 5050 will correctly keep 33 instances healthy. Using HOST_COUNT with a value of 5050 expects 5050 physical hosts, which exceeds the fleet size.
To identify the correct custom deployment configuration settings.

Key Concept

AWS CodeDeploy deployment configurations allow developers to specify the number or percentage of instances that must remain healthy during an in-place deployment to balance availability and speed.
Question 30Question →

A developer is configuring AWS CodeDeploy to deploy a Python web application to a fleet of Amazon EC2 instances. The deployment process must retrieve database credentials securely from AWS Systems Manager Parameter Store (stored as a `SecureString` parameter) and execute a database migration script before the application starts and begins accepting traffic.

Which two actions must the developer perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Grant the Amazon EC2 instance profile IAM role the `ssm:GetParameters` and `kms:Decrypt` permissions.; Execute the database migration script during the `AfterInstall` lifecycle hook in the `appspec.yml` file.

Answer

Granting the Amazon EC2 instance profile IAM role the necessary decrypt permissions and executing the migration script during the AfterInstall lifecycle hook in the appspec.yml file.
To successfully run the database migration before the application starts, the script must execute during a valid EC2 lifecycle hook like `AfterInstall`. Since the script runs on the EC2 instances, the instance profile IAM role must have permissions to retrieve the SecureString parameter and decrypt it using the associated KMS key.

Step-by-Step Solution

1
Identify the entity executing the deployment scripts.
The CodeDeploy agent runs on the EC2 instances and executes the AppSpec lifecycle hook scripts.
This determines that permissions to fetch parameters must be assigned to the EC2 instance profile role, not the CodeDeploy service role.
2
Select the correct CodeDeploy lifecycle hook for EC2.
The `AfterInstall` hook runs on EC2 instances before the application starts.
This ensures the schema migration is completed before the web server begins running.
3
Grant the EC2 instance profile access to Systems Manager Parameter Store and AWS KMS.
Add `ssm:GetParameters` and `kms:Decrypt` to the instance profile role's policy.
The script running on the instance must be authorized to pull and decrypt the database credentials.

Key Concept

AWS CodeDeploy EC2 deployments rely on the CodeDeploy agent running under the instance profile's IAM permissions and execute scripts within EC2-specific lifecycle hooks such as AfterInstall.
Estimated Time:2m 0s
Question 31Question →

A developer is using AWS Serverless Application Model (SAM) to deploy a serverless API. The application uses a Lambda function triggered by an API Gateway API (defined as an `Api` event source) to retrieve records from a database. During testing, the API Gateway endpoint returns a 502 Bad Gateway error. The Lambda function logs indicate that it executed successfully and returned the database records, but the integration failed. Additionally, the developer needs to store the database credentials securely and ensure they are rotated automatically.

Which of the following actions should the developer take to resolve the integration error and meet the security requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Format the Lambda function's return payload to include the statusCode, headers, and body fields.; Store the database credentials in AWS Secrets Manager and configure automatic rotation for the secret.

Answer

Format the Lambda function's return payload to include the statusCode, headers, and body fields, and store the database credentials in AWS Secrets Manager and configure automatic rotation for the secret.
The correct options are to format the Lambda function's return payload with status code, headers, and body fields, and to store the credentials in AWS Secrets Manager with automatic rotation. Because the default SAM Api event source deploys API Gateway with Lambda proxy integration, the Lambda response must adhere to a specific structure. Additionally, Secrets Manager is the correct service to use because it supports native automated credential rotation, whereas Systems Manager Parameter Store does not.

Step-by-Step Solution

1
Analyze the 502 Bad Gateway integration error.
The Lambda function executes successfully but the integration fails. Since AWS SAM's default Api event source configures API Gateway Lambda proxy integration, the Lambda function must return the response in a structured format containing the status code, headers, and body.
This determines how to format the Lambda function's response to satisfy API Gateway's proxy integration requirements.
2
Evaluate the database credential rotation requirement.
AWS Secrets Manager is selected because it natively supports automatic rotation of credentials, unlike AWS Systems Manager Parameter Store which requires custom implementations to achieve rotation.
This identifies the correct AWS service to store and rotate credentials securely.

Key Concept

AWS SAM templates default to API Gateway Lambda proxy integrations, requiring structured JSON responses from the backend Lambda function, and security credentials requiring rotation should be managed by AWS Secrets Manager.
Question 32Question →

A developer is configuring the deployment settings for a production web application hosted on AWS Elastic Beanstalk. The deployment process must satisfy the following requirements:

1. The new application version must be deployed to a completely separate, temporary Auto Scaling group and pass health checks before serving any production traffic.
2. If health checks fail, the rollback must be automatic, immediate, and leave the existing active instances completely untouched.
3. The deployment must avoid any DNS-level routing changes, such as swapping environment URLs.

Which Elastic Beanstalk deployment policy should the developer select?

Show answer & explanation

Answer: Immutable

Answer

Immutable
The correct option is Immutable because it is the only Elastic Beanstalk deployment policy that satisfies all constraints. It deploys the new version to a separate temporary Auto Scaling group under the same environment and load balancer. It validates the new version's health before directing any production traffic to it. If the health checks fail, the rollback is clean and instant since Elastic Beanstalk simply terminates the temporary Auto Scaling group, leaving the original instances untouched. Furthermore, since it uses the same load balancer, it does not require DNS CNAME swaps.

Step-by-Step Solution

1
Analyze the requirement for deploying to a separate, temporary Auto Scaling group with zero pre-traffic production exposure.
This eliminates Rolling and Rolling with Additional Batch, which update instances within the existing Auto Scaling group.
To ensure the active production instances remain completely untouched until health checks pass, the new version must be isolated initially.
2
Evaluate the requirement for avoiding DNS-level changes.
This eliminates Blue/Green deployments that rely on swapping CNAME URLs at the Route 53 or Elastic Beanstalk environment level.
The deployment must occur within the same Elastic Beanstalk environment under the same load balancer without changing CNAME records.
3
Compare Immutable vs Traffic Splitting and All at Once policies.
All at Once causes downtime. Traffic Splitting immediately routes production traffic to the new version before final promotion. Only Immutable meets all constraints by using a temporary Auto Scaling group under the same load balancer, running health checks, and offering clean rollback by simply terminating the temporary group.
Immutable is the only native Elastic Beanstalk policy that provides zero-downtime, separate temporary ASG testing, and clean rollback without DNS changes.

Key Concept

AWS Elastic Beanstalk Deployment Policies
Question 33Question →

A developer is managing a production database infrastructure stack using AWS CloudFormation. The template defines an Amazon RDS DB instance whose master password must be rotated automatically every 15 days. Additionally, a manual modification to the DB instance's security group settings made via the AWS Console has caused a subsequent CloudFormation stack update to fail, leaving the stack stuck in the UPDATE_ROLLBACK_FAILED state.

How should the developer securely reference the rotated password in the template and resolve the stack update failure?

Show answer & explanation

Answer: Store the password in AWS Secrets Manager and reference it using a dynamic reference in the template. To resolve the UPDATE_ROLLBACK_FAILED state, run the ContinueUpdateRollback action, manually correcting the out-of-band security group changes if necessary to match the expected state.

Answer

Store the password in AWS Secrets Manager and reference it using a dynamic reference in the template. To resolve the UPDATE_ROLLBACK_FAILED state, run the ContinueUpdateRollback action, manually correcting the out-of-band security group changes if necessary to match the expected state.
AWS Secrets Manager is the correct service for credentials that require automatic rotation. By referencing the secret via a dynamic reference in the template, CloudFormation retrieves the rotated credential securely. If an update fails and the rollback gets blocked (UPDATE_ROLLBACK_FAILED state), standard update actions are unavailable. The developer must invoke ContinueUpdateRollback to resume the rollback, manually aligning the out-of-band changes with the expected state to allow the rollback to finish.

Step-by-Step Solution

1
Select the correct credential storage service based on requirements
AWS Secrets Manager is chosen for password storage.
The security requirement states that the password must be rotated every 15 days. AWS Secrets Manager offers native, built-in support for rotating credentials, whereas Systems Manager Parameter Store does not support automated rotation without writing custom Lambda rotation logic.
2
Define the CloudFormation referencing method
Reference the secret using a dynamic reference string in the template.
Using a dynamic reference format like '{{resolve:secretsmanager:secret-id:SecretString:password}}' allows CloudFormation to securely pull the latest rotated password version during deployments without exposing the value in plaintext.
3
Identify the stack troubleshooting procedure
Invoke the ContinueUpdateRollback operation.
When a stack update fails and the subsequent rollback also fails, the stack gets locked in UPDATE_ROLLBACK_FAILED. Regular updates are blocked in this state. The developer must call ContinueUpdateRollback, which allows the rollback to proceed (often requiring manual reconciliation of the drifted resource in the console or CLI to match the rollback target configuration first).

Key Concept

Managing Secrets Manager dynamic references with auto-rotation, and troubleshooting CloudFormation rollback failures caused by drift.
Question 34Question →

A developer is configuring a release pipeline in AWS CodePipeline. The pipeline contains a stage that must invoke an AWS Lambda function to perform deployment validation tests. The developer creates a new IAM role for the pipeline to interact with AWS resources. During the first execution of the pipeline, the run fails at the Lambda stage with an access denied error. The developer verifies that the IAM policy attached to the pipeline's service role explicitly grants the `lambda:InvokeFunction` permission. Which of the following configuration failures is preventing the pipeline from executing the Lambda function?

Show answer & explanation

Answer: The IAM trust policy of the pipeline's service role does not allow the CodePipeline service principal (codepipeline.amazonaws.com) to assume the role.

Answer

The IAM trust policy of the pipeline's service role does not allow the CodePipeline service principal (codepipeline.amazonaws.com) to assume the role.
The correct answer is correct because AWS CodePipeline must assume the pipeline's service role to execute stage actions, such as invoking an AWS Lambda function. If the service role's trust policy does not explicitly permit the CodePipeline service principal (`codepipeline.amazonaws.com`) to perform the `sts:AssumeRole` action, CodePipeline cannot assume the role. As a result, the action will fail with an access denied error, regardless of whether the permission policy attached to the role has the `lambda:InvokeFunction` permission.

Step-by-Step Solution

1
Analyze the error message and current configurations.
The pipeline fails with an access denied error during the Lambda invocation stage, despite the pipeline's IAM role having permissions for `lambda:InvokeFunction`.
This indicates that CodePipeline cannot successfully utilize the role, pointing to an issue with role assumption rather than missing execution permissions.
2
Verify how AWS CodePipeline interacts with IAM roles.
AWS CodePipeline requires a trust relationship (trust policy) to assume the service role associated with the pipeline execution.
An IAM role cannot be assumed by an AWS service unless that service is defined as a trusted entity in the role's trust policy.
3
Identify the missing configuration.
The trust policy of the role must include the `codepipeline.amazonaws.com` service principal to allow the service to perform the `sts:AssumeRole` operation.
Correcting this trust policy resolves the access denied issue and allows CodePipeline to invoke the Lambda function.

Key Concept

AWS CodePipeline requires a properly configured IAM trust policy on its service role to allow the service principal to assume the role and execute stage actions.
Estimated Time:1m 30s
Question 35Question →

A developer is implementing a cross-account continuous delivery pipeline in AWS CodePipeline. The pipeline is located in Account A and uses an Amazon S3 bucket in Account A to store artifacts. The deployment stage is configured to deploy resources into Account B using an AWS CloudFormation action. During pipeline execution, the CloudFormation action in Account B fails with an Access Denied error when trying to retrieve the input artifact zip file from the S3 bucket in Account A. The IAM role used for the CloudFormation deployment in Account B has been granted read permission to the S3 bucket in Account A, and the S3 bucket policy in Account A permits access from Account B's deployment role.

Which configuration change is required to resolve this deployment failure?

Show answer & explanation

Answer: Configure the S3 bucket in Account A to use a customer managed AWS KMS key instead of the default S3 managed key, grant the deployment IAM role in Account B permission to use the KMS key, and update the KMS key policy in Account A to trust Account B's deployment role.

Answer

Configure the S3 bucket in Account A to use a customer managed AWS KMS key instead of the default S3 managed key, grant the deployment IAM role in Account B permission to use the KMS key, and update the KMS key policy in Account A to trust Account B's deployment role.
For cross-account deployments in AWS CodePipeline, artifacts stored in the Amazon S3 bucket must be encrypted using a customer managed AWS KMS key. The default S3 managed key (aws/s3) cannot be shared cross-account because its key policy cannot be modified to grant access to external IAM roles. By configuring a customer managed KMS key, the developer can explicitly grant the deployment IAM role in the destination account permission to decrypt the artifacts.

Step-by-Step Solution

1
Determine why the access is denied despite correct IAM and bucket policies.
The default S3 encryption key (aws/s3) is managed by AWS and its policy cannot be modified to grant cross-account permissions.
Identify the root cause of cross-account decryption failures in CodePipeline.
2
Create a customer managed AWS KMS key in Account A to encrypt the S3 artifact bucket.
The S3 bucket's default encryption is updated to use the new customer managed key.
Allows custom key policies to be configured for cross-account access.
3
Update the KMS key policy in Account A and the IAM deployment role in Account B.
The deployment role in Account B can now decrypt the artifacts when CloudFormation runs in Account B.
Establishes secure, cross-account access to the build artifacts.

Key Concept

AWS CodePipeline Cross-Account Deployments and Artifact Encryption
Estimated Time:2m 30s
Question 36Question →

A developer needs to audit a production environment deployed via AWS CloudFormation because some resources may have been modified manually outside of the stack template. The developer wants to identify these out-of-band changes.

Which of the following actions should the developer perform to detect these modifications? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Run drift detection on the entire CloudFormation stack from the AWS CloudFormation console or the AWS CLI.; Review the drift status details of the stack and individual resources to compare the actual and expected configurations.

Answer

Running drift detection on the CloudFormation stack and reviewing the drift status details to compare actual and expected configurations are the correct methods to identify manual changes.
To identify manual modifications made outside of CloudFormation, a developer can run drift detection on the stack. Reviewing the drift status details shows exactly which resources have drifted and how their actual configuration properties differ from the expected template configuration.

Step-by-Step Solution

1
Initiate a drift detection operation on the target stack.
CloudFormation scans the resources in the stack and compares them to the template definition.
This establishes the current state baseline and flags any discrepancies.
2
Review the drift status results in the console or CLI output.
The developer identifies modified properties, values, and status for drifted resources.
This provides granular details of the changes that were made manually outside of CloudFormation.

Key Concept

AWS CloudFormation Drift Detection
Question 37Question →

A developer is configuring an AWS CodeBuild project for a repository that contains multiple build configurations. The developer needs the project to use a custom build specification file named `buildspec-dev.yml` located inside a nested folder named `config`. How should the developer configure CodeBuild to locate this file?

Show answer & explanation

Answer: Specify the relative path to the file, `config/buildspec-dev.yml`, in the buildspec override setting of the CodeBuild project configuration.

Answer

Specify the relative path to the file, `config/buildspec-dev.yml`, in the buildspec override setting of the CodeBuild project configuration.
To use a buildspec file that has a custom name or is not located in the root of the source directory, the developer must specify the relative path to the file in the buildspec override setting of the CodeBuild project configuration. This instructs CodeBuild where to look for the file within the source code repository.

Step-by-Step Solution

1
Identify the default behavior of AWS CodeBuild regarding the buildspec file.
By default, AWS CodeBuild looks for a file named `buildspec.yml` in the root directory of the source provider.
This is the default convention for running builds without extra configuration.
2
Determine how to modify the buildspec file name or location.
AWS CodeBuild provides a 'buildspec override' configuration option at the project level.
This configuration allows developers to specify a custom buildspec file name or path relative to the root of the source directory.
3
Apply the custom path to the CodeBuild project settings.
Enter the relative path `config/buildspec-dev.yml` in the project's buildspec settings.
This tells CodeBuild exactly where to locate the configuration file for the build execution.

Key Concept

AWS CodeBuild supports overriding the default buildspec file name and location by configuring the buildspec path relative to the repository root.
Estimated Time:1m 0s
Question 38Question →

A developer is configuring an Amazon ECS task definition to deploy a microservice on AWS Fargate. The microservice retrieves database credentials from AWS Secrets Manager by referencing the secret's ARN in the container definition's `secrets` parameter. Additionally, the application code inside the container reads messages from an Amazon SQS queue. The container uses the `awslogs` log driver to send standard output logs to Amazon CloudWatch Logs. Which configuration of IAM roles correctly implements the principle of least privilege for this deployment?

Show answer & explanation

Answer: Configure the Task Execution Role with permissions to retrieve the database credentials from AWS Secrets Manager and write to Amazon CloudWatch Logs. Configure the Task Role with permissions to receive and delete messages from the Amazon SQS queue. Ensure both roles trust the ecs-tasks.amazonaws.com service principal.

Answer

Configure the Task Execution Role with permissions to retrieve the database credentials from AWS Secrets Manager and write to Amazon CloudWatch Logs, configure the Task Role with permissions to receive and delete messages from the Amazon SQS queue, and ensure both roles trust the ecs-tasks.amazonaws.com service principal.
The Task Execution Role grants the ECS agent permissions to pull container images, write logs to CloudWatch using the awslogs log driver, and retrieve secrets from AWS Secrets Manager. The Task Role grants permissions directly to the application running inside the container, allowing it to communicate with Amazon SQS. Both roles must have a trust relationship allowing the ecs-tasks.amazonaws.com service principal to assume them.

Step-by-Step Solution

1
Identify the actions performed by the Amazon ECS container agent during container initialization.
The agent pulls the container image, retrieves the database secret from AWS Secrets Manager to inject as an environment variable, and configures the awslogs log driver to stream stdout/stderr logs to CloudWatch Logs.
Actions performed by the ECS agent before the application runs must be authorized via the Task Execution Role.
2
Identify the actions performed by the application code running inside the container.
The application code makes calls using the AWS SDK to receive and delete messages from the Amazon SQS queue.
Actions performed by the application code itself must be authorized via the Task Role.
3
Determine the correct trust policy for the IAM roles to allow ECS to assume them.
The trust policy must allow the ecs-tasks.amazonaws.com service principal to assume the roles.
The ecs-tasks.amazonaws.com service principal is required for task-level execution and task role assumption, whereas ecs.amazonaws.com is used for the ECS service level operations.

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role, including proper IAM trust policies.
Estimated Time:2m 30s
Question 39Question →

A developer is deploying a containerized microservice to Amazon ECS using the Amazon EC2 launch type. The microservice application code needs to write records to an Amazon DynamoDB table and publish notifications to an Amazon SNS topic. The container also needs to send its standard output and error logs to Amazon CloudWatch Logs. How should the developer configure the IAM roles in the task definition to achieve this configuration securely?

Show answer & explanation

Answer: Assign an IAM role with DynamoDB and SNS write permissions as the Task Role, and assign an IAM role with CloudWatch Logs write permissions as the Task Execution Role.

Answer

Assign an IAM role with DynamoDB and SNS write permissions as the Task Role, and assign an IAM role with CloudWatch Logs write permissions as the Task Execution Role.
The ECS Task Role is assumed by the containers themselves to grant permissions to the application code (e.g., writing to DynamoDB and publishing to SNS). The ECS Task Execution Role is assumed by the ECS agent to perform actions on behalf of the container instance, such as pulling the container image from ECR and sending container logs to CloudWatch Logs. Configuring these roles separately adheres to the principle of least privilege.

Step-by-Step Solution

1
Identify the credentials required by the application code running inside the container.
The application code calls DynamoDB and SNS APIs, which requires permissions to be granted via the ECS Task Role.
The Task Role provides temporary credentials specifically to the processes running inside the container.
2
Identify the credentials required by the ECS agent to manage the container lifecycle.
The ECS agent needs to push container logs to CloudWatch Logs, which requires permissions to be granted via the ECS Task Execution Role.
The Task Execution Role provides permissions for the ECS container agent to perform system-level tasks like pulling images and publishing logs.
3
Verify the trust relationships for both roles.
Both roles must trust the ECS tasks service principal (ecs-tasks.amazonaws.com) to allow ECS to assume them.
Without the correct trust policy, AWS services cannot assume the roles on behalf of the ECS task.

Key Concept

Delineation between Amazon ECS Task Role and Task Execution Role
Question 40Question →

A developer is setting up an in-place deployment of a web application to Amazon EC2 instances using AWS CodeDeploy. The application revision bundle is stored in a private Amazon S3 bucket. During the deployment, the process fails during the DownloadBundle lifecycle event with an Access Denied error. Which action should the developer take to resolve this failure?

Show answer & explanation

Answer: Attach an IAM role that grants s3:GetObject permissions for the S3 bucket to the IAM instance profile of the EC2 instances.

Answer

Attach an IAM role that grants s3:GetObject permissions for the S3 bucket to the IAM instance profile of the EC2 instances.
The correct answer is to attach an IAM role with S3 read permissions to the EC2 instances' instance profile. In AWS CodeDeploy, the CodeDeploy agent runs directly on the EC2 instances. During the DownloadBundle deployment lifecycle event, this agent pulls the application revision bundle from Amazon S3. To authorize this request, the agent utilizes the permissions from the instance profile attached to the EC2 instance, not the CodeDeploy service role.

Step-by-Step Solution

1
Identify which component is downloading the application revision.
The CodeDeploy agent running locally on the Amazon EC2 instances downloads the application revision bundle from the specified Amazon S3 bucket.
Understanding which entity performs the action helps determine which IAM identity needs the permission.
2
Determine the credential source for the CodeDeploy agent.
The CodeDeploy agent uses the permissions attached to the EC2 instance's IAM instance profile.
Since the agent runs on the instance, it relies on the EC2 instance profile to authenticate and authorize its requests to other AWS services like Amazon S3.
3
Grant the minimum required S3 permission to the EC2 instance profile.
Add an IAM policy granting s3:GetObject permissions for the target S3 bucket to the role associated with the EC2 instance profile.
This allows the agent to fetch the bundle successfully during the DownloadBundle event.

Key Concept

CodeDeploy Agent Credentials and EC2 Instance Profiles
PreviousPage 2 / 19Next