Examkin

Deployment

376 questions

All types376Multiple choice191Multiple select171Ordering14
Question 261Question →

A software engineering team is using AWS CloudFormation to deploy a three-tier web application. The application requires a database password that must be rotated automatically every 30 days. Which approach should the developer use to securely reference the database password in the CloudFormation template?

Show answer & explanation

Answer: Retrieve the password using a dynamic reference to AWS Secrets Manager directly within the resource properties in the template.

Answer

Retrieve the password using a dynamic reference to AWS Secrets Manager directly within the resource properties in the template.
Using a dynamic reference to AWS Secrets Manager is the recommended best practice for referencing sensitive data that changes dynamically, such as database credentials that rotate every 30 days. AWS Secrets Manager natively integrates with AWS Lambda to rotate credentials automatically and integrates with CloudFormation templates via dynamic references, preventing plaintext passwords from appearing in the template or stack configuration.

Step-by-Step Solution

1
Identify the requirement for automatic rotation of the database password.
AWS Secrets Manager is identified as the service that natively supports automatic rotation (using AWS Lambda) and integration with CloudFormation.
Systems Manager Parameter Store does not support native rotation schedules for secrets.
2
Determine the secure method to fetch the secret in CloudFormation.
Dynamic references using the 'resolve:secretsmanager' pattern are chosen.
This avoids hardcoding or passing parameters that could be exposed in console logs or template history.
3
Ensure the template avoids manual drift.
Using dynamic references allows CloudFormation to resolve the latest secret value dynamically during deployment operations without requiring manual resource modifications.
Out-of-band updates violate infrastructure-as-code principles.

Key Concept

Using AWS Secrets Manager dynamic references in AWS CloudFormation to secure and automatically rotate database credentials without introducing stack drift.
Question 262Question →

A developer is configuring a deployment for a containerized application to Amazon ECS using AWS CodeDeploy. The developer is writing the AppSpec file in YAML format to manage the lifecycle of the deployment. Which two of the following configurations are valid and supported in the AppSpec file for this Amazon ECS deployment?

Select all that apply

Show answer & explanation

Answer: The resources section specifying the target ECS service name, task definition, container name, and container port.; The hooks section executing AWS Lambda validation functions during events like BeforeAllowTraffic or AfterAllowTraffic.

Answer

The correct configurations are the resources section specifying target service and task definition details, and the hooks section executing AWS Lambda functions during ECS lifecycle events.
For an Amazon ECS deployment, AWS CodeDeploy uses the AppSpec file to determine which ECS task definition to deploy and how to validate traffic routing. The resources section is required to specify details such as the target service, task definition, container name, and container port. The hooks section allows developers to trigger validation Lambda functions at specific points in the blue/green deployment workflow (like BeforeAllowTraffic and AfterAllowTraffic) to ensure the new version is healthy before complete traffic cutover.

Step-by-Step Solution

1
Analyze the target compute platform for the CodeDeploy deployment.
The target platform is Amazon ECS.
The structure and valid parameters of the AppSpec file vary depending on whether the deployment is for EC2/on-premises, AWS Lambda, or Amazon ECS.
2
Determine valid top-level sections for an ECS AppSpec file.
An ECS AppSpec file supports 'version', 'resources', and 'hooks'. It does not support 'files' or 'permissions'.
The resources section defines the ECS task definition and service, while hooks are used to coordinate the blue/green deployment traffic routing.
3
Identify valid lifecycle hooks and execution targets for ECS deployments.
ECS hooks only support AWS Lambda functions as targets. Valid hooks include BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic.
EC2-specific hooks (like ApplicationStart and ApplicationStop) and script execution are unsupported in ECS deployments.

Key Concept

AWS CodeDeploy AppSpec structure for Amazon ECS compute platform
Estimated Time:1m 0s
Question 263Question →

A developer is designing a deployment strategy for a high-traffic web application hosted on Amazon EC2 instances. The company requires a canary deployment strategy where 10%10\% of the production traffic is routed to the new version of the application for validation. The rollout must allow for an immediate rollback to the stable version in the event of an application error, without waiting for client DNS caches to expire.

Which approach should the developer implement to meet these requirements?

Show answer & explanation

Answer: Configure an Application Load Balancer (ALB) with a single listener and two target groups (one for the stable version and one for the new version). Set the listener routing rule to distribute traffic with a weight of 90%90\% to the stable target group and 10%10\% to the new target group.

Answer

Configure an Application Load Balancer (ALB) with a single listener and two target groups (one for the stable version and one for the new version). Set the listener routing rule to distribute traffic with a weight of 90%90\% to the stable target group and 10%10\% to the new target group.
Configuring an Application Load Balancer (ALB) with weighted target groups shifts traffic at the application layer (HTTP/HTTPS). The client resolves a single DNS name for the load balancer, which then determines how to route requests. When a rollback is required, changing the listener rule weight immediately routes all traffic to the stable target group. This occurs instantly at the ALB level, bypassing client-side DNS caching and TTL limitations.

