Practice Free DVA-C02 Exam Online Questions
Question #141
A developer is testing an AWS Lambda function by using the AWS SAM local CLI. The application that is implemented by the Lambda function makes several AWS API calls by using the AWS SDK. The developer wants to allow the function to make AWS API calls in a test AWS account from the developer’s laptop.
What should the developer do to meet these requirements?
- A . Edit the template.yml file. Add the AWS_ACCESS_KEY_ID property and the AWS_SECRET_ACCESS_KEY property in the Globals section.
- B . Add a test profile by using the aws configure command with the –profile option. Run AWS SAM by using sam local invoke with the –profile option.
- C . Edit the template.yml file. For the AWS: : Serverless: : Function resource, set the role to an IAM role in the AWS account.
- D . Run the function by using sam local invoke. Override the AWS_ACCESS_KEY_ID parameter and the AWS_SECRET_ACCESS_KEY parameter by specifying the –parameter-overrides option.
Correct Answer: B
B
Explanation:
When using AWS SAM local (sam local invoke, sam local start-api), the Lambda code runs in a local container on the developer’s machine. If that code uses the AWS SDK to call AWS services, it needs AWS credentials available in the local environment. The recommended way is to rely on the AWS SDK’s standard credential provider chain, which includes credentials stored by the AWS CLI in ~/.aws/credentials and selected via a named profile.
By running aws configure –profile <profileName>, the developer creates a dedicated set of access keys (and optionally a session token/region) for the test account. Then, running SAM with sam local invoke –profile <profileName> causes SAM to supply those credentials to the local container so the function can authenticate to AWS and make real API calls in the intended test account. This approach is clean, repeatable, and avoids hardcoding secrets into templates or source code.
Option A is insecure and not the intended use of SAM templates; templates are infrastructure definitions, not secret stores.
Option C sets the Lambda execution role for deployed functions in AWS, but it does not automatically grant credentials to code running locally on a laptop.
Option D misuses –parameter-overrides, which is meant for overriding template parameters at deployment/build time, not for securely injecting AWS access keys into local execution.
Therefore, the correct approach is B: configure an AWS CLI profile and run SAM local with the — profile option so the Lambda code can call AWS APIs in the test account using standard credential handling.
B
Explanation:
When using AWS SAM local (sam local invoke, sam local start-api), the Lambda code runs in a local container on the developer’s machine. If that code uses the AWS SDK to call AWS services, it needs AWS credentials available in the local environment. The recommended way is to rely on the AWS SDK’s standard credential provider chain, which includes credentials stored by the AWS CLI in ~/.aws/credentials and selected via a named profile.
By running aws configure –profile <profileName>, the developer creates a dedicated set of access keys (and optionally a session token/region) for the test account. Then, running SAM with sam local invoke –profile <profileName> causes SAM to supply those credentials to the local container so the function can authenticate to AWS and make real API calls in the intended test account. This approach is clean, repeatable, and avoids hardcoding secrets into templates or source code.
Option A is insecure and not the intended use of SAM templates; templates are infrastructure definitions, not secret stores.
Option C sets the Lambda execution role for deployed functions in AWS, but it does not automatically grant credentials to code running locally on a laptop.
Option D misuses –parameter-overrides, which is meant for overriding template parameters at deployment/build time, not for securely injecting AWS access keys into local execution.
Therefore, the correct approach is B: configure an AWS CLI profile and run SAM local with the — profile option so the Lambda code can call AWS APIs in the test account using standard credential handling.
Question #142
An ecommerce company integrates with a payment processing service that publishes payment activity messages to an Amazon SNS topic. A developer is building an AWS Lambda function to process refund events. The Lambda function must process only refund-related messages.
Which solution will meet this requirement in the MOST operationally efficient way?
- A . Configure a Lambda event filter to allow only refund messages to invoke the function.
- B . Add logic in the Lambda function to ignore non-refund messages.
- C . Use Amazon SNS subscription filter policies to deliver only refund messages to the Lambda function.
- D . Increase batch size and batching window parameters for the Lambda function.
Correct Answer: C
C
Explanation:
Amazon SNS subscription filter policies are designed to control which messages are delivered to subscribers based on message attributes. AWS documentation recommends using subscription filters to reduce unnecessary downstream processing and cost.
By configuring a filter policy on the SNS subscription, only messages that match refund-specific attributes are sent to the Lambda function. This ensures that the Lambda function is invoked only when required, eliminating wasted invocations and simplifying the function logic.
Option A is incorrect because Lambda event filtering applies to services such as SQS and DynamoDB Streams, not directly to SNS.
Option B increases invocation cost and code complexity.
Option D does not filter messages and does not address the requirement.
Therefore, SNS subscription filter policies provide the cleanest, most efficient, and AWS-recommended solution.
C
Explanation:
Amazon SNS subscription filter policies are designed to control which messages are delivered to subscribers based on message attributes. AWS documentation recommends using subscription filters to reduce unnecessary downstream processing and cost.
By configuring a filter policy on the SNS subscription, only messages that match refund-specific attributes are sent to the Lambda function. This ensures that the Lambda function is invoked only when required, eliminating wasted invocations and simplifying the function logic.
Option A is incorrect because Lambda event filtering applies to services such as SQS and DynamoDB Streams, not directly to SNS.
Option B increases invocation cost and code complexity.
Option D does not filter messages and does not address the requirement.
Therefore, SNS subscription filter policies provide the cleanest, most efficient, and AWS-recommended solution.
Question #143
A developer is managing an application that uploads user files to an Amazon S3 bucket named companybucket. The company wants to maintain copies of all the files uploaded by users for compliance purposes, while ensuring users still have access to the data through the application.
Which IAM permissions should be applied to users to ensure they can create but not remove files from the bucket?
- A . {"Version": "2012-10-17","Statement": [{"Sid": "statement1","Effect": "Allow","Action": ["s3: GetObject", "s3: PutObject", "s3: DeleteObject"],"Resource": ["arn: aws: s3: : : companybucket"]}]}
- B . {"Version": "2012-10-17","Statement": [{"Sid": "statement1","Effect": "Allow","Action": ["s3: CreateBucket", "s3: GetBucketLocation"],"Resource": "arn: aws: s3: : : companybucket"}]}
- C . {"Version": "2012-10-17","Statement": [{"Sid": "statement1","Effect": "Allow","Action": ["s3: GetObject", "s3: PutObject", "s3: DeleteObject", "s3: PutObjectRetention"],"Resource": "arn: aws: s3: : : companybucket"}]}
- D . {"Version": "2012-10-17","Statement": [{"Sid": "statement1","Effect": "Allow","Action": ["s3: GetObject", "s3: PutObject"],"Resource": ["arn: aws: s3: : : companybucket"]}]}
Correct Answer: D
D
Explanation:
To meet the requirement:
Users must be able to upload (PutObject) and read (GetObject) files but not delete them.
Option D ensures users cannot delete files by omitting the s3: DeleteObject action while allowing s3: GetObject and s3: PutObject.
Option A: Includes s3: DeleteObject, which allows users to delete files and does not meet the requirement.
Option B: Contains unrelated actions like CreateBucket, which is not relevant here.
Option C: Adds s3: PutObjectRetention, which is unnecessary and does not restrict DeleteObject.
Reference: AWS S3 Permissions Documentation
D
Explanation:
To meet the requirement:
Users must be able to upload (PutObject) and read (GetObject) files but not delete them.
Option D ensures users cannot delete files by omitting the s3: DeleteObject action while allowing s3: GetObject and s3: PutObject.
Option A: Includes s3: DeleteObject, which allows users to delete files and does not meet the requirement.
Option B: Contains unrelated actions like CreateBucket, which is not relevant here.
Option C: Adds s3: PutObjectRetention, which is unnecessary and does not restrict DeleteObject.
Reference: AWS S3 Permissions Documentation
Question #144
A company hosts a batch processing application on AWS Elastic Beanstalk with instances that run the most recent version of Amazon Linux. The application sorts and processes large datasets. In recent weeks, the application’s performance has decreased significantly during a peak period for traffic. A developer suspects that the application issues are related to the memory usage. The developer checks the Elastic Beanstalk console and notices that memory usage is not being tracked.
How should the developer gather more information about the application performance issues?
- A . Configure the Amazon CloudWatch agent to push logs to Amazon CloudWatch Logs by using port 443.
- B . Configure the Elastic Beanstalk .ebextensions directory to track the memory usage of the instances.
- C . Configure the Amazon CloudWatch agent to track the memory usage of the instances.
- D . Configure an Amazon CloudWatch dashboard to track the memory usage of the instances.
Correct Answer: C
C
Explanation:
To monitor memory usage in Amazon Elastic Beanstalk environments, it’s important to understand that default Elastic Beanstalk monitoring capabilities in Amazon CloudWatch do not track memory usage, as memory metrics are not collected by default. Instead, the Amazon CloudWatch agent must be configured to collect memory usage metrics.
Why Option C is Correct:
The Amazon CloudWatch agent can be installed and configured to monitor system-level metrics such as memory and disk utilization.
To enable memory tracking, developers need to install the CloudWatch agent on the Amazon Elastic Compute Cloud (EC2) instances associated with the Elastic Beanstalk environment.
After installation, the agent can be configured to collect memory metrics, which can then be sent to CloudWatch for further analysis.
How to Implement This Solution:
Install the CloudWatch Agent: Use .ebextensions or AWS Systems Manager to install and configure the CloudWatch agent on the EC2 instances running in the Elastic Beanstalk environment.
Modify CloudWatch Agent Configuration: Create a config.json file that specifies memory usage tracking and other desired metrics.
Enable Metrics Reporting: The CloudWatch agent can push the metrics to CloudWatch, where they can be monitored.
Why Other Options are Incorrect:
Option A: Configuring the agent to push logs is not sufficient to track memory metrics. This option addresses logging but not system-level metrics like memory usage.
Option B: The .ebextensions directory is used to customize Elastic Beanstalk environments but does not directly track memory metrics without additional configuration of the CloudWatch agent.
Option D: Configuring a CloudWatch dashboard will only visualize the metrics that are already being collected. It will not enable memory usage tracking.
AWS Documentation
Reference: Amazon CloudWatch Agent Overview
Elastic Beanstalk Customization Using .ebextensions
Monitoring Custom Metrics
C
Explanation:
To monitor memory usage in Amazon Elastic Beanstalk environments, it’s important to understand that default Elastic Beanstalk monitoring capabilities in Amazon CloudWatch do not track memory usage, as memory metrics are not collected by default. Instead, the Amazon CloudWatch agent must be configured to collect memory usage metrics.
Why Option C is Correct:
The Amazon CloudWatch agent can be installed and configured to monitor system-level metrics such as memory and disk utilization.
To enable memory tracking, developers need to install the CloudWatch agent on the Amazon Elastic Compute Cloud (EC2) instances associated with the Elastic Beanstalk environment.
After installation, the agent can be configured to collect memory metrics, which can then be sent to CloudWatch for further analysis.
How to Implement This Solution:
Install the CloudWatch Agent: Use .ebextensions or AWS Systems Manager to install and configure the CloudWatch agent on the EC2 instances running in the Elastic Beanstalk environment.
Modify CloudWatch Agent Configuration: Create a config.json file that specifies memory usage tracking and other desired metrics.
Enable Metrics Reporting: The CloudWatch agent can push the metrics to CloudWatch, where they can be monitored.
Why Other Options are Incorrect:
Option A: Configuring the agent to push logs is not sufficient to track memory metrics. This option addresses logging but not system-level metrics like memory usage.
Option B: The .ebextensions directory is used to customize Elastic Beanstalk environments but does not directly track memory metrics without additional configuration of the CloudWatch agent.
Option D: Configuring a CloudWatch dashboard will only visualize the metrics that are already being collected. It will not enable memory usage tracking.
AWS Documentation
Reference: Amazon CloudWatch Agent Overview
Elastic Beanstalk Customization Using .ebextensions
Monitoring Custom Metrics
Question #145
A developer has an application that asynchronously invokes an AWS Lambda function. The developer wants to store messages that resulted in failed invocations of the Lambda function so that the application can retry the call later.
What should the developer do to accomplish this goal with the LEAST operational overhead?
- A . Set up CloudWatch Logs log groups to filter and store the messages in an S3 bucket. Import the messages in Lambda. Run the Lambda function again.
- B . Configure Amazon EventBridge to send the messages to Amazon SNS to initiate the Lambda function again.
- C . Implement a dead-letter queue for discarded messages. Set the dead-letter queue as an event source for the Lambda function.
- D . Send Amazon EventBridge events to an Amazon SQS queue. Configure the Lambda function to pull messages from the SQS queue. Run the Lambda function again.
Correct Answer: C
C
Explanation:
For asynchronous Lambda invocations, AWS provides built-in failure handling options that require minimal code and minimal operational work. When an async invocation fails (after Lambda’s internal retry behavior), the event can be sent to a dead-letter queue (DLQ) so it is not lost. A DLQ is the standard mechanism for capturing events that could not be processed successfully, preserving the original payload for later inspection and reprocessing.
Using a DLQ (typically Amazon SQS or Amazon SNS) gives durable storage of failed events and decouples failure recovery from the main execution path. The developer can later re-drive the messages by building a simple replay process, such as moving messages from the DLQ back to the original event source or invoking the function again with the stored payloads. This aligns with the requirement: “store messages that resulted in failed invocations so the application can retry later.”
Among the options, C is the only one that uses Lambda’s native async failure capture mechanism.
Options A and B introduce unnecessary complexity and do not reliably store the original failed invocation payloads as a first-class workflow (CloudWatch Logs is not a message queue, and EventBridge→SNS doesn’t automatically capture only failed events from Lambda async invocations).
Option D changes the architecture to an SQS pull model for the Lambda function; while valid, it is more than needed and adds design/operational considerations (polling, batching, visibility timeouts, DLQ configuration on the queue, etc.) compared with simply enabling DLQ support for async invokes.
Therefore, the least operational overhead solution is C: configure a dead-letter queue for the Lambda function’s asynchronous invocations so failed events are stored for later retry.
C
Explanation:
For asynchronous Lambda invocations, AWS provides built-in failure handling options that require minimal code and minimal operational work. When an async invocation fails (after Lambda’s internal retry behavior), the event can be sent to a dead-letter queue (DLQ) so it is not lost. A DLQ is the standard mechanism for capturing events that could not be processed successfully, preserving the original payload for later inspection and reprocessing.
Using a DLQ (typically Amazon SQS or Amazon SNS) gives durable storage of failed events and decouples failure recovery from the main execution path. The developer can later re-drive the messages by building a simple replay process, such as moving messages from the DLQ back to the original event source or invoking the function again with the stored payloads. This aligns with the requirement: “store messages that resulted in failed invocations so the application can retry later.”
Among the options, C is the only one that uses Lambda’s native async failure capture mechanism.
Options A and B introduce unnecessary complexity and do not reliably store the original failed invocation payloads as a first-class workflow (CloudWatch Logs is not a message queue, and EventBridge→SNS doesn’t automatically capture only failed events from Lambda async invocations).
Option D changes the architecture to an SQS pull model for the Lambda function; while valid, it is more than needed and adds design/operational considerations (polling, batching, visibility timeouts, DLQ configuration on the queue, etc.) compared with simply enabling DLQ support for async invokes.
Therefore, the least operational overhead solution is C: configure a dead-letter queue for the Lambda function’s asynchronous invocations so failed events are stored for later retry.
Question #146
A developer has a financial application. The application uses AWS Secrets Manager to manage an Amazon RDS for PostgreSQL database’s username and password. The developer needs to rotate the
password while maintaining the application’s high availability.
Which solution will meet these requirements with LEAST development effort?
- A . Rotate the secret by using the alternating-users rotation strategy. Update the application with an appropriate retry strategy to handle authentication failures.
- B . Use the PostgreSQL client to create a new database username and password. Include the new secret values by performing an immediate rotation. Use the AWS CLI to update the RDS database password. Perform an immediate rotation of the Secrets Manager secrets.
- C . Rotate the secret by using multivalue answer rotation. Update the application with an appropriate retry strategy to handle authentication failures.
- D . Rotate the secret by using the single-user rotation strategy. Update the application with an appropriate retry strategy to handle authentication failures.
Correct Answer: D
D
Explanation:
Requirement Summary:
Secrets managed in AWS Secrets Manager
DB: Amazon RDS for PostgreSQL
Need automated password rotation
Must maintain high availability
Least development effort
Rotation Strategies:
Single-user rotation strategy
Simplest to implement
The secret contains one set of credentials used by app and rotation logic
Supports automated rotation
AWS provides built-in Lambda rotation templates for RDS
D
Explanation:
Requirement Summary:
Secrets managed in AWS Secrets Manager
DB: Amazon RDS for PostgreSQL
Need automated password rotation
Must maintain high availability
Least development effort
Rotation Strategies:
Single-user rotation strategy
Simplest to implement
The secret contains one set of credentials used by app and rotation logic
Supports automated rotation
AWS provides built-in Lambda rotation templates for RDS
Question #147
A developer manages a serverless application that uses an AWS Lambda function. The application periodically interacts with an external API by using short-lived authentication keys. Currently, the developer embeds the authentication keys directly in the Lambda function code. This approach requires manual updates and introduces security risks and operational inefficiencies.
The developer needs a secure and automated solution for authentication key storage, retrieval, and
rotation.
Which solution will meet these requirements?
- A . Store the authentication keys in AWS Secrets Manager. Configure the Lambda function to retrieve and cache the keys by using Lambda extensions.
- B . Store the authentication keys in an Amazon S3 bucket. Configure the Lambda function to retrieve the keys from the bucket during each invocation.
- C . Store the authentication keys in Lambda environment variables and manually update the values when needed.
- D . Store the authentication keys in AWS Systems Manager Parameter Store. Configure the Lambda function to retrieve the keys during every invocation.
Correct Answer: A
A
Explanation:
AWS Secrets Manager is purpose-built for securely storing and managing sensitive information such as API keys, tokens, and credentials. It provides automatic secret rotation, fine-grained IAM access control, encryption at rest using AWS KMS, and audit logging through AWS CloudTrail. This makes it the most secure and scalable option for managing short-lived authentication keys.
AWS Lambda extensions enable efficient secret retrieval by caching secrets locally within the execution environment. This reduces repeated calls to Secrets Manager on every invocation, improving performance and lowering costs while maintaining up-to-date credentials. AWS documentation explicitly recommends using Lambda extensions or caching logic for secrets that are frequently accessed.
Storing secrets in S3 (Option B) or environment variables (Option C) lacks built-in rotation and increases exposure risk. Parameter Store (Option D) supports encryption but does not provide native rotation for secrets without custom automation, making it less suitable for this use case.
Therefore, Secrets Manager with Lambda extensions provides the most secure, automated, and operationally efficient solution.
A
Explanation:
AWS Secrets Manager is purpose-built for securely storing and managing sensitive information such as API keys, tokens, and credentials. It provides automatic secret rotation, fine-grained IAM access control, encryption at rest using AWS KMS, and audit logging through AWS CloudTrail. This makes it the most secure and scalable option for managing short-lived authentication keys.
AWS Lambda extensions enable efficient secret retrieval by caching secrets locally within the execution environment. This reduces repeated calls to Secrets Manager on every invocation, improving performance and lowering costs while maintaining up-to-date credentials. AWS documentation explicitly recommends using Lambda extensions or caching logic for secrets that are frequently accessed.
Storing secrets in S3 (Option B) or environment variables (Option C) lacks built-in rotation and increases exposure risk. Parameter Store (Option D) supports encryption but does not provide native rotation for secrets without custom automation, making it less suitable for this use case.
Therefore, Secrets Manager with Lambda extensions provides the most secure, automated, and operationally efficient solution.
Question #148
A developer is creating a mobile app that calls a backend service by using an Amazon API Gateway REST API. For integration testing during the development phase, the developer wants to simulate different backend responses without invoking the backend service.
Which solution will meet these requirements with the LEAST operational overhead?
- A . Create an AWS Lambda function. Use API Gateway proxy integration to return constant HTTP responses.
- B . Create an Amazon EC2 instance that serves the backend REST API by using an AWS CloudFormation template.
- C . Customize the API Gateway stage to select a response type based on the request.
- D . Use a request mapping template to select the mock integration response.
Correct Answer: D
D
Explanation:
Amazon API Gateway supports mock integration responses, which are predefined responses that can be returned without sending requests to a backend service. Mock integration responses can be used for testing or prototyping purposes, or for simulating different backend responses based on certain conditions. A request mapping template can be used to select a mock integration response based on an expression that evaluates some aspects of the request, such as headers, query strings, or body content. This solution does not require any additional resources or code changes and has the least
operational overhead.
Reference: Set up mock integrations for an API Gateway REST API
https: //docs.aws.amazon.com/apigateway/latest/developerguide/how-to-mock-integration.html
D
Explanation:
Amazon API Gateway supports mock integration responses, which are predefined responses that can be returned without sending requests to a backend service. Mock integration responses can be used for testing or prototyping purposes, or for simulating different backend responses based on certain conditions. A request mapping template can be used to select a mock integration response based on an expression that evaluates some aspects of the request, such as headers, query strings, or body content. This solution does not require any additional resources or code changes and has the least
operational overhead.
Reference: Set up mock integrations for an API Gateway REST API
https: //docs.aws.amazon.com/apigateway/latest/developerguide/how-to-mock-integration.html
Question #149
A social media company is designing a platform that allows users to upload data, which is stored in Amazon S3. Users can upload data encrypted with a public key. The company wants to ensure that only the company can decrypt the uploaded content using an asymmetric encryption key. The data must always be encrypted in transit and at rest.
- A . Use server-side encryption with Amazon S3 managed keys (SSE-S3) to encrypt the data.
- B . Use server-side encryption with customer-provided encryption keys (SSE-C) to encrypt the data.
- C . Use client-side encryption with a data key to encrypt the data.
- D . Use client-side encryption with a customer-managed encryption key to encrypt the data.
Correct Answer: D
D
Explanation:
Step 1: Problem Understanding
Asymmetric Encryption Requirement: Users encrypt data with a public key, and only the company can decrypt it using a private key.
Data Encryption at Rest and In Transit: The data must be encrypted during upload (in transit) and when stored in Amazon S3 (at rest).
Step 2: Solution Analysis
Option A: Server-side encryption with Amazon S3 managed keys (SSE-S3).
Amazon S3 manages the encryption and decryption keys.
This does not meet the requirement for asymmetric encryption, where the company uses a private key.
Not suitable.
Option B: Server-side encryption with customer-provided keys (SSE-C).
Requires the user to supply encryption keys during the upload process.
Does not align with the asymmetric encryption requirement.
Not suitable.
Option C: Client-side encryption with a data key.
Data key encryption is symmetric, not asymmetric.
Does not satisfy the requirement for a public-private key pair.
Not suitable.
Option D: Client-side encryption with a customer-managed encryption key.
Data is encrypted on the client side using the public key.
Only the company can decrypt the data using the corresponding private key.
Data remains encrypted during upload (in transit) and in S3 (at rest).
Correct option.
Step 3: Implementation Steps for Option D
Generate Key Pair:
The company generates an RSA key pair (public/private) for encryption and decryption.
Encrypt Data on Client Side:
Use the public key to encrypt the data before uploading to S3.
S3 Upload:
Upload the encrypted data to S3 over an HTTPS connection.
Decrypt Data on the Server:
Use the private key to decrypt data when needed.
AWS Developer
Reference: Amazon S3 Encryption Options
Asymmetric Key Cryptography in AWS
D
Explanation:
Step 1: Problem Understanding
Asymmetric Encryption Requirement: Users encrypt data with a public key, and only the company can decrypt it using a private key.
Data Encryption at Rest and In Transit: The data must be encrypted during upload (in transit) and when stored in Amazon S3 (at rest).
Step 2: Solution Analysis
Option A: Server-side encryption with Amazon S3 managed keys (SSE-S3).
Amazon S3 manages the encryption and decryption keys.
This does not meet the requirement for asymmetric encryption, where the company uses a private key.
Not suitable.
Option B: Server-side encryption with customer-provided keys (SSE-C).
Requires the user to supply encryption keys during the upload process.
Does not align with the asymmetric encryption requirement.
Not suitable.
Option C: Client-side encryption with a data key.
Data key encryption is symmetric, not asymmetric.
Does not satisfy the requirement for a public-private key pair.
Not suitable.
Option D: Client-side encryption with a customer-managed encryption key.
Data is encrypted on the client side using the public key.
Only the company can decrypt the data using the corresponding private key.
Data remains encrypted during upload (in transit) and in S3 (at rest).
Correct option.
Step 3: Implementation Steps for Option D
Generate Key Pair:
The company generates an RSA key pair (public/private) for encryption and decryption.
Encrypt Data on Client Side:
Use the public key to encrypt the data before uploading to S3.
S3 Upload:
Upload the encrypted data to S3 over an HTTPS connection.
Decrypt Data on the Server:
Use the private key to decrypt data when needed.
AWS Developer
Reference: Amazon S3 Encryption Options
Asymmetric Key Cryptography in AWS
Question #150
For a deployment using AWS Code Deploy, what is the run order of the hooks for in-place deployments?
- A . BeforeInstall -> ApplicationStop -> ApplicationStart -> AfterInstall
- B . ApplicationStop -> BeforeInstall -> AfterInstall -> ApplicationStart
- C . BeforeInstall -> ApplicationStop -> ValidateService -> ApplicationStart
- D . ApplicationStop -> BeforeInstall -> ValidateService -> ApplicationStart
Correct Answer: B
B
Explanation:
For in-place deployments, AWS CodeDeploy uses a set of predefined hooks that run in a specific order during each deployment lifecycle event. The hooks are ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. The run order of the hooks for in-place deployments is as follows:
ApplicationStop: This hook runs first on all instances and stops the current application that is running on the instances.
BeforeInstall: This hook runs after ApplicationStop on all instances and performs any tasks required before installing the new application revision.
AfterInstall: This hook runs after BeforeInstall on all instances and performs any tasks required after installing the new application revision.
ApplicationStart: This hook runs after AfterInstall on all instances and starts the new application that has been installed on the instances.
ValidateService: This hook runs last on all instances and verifies that the new application is running properly on the instances.
Reference: [AWS CodeDeploy lifecycle event hooks reference]
B
Explanation:
For in-place deployments, AWS CodeDeploy uses a set of predefined hooks that run in a specific order during each deployment lifecycle event. The hooks are ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. The run order of the hooks for in-place deployments is as follows:
ApplicationStop: This hook runs first on all instances and stops the current application that is running on the instances.
BeforeInstall: This hook runs after ApplicationStop on all instances and performs any tasks required before installing the new application revision.
AfterInstall: This hook runs after BeforeInstall on all instances and performs any tasks required after installing the new application revision.
ApplicationStart: This hook runs after AfterInstall on all instances and starts the new application that has been installed on the instances.
ValidateService: This hook runs last on all instances and verifies that the new application is running properly on the instances.
Reference: [AWS CodeDeploy lifecycle event hooks reference]