Step-by-Step Solution

1
Analyze the requirement for a canary deployment that routes 10%10\% of traffic to the new version.
The solution must support weighted routing where 90%90\% goes to the stable version and 10%10\% to the new version.
This establishes the target traffic split for validation.
2
Analyze the constraint regarding immediate rollback without waiting for client DNS caches to expire.
DNS-level routing options (such as Route 53 Weighted routing) are disqualified due to DNS cache TTL latencies.
If an error occurs, client browsers that have cached the DNS record pointing to the canary version will continue to send traffic to it, violating the immediate rollback constraint.
3
Select the application-layer routing mechanism that bypasses DNS cache latency.
An Application Load Balancer (ALB) with weighted target groups distributes traffic at the HTTP layer.
Because the client connects to the same ALB DNS name, updating the listener rule to route 100%100\% of traffic back to the stable target group instantly redirects all subsequent requests without any DNS propagation delay.

Key Concept

Application Load Balancer weighted target groups shift traffic at the HTTP layer, bypassing DNS caching limitations during canary deployments.
Question 264Question →

An engineering team is implementing canary deployments for an AWS Lambda function using AWS CodeDeploy. They define the following `appspec.yaml` file to run validation tests on the new function version before traffic is shifted:

yaml
version: 0.0
Resources:
- myLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "myLambdaFunction"
Alias: "live"
CurrentVersion: "1"
TargetVersion: "2"
Hooks:
- BeforeAllowTraffic: "RunSanityCheck"

The CodeDeploy service role has the AWS-managed policy `AWSCodeDeployRoleForLambda` attached. During execution, the deployment immediately fails at the `BeforeAllowTraffic` lifecycle hook event.

Which of the following is the correct explanation for this deployment failure?

Show answer & explanation

Answer: The CodeDeploy service role lacks permissions to invoke the validation function because the AWS-managed policy restricts `lambda:InvokeFunction` to functions prefixed with `CodeDeployHook_`.

Answer

The CodeDeploy service role lacks permissions to invoke the validation function because the AWS-managed policy restricts `lambda:InvokeFunction` to functions prefixed with `CodeDeployHook_`.
The standard AWS-managed policy `AWSCodeDeployRoleForLambda` restricts the `lambda:InvokeFunction` permission to functions whose names start with the prefix `CodeDeployHook_`. Because the validation function is named `RunSanityCheck`, the CodeDeploy service role is not authorized to invoke it, leading to a failure during the `BeforeAllowTraffic` hook execution and triggering an automatic rollback.

Step-by-Step Solution

1
Analyze the AppSpec file for the compute platform target and hooks.
The target is AWS Lambda, and the validation hook `RunSanityCheck` is registered under `BeforeAllowTraffic`.
This confirms the hook placement and names conform to the AWS Lambda AppSpec specification.
2
Examine the IAM permissions of the CodeDeploy service role with `AWSCodeDeployRoleForLambda` attached.
The policy permits `lambda:InvokeFunction` but restricts the resource ARN to `arn:aws:lambda:*:*:function:CodeDeployHook_*`.
This is a security best practice built into the AWS-managed policy to prevent CodeDeploy from executing arbitrary Lambda functions.
3
Compare the validation function name with the policy constraint.
The function name `RunSanityCheck` does not start with `CodeDeployHook_`, triggering an AccessDenied exception during invocation.
Identifying the naming mismatch resolves why the deployment fails at the lifecycle hook execution step.

Key Concept

AWS CodeDeploy Lambda Hook Validation Permissions
Estimated Time:2m 0s
Question 265Question →

A developer is deploying a microservices application to Amazon ECS using the AWS Fargate launch type. The Docker image for the application is hosted in a private Docker Hub repository. The credentials for the private repository are securely stored in AWS Secrets Manager. The developer needs to configure the ECS task definition and IAM permissions so that the Amazon ECS container agent can pull the image during task startup.

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

Select all that apply

Show answer & explanation

Answer: In the container definition of the ECS task definition, configure the repositoryCredentials parameter and set the credentialsParameter property to the ARN of the AWS Secrets Manager secret containing the registry credentials.; Attach an IAM policy to the ECS task execution role that grants the secretsmanager:GetSecretValue permission for the secret, and configure the role's trust policy to trust the ecs-tasks.amazonaws.com service principal.

Answer

The developer must configure the repositoryCredentials parameter in the container definition to reference the Secrets Manager secret ARN, and attach a policy to the Task Execution Role allowing secretsmanager:GetSecretValue with a trust policy for ecs-tasks.amazonaws.com.
To pull container images from private external registries like Docker Hub on ECS Fargate, the container agent requires credentials. The correct procedure is to reference the AWS Secrets Manager secret ARN inside the repositoryCredentials block of the task definition. Because this action is performed by the Amazon ECS container agent before the container runs, the permissions (secretsmanager:GetSecretValue) must be granted to the ECS Task Execution Role, and this role must trust the ecs-tasks.amazonaws.com service principal to allow ECS to assume it.

Step-by-Step Solution

1
Determine which role is responsible for task initialization and image pulling.
The Task Execution Role is identified as the role assumed by the ECS agent to pull images and write logs, whereas the Task Role is for application runtime permissions.
This prevents assigning secret retrieval permissions to the wrong role (Task Role).
2
Identify the proper parameter for private registry authentication in the ECS task definition.
The repositoryCredentials parameter inside the container definition is selected, which requires the ARN of an AWS Secrets Manager secret.
This establishes that SSM Parameter Store is invalid for private registry credentials in ECS.
3
Configure the trust relationship and permissions for the Task Execution Role.
The Task Execution Role is granted secretsmanager:GetSecretValue permission, and its trust policy is configured to trust the ecs-tasks.amazonaws.com service principal.
This allows the ECS service to assume the execution role and retrieve the registry credentials during startup on Fargate.

Key Concept

Configuring private registry authentication on ECS Fargate requires the repositoryCredentials property in the task definition referencing a Secrets Manager secret, and granting the secretsmanager:GetSecretValue permission to the ECS Task Execution Role.
Estimated Time:2m 30s
Question 266Question →

A developer deployed an Amazon EC2 instance and an associated security group using an AWS CloudFormation stack. During a troubleshooting session, the developer manually added a new ingress rule to the security group using the AWS Management Console. The developer now wants to synchronize the CloudFormation stack with these changes to ensure future stack updates do not overwrite or fail due to this modification. Which action should the developer take to resolve this discrepancy?

Show answer & explanation

Answer: Run drift detection on the stack to identify the modifications, update the CloudFormation template to include the new ingress rule, and then perform a stack update.

Answer

Run drift detection on the stack to identify the modifications, update the CloudFormation template to include the new ingress rule, and then perform a stack update.
The correct action is to first identify the drift using the drift detection feature of CloudFormation. Once the drift details are known, the developer must update the template to include the manual modifications and run a stack update. This synchronizes the template definition with the actual resource state without interrupting the service or overwriting the rule.

Step-by-Step Solution

1
Detect drift
Detailed drift status showing that the security group resource has drifted from its template definition due to the manually added ingress rule.
Before making changes, the exact differences between the template and the live resources must be identified.
2
Modify template
The CloudFormation template now contains the new ingress rule in the security group resource definition.
To resolve drift, the template must be updated to align with the desired live state of the resources.
3
Perform stack update
The stack state is updated, and the resource is marked as in-sync.
Running the stack update applying the updated template reconciles the template state with the physical resource state.

Key Concept

CloudFormation Drift Detection and Reconciliation
Estimated Time:1m 30s
Question 267Question →

A developer has updated an API hosted on Amazon API Gateway. To minimize the risk of the new version affecting users, the developer wants to test the update by routing 5%5\% of the incoming API calls to the new version, while the remaining 95%95\% of the traffic goes to the current version. The developer wants to monitor the performance of the new version using CloudWatch and easily promote it to full production once verified. Which approach meets these requirements with the least operational complexity?

Show answer & explanation

Answer: Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to 5%5\%, and promote the canary after verification.

Answer

Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to 5%5\%, and promote the canary after verification.
The correct answer is to configure a canary release on the existing API Gateway stage. When a canary release is enabled, API Gateway automatically routes a specified percentage of API traffic (in this case, 5%5\%) to the new deployment. The developer can monitor the performance of this canary using Amazon CloudWatch metrics and easily promote it to the production release once verified, which requires the least operational effort.

Step-by-Step Solution

1
Identify the deployment target service and the primary goal.
The target is Amazon API Gateway, and the goal is to shift 5%5\% of traffic to a new version of the API and monitor performance.
Understanding the service context helps isolate native features from external workarounds.
2
Evaluate the native deployment features of Amazon API Gateway.
Amazon API Gateway natively supports canary releases directly on an existing deployment stage.
This features allows splitting traffic at the HTTP request level and integrating directly with CloudWatch for testing.
3
Analyze and eliminate alternative architectures based on complexity.
Route 53 weighted routing requires custom domains; Lambda alias routing operates at the backend layer rather than the API stage layer; ALB target groups are structurally redundant and complex.
This confirms that API Gateway canary release is the path of least operational complexity.

Key Concept

API Gateway Canary Deployments
Estimated Time:1m 30s
Question 268Question →

An organization runs a containerized data processing application on an Amazon ECS cluster using the EC2 launch type. The application uses the AWS SDK to interact with an Amazon DynamoDB table. During a security audit, the security team notices that the application is accessing DynamoDB using the credentials of the container host's EC2 instance profile role, rather than the more restrictive IAM role designed specifically for the ECS task. Which configuration issue explains why the application is using the EC2 instance profile credentials?

Show answer & explanation

Answer: The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.

Answer

The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.
The correct answer is that the trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal. When a containerized application uses the AWS SDK, the default credential provider chain searches for task credentials injected by the ECS agent. If the task role's trust relationship is misconfigured to trust EC2 instead of ECS, the ECS agent cannot assume the role, leaving the container credential URI unconfigured. Consequently, the AWS SDK's default credential provider chain falls back to checking the host EC2 instance's metadata endpoint (IMDS) for credentials, which succeeds but uses the host's broader permissions instead of the task-specific permissions.

Step-by-Step Solution

1
Determine how the AWS SDK resolves credentials inside an ECS container.
The SDK checks the AWS default credential chain, which queries the ECS task metadata endpoint (via the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable) before falling back to the EC2 Instance Metadata Service (IMDS).
Understanding the credential resolution hierarchy is key to diagnosing why the SDK defaulted to the host's EC2 instance profile credentials.
2
Analyze why the task-specific credentials were not provided to the container.
The ECS container agent could not retrieve temporary credentials for the task because the IAM role assigned to the task did not permit the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume it.
This identifies why the container credentials relative URI remained empty or was not resolved, prompting the SDK fallback behavior.
3
Identify the misconfiguration in the trust policy.
The IAM role's trust policy allowed the EC2 service principal (ec2.amazonaws.com) instead of the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume the role.
This is a common configuration error where developers confuse the hosting environment (EC2) with the service executing the tasks (ECS).

Key Concept

ECS Task IAM Roles and Service Trust Policies
Question 269Question →

A developer is using AWS CloudFormation to deploy a web application. The template requires a database password that must be retrieved securely without being hardcoded or exposed in plaintext. During the deployment testing phase, the developer also needs to ensure that if any resource fails to create or update, the stack does not automatically revert its changes, allowing the developer to investigate the failed resource state.

Which two actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reference the database password in the template using the dynamic reference pattern for AWS Secrets Manager.; Specify the --disable-rollback parameter when executing the create-stack or update-stack command via the AWS CLI.

Answer

Reference the database password using the AWS Secrets Manager dynamic reference pattern, and specify the --disable-rollback parameter when executing the create-stack or update-stack command via the AWS CLI.
The correct options are referencing the database password using the dynamic reference pattern for AWS Secrets Manager and specifying the --disable-rollback parameter when executing the create-stack or update-stack command. AWS Secrets Manager dynamic references securely fetch credentials at deployment time without exposing them. The --disable-rollback parameter prevents the stack from automatically reverting on failure, preserving the resource state for troubleshooting.

Step-by-Step Solution

1
Secure the database password by storing it in AWS Secrets Manager.
The password is encrypted and managed centrally, avoiding hardcoding.
AWS Secrets Manager is designed for storing sensitive secrets and credentials.
2
Update the CloudFormation template to reference the secret using the dynamic reference syntax: resolve:secretsmanager:secret-id.
CloudFormation retrieves the password dynamically at runtime during stack operations.
This prevents sensitive data from being recorded in the template or stack history.
3
Execute the stack creation or update command with the --disable-rollback CLI option.
If a deployment failure occurs, the stack remains in a failed state rather than rolling back.
This allows the developer to inspect the state and logs of the failed resources directly.

Key Concept

AWS CloudFormation secure parameter resolution and deployment troubleshooting
Question 270Question →

A developer is maintaining an application stack deployed via AWS CloudFormation. A recent stack update failed because a Security Group managed by the stack was manually deleted via the Amazon EC2 console, causing the stack rollback to fail. The stack is currently stuck in the UPDATE_ROLLBACK_FAILED state. The developer needs to return the stack to a stable state so they can apply a new template. Which two actions must the developer perform to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Invoke the ContinueUpdateRollback operation from the AWS CloudFormation console or CLI.; Recreate the manually deleted Security Group with the exact same physical name, or specify the resource to be skipped in the ResourcesToSkip parameter during the rollback continuation.

Answer

To resolve the UPDATE_ROLLBACK_FAILED state, the developer must continue the rollback using the ContinueUpdateRollback operation and either recreate the manually deleted Security Group or specify it as a resource to skip during rollback.
To resolve the UPDATE_ROLLBACK_FAILED state, the developer must continue the rollback using the ContinueUpdateRollback operation. Because the failure was caused by a manually deleted resource (the Security Group), the rollback cannot proceed unless the developer either recreates the resource with the exact same physical ID/name so the rollback process can delete or modify it, or explicitly skips the resource using the ResourcesToSkip parameter.

Step-by-Step Solution

1
Analyze the cause of the rollback failure
Identify that the rollback failed because a Security Group managed by the stack was deleted out-of-band.
CloudFormation attempts to clean up or modify the Security Group during rollback, but cannot find it, causing the rollback to fail.
2
Perform remedial action on the deleted resource
Either recreate the Security Group manually with the exact configuration and physical name, or prepare to skip it during rollback.
This satisfies CloudFormation's expectation of the resource's existence or instructs CloudFormation to ignore it, allowing the rollback to proceed.
3
Trigger ContinueUpdateRollback
Run the continue-update-rollback CLI command (or use the console) specifying the ResourcesToSkip if skipping.
This transitions the stack from UPDATE_ROLLBACK_FAILED back to a stable UPDATE_ROLLBACK_COMPLETE state, enabling future updates.

Key Concept

Resolving UPDATE_ROLLBACK_FAILED state in AWS CloudFormation
Question 271Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline has a deploy stage that deploys a serverless API, followed by an integration test stage that runs an AWS Lambda function. The Lambda function must retrieve a database password that requires automatic rotation every 30 days. Additionally, the Lambda function needs permissions to execute and log to Amazon CloudWatch.

Which two configurations should the developer implement to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and configure automatic rotation.; Configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.

Answer

Store the database password in AWS Secrets Manager and configure automatic rotation, and configure the Lambda function's IAM execution role with a trust policy that allows the lambda.amazonaws.com service principal to assume the role.
Storing the password in AWS Secrets Manager satisfies the requirement for automatic 30-day rotation, as Secrets Manager natively handles automatic rotation via integrated Lambda templates. Additionally, configuring the Lambda function's execution role with a trust policy that allows lambda.amazonaws.com ensures the Lambda service can assume the role at runtime to perform its actions and write logs to CloudWatch.

Step-by-Step Solution

1
Determine the appropriate secret storage service.
AWS Secrets Manager is chosen over Systems Manager Parameter Store.
Only Secrets Manager provides native support for automatic rotation of secrets.
2
Determine the trust relationship for the Lambda execution role.
The trust policy must allow lambda.amazonaws.com to assume the role.
AWS Lambda needs to assume the execution role at runtime to execute the function and perform actions like logging to CloudWatch.

Key Concept

AWS CodePipeline integration with AWS Lambda and secure credential management using AWS Secrets Manager.
Question 272Question →

A developer is using AWS CodeDeploy to deploy a Node.js web application to a fleet of Amazon EC2 instances. During the initial deployment run, the deployment fails.

The developer inspects the deployment console and identifies two root causes:
1. The CodeDeploy service is unable to interact with the EC2 instances to initiate the deployment.
2. A bash script specified in the `appspec.yml` file fails with an access denied error when attempting to retrieve database credentials from AWS Systems Manager Parameter Store.

The application's `appspec.yml` file is configured as follows:

yaml
version: 0.0
os: linux
files:
- source: /index.js
destination: /var/www/html/
hooks:
BeforeInstall:
- location: scripts/decrypt_creds.sh
timeout: 300
runas: dbadmin

Which two configurations must the developer implement to resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the trust policy of the CodeDeploy service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.; Attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions to the IAM role associated with the EC2 instance profile.

Answer

Configure the trust policy of the CodeDeploy service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action, and attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions to the IAM role associated with the EC2 instance profile.
The CodeDeploy service role requires a trust policy allowing the codedeploy.amazonaws.com service principal to assume the role. This permits the service to perform deployment orchestration. When the CodeDeploy agent runs scripts defined under the hooks section on the EC2 instance, the script processes assume the identity of the EC2 instance profile. Therefore, to fetch parameters from the Systems Manager Parameter Store, the instance profile's associated role must have the ssm:GetParameters and ssm:GetParameter permission policies attached.

Step-by-Step Solution

1
Analyze CodeDeploy service permissions.
The CodeDeploy service itself requires an IAM service role to communicate with EC2 instances. The trust relationship for this service role must explicitly permit the codedeploy.amazonaws.com service principal to execute the sts:AssumeRole action.
This establishes trust between CodeDeploy and the IAM role, allowing the service to orchestrate deployments.
2
Determine the execution environment of AppSpec script hooks.
Scripts defined in the AppSpec hooks section run locally on target EC2 instances, executed by the CodeDeploy agent daemon.
This helps locate which IAM role requires permissions to query external AWS APIs during script runs.
3
Assign Parameter Store permissions to the correct entity.
Assign ssm:GetParameter and ssm:GetParameters to the EC2 instance profile role rather than the CodeDeploy service role.
Because the agent running on the EC2 instance executes the decrypt_creds.sh script locally, it uses the credentials supplied by the EC2 instance profile.

Key Concept

AWS CodeDeploy Service Role vs. EC2 Instance Profile Permissions
Question 273Question →

A developer is writing an AWS CloudFormation template to deploy an application on Amazon EC2. The application requires two configurations: a database connection password that is sensitive and must be rotated automatically every 30 days, and an environment-specific application logging level (e.g., DEBUG or INFO) that is non-sensitive and updated frequently. Which configuration strategy should the developer implement in the template to meet these requirements securely and cost-effectively?

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and reference it using a dynamic reference. Store the logging level in Systems Manager Parameter Store and reference it using a Parameter Store dynamic reference.

Answer

Store the database password in AWS Secrets Manager and reference it using a dynamic reference. Store the logging level in Systems Manager Parameter Store and reference it using a Parameter Store dynamic reference.
The correct strategy is to store the sensitive database password requiring automatic rotation in AWS Secrets Manager and reference it via dynamic references, while using Systems Manager Parameter Store for the non-sensitive logging level configuration. This aligns with AWS security best practices and cost optimization recommendations.

Step-by-Step Solution

1
Identify the security and rotation requirements for the database password.
The database password is sensitive and requires automatic rotation every 30 days, which is a native feature of AWS Secrets Manager.
Secrets Manager provides secure storage, built-in rotation integration for databases, and dynamic reference integration with CloudFormation.
2
Identify the requirements for the application logging level setting.
The logging level is non-sensitive, changes frequently, and does not require rotation.
Systems Manager Parameter Store is designed for configuration data and is more cost-effective than Secrets Manager for non-sensitive data.
3
Select the correct CloudFormation referencing mechanisms for both resources.
Reference the database password using a Secrets Manager dynamic reference and the logging level using a Parameter Store dynamic reference.
This combined approach maximizes security for secrets while optimizing costs for non-sensitive parameters.

Key Concept

CloudFormation dynamic references for AWS Secrets Manager and Systems Manager Parameter Store
Question 274Question →

A developer is configuring a blue/green deployment for an Amazon Elastic Container Service (Amazon ECS) service using AWS CodeDeploy. The deployment must shift traffic to the new task set gradually to allow for monitoring, but the entire deployment process must finish shifting 100%100\% of the traffic in less than 1010 minutes.

Which TWO predefined deployment configurations will meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: CodeDeployDefault.ECSLinear10PercentEvery1Minute; CodeDeployDefault.ECSCanary10Percent5Minutes

Answer

The configurations CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes meet the requirements.
The correct configurations are CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes. The linear configuration shifts 10%10\% of traffic each minute, completing the transition in 99 minutes. The canary configuration shifts 10%10\% first, waits 55 minutes, and then shifts the remaining 90%90\%, completing the transition in 55 minutes. Both configurations satisfy the requirements of shifting traffic gradually and completing the deployment in less than 1010 minutes.

Step-by-Step Solution

1
Analyze the requirement to shift traffic gradually.
Discard the all-at-once configuration since it shifts traffic immediately and does not allow for gradual transition or monitoring.
Gradual shifting is a strict constraint specified in the prompt.
2
Calculate the total traffic shifting duration for each remaining configuration.
The 1-minute linear configuration takes 99 minutes, the 5-minute canary configuration takes 55 minutes, the 3-minute linear configuration takes 2727 minutes, and the 15-minute canary configuration takes 1515 minutes.
This determines which configurations complete within the required 10-minute window.
3
Select the configurations that meet the duration constraint.
The 1-minute linear configuration and the 5-minute canary configuration both complete in less than 1010 minutes.
Only these two configurations satisfy both the gradual shifting and the time constraint of less than 10 minutes.

Key Concept

AWS CodeDeploy ECS Deployment Configurations
Question 275Question →

A developer is maintaining a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, and Deploy stages. The Deploy stage uses AWS CodeDeploy to release updates to an Amazon ECS service. The developer needs to temporarily prevent new builds from being deployed to ECS while the production database undergoes a scheduled maintenance window. However, developers must still be able to commit code changes, and the pipeline must continue to run the Source and Build stages to validate the builds. Which configuration change should the developer make to achieve this goal with the least administrative effort?

Show answer & explanation

Answer: Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.

Answer

Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.
Disabling the transition between stages in AWS CodePipeline prevents new executions from entering the target stage (Deploy) while allowing preceding stages (Source, Build) to complete successfully. The pipeline execution stops at the boundary, and once the maintenance is complete, the transition can be re-enabled to allow the latest build artifact to progress to the Deploy stage automatically.

Step-by-Step Solution

1
Identify the requirement to pause deployments at a specific stage while allowing earlier stages (Source, Build) to continue execution.
Determine that stopping the entire pipeline or causing errors in subsequent stages is undesirable.
The requirement states that developers must still commit code and runs must occur in the Source and Build stages.
2
Evaluate CodePipeline's built-in control mechanisms.
Recognize that stage transitions can be disabled to prevent executions from moving from one stage to another.
Disabling transitions is a native feature that cleanly halts the pipeline progress at a boundary without failing the running execution or the pipeline itself.
3
Configure the transition control in the AWS Management Console or via the AWS CLI.
Disable the transition between the Build and Deploy stages, and re-enable it after the database maintenance is complete.
This satisfies the requirement with the least administrative effort and without altering IAM roles or application logic.

Key Concept

AWS CodePipeline Stage Transitions
Question 276Question →

A developer is configuring a deployment to shift traffic to a new version of an AWS Lambda function using AWS CodeDeploy. The deployment group is configured with an IAM service role. When the deployment is initiated, the developer encounters an error during the initial validation of the AppSpec file, and the deployment is aborted. The AppSpec file is configured as follows:

yaml
version: 0.0
Resources:
- MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "MyServiceFunction"
Alias: "live"
CurrentVersion: "1"
TargetVersion: "2"
Hooks:
- BeforeInstall: "ValidationFunction"

What is the reason for this deployment failure?

Show answer & explanation

Answer: The AppSpec file specifies 'BeforeInstall' under the 'Hooks' section, which is a lifecycle hook reserved for EC2/on-premises and ECS deployments and is invalid for AWS Lambda deployments.

Answer

The AppSpec file specifies 'BeforeInstall' under the 'Hooks' section, which is a lifecycle hook reserved for EC2/on-premises and ECS deployments and is invalid for AWS Lambda deployments.
The correct option is correct because AWS CodeDeploy deployments for the Lambda compute platform only support the 'BeforeAllowTraffic' and 'AfterAllowTraffic' lifecycle hooks. Hook names such as 'BeforeInstall', 'AfterInstall', and 'AfterAllowTestTraffic' are invalid for Lambda deployments (though they are valid for ECS or EC2/on-premises deployments). Specifying an invalid hook causes the AppSpec validation to fail before the deployment can proceed.

Step-by-Step Solution

1
Inspect the resources and hooks sections of the AppSpec file.
Identify that the resource type is 'AWS::Lambda::Function' and the hook is 'BeforeInstall'.
AWS CodeDeploy supports different hooks depending on the target compute platform.
2
Recall the valid lifecycle hooks for AWS Lambda deployments in AWS CodeDeploy.
Lambda deployments only support 'BeforeAllowTraffic' and 'AfterAllowTraffic'.
Other hooks like 'BeforeInstall' are only applicable to EC2/on-premises or ECS platforms.
3
Identify why the validation failed based on the hook mismatch.
The presence of 'BeforeInstall' causes the AppSpec validation to fail immediately.
CodeDeploy rejects AppSpec files containing invalid hooks for the specified resource type.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks for AWS Lambda deployments
Question 277Question →

A developer is preparing to deploy a containerized backend application to Amazon ECS using the AWS Fargate launch type. The application must process incoming requests and write transaction records directly to an Amazon DynamoDB table. The container image is stored in a private Amazon Elastic Container Registry (Amazon ECR) repository. Additionally, the task definition is configured to use the awslogs log driver to stream container logs to Amazon CloudWatch Logs. Which configuration steps must the developer perform to ensure that the task has the minimum required permissions to initialize and run successfully? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure an IAM role (Task Role) that grants permissions for dynamodb:PutItem and dynamodb:UpdateItem, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the taskRoleArn parameter in the task definition.; Configure an IAM role (Task Execution Role) that grants permissions for ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, logs:CreateLogStream, and logs:PutLogEvents, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the executionRoleArn parameter in the task definition.

Answer

The developer must configure a Task Role with DynamoDB permissions and assign it to taskRoleArn, and configure a Task Execution Role with ECR and CloudWatch Logs permissions and assign it to executionRoleArn.
The correct options properly separate application-level permissions (assigned to the Task Role via taskRoleArn) from infrastructure/agent-level permissions (assigned to the Task Execution Role via executionRoleArn). Under the Fargate launch type, both roles must trust the ecs-tasks.amazonaws.com service principal.

Step-by-Step Solution

1
Determine application code requirements.
The application code running inside the container needs to write to Amazon DynamoDB, requiring dynamodb:PutItem and dynamodb:UpdateItem permissions.
Application-level permissions must be defined in the Task Role (taskRoleArn).
2
Determine container orchestration requirements.
The ECS container agent needs to pull the image from a private Amazon ECR repository and send logs to CloudWatch Logs, requiring ECR pull permissions and CloudWatch logs permission.
Agent-level and launch-level permissions must be defined in the Task Execution Role (executionRoleArn).
3
Verify trust policy for ECS Fargate.
Both IAM roles must trust the ecs-tasks.amazonaws.com service principal.
AWS Fargate is a serverless execution environment where tasks are managed directly by ECS, meaning the roles must trust the ECS tasks principal rather than the EC2 instance principal.

Key Concept

ECS Task Role vs Task Execution Role
Question 278Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline builds a database migration package in AWS CodeBuild and then runs a post-migration check using an AWS Lambda function. The CodeBuild project must retrieve a database password stored as a SecureString in AWS Systems Manager Parameter Store. The Lambda function must report its execution status back to CodePipeline.

Arrange the execution steps in the correct chronological order from start to finish to ensure the pipeline runs successfully without permission or credential failures.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The pipeline first pulls the source code, then CodeBuild retrieves and decrypts the database password from Parameter Store, next the Lambda service assumes the Lambda execution role to run, and finally the Lambda function invokes PutJobSuccessResult to notify CodePipeline of completion.
The correct order requires pulling the source code first, then allowing CodeBuild to assume its service role and decrypt the SecureString from Parameter Store using AWS KMS. After CodeBuild completes, CodePipeline invokes the Lambda function. The Lambda service assumes the execution role (which requires a trust relationship with lambda.amazonaws.com), and once the code runs, the function must explicitly report success to CodePipeline using PutJobSuccessResult.

Step-by-Step Solution

1
Source artifact generation
Source code is successfully fetched and packaged.
AWS CodePipeline requires a source artifact to trigger downstream stages.
2
CodeBuild retrieves secure credentials
The decrypted database password is loaded into CodeBuild's environment.
CodeBuild needs credentials to run the migration; the CodeBuild service role must have permissions to decrypt the KMS key used by the SecureString parameter.
3
Lambda function execution
The Lambda service assumes the execution role and runs the verification code.
The Lambda execution role must trust the lambda.amazonaws.com service principal to execute the code.
4
CodePipeline status notification
CodePipeline receives a success result and completes the action.
Asynchronous Lambda actions in CodePipeline do not auto-complete; they require a PutJobSuccessResult call to advance the pipeline.

Key Concept

AWS CodePipeline execution flow, secure parameter retrieval, and service role trust configurations.
Estimated Time:1m 30s
Question 279Question →

A developer is configuring an Amazon ECS task definition to deploy an application on AWS Fargate. The container needs to retrieve a database password from AWS Systems Manager Parameter Store during container startup to set it as an environment variable. Once the container is running, the application code uses the AWS SDK to write application logs to an Amazon DynamoDB table. Which combination of configuration steps and IAM roles should the developer configure?

Show answer & explanation

Answer: Configure the ECS Task Execution Role with permissions to retrieve the parameter from Systems Manager Parameter Store, configure the ECS Task Role with permissions to perform DynamoDB operations, and configure the trust policy of both roles to allow the ecs-tasks.amazonaws.com service to assume them.

Answer

Configure the ECS Task Execution Role with permissions to retrieve the parameter from Systems Manager Parameter Store, configure the ECS Task Role with permissions to perform DynamoDB operations, and configure the trust policy of both roles to allow the ecs-tasks.amazonaws.com service to assume them.
The correct configuration requires assigning permissions to retrieve the Systems Manager Parameter Store parameter to the ECS Task Execution Role, because the ECS agent must fetch this value during the container setup phase. The ECS Task Role must be configured with permissions for the DynamoDB operations because this role is used by the application code running inside the container to call AWS services. Additionally, both roles require a trust relationship with the ecs-tasks.amazonaws.com service principal so that Amazon ECS can assume them.

Step-by-Step Solution

1
Identify the credentials needed at container start time versus application runtime.
The ECS agent requires permissions during startup to fetch the database password from Parameter Store (requiring the Task Execution Role), while the application code needs permissions to write logs to DynamoDB at runtime (requiring the Task Role).
Delineating between task execution and application runtime roles aligns with the principle of least privilege and container security architecture.
2
Define IAM policies for the Task Execution Role and the Task Role.
Create a policy allowing ssm:GetParameters and ssm:GetParameter for the Task Execution Role, and a policy allowing dynamodb:PutItem or dynamodb:BatchWriteItem for the Task Role.
The Task Execution Role performs operations before the container starts, whereas the Task Role handles application-level API requests.
3
Configure trust policies for both IAM roles.
Set the trust relationship service principal to ecs-tasks.amazonaws.com for both roles.
This allows the ECS service to assume the roles when launching and running the Fargate tasks.

Key Concept

ECS Task Role vs. ECS Task Execution Role
Estimated Time:1m 30s
Question 280Question →

A developer is managing an AWS CloudFormation stack for a web application. The application requires a database password that must be rotated automatically every 30 days. During a stack update to modify the application configuration, a database connection error causes the update to fail, leaving the stack stuck in the UPDATE_ROLLBACK_FAILED state. Which combination of actions should the developer take to securely retrieve the database password in the template and resolve the failed stack update?

Show answer & explanation

Answer: Reference the database password in the template using a dynamic reference to AWS Secrets Manager, resolve the database connection issue, and run the ContinueUpdateRollback command.

Answer

Reference the database password in the template using a dynamic reference to AWS Secrets Manager, resolve the database connection issue, and run the ContinueUpdateRollback command.
The correct answer combines retrieving rotated secrets using Secrets Manager dynamic references with recovering a stuck stack using the ContinueUpdateRollback command. Secrets Manager supports automatic secret rotation, and dynamic references securely fetch these secrets without exposing them. When a stack is in the UPDATE_ROLLBACK_FAILED state, it cannot be updated directly; the underlying issue must be fixed, and ContinueUpdateRollback must be run to complete the rollback to a stable state.

Step-by-Step Solution

1
Select the correct secrets retrieval mechanism.
Identify that AWS Secrets Manager supports dynamic references and automatic rotation, unlike Parameter Store which is not designed for native secret rotation.
The requirement specifies that the database password must be rotated automatically every 30 days.
2
Identify the mechanism to resolve the stack rollback failure.
Determine that a stack stuck in UPDATE_ROLLBACK_FAILED cannot be updated directly and requires a ContinueUpdateRollback operation after fixing the underlying resource issue.
CloudFormation blocks new stack updates until the stack returns to a stable state (e.g., UPDATE_ROLLBACK_COMPLETE).

Key Concept

AWS CloudFormation Stack Rollback Resolution and Secrets Management Integration
PreviousPage 14 / 19Next
Deployment Practice Questions — AWS Certified Developer - Associate — Page 14 | Examkin