Practice Exams | AWS Certified DevOps Engineer Professional

Practice Test 1: Mini Practice Test: AWS Certified DevOps Engineer Professional - DOP-C02
Open

Practice Test 2: Full Practice Test - AWS Certifie…

Set a certification due date

AWS Certified DevOps Engineer – Professional

Course content

AI Assistant

Practice tests

Start

Practice Test 1: Mini Practice Test: AWS Certified DevOps Engineer Professional - DOP-C02

Start

Practice Test 2: Full Practice Test - AWS Certified DevOps Engineer Professional - DOP-C02

Close panel

Overview

Q&AQuestions and answers

Notes

Announcements

Reviews

Learning tools

Search course content

Start a new search

To find captions, lectures or resources

information alert
Schedule learning time

Learning a little each day adds up. Research shows that students who make learning a habit are more likely to reach their goals. Set time aside to learn and get reminders using your learning scheduler.

Get startedDismiss

Prepare for your certification with this course.

Issued by Amazon Web Services Training and Certification Add to interests

AWS Certified DevOps: 120 high fidelity questions: AWS Certified DevOps Engineer Professional DOP-C02.

Rating: 4.5 out of 54.5
2,609 ratings

31,064

Students

120 questions

Total

Last updated May 2024

English

What you'll learn

120 original questions for AWS Certified DevOps Engineer Professional (DOP-C02)

Detailed explanations for each question, right and wrong answer

Similar difficulty to the actual exam.

Should be taken after doing the full AWS Certified DevOps Engineer Professional course

Description

Preparing for AWS Certified DevOps Engineer Professional Certification? This is THE practice exams course to give you the winning edge.

These practice exams have been co-authored by Stephane Maarek and Abhishek Singh who bring their collective experience of passing 18 AWS Certifications to the table.

The tone and tenor of the questions mimic the real exam. Along with the detailed description and “exam alert” provided within the explanations, we have also extensively referenced AWS documentation to get you up to speed on all domain areas being tested for the DOP-C02 exam.

FEATURED REVIEWS:

5 stars: Stephane did a great job with this practice exam. I used this as my final knowledge validation exercise before the actual exam. I passed the real test first time, and this course certainly helped to get me there. Thank Stephane! - Nick S.

5 stars: High quality course as well as the practice test, best way to prepare for the AWS DevOps Pro certification. - John L.

5 stars: I took both the DevOps course and practice exam and the exam is close to the real exam. I took this practice exam and passed the DevOps exam. Thanks Stephane for your good training resources. - Eric C.

Instructor

My name is Stéphane Maarek, I am passionate about Cloud Computing, and I will be your instructor in this course. I teach about AWS certifications, focusing on helping my students improve their professional proficiencies in AWS.

I have already taught 1,500,000+ students and gotten 500,000+ reviews throughout my career in designing and delivering these certifications and courses!

I'm delighted to welcome Abhishek Singh as my co-instructor for these practice exams!

The practice exams contain:

45 high-quality, high-fidelity and difficult questions in a mini practice test. These questions are representative of what you will be asked of at the AWS Certified DevOps Engineer Professional exam.

75 high-quality, high-fidelity and difficult questions in a full practice test. These questions are representative of what you will be asked of at the AWS Certified DevOps Engineer Professional exam.

These are NOT AWS Certified DevOps Engineer Professional dumps and should not be considered as such.

A detailed explanation is available for all questions, for the correct and wrong answers.

Happy learning and best of luck for your AWS Certified DevOps Engineer Professional exam!

Who this course is for:

Students wanting to pass the AWS Certified DevOps Engineer Professional (DOP-C02) exam

Show moreShow less

Instructors

Stephane Maarek | AWS Certified Cloud Practitioner,Solutions Architect,Developer

Best Selling Instructor, 11x AWS Certified, Kafka Guru

Stephane is a solutions architect, consultant and software developer that has a particular interest in all things related to Cloud & Big Data. He's also a many-times best seller instructor on Udemy for his courses in AWS and Apache Kafka.

[See FAQ below to see in which order you can take my courses]

Stéphane is recognized as an AWS Hero and is an AWS Certified Solutions Architect Professional & AWS Certified DevOps Professional. He loves to teach people how to use the AWS properly, to get them ready for their AWS certifications, and most importantly for the real world.

He also loves Apache Kafka. He used on the Program Committee organizing the Kafka Summit in New York, London and San Francisco. He also was an active member of the Apache Kafka community, and has authored blogs on Medium and the guest blog for Confluent. He also has co-founded Conduktor, a prominent company in the Kafka ecosystem.

During his spare time he enjoys cooking, practicing yoga, surfing, watching TV shows, and traveling to awesome destinations!

FAQ: In which order should you learn?...

AWS Cloud: Start with AWS Certified Cloud Practitioner or AWS Certified Solutions Architect Associate, then move on to AWS Certified Developer Associate and then AWS Certified SysOps Administrator. Afterwards you can either do AWS Certified Solutions Architect Professional or AWS Certified DevOps Professional, or a specialty certification of your choosing. You can also learn about AI with the AWS Certified AI Practitioner course!

Apache Kafka: Start with Apache Kafka for Beginners, then you can learn Connect, Streams and Schema Registry if you're a developer, and Setup and Monitoring courses if you're an admin. Both tracks are needed to pass the Confluent Kafka certification.

Show moreShow less

Abhishek Singh

Cloud Evangelist

Abhishek is an AWS veteran and has built successful SaaS and consumer solutions using AWS services since 2012. Over the course of his professional career, Abhishek has interviewed and mentored hundreds of candidates for entry-level and lateral positions for Cloud based IT solutions development. Abhishek is passionate about sharing his knowledge on AWS Cloud, Machine Learning and Big Data. He wants to help his fellow IT Professionals level-up their skills to ace the AWS Certifications and above all, get ready for the real world AWS ecosystem.

He is an AWS Certified Solutions Architect Professional, AWS Certified DevOps Engineer Professional, AWS Certified Machine Learning Specialist, AWS Certified Big Data Specialist and AWS Certified Database Specialist.

Overall, Abhishek has over 15 years of experience working on a diverse range of Enterprise Technologies based on AI/ML, Big Data and Analytics. He runs a successful AI/ML and Big Data Consultancy advocating solutions on AWS Cloud and has advised multiple clients in the US to architect and implement their AI/ML and Big Data solutions using the AWS suite of services.

Show moreShow less

Requirements

Study the full AWS Certified DevOps Engineer Professional course

Create a new note at 0:00

All lectures

All lectures

Current lecture

Sort by most recent

Sort by most recent

Sort by oldest

Click the "Create a new note" box, the "+" button, or press "B" to make your first note.

Learning reminders

Learning a little each day adds up. Research shows that students who make learning a habit are more likely to reach their goals. Set time aside to learn and get reminders using your learning scheduler.

Học code thui bạn ơi

7:00 PM

Daily

Added to your calendar

Edit

Delete

Download again

Add another

English

Get the app

About us

Help and Support

Terms

Privacy policy

Sitemap

Accessibility statement

© 2025 Udemy, Inc.

Practice Test 1: Mini Practice Test: AWS Certified DevOps Engineer Professional - DOP-C02

Mini Practice Test: AWS Certified DevOps Engineer Professional - DOP-C02 - Results

Back to result overview
Attempt 1

All domains

All domains

Domain 1: SDLC Automation

Domain 6: Security and Compliance

Domain 4: Monitoring and Logging

Domain 3: Resilient Cloud Solutions

Domain 5: Incident and Event Response

Domain 2: Configuration Management and IaC

45 all

0 correct

0 incorrect

45 skipped

0 marked

Collapse all questions

Question 1Skipped

A web application is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). While using CodeDeploy Blue/Green deployment to deploy a new version, the deployment failed during the AllowTraffic lifecycle event. The DevOps team has found no errors in the deployment logs.

Which of the following would you identify as the root cause behind the failure of the deployment?

The cause of the failure could be a script from the last successful deployment that never runs successfully. Create a new deployment and specify that the ApplicationStop, BeforeBlockTraffic, and AfterBlockTraffic failures should be ignored

If an instance is terminated between lifecycle events or before the first lifecycle event step starts, then AllowTraffic lifecycle event fails without generating logs

Correct answer

Incorrectly configured health checks on Application Load Balancer (ALB) are responsible for this issue

A scale-in event or any other termination event, during an in-progress deployment, causes the instance to detach from the Amazon EC2 Auto Scaling group and the instance fails the AllowTraffic lifecycle event

Overall explanation

Correct option:

Incorrectly configured health checks on Application Load Balancer (ALB) are responsible for this issue

In some cases, a Blue/Green deployment fails during the AllowTraffic lifecycle event, but the deployment logs do not indicate the cause for the failure.

This failure is typically due to incorrectly configured health checks in Elastic Load Balancing for the Classic Load Balancer, Application Load Balancer, or Network Load Balancer used to manage traffic for the deployment group.

To resolve the issue, review and correct any errors in the health check configuration for the load balancer.

Incorrect options:

The cause of the failure could be a script from the last successful deployment that never runs successfully. Create a new deployment and specify that the ApplicationStop, BeforeBlockTraffic, and AfterBlockTraffic failures should be ignored - During a deployment, the CodeDeploy agent runs the scripts specified for ApplicationStop, BeforeBlockTraffic, and AfterBlockTraffic in the AppSpec file from the previous successful deployment. (All other scripts are run from the AppSpec file in the current deployment.) If one of these scripts contains an error and does not run successfully, the deployment can fail. This kind of failure generates logs and will not fail at AllowTraffic lifecycle event.

If an instance is terminated between lifecycle events or before the first lifecycle event step starts, then AllowTraffic lifecycle event fails without generating logs - This statement is incorrect. Deployments do not fail for up to an hour when an instance is terminated during a deployment.

A scale-in event or any other termination event, during an in-progress deployment, causes the instance to detach from the Amazon EC2 Auto Scaling group and the instance fails the AllowTraffic lifecycle event - During an in-progress deployment, a scale-in event or any other termination event causes the instance to detach from the Amazon EC2 Auto Scaling group and then terminate. Because the deployment cannot be completed, it fails. This error is specific to Auto Scaling Groups (ASG) and hence does not relate to the given issue.

References:

https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html

https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-ec2-instances.html

Domain

Domain 1: SDLC Automation

Question 2Skipped

A company implements access control by creating different policies for different job functions. These policies are attached to IAM roles/groups with minimum permissions necessary for the job function. Up until this point, the solution has been functioning effectively. However, with business expansion, the administrator has to frequently update the existing policies to allow access to new resources.

Which of the following solutions can make the access control applicable to all new resources without the need to update the policies?

Correct answer

Configure Attribute-based access control by use of tags. Create tags for IAM roles based on their function. Whenever a new resource is created, add these tag(s) to the resource for immediate access to the resource created

Create an AWS Organization and enable all the features. Attach identity-based IAM roles for newly created resources and share them using Service control policies (SCPs) with all member accounts of the organization

Configure Access control lists (ACLs) to allow access to certain principals in the account. Add the ACLs to a session policy to dynamically add permissions to the IAM role that the user already has

Create a Resource-based policy on the newly created resources to add to the existing permissions of the IAM roles accessing the created resources

Overall explanation

Correct option:

Configure Attribute-based access control by use of tags. Create tags for IAM roles based on their function. Whenever a new resource is created, add these tag(s) to the resource for immediate access to the resource created

The traditional authorization model used in IAM is called role-based access control (RBAC). RBAC defines permissions based on a person's job function, known outside of AWS as a role. Within AWS a role usually refers to an IAM role, which is an identity in IAM that you can assume.

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. You can attach tags to IAM resources, including IAM entities (users or roles), and to AWS resources. You can create a single ABAC policy or a small set of policies for your IAM principals. These ABAC policies can be designed to allow operations when the principal's tag matches the resource tag. ABAC is helpful in environments that are growing rapidly and help with situations where policy management becomes cumbersome.

Comparing ABAC to the traditional RBAC model:

via - https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html

Incorrect options:

Create an AWS Organization and enable all the features. Attach identity-based IAM roles for newly created resources and share them using Service control policies (SCPs) with all member accounts of the organization - SCP is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are similar to IAM permissions policies except that they don't grant any permissions. Instead, SCPs specify the maximum permissions for an organization, organizational unit (OU), or account.

Create a Resource-based policy on the newly created resources to add to the existing permissions of the IAM roles accessing the created resources - If you have to create a Resource-based policy for every new resource that is added to the account, then we are pretty much at the same place without offering any solution. Hence, this option is not a valid choice for the given use case.

Configure Access control lists (ACLs) to allow access to certain principals in the account. Add the ACLs to a session policy to dynamically add permissions to the IAM role that the user already has - Access control lists (ACLs) are service policies that allow you to control which principals in another account can access a resource. ACLs cannot be used to control access for a principal within the same account.

Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies.

Neither ACL nor a session policy is the right choice for the given use case.

References:

https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

Domain

Domain 6: Security and Compliance

Question 3Skipped

A video-sharing application stores its files on an Amazon S3 bucket. During the last year, the user traffic has multiplied by thousands and the company is planning on introducing subscription services for its video sharing application. The company needs the access pattern of the video files to identify the most viewed and downloaded videos.

Which of the following would you identify as the MOST cost-effective solution that can be implemented at the earliest?

Correct answer

Enable server access logging on the S3 bucket. Configure Amazon Athena to create an external table with the log files. Use SQL query to analyze the access patterns from Athena

Leverage Amazon S3 request metrics from CloudWatch for analysis via an AWS Lambda function. The AWS/S3 namespace includes the request metrics GetRequests and BytesDownloaded that can be passed to the Lambda function for analyzing the access pattern of the S3 bucket. The output of the Lambda function can be stored in an S3 bucket and visually analyzed using Amazon QuickSight

Enable server access logging on the S3 bucket. Use Amazon Redshift Spectrum to efficiently query large datasets leveraging the massive parallelism offered by dedicated Amazon Redshift servers

Enable server access logging on the S3 bucket. Configure file create event notification on Access log S3 bucket to trigger an AWS Lambda function. Configure Lambda to write the data to Kinesis Firehose which then writes the log data to Amazon OpenSearch Service. Use Elasticsearch search and analytics engine for analyzing usage patterns of the S3 access logs

Overall explanation

Correct option:

Enable server access logging on the S3 bucket. Configure Amazon Athena to create an external table with the log files. Use SQL query to analyze the access patterns from Athena

Server access logging provides detailed records for the requests that are made to an Amazon S3 bucket. Server access logs are useful for many applications. For example, access log information can be useful in security and access audits. It can also help you learn about your customer base and understand your Amazon S3 bill.

Amazon S3 periodically collects access log records, consolidates the records in log files, and then uploads log files to your target bucket as log objects. If you enable logging on multiple source buckets that identify the same target bucket, the target bucket will have access logs for all those source buckets. However, each log object reports access log records for a specific source bucket.

Amazon Athena is an interactive query service that makes it easy to analyze data directly from Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to set up or manage and you can start analyzing your data immediately. Athena uses an approach known as schema-on-read, which allows you to project your schema onto your data at the time you execute a query. This eliminates the need for any data loading or ETL.

Amazon Athena:

https://aws.amazon.com/athena/

CREATE EXTERNAL TABLE [IF NOT EXISTS] syntax is used to create the table in Athena. EXTERNAL keyword specifies that the table is based on an underlying data file that exists in Amazon S3, in the location that you specify.

You can use queries on Amazon S3 server access logs to identify Amazon S3 object access requests, for operations such as GET, PUT, and DELETE, and discover further information about those requests.

Analysing object access requests using SQL queries in Athena:

via - https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-s3-access-logs-to-identify-requests.html

Incorrect options:

Leverage Amazon S3 request metrics from CloudWatch for analysis via an AWS Lambda function. The AWS/S3 namespace includes the request metrics GetRequests and BytesDownloaded that can be passed to the Lambda function for analyzing the access pattern of the S3 bucket. The output of the Lambda function can be stored in an S3 bucket and visually analyzed using Amazon QuickSight - The request metrics GetRequests and BytesDownloaded will give the overall count of all Get requests and Bytes downloaded through these requests. It does not help in answering the access pattern questions, such as, which files have been viewed/downloaded the most.

Enable server access logging on the S3 bucket. Use Amazon Redshift Spectrum to efficiently query large datasets leveraging the massive parallelism offered by dedicated Amazon Redshift servers - Using Amazon Redshift Spectrum, you can efficiently query and retrieve structured and semistructured data from files in Amazon S3 without having to load the data into Amazon Redshift tables. Redshift Spectrum queries employ massive parallelism to run very fast against large datasets. Amazon Redshift Spectrum has a dependency on provisioned Amazon Redshift servers, which represents a cost-intensive solution. Therefore, Amazon Redshift Spectrum is a cost overkill for the simple access pattern analysis that the current use case needs.

Enable server access logging on the S3 bucket. Configure file create event notification on Access log S3 bucket to trigger an AWS Lambda function. Configure Lambda to write the data to Kinesis Firehose which then writes the log data to Amazon OpenSearch Service. Use Elasticsearch search and analytics engine for analyzing usage patterns of the S3 access logs - Amazon OpenSearch is a managed service that makes it easier to deploy, operate, and scale Elasticsearch clusters in the AWS Cloud. Elasticsearch is a popular open-source search and analytics engine for use cases such as log analytics, real-time application monitoring, and clickstream analysis. The service provides support for open-source Elasticsearch APIs, managed Kibana, and integration with other AWS services such as Amazon S3 and Amazon Kinesis for loading streaming data into Amazon ES. OpenSearch is well-suited for real-time analysis of logs or clickstreams. This is not a cost-effective solution as it uses AWS Lambda, Kinesis Data Firehose, and Amazon OpenSearch services for the simple access pattern analysis that the current use case needs.

References:

https://aws.amazon.com/athena/

https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/metrics-dimensions.html#s3-cloudwatch-metrics

https://docs.aws.amazon.com/redshift/latest/dg/c-using-spectrum.html

https://aws.amazon.com/blogs/big-data/analyzing-amazon-s3-server-access-logs-using-amazon-opensearch-service/

Domain

Domain 4: Monitoring and Logging

Question 4Skipped

A production support team manages a web application running on a fleet of Amazon EC2 instances configured with an Application Load balancer (ALB). The instances run in an EC2 Auto Scaling group across multiple Availability Zones. A critical bug fix has to be deployed to the production application. The team needs a deployment strategy that can:

a) Create another fleet of instances with the same capacity and configuration as the original one. b) Continue access to the original application without a downtime c) Transition the traffic to the new fleet when the deployment is fully done. The production test team has requested a two-hour window to complete thorough testing on the new fleet of instances. d) Terminate the original fleet automatically once the test window expires.

As a DevOps engineer, which deployment solution will you choose to cater to all the given requirements?

Correct answer

Use AWS CodeDeploy with a deployment type configured to Blue/Green deployment configuration. To terminate the original fleet after two hours, change the deployment settings of the Blue/Green deployment. Set Original instances value to Terminate the original instances in the deployment group and choose a waiting period of two hours

Configure AWS Elastic Beanstalk to use rolling deployment policy. Elastic Beanstalk splits the environment's Amazon EC2 instances into batches and deploys the new version of the application to one batch at a time. Production traffic is served unaffected. Use rolling restarts to restart the proxy and application servers running on your environment's instances without downtime

Use AWS CodeDeploy with a deployment type configured to Blue/Green deployment configuration. To terminate the original fleet after two hours, change the deployment settings of the Blue/Green deployment. Set Original instances value to 'Terminate the original instances in the deployment group' and choose a waiting period of two hours. Choose OneAtATime Deployment configuration setting to deregister the original fleet of instances one at a time to provide increased test time for the production team

Configure AWS Elastic Beanstalk to perform a Blue/Green deployment. This will create a new environment different from the original environment to continue serving the production traffic. Terminate the original environment after two hours and confirm the DNS changes of the new environment have propagated correctly

Overall explanation

Correct option:

Use AWS CodeDeploy with a deployment type configured to Blue/Green deployment configuration. To terminate the original fleet after two hours, change the deployment settings of the Blue/Green deployment. Set Original instances value to Terminate the original instances in the deployment group and choose a waiting period of two hours

Traditional deployments with in-place upgrades make it difficult to validate your new application version in a production deployment while also continuing to run the earlier version of the application. Blue/Green deployments provide a level of isolation between your blue and green application environments. This helps ensure spinning up a parallel green environment does not affect the resources underpinning your blue environment. This isolation reduces your deployment risk.

After you deploy the green environment, you have the opportunity to validate it. You might do that with test traffic before sending production traffic to the green environment, or by using a very small fraction of production traffic, to better reflect real user traffic. This is called canary analysis or canary testing. If you discover the green environment is not operating as expected, there is no impact on the blue environment. You can route traffic back to it, minimizing impaired operation or downtime and limiting the blast radius of impact.

This ability to simply roll traffic back to the operational environment is a key benefit of Blue/Green deployments. You can roll back to the blue environment at any time during the deployment process. Impaired operation or downtime is minimized because the impact is limited to the window of time between green environment issue detection and the shift of traffic back to the blue environment. Additionally, the impact is limited to the portion of traffic going to the green environment, not all traffic. If the blast radius of deployment errors is reduced, so is the overall deployment risk.

In AWS CodeDeploy Blue/Green deployment type, for deployment groups that contain more than one instance, the overall deployment succeeds if the application revision is deployed to all of the instances. The exception to this rule is that if deployment to the last instance fails, the overall deployment still succeeds. This is because CodeDeploy allows only one instance at a time to be taken offline with the CodeDeployDefault.OneAtATime configuration (If you don't specify a deployment configuration, CodeDeploy uses the CodeDeployDefault.OneAtATime deployment configuration).

If you choose Terminate the original instances in the deployment group: After traffic is rerouted to the replacement environment, the instances that were deregistered from the load balancer are terminated following the wait period you specify.

Blue/Green deployment example:

via - https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html

Incorrect options:

Configure AWS Elastic Beanstalk to perform a Blue/Green deployment. This will create a new environment different from the original environment to continue serving the production traffic. Terminate the original environment after two hours and confirming the DNS changes of the new environment have propagated correctly

Configure AWS Elastic Beanstalk to use rolling deployment policy. Elastic Beanstalk splits the environment's Amazon EC2 instances into batches and deploys the new version of the application to one batch at a time. Production traffic is served unaffected. Use rolling restarts to restart the proxy and application servers running on your environment's instances without downtime

These two options use AWS Elastic Beanstalk, which creates a new environment and not a new fleet of EC2 instances, as needed in the use case. Hence, these are incorrect.

Use AWS CodeDeploy with a deployment type configured to Blue/Green deployment configuration. To terminate the original fleet after two hours, change the deployment settings of the Blue/Green deployment. Set Original instances value to Terminate the original instances in the deployment group and choose a waiting period of two hours. Choose OneAtATime Deployment configuration setting to deregister the original fleet of instances one at a time to provide increased test time for the production team - Deregistering the original fleet of instances one at a time is not possible. After traffic is successfully routed to the replacement environment, instances in the original environment are deregistered all at once no matter which deployment configuration is selected.

References:

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html

https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups-create-blue-green.html

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html

Domain

Domain 1: SDLC Automation

Question 5Skipped

A company uses an AWS CodePipeline pipeline to deploy updates to the API several times a month. As part of this process, the DevOps team exports the JavaScript SDK for the API from the API Gateway console and uploads it to an Amazon S3 bucket, which is being used as an origin for an Amazon CloudFront distribution. Web clients access the SDK through the CloudFront distribution's endpoint. The goal is to have an automated solution that ensures the latest SDK is always available to clients whenever there's a new API deployment.

As an AWS Certified DevOps Engineer - Professional, what solution will you suggest?

Set up an Amazon EventBridge rule that reacts to CreateDeployment events from aws.apigateway. Configure this rule to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path

Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path

Set up an Amazon EventBridge rule on a schedule that is invoked every 5 minutes. Configure this rule to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path

Correct answer

Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path

Overall explanation

Correct option:

Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. By creating a CodePipeline action with an AWS Lambda function immediately after the API deployment stage, the DevOps team can automate the process of downloading the SDK from API Gateway and uploading it to the S3 bucket. Additionally, the Lambda function can create a CloudFront invalidation for the SDK path, ensuring that web clients get the latest SDK without any caching issues.

Incorrect options:

Set up an Amazon EventBridge rule that reacts to CreateDeployment events from aws.apigateway. Configure this rule to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path

Set up a CodePipeline action that runs immediately after the API deployment stage. Configure this action to leverage the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Trigger another action that calls the S3 API to invalidate the cache for the SDK path

You cannot use any S3 API to invalidate the CloudFront cache, so both of these options are incorrect.

Set up an Amazon EventBridge rule on a schedule that is invoked every 5 minutes. Configure this rule to invoke an AWS Lambda function. The Lambda function will then download the SDK from API Gateway, upload it to the S3 bucket, and create a CloudFront invalidation for the SDK path - It is wasteful to invoke an EventBridge rule every 5 minutes to invalidate the CloudFront cache. You should only invalidate the cache when the API has actually been updated.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-deploy-api.html

https://aws.amazon.com/blogs/devops/automating-your-api-testing-with-aws-codebuild-aws-codepipeline-and-postman/

Domain

Domain 1: SDLC Automation

Question 6Skipped

A media application runs on a host of Amazon EC2 instances fronted with an Application Load Balancer (ALB) and Amazon S3 buckets as storage service. For enhanced security, an AWS Web Application Firewall (AWS WAF) has been set up to monitor the requests coming to the ALB. The DevOps team needs to submit a quarterly report on the web requests received by AWS WAF, having detailed information about each web request as well as the details about rules that the request matched. The team has reached out to you for implementing the changes needed for collecting the security data for the coming months.

As DevOps Engineer, how will you implement this requirement?

Correct answer

Create an Amazon S3 bucket. Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with aws-waf-logs- and can end with any suffix you want

To send logs to Amazon CloudWatch Logs, create a CloudWatch Logs log group. When you enable logging in AWS WAF, provide the log group ARN as the WAF logging destination. Log group names must start with aws-waf-logs- and end with any suffix. Define CloudWatch Metrics for the logs collected and trigger CloudWatch alarm(s) based on the logs generated

Enable logging on AWS WAF and configure Amazon Kinesis Data Firehose with a configured storage destination as WAF logging destination. Configure Firehose to use a Kinesis stream as its source. Data firehose name should start with the prefix aws-waf-logs-

Create an Amazon S3 bucket. Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with aws-waf-logs- and can end with any suffix you want. For added security, you can add log encryption configuration by providing AWS Key Management Service keys that are managed by AWS

Overall explanation

Correct option:

Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with aws-waf-logs- and can end with any suffix you want

You can enable logging AWS WAF web ACL traffic, to get detailed information about traffic that is analyzed by your web ACL. Logged information includes the time that AWS WAF received a web request from your AWS resource, detailed information about the request, and details about the rules that the request matched. You can send your logs to an Amazon CloudWatch Logs log group, an Amazon Simple Storage Service (Amazon S3) bucket, or an Amazon Kinesis Data Firehose.

To send your web ACL traffic logs to Amazon S3, you need to set up an Amazon S3 bucket for the logs. When you enable logging for AWS WAF, you provide the bucket ARN. Your web ACLs publish their log files to the Amazon S3 bucket at 5-minute intervals. Each log file contains log records for the traffic recorded in the previous 5 minutes.

The maximum file size for a log file is 75 MB. If the log file reaches the file size limit within the 5-minute period, the log stops adding records to it, publishes it to the Amazon S3 bucket, and then creates a new log file.

Your bucket names for AWS WAF logging must start with aws-waf-logs- and can end with any suffix you want. For example, aws-waf-logs-DOC-EXAMPLE-BUCKET-SUFFIX.

Incorrect options:

Create an Amazon S3 bucket. Enable logging and provide an Amazon S3 bucket ARN as a WAF logging destination. Bucket names for AWS WAF logging must start with aws-waf-logs- and can end with any suffix you want. For added security, you can add log encryption configuration by providing AWS Key Management Service keys that are managed by AWS - AWS WAF supports encryption with Amazon S3 buckets for key type Amazon S3 key (SSE-S3) and AWS Key Management Service (SSE-KMS) AWS KMS keys. AWS WAF doesn't support encryption for AWS Key Management Service keys that are managed by AWS.

Enable logging on AWS WAF and configure Amazon Kinesis Data Firehose with a configured storage destination as a WAF logging destination. Configure Firehose to use a Kinesis stream as its source. Data Firehose name should start with the prefix aws-waf-logs- - AWS recommends that the Kinesis stream should not be used as a source when configuring Data Firehose as a WAF logging destination.

To send logs to Amazon CloudWatch Logs, create a CloudWatch Logs log group. When you enable logging in AWS WAF, provide the log group ARN as the WAF logging destination. Log group names must start with aws-waf-logs- and end with any suffix. Define CloudWatch Metrics for the logs collected and trigger CloudWatch alarm(s) based on the logs generated - This is a made-up option, given only as a distractor.

References:

https://docs.aws.amazon.com/waf/latest/developerguide/logging-s3.html

https://docs.aws.amazon.com/waf/latest/developerguide/logging-cw-logs.html

Domain

Domain 4: Monitoring and Logging

Question 7Skipped

A company uses serverless application architecture to process thousands of requests using AWS Lambda with Amazon DynamoDB as the database. The Amazon API Gateway REST API is used to invoke an AWS Lambda function that loads a large amount of data from the Amazon DynamoDB database. This results in cold start latencies of 7-10 seconds. The DynamoDB tables have already been configured with DynamoDB Accelerator (DAX) to reduce latency. Yet, customers report of application latency, especially during peak access hours. The application receives maximum traffic between 2 PM -5 PM every day and gradually reduces thereafter, reporting a minimum traffic post 8 PM.

How should a DevOps engineer configure the AWS Lambda function to reduce its latency at all times?

Configure the Lambda function execution environment to use up to 10,240 MB of ephemeral storage. This transient cache for data between invocations can be accessed from the Lambda function code via /tmp space

Configure the AWS Lambda function to use Reserved concurrency. Configure the application Auto Scaling on the Lambda function with reserved concurrency as half of the Lambda function instances invoked during peak traffic hours

Correct answer

Configure the AWS Lambda function to use provisioned concurrency. Configure the application Auto Scaling on the Lambda function with provisioned concurrency values of 1 (minimum) and 100 (maximum) respectively

Use the Lambda function layers for parallel processing of Lambda runtime requests. Deploy the Lambda function as a .zip file archive to utilize Lambda layer functionality

Overall explanation

Correct option:

Configure the AWS Lambda function to use provisioned concurrency. Configure the application Auto Scaling on the Lambda function with provisioned concurrency values of 1 (minimum) and 100 (maximum) respectively

For a Lambda function, concurrency is the number of in-flight requests your function is handling at the same time. Provisioned concurrency is the number of pre-initialized execution environments you want to allocate to your function. These execution environments are prepared to respond immediately to incoming function requests. Configuring provisioned concurrency incurs charges to your AWS account.

Estimating required provisioned concurrency- If your function is currently serving traffic, you can easily view its concurrency metrics using CloudWatch metrics. Specifically, the ConcurrentExecutions metric shows you the number of concurrent invocations for each function in your account.

When working with provisioned concurrency, Lambda suggests including a 10% buffer on top of the amount of concurrency your function typically needs. For example, if your function usually peaks at 200 concurrent requests, set your provisioned concurrency at 220 instead (200 concurrent requests + 10% = 220 provisioned concurrency).

You can alleviate cold start issues by configuring the optimum provisioned concurrency for the Lambda function.

Optimizing latency with provisioned concurrency:

via - https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html

Accurately estimating required provisioned concurrency:

via - https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html

Incorrect options:

Configure the AWS Lambda function to use Reserved concurrency. Configure the application Auto Scaling on the Lambda function with reserved concurrency as half of the Lambda function instances invoked during peak traffic hours - Reserved concurrency is the maximum number of concurrent instances you want to allocate to your function. When a function has reserved concurrency, no other function can use that concurrency. Reserved concurrency is well suited for use cases where traffic is constant and predictable over the day.

Configure the Lambda function execution environment to use up to 10,240 MB of ephemeral storage. This transient cache for data between invocations can be accessed from the Lambda function code via /tmp space - For data-intensive applications such as machine learning inference, and financial computations, customers often need to read and write large amounts of data to ephemeral storage. The Lambda execution environment provides an ephemeral file system for customers’ code to access via /tmp space, which is preserved for the lifetime of the execution environment, and can provide a transient cache for data between invocations. This option acts as a distractor.

Use the Lambda function layers for parallel processing of Lambda runtime requests. Deploy the Lambda function as a .zip file archive to utilize Lambda layer functionality - A Lambda function layer is a .zip file archive that can contain additional code or data. A layer can contain libraries, a custom runtime, data, or configuration files. Layers promote code sharing and separation of responsibilities so that you can iterate faster on writing business logic. This option is irrelevant to the given use case.

References:

https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency

https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html

https://aws.amazon.com/about-aws/whats-new/2022/03/aws-lambda-configure-ephemeral-storage/

Domain

Domain 3: Resilient Cloud Solutions

Question 8Skipped

As a security best practice, a company has decided to back up all of its Amazon Elastic Block Store (Amazon EBS) volumes every week. To implement this change, developers are mandated to tag all Amazon EBS volumes with a custom tag. The company runs an automated solution that reads the custom tag having the value of the desired backup frequency as weekly for each EBS volume and then the solution schedules the backup. However, a recent audit report has highlighted the fact that a few EBS volumes were not backed up as expected because of the missing custom tag.

As a DevOps engineer which solution will you choose to enforce backup for all EBS volumes used by an AWS account?

Correct answer

Set up AWS Config in the AWS account. Use a managed rule for Resource Type AWS::EC2::Volume that returns a compliance failure if the custom tag is not applied on the EBS volume. Configure a remediation action that uses a custom AWS Systems Manager Automation documents (runbooks) to apply the custom tag with predefined backup frequency to all non-compliant EBS volumes

Create an Amazon EventBridge rule that responds to an EBS CreateVolume event from AWS CloudTrail logs. Configure a custom AWS Systems Manager Automation runbook to apply the custom tag with the default weekly value. Specify this runbook as the target of the EventBridge rule

Create an Amazon EventBridge rule that responds to an EBS VolumeBackup check event from AWS Trusted Advisor. Configure a custom AWS Systems Manager Automation runbook to apply the custom tag with the default weekly value. Specify this runbook as the target of the EventBridge rule

Set up AWS Config in the AWS account. Use a managed rule for Resource Type EC2::Instance that returns a compliance failure if the custom tag is not applied on the EBS volume attached to the instance. Configure a remediation action that uses a custom AWS Systems Manager Automation documents (runbooks) to apply the custom tag with predefined backup frequency to all non-compliant EBS volumes

Overall explanation

Correct option:

Set up AWS Config in the AWS account. Use a managed rule for Resource Type EC2::Volume that returns a compliance failure if the custom tag is not applied to the EBS volume. Configure a remediation action that uses custom AWS Systems Manager Automation documents (runbooks) to apply the custom tag with predefined backup frequency to all non-compliant EBS volumes

Set up AWS Config in the AWS account that needs the security best practice implemented. You can use the managed rule required-tags to check if your resources have the tags that you specify. For example, you can check whether your Amazon EC2 instances have the CostCenter tag, while also checking if all your RDS instances have one set of Keys tag. Separate multiple values with commas. You can check up to 6 tags at a time. This managed rule is applicable for the EC2::Volume Resource Type.

AWS Config managed rule that checks required-tags:

via - https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html

This managed rule checks for the existence of the custom tag on the EBS volume. When an EBS volume is found to be non-compliant, you can specify a remediation action through a custom AWS Systems Manager Automation document to apply the custom tag with a predefined backup frequency to all non-compliant EBS volumes.

AWS Config rules remediation with automation runbooks architecture:

via - https://aws.amazon.com/blogs/mt/remediate-noncompliant-aws-config-rules-with-aws-systems-manager-automation-runbooks/

Incorrect options:

Set up AWS Config in the AWS account. Use a managed rule for Resource Type EC2::Instance that returns a compliance failure if the custom tag is not applied on the EBS volume attached to the instance. Configure a remediation action that uses a custom AWS Systems Manager Automation documents (runbooks) to apply the custom tag with predefined backup frequency to all non-compliant EBS volumes - In this option, the Resource type is mentioned as AWS::EC2::Instance. This is incorrect since the compliance check has to be done only for the EBS volume and not for the EC2 instance.

Create an Amazon EventBridge rule that responds to an EBS CreateVolume event from AWS CloudTrail logs. Configure a custom AWS Systems Manager Automation runbook to apply the custom tag with the default weekly value. Specify this runbook as the target of the EventBridge rule - This option is incorrect, as it's possible to remove the custom tag post the creation of the EBS volume and this action would still stay undetected. The right solution is to leverage AWS Config to ensure ongoing backup compliance for EBS volumes for the given use case.

Create an Amazon EventBridge rule that responds to an EBS VolumeBackup check event from AWS Trusted Advisor. Configure a custom AWS Systems Manager Automation runbook to apply the custom tag with the default weekly value. Specify this runbook as the target of the EventBridge rule - AWS Trusted Advisor scans your AWS infrastructure, compares with AWS best practices, and provides recommended actions. Remedial actions are not possible with AWS Trusted Advisor.

References:

https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html

https://aws.amazon.com/blogs/mt/remediate-noncompliant-aws-config-rules-with-aws-systems-manager-automation-runbooks/

Domain

Domain 4: Monitoring and Logging

Question 9Skipped

A company has hired you as an AWS Certified DevOps Engineer - Professional to provide recommendations for a failed security audit of its flagship project. You have been tasked to review the company's buildspec.yaml file for its AWS CodeBuild project. Upon investigation, you have noticed that the file has hard-coded values for the environment variables that reference the AWS Access Key ID, Secret Access Key, and the database password. In addition, to perform one-time configuration changes during the build phase, the file has commands to ssh and scp into an EC2 instance using an SSH private key stored on Amazon S3.

What changes would you recommend to comply with AWS security best practices? (Select three)

Leverage the AWS Systems Manager automation document to manage the EC2 instance, rather than using commands to ssh and scp into the EC2 instance via the SSH private key stored on Amazon S3

Store the database password as a SecureString value in AWS Secrets Manager which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file

Correct selection

Store the database password as a SecureString value in AWS Systems Manager Parameter Store which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file

Correct selection

Leverage the AWS Systems Manager run command to manage the EC2 instance, rather than using commands to ssh and scp into the EC2 instance via the SSH private key stored on Amazon S3

Store the environment variables that reference the AWS Access Key ID, Secret Access Key, and the database password in an encrypted format on Amazon S3. Leverage a Python script to dynamically import the values from S3 during the pre-build phase

Correct selection

Configure the CodeBuild project role with the necessary permissions policy and then delete the environment variables referencing the AWS credentials from the buildspec.yaml file

Overall explanation

Correct options:

Configure the CodeBuild project role with the necessary permissions policy and then delete the environment variables referencing the AWS credentials from the buildspec.yaml file

It is considered a bad practice to store hard-coded AWS credentials in code, configuration, or build files such as the buildspec.yaml file. AWS recommends using an appropriate permissions policy that is attached to the CodeBuild project role to grant the necessary access to the required resources.

via - https://docs.aws.amazon.com/codebuild/latest/userguide/auth-and-access-control-iam-access-control-identity-based.html

Store the database password as a SecureString value in AWS Systems Manager Parameter Store which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file

It is considered a bad practice to store hard-coded database credentials in code, configuration, or build files such as the buildspec.yaml file. As a security best practice, AWS recommends using the database password as a SecureString value in AWS Systems Manager Parameter Store which can then be referenced in the buildspec file like so:

via - https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html

The configuration above is required when you want to retrieve custom environment variables stored in Amazon EC2 Systems Manager Parameter Store. This contains a mapping of key/value scalars, where each mapping represents a single custom environment variable stored in the Amazon EC2 Systems Manager Parameter Store. key is the name you use later in your build commands to refer to this custom environment variable, and value is the name of the custom environment variable stored in Amazon EC2 Systems Manager Parameter Store. To allow CodeBuild to retrieve custom environment variables stored in Amazon EC2 Systems Manager Parameter Store, you must add the ssm:GetParameters action to your CodeBuild service role.

Leverage the AWS Systems Manager run command to manage the EC2 instance, rather than using commands to ssh and scp into the EC2 instance via the SSH private key stored on Amazon S3

Using Run Command, a capability of AWS Systems Manager, you can remotely and securely manage the configuration of your managed nodes. A managed node is any Amazon Elastic Compute Cloud (Amazon EC2) instance or non-EC2 machine in your hybrid and multi-cloud environment that has been configured for Systems Manager. Run Command allows you to automate common administrative tasks and perform one-time configuration changes at scale. You can use Run Command from the AWS Management Console, the AWS Command Line Interface (AWS CLI), AWS Tools for Windows PowerShell, or the AWS SDKs. Run Command is offered at no additional cost.

It is considered a security bad practice to store the SSH private key on Amazon S3. Using the AWS Systems Manager run command for the given use case meets the security best practices.

Incorrect options:

Store the database password as a SecureString value in AWS Secrets Manager which is then referenced in the buildspec environment. Also, delete the environment variable referencing the hard-coded value of the database password from the buildspec.yaml file - In Secrets Manager, a secret consists of secret information, the secret value, plus metadata about the secret. A secret value can be a string or binary. Secrets Manager uses IAM permission policies to make sure that only authorized users can access or modify a secret. There is no such thing as a SecureString value in AWS Secrets Manager. This option has been added as a distractor.

Store the environment variables that reference the AWS Access Key ID, Secret Access Key, and the database password in an encrypted format on Amazon S3. Leverage a Python script to dynamically import the values from S3 during the pre-build phase - It is considered a security bad practice to store the AWS access credentials on Amazon S3, so this option is incorrect.

Leverage the AWS Systems Manager automation document to manage the EC2 instance, rather than using commands to ssh and scp into the EC2 instance via the SSH private key stored on Amazon S3 - Automation feature of the AWS Systems Manager helps you to build automated solutions to deploy, configure, and manage AWS resources at scale. With Automation, you have granular control over the concurrency of your automation. This means you can specify how many resources to target concurrently, and how many errors can occur before an automation is stopped. Since the given use case involves one-time configuration changes, it is better to use the AWS Systems Manager run command.

References:

https://docs.aws.amazon.com/codebuild/latest/userguide/concepts.html#concepts-how-it-works

https://docs.aws.amazon.com/codebuild/latest/userguide/auth-and-access-control-iam-access-control-identity-based.html

https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html

https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.parameter-store

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html

https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html

Domain

Domain 6: Security and Compliance

Question 10Skipped

An Aurora cluster is configured with a single DB instance for a web application. The application uses the instance endpoint to read/write data to the database. The operations team has scheduled an update on the cluster during the upcoming maintenance window. The application support team has requested help to ensure uninterrupted access to the application during the maintenance window.

Which step should a DevOps Engineer take so that the users experience the least possible interruption during the maintenance window?

Turn on the Multi-AZ option on the Aurora cluster write operations. Update the application configuration to use the Aurora cluster endpoint for write operations. Read operations will automatically be served since its a Multi-AZ cluster configuration

Correct answer

Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster endpoint for write operations. Update the Aurora cluster reader endpoint for read operations

Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster custom endpoints by creating two groups of DB instances, one for read and the other for write requests. Update the Aurora cluster's reader endpoint to point to the read DB group of instances

Turn on the Multi-AZ option on the Aurora cluster. Update the application configuration to use the Aurora cluster Multi-AZ instance endpoint for read/write operations

Overall explanation

Correct option:

Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster endpoint for write operations. Update the Aurora cluster reader endpoint for read operations

Aurora Replicas also referred to as reader instances have two main purposes. You can issue queries to them to scale the read operations for your application. You typically do so by connecting to the reader endpoint of the cluster. That way, Aurora can spread the load for read-only connections across as many Aurora Replicas as you have in the cluster. Aurora Replicas also help to increase availability.

By adding a reader instance to the Aurora cluster, the read-only traffic requests can be served from the reader instance, greatly reducing the traffic to the primary DB and avoiding interruption.

An instance endpoint connects to a specific DB instance within an Aurora cluster. Each DB instance in a DB cluster has its unique instance endpoint. A cluster endpoint (or writer endpoint) for an Aurora DB cluster connects to the current primary DB instance for that DB cluster. This endpoint is the only one that can perform write operations such as DDL statements.

The cluster endpoint provides failover support for read/write connections to the DB cluster. If the current primary DB instance of a DB cluster fails, Aurora automatically fails over to a new primary DB instance. During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new primary DB instance, with minimal interruption of service. This is the reason we need to change the application configuration to point to cluster endpoint and not to instance endpoint, in the current scenario.

Incorrect options:

Turn on the Multi-AZ option on the Aurora cluster. Update the application configuration to use the Aurora cluster Multi-AZ instance endpoint for read/write operations

Turn on the Multi-AZ option on the Aurora cluster write operations. Update the application configuration to use the Aurora cluster endpoint for write operations. Read operations will automatically be served since its a Multi-AZ cluster configuration

Once you have created an Aurora cluster, you cannot change its configuration to Multi-AZ, so both of these options are incorrect.

Add a reader instance to the Aurora cluster. Update the application configuration to use the Aurora cluster custom endpoints by creating two groups of DB instances, one for read and the other for write requests. Update the Aurora cluster's reader endpoint to point to the read DB group of instances - The custom endpoint provides load-balanced database connections based on criteria other than the read-only or read/write capability of the DB instances. For example, you might define a custom endpoint to connect to instances that use a particular AWS instance class or a particular DB parameter group. Then you might tell particular groups of users about this custom endpoint. Leveraging a custom endpoint for this use case is overkill, so this option is not the best fit.

References:

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html

Domain

Domain 5: Incident and Event Response

Question 11Skipped

During an AWS CloudFormation stack update process, an error occurred in the updated template, causing AWS CloudFormation to initiate an automatic stack rollback. After the rollback attempt, a DevOps engineer noticed that the application remained unavailable, and the stack is now in the UPDATE_ROLLBACK_FAILED state.

To ensure the successful completion of the stack rollback, which actions should the DevOps engineer take? (Select two)

Update the existing AWS CloudFormation stack by using the original template

Correct selection

Manually fix the resources to match the correct state of the stack

Correct selection

Execute a ContinueUpdateRollback command from the AWS CloudFormation

Automatically fix the issue by using AWS CloudFormation stack sets

Automatically fix the issue by using AWS CloudFormation drift detection

Overall explanation

Correct option:

Execute a ContinueUpdateRollback command from the AWS CloudFormation

Manually fix the resources to match the correct state of the stack

When an update to a CloudFormation stack fails, AWS CloudFormation automatically initiates a rollback process to revert the stack to its previous known stable state. In certain cases, such as when there are dependencies on external resources, the rollback process might stall or encounter an error. To help recover from a failed stack update, you can use the ContinueUpdateRollback command. This command instructs CloudFormation to continue the stack rollback and can help resolve the UPDATE_ROLLBACK_FAILED state.

A dependent resource can't return to its original state, causing the rollback to fail (UPDATE_ROLLBACK_FAILED state). For example, you might have a stack that's rolling back to an old database instance that was deleted outside of AWS CloudFormation. Because AWS CloudFormation doesn't know the database was deleted, it assumes that the database instance still exists and attempts to roll back to it, causing the update rollback to fail.

Depending on the cause of the failure, you can manually fix the error and continue the rollback. By continuing the rollback, you can return your stack to a working state (the UPDATE_ROLLBACK_COMPLETE state), and then try to update the stack again.

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-update-rollback-failed

Incorrect options:

Automatically fix the issue by using AWS CloudFormation drift detection

While AWS CloudFormation drift detection can help identify resources that have drifted from their expected template configurations, it is not directly related to resolving the UPDATE_ROLLBACK_FAILED state. Drift detection is used to detect and compare configuration changes made outside of CloudFormation, and it helps to bring the resources back in line with the template. However, it doesn't address the issue of a failed stack rollback.

Automatically fix the issue by using AWS CloudFormation stack sets

AWS CloudFormation StackSets extends the capability of stacks by enabling you to create, update, or delete stacks across multiple accounts and AWS Regions with a single operation. Using an administrator account, you define and manage an AWS CloudFormation template, and use the template as the basis for provisioning stacks into selected target accounts across specified AWS Regions. It cannot fix the issue with a failed stack rollback.

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html

Update the existing AWS CloudFormation stack by using the original template - Reapplying the original template will not address the issue that caused the stack update to fail initially. The same problem will likely persist, and the stack rollback will continue to fail. To complete the rollback, the cause of the update failure should be addressed, and the rollback should be explicitly continued using the ContinueUpdateRollback command.

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-update-rollback-failed

[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)

Domain

Domain 2: Configuration Management and IaC

Question 12Skipped

A company wants to create an automated monitoring solution to generate real-time customized notifications regarding unrestricted security groups in the company's production AWS account. The notification must contain the name and ID of the noncompliant security group. The DevOps team at the company has already activated the restricted-ssh AWS Config managed rule. The team has also set up an Amazon Simple Notification Service (Amazon SNS) topic and subscribed relevant personnel to it.

Which of the following options represents the BEST solution for the given scenario?

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of NON_COMPLIANT for all AWS Config managed rules. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic. Set up a filter policy on the SNS topic to send only notifications that contain the text of NON_COMPLIANT in the notification to subscribers

Correct answer

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of NON_COMPLIANT for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic

Set up an Amazon EventBridge rule that matches all AWS Config evaluation results for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic. Set up a filter policy on the SNS topic to send only notifications that contain the text of NON_COMPLIANT in the notification to subscribers

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of ERROR for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic

Overall explanation

Correct option:

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of NON_COMPLIANT for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic

You can use AWS Config to evaluate the configuration settings of your AWS resources. You do this by creating AWS Config rules, which represent your ideal configuration settings. AWS Config provides customizable, predefined rules called managed rules to help you get started. While AWS Config continuously tracks the configuration changes that occur among your resources, it checks whether these changes do not comply with the conditions in your rules.

The restricted-ssh rule checks if the incoming SSH traffic for the security groups is accessible. The rule is COMPLIANT when IP addresses of the incoming SSH traffic in the security groups are restricted (CIDR other than 0.0.0.0/0). This rule applies only to IPv4.

For the given use case, you need to monitor for the NON_COMPLIANT evaluation result of the rule, which implies that the rule has failed the conditions of the compliance check. You can then create an Amazon EventBridge rule (with AWS Config configured as a source) that is put in action when it matches the NON_COMPLIANT evaluation result of the restricted-ssh rule. The EventBridge rule, in turn, publishes a notification to the SNS topic.

via - https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

Incorrect options:

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of NON_COMPLIANT for all AWS Config managed rules. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic. Set up a filter policy on the SNS topic to send only notifications that contain the text of NON_COMPLIANT in the notification to subscribers

Set up an Amazon EventBridge rule that matches all AWS Config evaluation results for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic. Set up a filter policy on the SNS topic to send only notifications that contain the text of NON_COMPLIANT in the notification to subscribers

You should note that you can only set up a filter policy on an SNS subscription and NOT on the SNS topic itself. In addition, it is wasteful to set up Amazon EventBridge rule on all AWS Config managed rules, rather than only the restricted-ssh rule. Therefore, both these options are incorrect.

Set up an Amazon EventBridge rule that matches an AWS Config evaluation result of ERROR for the restricted-ssh rule. Create an input transformer for the EventBridge rule. Set up the EventBridge rule to publish a notification to the SNS topic - You get an ERROR evaluation result when one of the required/optional parameters is not valid, or not of the correct type, or is formatted incorrectly. This option has been added as a distractor.

References:

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html

https://docs.aws.amazon.com/config/latest/developerguide/restricted-ssh.html

https://docs.aws.amazon.com/sns/latest/dg/sns-message-filtering.html

Domain

Domain 6: Security and Compliance

Question 13Skipped

A company has configured AWS Organizations to manage its multiple AWS accounts. The company uses Amazon Elastic File System (Amazon EFS) as a shared storage service, configured in AWS Account A of the company. To implement a serverless architecture, the company has decided to move its applications to AWS Lambda. The Lambda functions will be managed through another AWS account (Account B). All the Lambda functions will be deployed in a VPC. A DevOps team needs help to continue using Amazon EFS in Account A with the Lambda function in Account B.

How will you reconfigure the existing EFS file system for use with AWS Lambda function? (Select two)

Correct selection

Update the Lambda execution roles with permission to access the VPC and the EFS file system

Create a VPC peering connection to connect Account A to Account B. Create Service control policies (SCPs) to set permission guardrails for access to Amazon EFS from AWS Lambda function execution role

Configure the Lambda functions in Account B to assume an existing IAM role in Account A for the cross-region, or cross-AZ connectivity between EFS and Lambda

Lambda charges for data transfer between VPCs. To manage costs, create a new EFS file system in Account B. Configure AWS DataSync to transfer data from EFS in Account B to EFS in Account B

Correct selection

Create a VPC peering connection to connect Account A to Account B. Update the EFS file system policy to provide Account B with access to mount and write to the EFS file system in Account A

Overall explanation

Correct options:

Create a VPC peering connection to connect Account A to Account B. Update the EFS file system policy to provide Account B with access to mount and write to the EFS file system in Account A

Update the Lambda execution roles with permission to access the VPC and the EFS file system

You can configure a function to mount an Amazon Elastic File System (Amazon EFS) file system to a local directory. With Amazon EFS, your function code can access and modify shared resources safely and at high concurrency.

Execution role and user permissions: If the file system doesn't have a user-configured AWS Identity and Access Management (IAM) policy, EFS uses a default policy that grants full access to any client that can connect to the file system using a file system mount target. If the file system has a user-configured IAM policy, your function's execution role must have the correct elasticfilesystem permissions.

Configuring a file system and access point: To connect an EFS file system with a Lambda function, you use an EFS access point, an application-specific entry point into an EFS file system that includes the operating system user and group to use when accessing the file system, file system permissions, and can limit access to a specific path in the file system. This helps keep file system configuration decoupled from the application code.

You can access the same EFS file system from multiple functions, using the same or different access points. For example, using different EFS access points, each Lambda function can access different paths in a file system, or use different file system permissions.

Connecting to a file system: A function connects to a file system over the local network in a VPC. The subnets that your function connects to can be the same subnets that contain mount points for your file system, or subnets in the same Availability Zone that can route NFS traffic (port 2049) to the file system. To mount an EFS file system, your Lambda functions must be connected to an Amazon Virtual Private Cloud (Amazon VPC) that can reach the EFS mount targets.

A Lambda function in one account can mount a file system in a different account. For this scenario, you configure VPC peering between the function VPC and the file system VPC.

An example showcasing the use of EFS with AWS Lambda:

via - https://aws.amazon.com/blogs/aws/new-a-shared-file-system-for-your-lambda-functions/

Incorrect options:

Create a VPC peering connection to connect Account A to Account B. Create Service control policies (SCPs) to set permission guardrails for access to Amazon EFS from AWS Lambda function execution role - A VPC peering connection is needed since EFS and AWS Lambda are in different AWS accounts. SCPs alone are not sufficient to grant permissions to the accounts in your organization. You should note that no permissions are granted by an SCP. The Lambda execution role will need explicit permissions for access to EFS.

Configure the Lambda functions in Account B to assume an existing IAM role in Account A for the cross-region or cross-AZ connectivity between EFS and Lambda - This statement is incorrect. AWS does not support cross-region, or cross AZ connectivity between EFS and Lambda.

Lambda charges for data transfer between VPCs. To manage costs, create a new EFS file system in Account B. Configure AWS DataSync to transfer data from EFS in Account B to EFS in Account B - It is mentioned in the use case that EFS and AWS Lambda will remain in their respective accounts. Hence, this option is incorrect.

References:

https://docs.aws.amazon.com/lambda/latest/dg/services-efs.html

https://docs.aws.amazon.com/lambda/latest/dg/configuration-filesystem.html

Domain

Domain 3: Resilient Cloud Solutions

Question 14Skipped

A company uses AWS CodeDeploy to deploy an AWS Lambda function as the final step of a CI/CD pipeline. The company has developed the Lambda function to handle incoming orders through an order-processing API. The DevOps team has noticed intermittent failures in the API occurring for a brief period after deploying the Lambda function. Upon investigation, the team suspects that the failures are a result of incomplete propagation of database changes before the Lambda function gets invoked.

What measures can help resolve this issue?

Add a BeforeInstall hook to the AppSpec file that tests and waits for any necessary database changes before deploying a new version of the Lambda function

Correct answer

Add a BeforeAllowTraffic hook to the AppSpec file that tests and waits for any necessary database changes before traffic can flow to the new version of the Lambda function

Add an AfterAllowTestTraffic hook to the AppSpec file that tests and waits for any necessary database changes after allowing a test traffic

Add a ValidateService hook to the AppSpec file that validates that any necessary database changes are propagated

Overall explanation

Correct option:

Add a BeforeAllowTraffic hook to the AppSpec file that tests and waits for any necessary database changes before traffic can flow to the new version of the Lambda function

BeforeAllowTraffic hook is used to run tasks before traffic is shifted to the deployed Lambda function version. By using the "BeforeAllowTraffic" hook, the DevOps team can ensure that traffic to the new version of the Lambda function is allowed only after necessary database changes have fully propagated, thus avoiding intermittent failures after deployment.

via - https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html

Incorrect options:

Add a BeforeInstall hook to the AppSpec file that tests and waits for any necessary database changes before deploying a new version of the Lambda function

Add a ValidateService hook to the AppSpec file that validates that any necessary database changes are propagated

Add an AfterAllowTestTraffic hook to the AppSpec file that tests and waits for any necessary database changes after allowing test traffic

None of these three lifecycle event hooks are available for an AWS Lambda deployment, so these options are incorrect.

Reference:

https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html

Domain

Domain 2: Configuration Management and IaC

Question 15Skipped

A DevOps Engineer is working on multiple applications that need to be configured for Application Auto scaling, however, there are some application constraints to be addressed:

a) A serverless application is built on AWS Lambda with the following traffic pattern - The traffic for the application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. b) Another flagship application runs on Spot Fleet. The CPU utilization of the fleet has to stay at around 50 percent when the load on the application changes.

Which of the following solutions can address these requirements? (Select two)

Create an Amazon CloudWatch metric to track average CPU utilization of 50 percent for the Spot Fleet. Create a target tracking auto-scaling policy CloudWatch alarm against the CloudWatch metric created from the AWS console

Correct selection

Use Scheduled scaling Auto Scaling policy, and create a scheduled action with AWS Lambda function as a scalable target. Specify the minimum and maximum capacity based on the requirements. AWS CLI, SDKs, or CloudFormation can be used for configuring the schedule scaling

Use Scheduled scaling Auto Scaling policy, and create a scheduled action with Spot instances as a scalable target. Specify the minimum and maximum capacity based on the requirements

Correct selection

Create a target tracking auto-scaling policy that targets an average CPU utilization of 50 percent for an application that runs on Spot Fleet. You can create and manage target tracking using the AWS CLI, SDKs, or CloudFormation

Create an Amazon CloudWatch metric to track the utilization of the AWS Lambda function. Setup step scaling policy by configuring the upper bound, lower bound, and breach threshold values for the Lambda function

Overall explanation

Correct options:

Create a target tracking auto-scaling policy that targets an average CPU utilization of 50 percent for an application that runs on Spot Fleet. You can create and manage target tracking using the AWS CLI, SDKs, or CloudFormation

To create a target tracking scaling policy, you specify an Amazon CloudWatch metric and a target value that represents the ideal average utilization or throughput level for your application. Application Auto Scaling can then scale out the scalable target (add capacity) to handle peak traffic, and scale in the scalable target (remove capacity) to reduce costs during periods of low utilization or throughput.

For example, let's say that you currently have an application that runs on Spot Fleet, and you want the CPU utilization of the fleet to stay at around 50 percent when the load on the application changes. This gives you extra capacity to handle traffic spikes without maintaining an excessive number of idle resources.

You can meet this need by creating a target tracking scaling policy that targets an average CPU utilization of 50 percent. Then, Application Auto Scaling scales the number of instances to keep the actual metric value at or near 50 percent.

Target tracking scaling policies for Application Auto Scaling:

via - https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html

Use Scheduled scaling Auto Scaling policy, and create a scheduled action with AWS Lambda function as a scalable target. Specify the minimum and maximum capacity based on the requirements. AWS CLI, SDKs, or CloudFormation can be used for configuring the schedule scaling

Scaling based on a schedule allows you to set your own scaling schedule according to predictable load changes. For example, let's say that every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can configure a schedule for Application Auto Scaling to increase capacity on Wednesday and decrease capacity on Friday.

To use scheduled scaling, create scheduled actions, which tell Application Auto Scaling to perform scaling activities at specific times. When you create a scheduled action, you specify the scalable target, when the scaling activity should occur, a minimum capacity, and a maximum capacity. You can create scheduled actions that scale one time only or that scale on a recurring schedule.

Scheduled scaling for Application Auto Scaling:

via - https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html

Incorrect options:

Create an Amazon CloudWatch metric to track average CPU utilization of 50 percent for the Spot Fleet. Create a target tracking auto scaling policy CloudWatch alarm against the CloudWatch metric created from the AWS console - With target tracking scaling policies you do not create, edit, or delete the CloudWatch alarms that are used with a target tracking scaling policy. Application Auto Scaling creates and manages the CloudWatch alarms that are associated with your target tracking scaling policies and deletes them when no longer needed.

Use Scheduled scaling Auto Scaling policy, and create a scheduled action with Spot instances as a scalable target. Specify the minimum and maximum capacity based on the requirements - Scheduled scaling is not the right option when a parameter has to be tracked and forms the basis of the scale-in and scale-out activity of the ASG. Target tracking is better suited for these use cases.

Create an Amazon CloudWatch metric to track the utilization of the AWS Lambda function. Setup step scaling policy by configuring the upper bound, lower bound, and breach threshold values for the Lambda function - With step scaling, you choose scaling metrics and threshold values for the CloudWatch alarms that trigger the scaling process as well as define how your scalable target should be scaled when a threshold is in breach for a specified number of evaluation periods. Step scaling policies are not supported for DynamoDB, Amazon Comprehend, Lambda, Amazon Keyspaces, Amazon MSK, ElastiCache, or Neptune.

References:

https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html

https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-step-scaling-policies.html

Domain

Domain 3: Resilient Cloud Solutions

Question 16Skipped

A social media company has its web application hosted on Amazon EC2 instances that are deployed in a single AWS Region. The company has now expanded its operations into new geographies and the company wants to offer low-latency access for the application to its customers. To comply with different financial regulations of each geography, the application needs to operate in silos and the underlying instances in one region should not interact with instances running in other regions.

Which of the following represents the most optimal solution to automate the application deployment to different AWS regions?

Correct answer

Create a CloudFormation template describing the application infrastructure in the Resources section. Use CloudFormation stack set from an administrator account to launch stack instances that deploy the application to various other regions

Create a shell script that uses the AWS CLI to query the current state in one region and output an AWS CloudFormation template. Create a CloudFormation stack from the template by using the AWS CLI, specifying the --region parameter to deploy the application to other regions

Create a CloudFormation template describing the application infrastructure in the Resources section. Use CloudFormation change set from an administrator account to launch stack instances that deploy the application to various other regions

Create a CloudFormation template describing the application infrastructure in the Resources section. Create a CloudFormation stack from the template by using the AWS CLI, specify multiple regions using the --regions parameter to deploy the application

Overall explanation

Correct option:

Create a CloudFormation template describing the application infrastructure in the Resources section. Use CloudFormation stack set from an administrator account to launch stack instances that deploy the application to various other regions

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-howdoesitwork.html

Here are the relevant CloudFormation concepts:

Template: A CloudFormation template is a JSON or YAML formatted text file. You can save these files with any extension, such as .json, .yaml, .template, or .txt. CloudFormation uses these templates as blueprints for building your AWS resources.

Stack: When you use CloudFormation, you manage related resources as a single unit called a stack. You create, update, and delete a collection of resources by creating, updating, and deleting stacks. All the resources in a stack are defined by the stack's CloudFormation template.

Change set: If you need to make changes to the running resources in a stack, you update the stack. Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes. Change sets allow you to see how your changes might impact your running resources, especially critical resources, before implementing them.

Stack set: A stack set lets you create stacks in AWS accounts across regions by using a single CloudFormation template. All the resources included in each stack are defined by the stack set's CloudFormation template. As you create the stack set, you specify the template to use, in addition to any parameters and capabilities that the template requires.

After you've defined a stack set, you can create, update, or delete stacks in the target accounts and AWS Regions you specify. When you create, update, or delete stacks, you can also specify operation preferences, such as the order of Regions in which you want the operation to be performed, the failure tolerance beyond which stack operations stop, and the number of accounts in which operations are performed on stacks concurrently. A stack set is a regional resource. If you create a stack set in one AWS Region, you can't see it or change it in other Regions.

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html

For the given use case, you need to create a stack set that includes the CloudFormation template that you want to use to create stacks and then identify the AWS Regions in which you want to deploy stacks in your target accounts. A stack set ensures consistent deployment of the same stack resources, with the same settings, to all specified target accounts within the Regions you choose.

Incorrect options:

Create a CloudFormation template describing the application infrastructure in the Resources section. Create a CloudFormation stack from the template by using the AWS CLI, specify multiple regions using the --regions parameter to deploy the application - You can create a stack using the AWS Management Console or using AWS CloudFormation commands in the AWS CLI. The aws cloudformation create-stack command supports only a region parameter for a single region and not regions parameter for multiple regions.

via - https://aws.amazon.com/blogs/infrastructure-and-automation/multiple-account-multiple-region-aws-cloudformation/

Create a shell script that uses the AWS CLI to query the current state in one region and output an AWS CloudFormation template. Create a CloudFormation stack from the template by using the AWS CLI, specifying the --region parameter to deploy the application to other regions - Creating a script is not an elegant solution to provision the same infrastructure in multiple AWS regions since this functionality is directly offered by AWS in the form of stack sets.

Create a CloudFormation template describing the application infrastructure in the Resources section. Use CloudFormation change set from an administrator account to launch stack instances that deploy the application to various other regions - When you need to update a stack, understanding how your changes will affect running resources before you implement them can help you update stacks with confidence. Change sets allow you to preview how proposed changes to a stack might impact your running resources, for example, whether your changes will delete or replace any critical resources, AWS CloudFormation makes the changes to your stack only when you decide to execute the change set, allowing you to decide whether to proceed with your proposed changes or explore other changes by creating another change set. You cannot use change sets to deploy an application to multiple AWS regions.

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-howdoesitwork.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html

Domain

Domain 2: Configuration Management and IaC

Question 17Skipped

An e-commerce company has a serverless application stack that consists of CloudFront, API Gateway and Lambda functions. The company has hired you to improve the current deployment process which creates a new version of the Lambda function and then runs an AWS CLI script for deployment. In case the new version errors out, then another CLI script is invoked to deploy the previous working version of the Lambda function. The company has mandated you to decrease the time to deploy new versions of the Lambda functions and also reduce the time to detect and roll back when errors are identified.

Which of the following solutions would you suggest for the given use case?

Set up and deploy nested CloudFormation stacks with the CloudFront distribution as well as the API Gateway in the parent stack. Create and deploy a child stack containing the Lambda functions. To address any changes in a Lambda function, create a CloudFormation change set and deploy. In case the Lambda function errors out, rollback the CloudFormation change set to the previous version

Set up and deploy nested CloudFormation stacks with the CloudFront distribution as well as the API Gateway in the parent stack. Create and deploy a child stack containing the Lambda functions. To address any changes in a Lambda function, create a CloudFormation change set and deploy. Use pre-traffic and post-traffic test functions of the change set to verify the deployment. Rollback in case CloudWatch alarms are triggered

Correct answer

Use Serverless Application Model (SAM) and leverage the built-in traffic-shifting feature of SAM to deploy the new Lambda version via CodeDeploy and use pre-traffic and post-traffic test functions to verify code. Rollback in case CloudWatch alarms are triggered

Set up and deploy a CloudFormation stack containing a new API Gateway endpoint that points to the new Lambda version. Test the updated CloudFront origin that points to this new API Gateway endpoint and in case errors are detected then revert the CloudFront origin to the previous working API Gateway endpoint

Overall explanation

Correct option:

Use Serverless Application Model (SAM) and leverage the built-in traffic-shifting feature of SAM to deploy the new Lambda version via CodeDeploy and use pre-traffic and post-traffic test functions to verify code. Rollback in case CloudWatch alarms are triggered

The AWS Serverless Application Model (SAM) is an open-source framework for building serverless applications. It provides shorthand syntax to express functions, APIs, databases, and event source mappings. You define the application you want with just a few lines per resource and model it using YAML. During deployment, SAM transforms and expands the SAM syntax into AWS CloudFormation syntax. Then, CloudFormation provisions your resources with reliable deployment capabilities.

To address the given use case, you can use the traffic shifting feature of SAM to easily test the new version of the Lambda function without having to manually move 100% of the traffic to the new version in one shot.

You can use CodeDeploy to create a deployment process that publishes the new Lambda version but does not send any traffic to it. Then it executes a PreTraffic test to ensure that your new function works as expected. After the test succeeds, CodeDeploy automatically shifts traffic gradually to the new version of the Lambda function. This workflow addresses one of the key requirements of reducing the time to detect errors. You can roll back to the previous version in case the new version errors out.

via - https://aws.amazon.com/blogs/compute/implementing-safe-aws-lambda-deployments-with-aws-codedeploy/

Incorrect options:

Set up and deploy nested CloudFormation stacks with the CloudFront distribution as well as the API Gateway in the parent stack. Create and deploy a child stack containing the Lambda functions. To address any changes in a Lambda function, create a CloudFormation change set and deploy. In case the Lambda function errors out, rollback the CloudFormation change set to the previous version - You can use CloudFormation change sets to preview how proposed changes to a stack might impact your running resources, for example, whether your changes will delete or replace any critical resources, AWS CloudFormation makes the changes to your stack only when you decide to execute the change set, allowing you to decide whether to proceed with your proposed changes or explore other changes by creating another change set.

This option does not help in reducing the time to detect any potential deployment errors as you would not know about any potential failures until you actually deploy the stack.

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html

Instead, you should use SAM to create your serverless application as it comes built-in with CodeDeploy to provide gradual Lambda deployments. Also, you can define pre-traffic and post-traffic test functions to verify that the newly deployed code is configured correctly and your application operates as expected. You can roll back the deployment if CloudWatch alarms are triggered.

Set up and deploy a CloudFormation stack containing a new API Gateway endpoint that points to the new Lambda version. Test the updated CloudFront origin that points to this new API Gateway endpoint and in case errors are detected then revert the CloudFront origin to the previous working API Gateway endpoint - This option does not help in reducing the time to detect any potential deployment errors as you would not know about any potential failures until you actually deploy the stack and point to the new endpoint.

Instead, you should use SAM to create your serverless application as it comes built-in with CodeDeploy to provide gradual Lambda deployments. Also, you can define pre-traffic and post-traffic test functions to verify that the newly deployed code is configured correctly and your application operates as expected. You can roll back the deployment if CloudWatch alarms are triggered.

Set up and deploy nested CloudFormation stacks with the CloudFront distribution as well as the API Gateway in the parent stack. Create and deploy a child stack containing the Lambda functions. To address any changes in a Lambda function, create a CloudFormation change set and deploy. Use pre-traffic and post-traffic test functions of the change set to verify the deployment. Rollback in case CloudWatch alarms are triggered - This option has been added as a distractor since CloudFormation change sets do not have pre-traffic and post-traffic test functions. Therefore this option is incorrect.

References:

https://aws.amazon.com/blogs/compute/implementing-safe-aws-lambda-deployments-with-aws-codedeploy/

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html

Domain

Domain 2: Configuration Management and IaC

Question 18Skipped

A company is implementing AWS serverless architecture with Amazon API Gateway, AWS Lambda, and Amazon DynamoDB services. The company's existing users are primarily located in Europe and Asia-Pacific regions. The company is now looking for a quick-start solution that offers high reliability and low latency for a global user base across regions as its offerings are getting popular worldwide.

How will you implement this requirement?

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use failover routing and Application Recovery Controller health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use geolocation routing and health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table

Configure Amazon Route 53 to point to AWS Global Accelerator. Configure Global Accelerator to point to API Gateway API endpoint(s) of both regions via an Application Load Balancer(ALB). Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table

Correct answer

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use latency-based routing and health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table

Overall explanation

Correct option:

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use latency-based routing and health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table

Route 53: If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency. To use latency-based routing, you create latency records for your resources in multiple AWS Regions. When Route 53 receives a DNS query for your domain or subdomain (example.com or acme.example.com), it determines which AWS Regions you've created latency records for, determines which region gives the user the lowest latency, and then selects a latency record for that region. Route 53 responds with the value from the selected record, such as the IP address for a web server. Amazon Route 53 latency-based routing will reduce latency by serving the user from the fastest available route between the two AWS regions.

You can use Amazon Route 53 health checks to control DNS failover from an API Gateway API in a primary AWS Region to one in a secondary Region. This can help mitigate impacts in the event of a Regional issue.

AWS Lambda provides easy scaling and high availability to your serverless architecture without additional effort on your part.

Amazon DynamoDB global tables is a fully managed, serverless, multi-Region, and multi-active database. Global tables provide you 99.999% availability, increased application resiliency, and improved business continuity. As global tables replicate your Amazon DynamoDB tables automatically across your choice of AWS Regions, you can achieve fast, local read and write performance.

A DynamoDB global table is comprised of multiple replica tables. Each replica table exists in a different Region, but all replicas have the same name and primary key. When data is written to any replica table, DynamoDB automatically replicates that data to all other replica tables in the global table. Global tables enable the users of your application to have low-latency access to the data no matter where they are located. In the unlikely event that one AWS Region was to become temporarily unavailable, your customers can still access the replica tables in the other Regions.

Incorrect options:

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use geolocation routing and health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table - Route 53 geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from. For example, you might want all queries from Europe to be routed to an ELB load balancer in the Frankfurt region. While using geolocation routing can help you localize your content and present some or all of your website in the language of your users, it is not suitable to serve content with the lowest latency.

Configure Amazon Route 53 to point to API Gateway APIs in Europe and Asia-Pacific regions. Use failover routing and Application Recovery Controller health checks in Route 53. Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table - While failover routing lets you route traffic to a resource when the resource is healthy or to a different resource when the first resource is unhealthy, it is not suitable when the key requirement is to serve content with lowest possible latency.

Configure Amazon Route 53 to point to AWS Global Accelerator. Configure Global Accelerator to point to API Gateway API endpoint(s) of both regions via an Application Load Balancer(ALB). Configure the APIs to forward requests to an AWS Lambda function in the respective Regions. Setup the Lambda function to retrieve and update the data in a DynamoDB global table - AWS Global Accelerator can be used in conjunction with the Amazon API Gateway to present Internet-facing API via static IP addresses to end users. This design addresses the need for static IP safe listing, however, it is not useful for the given requirements.

References:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-latency.html

https://aws.amazon.com/dynamodb/global-tables/

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-geo.html

https://aws.amazon.com/blogs/networking-and-content-delivery/accessing-an-aws-api-gateway-via-static-ip-addresses-provided-by-aws-global-accelerator/

Domain

Domain 3: Resilient Cloud Solutions

Question 19Skipped

In a multinational company, various AWS accounts are efficiently managed using AWS Control Tower. The company operates both internal and public applications across its infrastructure. To streamline operations, each application team is assigned a dedicated AWS account responsible for hosting their respective applications. These accounts are consolidated under an organization in AWS Organizations. Additionally, a specific AWS Control Tower member account acts as a centralized DevOps hub, offering Continuous Integration/Continuous Deployment (CI/CD) pipelines that application teams utilize to deploy applications to their designated AWS accounts. A specialized IAM role for deployment is available within this central DevOps account.

Currently, a particular application team is facing challenges while attempting to deploy its application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster situated in their application-specific AWS account. They have an existing IAM role for deployment within the application AWS account. The deployment process relies on an AWS CodeBuild project, configured within the centralized DevOps account, and utilizes an IAM service role for CodeBuild. However, the deployment process is encountering an Unauthorized error when trying to establish connections to the cross-account EKS cluster from the CodeBuild environment.

To resolve this error and facilitate a successful deployment, what solution would you recommend?

Correct answer

Establish a trust relationship in the application account's deployment IAM role for the centralized DevOps account, allowing the sts:AssumeRole action. Also, grant the application account's deployment IAM role the necessary access to the EKS cluster. Additionally, configure the EKS cluster aws-auth ConfigMap to map the role to the appropriate system permissions

Establish a trust relationship in the centralized DevOps account for the application account's deployment IAM role, allowing the sts:AssumeRole action. Also, grant the application account's deployment IAM role the necessary access to the EKS cluster. Additionally, configure the EKS cluster aws-auth ConfigMap to map the role to the appropriate system permissions

Establish a trust relationship in the centralized DevOps account's deployment IAM role for the application account, allowing the sts:AssumeRoleWithSAML action. Also, grant the centralized DevOps account's deployment IAM role the required access to CodeBuild

Establish a trust relationship in the application account's deployment IAM role for the centralized DevOps account, allowing the sts:AssumeRoleWithSAML action. Also, grant the centralized DevOps account's deployment IAM role the required access to CodeBuild and the EKS cluster

Overall explanation

Correct option:

Establish a trust relationship in the application account's deployment IAM role for the centralized DevOps account, allowing the sts:AssumeRole action. Also, grant the application account's deployment IAM role the necessary access to the EKS cluster. Additionally, configure the EKS cluster aws-auth ConfigMap to map the role to the appropriate system permissions

By configuring a trust relationship in the application account's deployment IAM role for the centralized DevOps account, using the sts:AssumeRole action, CodeBuild in the centralized DevOps account will be allowed to assume the IAM role in the application account. This will enable CodeBuild to access the EKS cluster in the application account. Additionally, granting the application account's deployment IAM role the necessary access to the EKS cluster ensures that it has the required permissions to perform the deployment tasks. Finally, configuring the EKS cluster aws-auth ConfigMap to map the role to the appropriate system permissions ensures that the IAM role has the required permissions within the EKS cluster.

via - https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

Incorrect options:

Establish a trust relationship in the application account's deployment IAM role for the centralized DevOps account, allowing the sts:AssumeRoleWithSAML action. Also, grant the centralized DevOps account's deployment IAM role the required access to CodeBuild and the EKS cluster

Establish a trust relationship in the centralized DevOps account's deployment IAM role for the application account, allowing the sts:AssumeRoleWithSAML action. Also, grant the centralized DevOps account's deployment IAM role the required access to CodeBuild

AssumeRoleWithSAML is used for federation scenarios involving SAML-based identity providers, which is not relevant to the given use case, so both these options are incorrect.

Establish a trust relationship in the centralized DevOps account for the application account's deployment IAM role, allowing the sts:AssumeRole action. Also, grant the application account's deployment IAM role the necessary access to the EKS cluster. Additionally, configure the EKS cluster aws-auth ConfigMap to map the role to the appropriate system permissions

You need to configure a trust relationship in the application account's deployment IAM role for the centralized DevOps account, so that CodeBuild in the centralized DevOps account can assume the IAM role in the application account, by using the sts:AssumeRole action. However, this option sets up the trust relationship in the reverse direction, so it's incorrect.

References:

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html

Domain

Domain 2: Configuration Management and IaC

Question 20Skipped

A data analytics company wants to move all its clients belonging to the regulated and security-sensitive industries such as financial services and healthcare to the AWS Cloud as it wants to leverage the out-of-box security-specific capabilities offered by AWS. The DevOps team at the company is developing a framework to validate the adoption of AWS best practices and industry-recognized compliance standards. The AWS Management Console is the preferred method for the in-house teams wanting to provision resources.

Which of the following strategies would you adopt to address these business requirements for continuously assessing, auditing and monitoring the configurations of AWS resources? (Select two)

Leverage CloudWatch Logs agent to collect all the AWS SDK logs. Search the log data using a pre-defined set of filter patterns that match mutating API calls. Use CloudWatch alarms to send notifications via SNS when unintended changes are performed. Archive log data by using a batch export to Amazon S3 and analyze via Athena

Correct selection

Leverage AWS Config rules to audit changes to AWS resources and monitor the compliance of the configuration by running the evaluations for the rule at a frequency that you choose. Develop AWS Config custom rules to establish a test-driven development approach by triggering the evaluation when any resource that matches the rule's scope changes in configuration

Leverage EventBridge events near-real-time capabilities to monitor system events patterns to trigger Lambda functions to automatically revert non-authorized changes in AWS resources. Send notifications via SNS topics to improve the incidence response time

Leverage CloudTrail integration with SNS to automatically notify unauthorized API activities. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services. Use Lambda functions to automatically revert non-authorized changes in AWS resources

Correct selection

Enable trails and set up CloudTrail events to review and monitor management activities of all AWS accounts by logging these activities into CloudWatch Logs using a KMS key. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services

Overall explanation

Correct options:

Leverage AWS Config rules to audit changes to AWS resources and monitor the compliance of the configuration by running the evaluations for the rule at a frequency that you choose. Develop AWS Config custom rules to establish a test-driven development approach by triggering the evaluation when any resource that matches the rule's scope changes in configuration

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. With Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines. You can use Config to answer questions such as - “What did my AWS resource look like at xyz point in time?”.

How AWS Config Works:

via - https://aws.amazon.com/config/

For the given use case, you can use AWS Config to evaluate the configuration settings of your AWS resources. You do this by creating AWS Config rules, which represent your ideal configuration settings. AWS Config provides customizable, predefined rules called managed rules to help you get started. You can also create your own custom rules. While AWS Config continuously tracks the configuration changes that occur among your resources, it checks whether these changes violate any of the conditions in your rules. If a resource violates a rule, AWS Config flags the resource and marks the rule as non-compliant.

There are two types of evaluation trigger types for Config rules:

Configuration changes – AWS Config triggers the evaluation when any resource that matches the rule's scope changes in configuration. The evaluation runs after AWS Config sends a configuration item change notification.

Periodic – AWS Config runs evaluations for the rule at a frequency that you choose (for example, every 24 hours).

Enable trails and set up CloudTrail events to review and monitor management activities of all AWS accounts by logging these activities into CloudWatch Logs using a KMS key. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services

CloudTrail is an AWS service that helps you enable governance, compliance, and operational and risk auditing of your AWS account. Actions taken by a user, role, or AWS service are recorded as events in CloudTrail. An event in CloudTrail is the record of activity in an AWS account. This activity can be an action taken by a user, role, or service that is monitorable by CloudTrail. CloudTrail events provide a history of both API and non-API account activity made through the AWS Management Console, AWS SDKs, command line tools, and other AWS services.

CloudTrail data events are disabled by default. You can enable logging at an additional cost. Data events are also known as data plane operations and are often high-volume activities. Data events aren't viewable in CloudTrail event history and are charged for all copies at a reduced rate compared to management events.

CloudTrail records management events for the last 90 days free of charge, and are viewable in the Event History with the CloudTrail console. For Amazon S3 delivery of CloudTrail events, the first copy delivered is free. Additional copies of management events are charged.

via - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-management-events

Incorrect options:

Leverage the CloudWatch Logs agent to collect all the AWS SDK logs. Search the log data using a pre-defined set of filter patterns that match mutating API calls. Use CloudWatch alarms to send notifications via SNS when unintended changes are performed. Archive log data by using a batch export to Amazon S3 and analyze via Athena - One of the key constraints for the given scenario is that the AWS Management Console is the preferred method for the in-house teams wanting to provision resources. Although this option is technically feasible, it focuses on using the CloudWatch Logs agent to collect all the AWS SDK logs. The given use case has no specific requirements for AWS SDKs or AWS APIs because AWS Management Console is the preferred method to provision resources. So this option is not the best-fit solution.

Leverage CloudTrail integration with SNS to automatically notify unauthorized API activities. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services. Use Lambda functions to automatically revert non-authorized changes in AWS resources - One of the key constraints for the given scenario is that the AWS Management Console is the preferred method for the in-house teams wanting to provision resources. Although this option is technically feasible, it focuses on capturing unauthorized API activities. The given use case has no specific requirements for AWS SDKs or AWS APIs because AWS Management Console is the preferred method to provision resources. In addition, the use case just talks about assessing, auditing, and monitoring the configurations of AWS resources. Reverting non-authorized changes in AWS resources is not part of the mandate. So this option is not correct.

Leverage EventBridge events near-real-time capabilities to monitor system event patterns to trigger Lambda functions to automatically revert non-authorized changes in AWS resources. Send notifications via SNS topics to improve the incidence response time - The use-case just talks about assessing, auditing and monitoring the configurations of AWS resources. Reverting non-authorized changes in AWS resources is not part of the mandate. So this option is not correct.

References:

https://aws.amazon.com/config/

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_manage-rules.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-management-events

Domain

Domain 6: Security and Compliance

Question 21Skipped

The security policy of a company mandates encrypting all AMIs that the company shares across its AWS accounts. An AWS account (Account A) has a custom AMI that is not encrypted. This AMI needs to be shared with another AWS Account B. Account B has Amazon EC2 instances configured with an Auto Scaling group that will use the AMI. Account A already has an AWS Key Management Service (AWS KMS) key.

As a DevOps Engineer, which combination of steps will you take to share the AMI with Account B while adhering to the company's security policy? (Select two)

In Account A, create an encrypted AMI from the unencrypted version with AWS managed key. Modify the key policy to give permissions to Account B for creating a grant. Share the encrypted AMI with Account B

Correct selection

In Account B, create a KMS grant that delegates permissions to the service-linked role attached to the Auto Scaling group

Correct selection

In Account A, create an encrypted AMI from the unencrypted version and specify the KMS key in the copy action. Modify the key policy to give permissions to Account B for creating a grant. Share the encrypted AMI with Account B

In Account A, create an encrypted AMI from the unencrypted version and encrypt the associated EBS snapshots with it. Specify the KMS key in the copy action. Share the encrypted AMI with Account B

In Account A, create an encrypted AMI from the unencrypted version and specify the KMS key in the copy action. Modify permissions on the AMI to be accessible from Account B

Overall explanation

Correct options:

In Account A, create an encrypted AMI from the unencrypted version and specify the KMS key in the copy action. Modify the key policy to give permissions to Account B for creating a grant. Share the encrypted AMI with Account B

In Account B, create a KMS grant that delegates permissions to the service-linked role attached to the Auto Scaling group

As per the security policy of the company, encrypt the unencrypted AMI using the KMS key. The encrypted snapshots must be encrypted with a KMS key. You can’t share AMIs that are backed by snapshots that are encrypted with the default AWS-managed key.

Amazon EC2 Auto Scaling uses service-linked roles to delegate permissions to other AWS services. Amazon EC2 Auto Scaling service-linked roles are predefined and include permissions that Amazon EC2 Auto Scaling requires to call other AWS services on your behalf. The predefined permissions also include access to your AWS-managed keys. However, they do not include access to your customer-managed keys, allowing you to maintain full control over these keys.

If you create a customer-managed key in a different account than the Auto Scaling group, you must use a grant in combination with the key policy to allow cross-account access to the key. This is a two-step process (refer to the image attached)

The first policy allows Account A to give an IAM user or role in the specified Account B permission to create a grant for the key. However, this does not by itself give any users access to the key.

Then, from Account B which contains the Auto Scaling group, create a grant that delegates the relevant permissions to the appropriate service-linked role. The Grantee Principal element of the grant is the ARN of the appropriate service-linked role. The key-id is the ARN of the key.

Key policy sections that allow cross-account access to the customer-managed key:

via - https://docs.aws.amazon.com/autoscaling/ec2/userguide/key-policy-requirements-EBS-encryption.html

Incorrect options:

In Account A, create an encrypted AMI from the unencrypted version with AWS managed key. Modify the key policy to give permissions to Account B for creating a grant. Share the encrypted AMI with Account B

In Account A, create an encrypted AMI from the unencrypted version and specify the KMS key in the copy action. Modify permissions on the AMI to be accessible from Account B

In Account A, create an encrypted AMI from the unencrypted version and encrypt the associated EBS snapshots with it. Specify the KMS key in the copy action. Share the encrypted AMI with Account B

These three options contradict the explanation provided above, so these options are incorrect.

References:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/key-policy-requirements-EBS-encryption.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html

Domain

Domain 6: Security and Compliance

Question 22Skipped

A project has two AWS accounts, a development account and a production account, in the us-east-1 Region. A DevOps engineer has to deploy artifacts from the development account's S3 bucket to the production account's S3 bucket using AWS CodePipeline with Amazon S3 deploy action.

What configurations are mandatory for this cross-account deployment? (Select two)

Create Secrets Manager key to use with CodePipeline in the development account

Correct selection

Configure a cross-account role in the production account. Attach a policy to your CodePipeline service role in the development account that allows it to assume the cross-account role that you created

You need to use an AWS KMS multi-Region key with multiple replicas

Correct selection

Create an AWS KMS key to use with CodePipeline in the development account. Also, the input bucket from the development account must have versioning activated to work with CodePipeline

Configure a cross-account role in the development account. Attach a policy to the S3 bucket in the production account that allows access to the cross-account role that you created

Overall explanation

Correct options:

Create an AWS KMS key to use with CodePipeline in the development account. Also, the input bucket from the development account must have versioning activated to work with CodePipeline

You must use the AWS Key Management Service (AWS KMS) customer-managed key for cross-account deployments. If the key isn't configured, then CodePipeline encrypts the objects with default encryption, which can't be decrypted by the role in the destination account.

The input bucket must have versioning activated to work with CodePipeline.

Configure a cross-account role in the production account. Attach a policy to your CodePipeline service role in the development account that allows it to assume the cross-account role that you created

In the deploy action, the CodePipeline service role assumes the cross-account role in the production account. CodePipeline uses the cross-account role to access the KMS key and artifact bucket in the development account. Then, CodePipeline deploys the extracted files to the production output S3 bucket in the production account.

Incorrect options:

Create Secrets Manager key to use with CodePipeline in the development account - This option is not relevant for the given use case.

Configure a cross-account role in the development account. Attach a policy to the S3 bucket in the production account that allows access to the cross-account role that you created - This statement is incorrect and given only as a distractor.

You need to use an AWS KMS multi-Region key with multiple replicas - This option has been added as a distractor. Only when the production account's Region is different than your pipeline's Region, then you must also use an AWS KMS multi-Region key with multiple replicas.

References:

https://repost.aws/knowledge-center/codepipeline-artifacts-s3

https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-S3Deploy.html

Domain

Domain 2: Configuration Management and IaC

Question 23Skipped

A multi-national company with hundreds of AWS accounts has slowly adopted AWS Organizations with all features enabled. The company has also configured a few Organization Units (OUs) to serve its business objectives. The company has some AWS Identity and Access Management (IAM) roles that need to be configured for every new AWS account created for the company. Also, the security policy mandates enabling AWS CloudTrail for all AWS accounts. The company is looking for an automated solution that can add the mandatory IAM Roles and CloudTrail configurations to all newly created accounts and also delete the resources/configurations when an account leaves the organization without manual intervention.

What should a DevOps engineer do to meet these requirements with the minimal overhead?

Run automation across multiple accounts using AWS System Manager Automation. Create an AWS resource group from the management account (or any centralized account) and name it exactly the same for all accounts and OUs and add the account ID or OU as a prefix as per standard naming convention. Include the CloudTrail configuration and the IAM role to be created

From the management account of AWS Organizations, create an Amazon EventBridge rule that is triggered by AWS account creation API call. Configure an AWS Lambda function to enable CloudTrail logging and to attach the necessary IAM roles to the account

From the management account of AWS Organizations, enable AWS CloudTrail logs for all member accounts. Similarly, create an IAM role and share it across accounts and OUs of the AWS Organization

Correct answer

From the management account of AWS Organizations, create an AWS CloudFormation stack set to enable AWS Config and deploy your centralized AWS Identity and Access Management (IAM) roles. Configure the stack set to deploy automatically when an account is created through AWS Organizations

Overall explanation

Correct option:

From the management account of AWS Organizations, create an AWS CloudFormation stack set to enable AWS Config and deploy your centralized AWS Identity and Access Management (IAM) roles. Configure the stack set to deploy automatically when an account is created through AWS Organizations

You can centrally orchestrate any AWS CloudFormation enabled service across multiple AWS accounts and regions. For example, you can deploy your centralized AWS Identity and Access Management (IAM) roles, provision Amazon Elastic Compute Cloud (Amazon EC2) instances or AWS Lambda functions across AWS Regions and accounts in your organization. CloudFormation StackSets simplify the configuration of cross-account permissions and allow for the automatic creation and deletion of resources when accounts are joined or removed from your Organization.

You can get started by enabling data sharing between CloudFormation and Organizations from the StackSets console. Once done, you will be able to use StackSets in the AWS Organizations master account to deploy stacks to all accounts in your organization or specific organizational units (OUs). A new service-managed permission model is available with these StackSets. Choosing Service managed permissions allows StackSets to automatically configure the necessary IAM permissions required to deploy your stack to the accounts in your organization.

In addition to setting permissions, CloudFormation StackSets offer the option for automatically creating or removing your CloudFormation stacks when a new AWS account joins or quits your Organization. You do not need to remember to manually connect to the new account to deploy your common infrastructure or to delete infrastructure when an account is removed from your Organization. When an account leaves the organization, the stack will be removed from the management of StackSets. However, you can choose to either delete or retain the resources managed by the stack.

Lastly, you choose whether to deploy a stack to your entire organization or just to one or more Organization Units (OU). You also choose a couple of deployment options: how many accounts will be prepared in parallel, and how many failures you tolerate before stopping the entire deployment.

Use AWS CloudFormation StackSets for Multiple Accounts in an AWS Organization:

via - https://aws.amazon.com/blogs/aws/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/

Incorrect options:

From the management account of AWS Organizations, create an Amazon EventBridge rule that is triggered by an AWS account creation API call. Configure an AWS Lambda function to enable CloudTrail logging and to attach the necessary IAM roles to the account - This option involves using too many services which unnecessarily adds to the complexity and cost of the overall solution. So, this option is incorrect.

Run automation across multiple accounts using AWS System Manager Automation. Create an AWS resource group from the management account (or any centralized account) and name it exactly the same for all accounts and OUs and add the account ID or OU as a prefix as per standard naming convention. Include the CloudTrail configuration and the IAM role to be created - While you can use AWS Systems Manager to automate tasks across multiple accounts in AWS Organization, the other details in this option are irrelevant to the given use case.

When you run automation across multiple Regions and accounts, you target resources by using tags or the name of an AWS resource group. The resource group must exist in each target account and Region. The resource group name must be the same in each target account and Region. The automation fails to run on those resources that don't have the specified tag or that aren't included in the specified resource group.

From the management account of AWS Organizations, enable AWS CloudTrail logs for all member accounts. Similarly, create an IAM role and share it across accounts and OUs of the AWS Organization - It is possible to enable CloudTrail logging from the management account of AWS Organizations, and is referred to as the organization trail. The use case is to be able to log all Trail events to a commonplace. Also, creating an IAM role in the management account and sharing it across all member accounts is not straightforward and requires manual work. Hence, this option is incorrect for the given use case.

IAM policies usage in AWS Organizations:

via - https://docs.aws.amazon.com/organizations/latest/userguide/orgs_permissions_overview.html

References:

https://aws.amazon.com/blogs/aws/new-use-aws-cloudformation-stacksets-for-multiple-accounts-in-an-aws-organization/

https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html

Domain

Domain 1: SDLC Automation

Question 24Skipped

The flagship application at a company is deployed on Amazon EC2 instances running behind an Application Load Balancer (ALB) within an Auto Scaling group. A DevOps Engineer wants to configure a Blue/Green deployment for this application and has already created launch templates and Auto Scaling groups for both blue and green environments, each deploying to their respective target groups. The ALB can direct traffic to either environment's target group, and an Amazon Route 53 record points to the ALB. The goal is to enable an all-at-once transition of traffic from the software running on the blue environment's EC2 instances to the newly deployed software on the green environment's EC2 instances.

What steps should the DevOps Engineer take to fulfill these requirements?

Initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances. Perform a Route 53 DNS update to point to the green environment's endpoint on the ALB

Leverage an AWS CLI command to update the ALB and direct traffic to the green environment's target group. Then initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances

Set up an all-at-once deployment to the blue environment's EC2 instances. Perform a Route 53 DNS update to point to the green environment's endpoint on the ALB

Correct answer

Initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances. Once the rolling restart is complete, leverage an AWS CLI command to update the ALB and direct traffic to the green environment's target group

Overall explanation

Correct option:

Initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances. Once the rolling restart is complete, leverage an AWS CLI command to update the ALB and direct traffic to the green environment's target group

A Blue/Green deployment is a deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new application version. Using a Blue/Green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic is directed to the green environment and the blue environment is deprecated.

Several AWS deployment services support Blue/Green deployment strategies including Elastic Beanstalk, OpsWorks, CloudFormation, CodeDeploy, and Amazon ECS.

For the given use case, the blue group carries the production load while the green group is staged and deployed with the new code. When it’s time to deploy, you simply attach the green group to the existing load balancer to introduce traffic to the new environment. As you scale up the green Auto Scaling group, you can take the blue Auto Scaling group instances out of service by either terminating them or putting them in a Standby state.

via - https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

Incorrect options:

Set up an all-at-once deployment to the blue environment's EC2 instances. Perform a Route 53 DNS swap to the green environment's endpoint on the ALB

Initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances. Perform a Route 53 DNS swap to the green environment's endpoint on the ALB

Both these options have been added as distractors. Since there is only a single ALB per the given use case, so there is no alternate endpoint available for a Route 53 DNS update.

Leverage an AWS CLI command to update the ALB and direct traffic to the green environment's target group. Then initiate a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment's EC2 instances - The order of execution for this option is incorrect as it points the ALB to the green environment's target group before deploying the new software on the green environment's EC2 instances.

References:

https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html

Domain

Domain 1: SDLC Automation

Question 25Skipped

A support team wants to be notified via an Amazon Simple Notification Service (Amazon SNS) notification when an AWS Glue job fails a retry.

As a DevOps Engineer, how will you implement this requirement?

Amazon Simple Notification Service (Amazon SNS) cannot retry failures, leverage Amazon Simple Queue Service (Amazon SQS) dead-letter queues to retry the failed Glue jobs

Check the AWS Personal Health Dashboard for failed AWS Glue jobs. Schedule an AWS Lambda function to pick the failed event from the service health dashboard and trigger an Amazon Simple Notification Service (Amazon SNS) notification when a retry fails

Configure Amazon EventBridge events for AWS Glue. Configure an Amazon Simple Notification Service (Amazon SNS) notification when the Glue job fails a retry

Correct answer

Configure Amazon EventBridge events for AWS Glue. Define the AWS Lambda function as a target to the EventBridge. The Lambda function will have the logic to process the events and filter the AWS Glue job retry failure event. Publish a message to Amazon Simple Notification Service (Amazon SNS) notification if such an event is found

Overall explanation

Correct option:

Configure Amazon EventBridge events for AWS Glue. Define the AWS Lambda function as a target to the EventBridge. The Lambda function will have the logic to process the events and filter the AWS Glue job retry failure event. Publish a message to Amazon Simple Notification Service (Amazon SNS) notification if such an event is found

Amazon EventBridge events for AWS Glue can be used to create Amazon SNS alerts, but the alerts might not be specific enough for certain situations. To receive SNS notifications for certain AWS Glue Events, such as an AWS Glue job failing on retry, you can use AWS Lambda. You can create a Lambda function to do the following:

Check the incoming event for a specific string.

Publish a message to Amazon SNS if the string in the event matches the string in the Lambda function.

To use an AWS Lambda function to receive an email from SNS when any of your AWS Glue jobs fail a retry, do the following: 1. Create an Amazon SNS topic. 2. Create an AWS Lambda function. 3. Create an Amazon EventBridge event that uses the Lambda function to initiate email notifications.

AWS Lambda function logic:

via - https://repost.aws/knowledge-center/glue-job-fail-retry-lambda-sns-alerts

Incorrect options:

Configure Amazon EventBridge events for AWS Glue. Configure an Amazon Simple Notification Service (Amazon SNS) notification when the Glue job fails a retry - Amazon EventBridge cannot be directly used without a Lambda function since the use case needs notifications only for Glue job retry failure. So this logic has to be included in a Lambda function.

Amazon Simple Notification Service (Amazon SNS) cannot retry failures, leverage Amazon Simple Queue Service (Amazon SQS) dead-letter queues to retry the failed Glue jobs - The use case is not about retrying the Glue job, but about sending an SNS notification when the retry of the job fails.

Check the AWS Personal Health Dashboard for failed AWS Glue jobs. Schedule an AWS Lambda function to pick the failed event from the service health dashboard and trigger an Amazon Simple Notification Service (Amazon SNS) notification when a retry fails - AWS Personal Health Dashboard provides proactive notifications of scheduled activities, such as any changes to the infrastructure powering your resources, enabling you to better plan for events that may affect you. This option is not relevant to the given requirements.

Reference:

https://repost.aws/knowledge-center/glue-job-fail-retry-lambda-sns-alerts

Domain

Domain 5: Incident and Event Response

Question 26Skipped

A DevOps Engineer needs to use the AWS CloudFormation stack to deploy an application. But the DevOps Engineer does not have the required permissions to provision the resources specified in the AWS CloudFormation template.

Which solution will allow the DevOps Engineer to deploy the stack while providing the least privileges possible?

Correct answer

Create an AWS CloudFormation service role with required permissions and associate this service role to the stack. Grant the developer iam:PassRole permissions to pass the role to the service. Use this newly created service role during stack deployments

Create an AWS CloudFormation service role with full permissions and associate this service role to the stack. Grant the developer iam:PassRole permissions. Limit the permissions to pass a role based on tags attached to the role using the ResourceTag/key-name condition key

Create an AWS CloudFormation service role with necessary permissions and use aws:SourceIp AWS-wide condition to specify the IP addresses of the developers. Associate this service role to the stack. Grant the developer iam:PassRole permissions to pass the role to the service. Use this newly created service role during stack deployments

Create an AWS CloudFormation service role with required permissions and associate this service role to the stack. Use this newly created service role during stack deployments

Overall explanation

Correct option:

Create an AWS CloudFormation service role with required permissions and associate this service role to the stack. Grant the developer iam:PassRole permissions to pass the role to the service. Use this newly created service role during stack deployments

A service role is an AWS Identity and Access Management (IAM) role that allows AWS CloudFormation to make calls to resources in a stack on your behalf. You can specify an IAM role that allows AWS CloudFormation to create, update, or delete your stack resources. By default, AWS CloudFormation uses a temporary session that it generates from your user credentials for stack operations. If you specify a service role, AWS CloudFormation uses that role's credentials.

Use a service role to explicitly specify the actions that AWS CloudFormation can perform, which might not always be the same actions that you or other users can do. For example, you might have administrative privileges, but you can limit AWS CloudFormation access to only Amazon EC2 actions.

When you specify a service role, AWS CloudFormation always uses that role for all operations that are performed on that stack. It is not possible to remove a service role attached to a stack after the stack is created. Other users that have permission to perform operations on this stack will be able to use this role, but they must have the iam:PassRole permission.

To pass a role (and its permissions) to an AWS service, a user must have permission to pass the role to the service. This helps administrators ensure that only approved users can configure a service with a role that grants permissions. To allow a user to pass a role to an AWS service, you must grant PassRole permission to the user's IAM user, role, or group.

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html

Incorrect options:

Create an AWS CloudFormation service role with full permissions and associate this service role to the stack. Grant the developer iam:PassRole permissions. Limit the permissions to pass a role based on tags attached to the role using the ResourceTag/key-name condition key - Giving full permissions is against the security best practice that says a role should have the least possible privileges to complete the action needed. AWS suggests not using the ResourceTag condition key in a policy with the iam:PassRole action. You cannot use the tag on an IAM role to control access to who can pass that role.

Create an AWS CloudFormation service role with necessary permissions and use aws:SourceIp AWS-wide condition to specify the IP addresses of the developers. Associate this service role to the stack. Grant the developer iam:PassRole permissions to pass the role to the service. Use this newly created service role during stack deployments - This statement is incorrect. AWS suggests not using the aws:SourceIp AWS-wide condition. AWS CloudFormation provisions resources by using its own IP address, not the IP address of the originating request. For example, when you create a stack, AWS CloudFormation makes requests from its IP address to launch an Amazon EC2 instance or to create an Amazon S3 bucket, not from the IP address from the CreateStack call or the AWS CloudFormation create-stack command.

Create an AWS CloudFormation service role with required permissions and associate this service role to the stack. Use this newly created service role during stack deployments - To pass a role (and its permissions) to an AWS service, a user must have permission to pass the role to the service. To allow a user to pass a role to an AWS service, you must grant the PassRole permission to the user's IAM user, role, or group. Granting the developer iam:PassRole permissions to pass the role to the service is a necessary step if the developers have to deploy the CloudFormation stacks.

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html

Domain

Domain 2: Configuration Management and IaC

Question 27Skipped

A DevOps Engineer has been asked to chalk out a disaster recovery (DR) plan for a workload in production. The workload runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances are configured with an Auto Scaling group across multiple Availability Zones. Amazon Route 53 is configured to point to the ALB using an alias record. Amazon RDS for PostgreSQL DB instance is the database service. The draft DR plan mandates an RTO of three hours and an RPO of around 15 minutes.

Which Disaster Recovery (DR) strategy should the DevOps Engineer opt for a cost-effective solution?

Opt for a Warm standby approach by ensuring that there is a scaled-down, but fully functional, copy of your production environment in another AWS Region. Then, deploy enough resources to handle initial traffic, ensuring low RTO, and then rely on Auto Scaling to ramp up for subsequent traffic

Configure your workload to simultaneously run in multiple AWS Regions as part of a multi-site active/active DR strategy. Replicate your entire workload to another AWS Region. With this strategy, asynchronous data replication between the regions enables near-zero RPO. Configure Amazon Route 53 with latency-based routing to choose between the active regional endpoint for directing user traffic

Correct answer

Opt for a pilot light DR strategy. Provision a copy of your core workload infrastructure to a different AWS Region. Create an RDS read replica in the new Region, and configure the new environment to point to the local RDS PostgreSQL DB instance. Configure Amazon Route 53 health checks to automatically initiate DNS failover to a new Region. Promote the read replica to the primary DB instance in case of a disaster

Opt for a pilot light DR strategy. Provision a copy of your entire workload infrastructure to a different AWS Region. Copy the first backup that consists of a full instance backup to the new RDS instance. In case of disaster, apply the incremental backup to the RDS instance in the new AWS Region. Configure Amazon Route 53 health checks to automatically initiate DNS failover to new Region

Overall explanation

Correct option:

Opt for a pilot light DR strategy. Provision a copy of your core workload infrastructure to a different AWS Region. Create an RDS read replica in the new Region, and configure the new environment to point to the local RDS PostgreSQL DB instance. Configure Amazon Route 53 health checks to automatically initiate DNS failover to a new Region. Promote the read replica to the primary DB instance in case of a disaster

With the pilot light approach, you replicate your data from one Region to another and provision a copy of your core workload infrastructure. Resources required to support data replication and backup, such as databases and object storage, are always on. Other elements, such as application servers, are loaded with application code and configurations, but are "switched off" and are only used during testing or when disaster recovery failover is invoked. In the cloud, you have the flexibility to de-provision resources when you do not need them, and provision them when you do. A best practice for “switched off” is to not deploy the resource, and then create the configuration and capabilities to deploy it (“switch on”) when needed. Unlike the backup and restore approach, your core infrastructure is always available and you always have the option to quickly provision a full-scale production environment by switching on and scaling out your application servers.

A pilot light approach minimizes the ongoing cost of disaster recovery by minimizing the active resources and simplifies recovery at the time of a disaster because the core infrastructure requirements are all in place.

For pilot light, continuous data replication to live databases and data stores in the DR region is the best approach for low RPO. When failing over to run your read/write workload from the disaster recovery Region, you must promote an RDS read replica to become the primary instance.

For an active/passive configuration such as the pilot light, all traffic initially goes to the primary Region and switches to the disaster recovery Region if the primary Region is no longer available. This failover operation can be initiated either automatically or manually.

Using Amazon Route 53, you can associate multiple IP endpoints in one or more AWS Regions with a Route 53 domain name. Then, you can route traffic to the appropriate endpoint under that domain name. On failover you need to switch traffic to the recovery endpoint, and away from the primary endpoint. Amazon Route 53 health checks monitor these endpoints. Using these health checks, you can configure automatically initiated DNS failover to ensure traffic is sent only to healthy endpoints, which is a highly reliable operation done on the data plane.

The pilot light strategy is the one best suited for the given requirements since it keeps the overall costs down when compared to the rest of the options. Also, the core infrastructure is ready to be used as and when required. Since RTO is given in hours, we can spin up these resources well before the given time. The database is update-to-date and only needs a switch from replica to primary. This is the right strategy when RPO is in minutes.

Pilot light DR strategy:

via - https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

Incorrect options:

Opt for a pilot light DR strategy. Provision a copy of your entire workload infrastructure to a different AWS Region. Copy the first backup that consists of a full instance backup to the new RDS instance. In case of disaster, apply the incremental backup to the RDS instance in the new AWS Region. Configure Amazon Route 53 health checks to automatically initiate DNS failover to new Region - With pilot light DR strategy, resources required to support data replication and backup, such as databases and object storage, are always on. When the expected RPO is 15 minutes, it is not possible to apply incremental backups to the database since this could be huge amounts of data which may take hours. Hence, this option is incorrect.

Configure your workload to simultaneously run in multiple AWS Regions as part of a multi-site active/active DR strategy. Replicate your entire workload to another AWS Region. With this strategy, asynchronous data replication between the regions enables near-zero RPO. Configure Amazon Route 53 with latency-based routing to choose between the active regional endpoint for directing user traffic - You can run your workload simultaneously in multiple Regions as part of a multi-site active/active strategy. Multi-site active/active serves traffic from all regions to which it is deployed. With a multi-site active/active approach, users can access your workload in any of the Regions in which it is deployed. This approach is the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero for most disasters with the correct technology choices and implementation. Since RTO is given as three hours, opting for this DR strategy will prove to be cost-ineffective.

Opt for a Warm standby approach by ensuring that there is a scaled-down, but fully functional, copy of your production environment in another AWS Region. Then, deploy enough resources to handle initial traffic, ensuring low RTO, and then rely on Auto Scaling to ramp up for subsequent traffic - The warm standby approach involves ensuring that there is a scaled-down, but fully functional, copy of your production environment in another Region. This approach extends the pilot light concept and decreases the time to recovery because your workload is always-on in another Region. Since RTO is given as three hours, the warm standby approach will end up being a costly alternative to an otherwise cost-effective pilot light strategy.

References:

https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/

https://aws.amazon.com/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/

Domain

Domain 5: Incident and Event Response

Question 28Skipped

A production environment has Amazon EC2 instances configured to log all application/system logs via the CloudWatch Logs agent that has been configured on all instances. The company has recently introduced a security policy that mandates terminating any Amazon EC2 instance accessed manually by a user other than the administrators within an hour. All the production instances are configured with Auto Scaling groups.

As a DevOps Engineer, how will you automate this process?

Create a CloudWatch Logs subscription to an AWS Step Function that coordinates with AWS Lambda function and Amazon EventBridge to create a serverless automated solution. Configure an AWS Lambda function to add a tag to the EC2 instance that produced the login event and mark the instance to be decommissioned. Create an Amazon EventBridge rule to invoke a second Lambda function every hour, which will terminate all instances with this tag

Set up an Amazon CloudWatch alarm that is triggered by login event data to call an AWS Lambda function. Configure the Lambda function to add a decommission tag to the EC2 instance that produced the login event. Schedule an Amazon EventBridge rule to invoke the Lambda function every hour, to terminate all EC2 instances with the decommission tag

Correct answer

Create a CloudWatch Logs subscription to deliver the login event data of Amazon EC2 instances to an AWS Lambda function. Configure the Lambda function to add a decommission tag to the EC2 instance that produced the login event. Schedule an Amazon EventBridge rule to invoke another Lambda function every hour, to terminate all EC2 instances with the decommission tag

Create an Amazon CloudWatch alarm that is triggered by the login event data. Create alarm action that notifies system administrators through a message using the Amazon Simple Notification Service topic. The system administrators will then manually terminate the instance

Overall explanation

Correct option:

Create a CloudWatch Logs subscription to deliver the login event data of Amazon EC2 instances to an AWS Lambda function. Configure the Lambda function to add a decommission tag to the EC2 instance that produced the login event. Schedule an Amazon EventBridge rule to invoke another Lambda function every hour, to terminate all EC2 instances with the decommission tag

You can use CloudWatch Log subscriptions to get access to a real-time feed of log events from CloudWatch Logs and have it delivered to other services such as an Amazon Kinesis stream, an Amazon Kinesis Data Firehose stream, or AWS Lambda for custom processing, analysis, or loading to other systems. When log events are sent to the receiving service, they are base64 encoded and compressed with the gzip format.

For the given use case, you can invoke a Lambda function via the CloudWatch Logs subscription. The Lambda then adds a decommission tag to the EC2 instance that produced the login event. Lastly, you can set up an Amazon EventBridge rule to invoke another Lambda function on an hourly schedule, to terminate all EC2 instances that are marked with the decommission tag.

An Amazon EventBridge rule matches incoming events and sends them to targets for processing. A rule can run in response to an event, or at certain time intervals. For example, to periodically run an AWS Lambda function, you can create a rule to run on a schedule.

In EventBridge, you can create two types of scheduled rules:

Rules that run at a regular rate

EventBridge runs these rules at regular intervals; for example, every 20 minutes.

To specify the rate for a scheduled rule, you define a rate expression.

Rules that run at specific times

EventBridge runs these rules at specific times and dates; for example, 8:00 a.m. PST on the first Monday of every month.

To specify the time and dates a scheduled rule runs, you define a cron expression.

Incorrect options:

Create an Amazon CloudWatch alarm that is triggered by the login event data. Create alarm action that notifies system administrators through a message using the Amazon Simple Notification Service topic. The system administrators will then manually terminate the instance - This option does not provide a solution for complete automation since system administrators are expected to terminate the systems manually.

Set up an Amazon CloudWatch alarm that is triggered by login event data to call an AWS Lambda function. Configure the Lambda function to add a decommission tag to the EC2 instance that produced the login event. Schedule an Amazon EventBridge rule to invoke the Lambda function every hour, to terminate all EC2 instances with the decommission tag - Amazon CloudWatch alarm does not support having AWS Lambda function as an alarm action. Amazon Simple Notification Service can be used as an intermediatory service if you wish to use AWS Lambda with CloudWatch alarms.

Create a CloudWatch Logs subscription to an AWS Step Function that coordinates with the AWS Lambda function and Amazon EventBridge to create a serverless automated solution. Configure an AWS Lambda function to add a tag to the EC2 instance that produced the login event and mark the instance to be decommissioned. Create an Amazon EventBridge rule to invoke a second Lambda function every hour, which will terminate all instances with this tag - AWS Step Functions is a serverless orchestration service that lets you integrate with AWS Lambda functions and other AWS services to build business-critical applications. Step Function is overkill for the simple automation via the AWS Lambda function that the given use case needs.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html

Domain

Domain 4: Monitoring and Logging

Question 29Skipped

A DevOps engineer is currently involved in a data archival project where the task is to migrate on-premises data to an Amazon S3 bucket. The engineer has created a script that handles the incremental archiving of on-premises data, specifically transferring data older than 6 months to Amazon S3. As part of the process, the data is removed from the on-premises location after being successfully transferred using the S3 PutObject operation.

During a thorough code review, the DevOps engineer identified a crucial issue in the script. The script does not include any validation to confirm whether the data is copied to Amazon S3 without any corruption. To ensure data integrity throughout the transmission, the DevOps engineer needs to update the script accordingly. The new solution must use MD5 checksums to verify the data integrity before allowing the deletion of the on-premises data.

Considering these requirements, what modifications or solutions should the DevOps engineer implement in the script to ensure successful data transfer and integrity validation? (Select two)

Correct selection

Provide the MD5 digest within the Content-MD5 parameter of the PUT command. Examine the Amazon S3's call return status to check for an error

Examine the returned response for the version ID. Compare the version ID value of the object with a calculated or previously stored Content-MD5 digest

Provide the MD5 digest as a custom name-value pair in the metadata of the object. Examine the Amazon S3's call return status to check for an error

Provide the MD5 digest as a trailing checksum of the object. Examine the Amazon S3's call return status to check for an error

Correct selection

Examine the returned response for the ETag. Compare the ETag value of the object with a calculated or previously stored Content-MD5 digest

Overall explanation

Correct option:

Provide the MD5 digest within the Content-MD5 parameter of the PUT command. Examine the Amazon S3's call return status to check for an error

Amazon S3 uses checksum values to verify the integrity of data that you upload to or download from Amazon S3. In addition, you can request that another checksum value be calculated for any object that you store in Amazon S3. You can select from one of several checksum algorithms to use when uploading or copying your data. Amazon S3 uses this algorithm to compute an additional checksum value and store it as part of the object metadata.

One way to verify the integrity of your object after uploading is to provide an MD5 digest of the object when you upload it. If you calculate the MD5 digest for your object, you can provide the digest with the PUT command by using the Content-MD5 header. After uploading the object, Amazon S3 calculates the MD5 digest of the object and compares it to the value that you provided. The request succeeds only if the two digests match.

Examine the returned response for the ETag. Compare the ETag value of the object with a calculated or previously stored Content-MD5 digest

The entity tag (ETag) for an object represents a specific version of that object. Keep in mind that the ETag reflects changes only to the content of an object, not to its metadata. If only the metadata of an object changes, the ETag remains the same. For objects where the ETag is the Content-MD5 digest of the object, you can compare the ETag value of the object with a calculated or previously stored Content-MD5 digest.

via - https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html

Incorrect options:

Provide the MD5 digest as a trailing checksum of the object. Examine the Amazon S3's call return status to check for an error - When uploading objects to Amazon S3, you can either provide a precalculated checksum for the object or use an AWS SDK to automatically create trailing checksums on your behalf. You cannot provide a trailing checksum as it is calculated by AWS, so this option is incorrect.

Provide the MD5 digest as a custom name-value pair in the metadata of the object. Examine the Amazon S3's call return status to check for an error - You need to provide the MD5 digest within the Content-MD5 parameter of the PUT command, and NOT as a custom name-value pair in the metadata of the object.

Examine the returned response for the version ID. Compare the version ID value of the object with a calculated or previously stored Content-MD5 digest - Versioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket. When you enable versioning in a bucket, all new objects are versioned and given a unique version ID. You cannot use version ID to compare with the Content-MD5 digest.

References:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html

https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html

Domain

Domain 3: Resilient Cloud Solutions

Question 30Skipped

An application runs on a fleet of Amazon EC2 Windows instances configured with an Auto Scaling group (ASG). When scaling-in takes place in the ASG, the instances are terminated without notification. The application team wants to create an AMI and remove the Amazon EC2 Windows instance from its domain before terminating the scaled-in instances.

As a DevOps Engineer, which combination of steps will you choose to implement this requirement? (Select two)

Add a lifecycle hook that puts the instance in Terminating:Pending status and setup an Amazon CloudWatch event to monitor the Terminating:Pending status

Add an AWS Systems Manager Patch Manager as a CloudWatch Event target. The automation document runs a Windows PowerShell script to remove the computer from the domain and creates an AMI of the EC2 instance

Correct selection

Add an AWS Systems Manager automation document as a CloudWatch Event target. The automation document runs a Windows PowerShell script to remove the computer from the domain and creates an AMI of the EC2 instance

Configure an AWS Systems Manager Maintenance Window to schedule an action to run a Windows PowerShell script to remove the computer from the domain and creates an AMI of the EC2 instance

Correct selection

Add a lifecycle hook that puts the instance in Terminating:Wait status and setup an Amazon CloudWatch event to monitor the Terminating:Wait status

Overall explanation

Correct options:

Add a lifecycle hook that puts the instance in Terminating:Wait status and setup an Amazon CloudWatch event to monitor the Terminating:Wait status

Add an AWS Systems Manager automation document as a CloudWatch Event target. The automation document runs a Windows PowerShell script to remove the instance from the domain and create an AMI of the EC2 instance

Oftentimes, you may want to execute some code and actions before terminating an Amazon Elastic Compute Cloud (Amazon EC2) instance that is part of an Amazon EC2 Auto Scaling group.

One way to execute code and actions before terminating an instance is to create a lifecycle hook that puts the instance in Terminating:Wait status. This allows you to perform any desired actions before immediately terminating the instance within the Auto Scaling group. The Terminating:Wait status can be monitored by an Amazon CloudWatch event, which triggers an AWS Systems Manager automation document to perform the action you want.

Broadly, the steps needed for the above configuration: 1. Add a lifecycle hook. 2. Create a Systems Manager automation document. 3. Create AWS Identity and Access Management (IAM) policies and a role to delegate permissions to the Systems Manager automation document. 4. Create IAM policies and a role to delegate permissions to CloudWatch Events, which invokes the Systems Manager automation document. 5. Create a CloudWatch Events rule. 6. Add a Systems Manager automation document as a CloudWatch Event target.

Using Lifecycle hooks to run code before terminating an EC2 Auto Scaling instance:

via - https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/

Incorrect options:

Add a lifecycle hook that puts the instance in Terminating:Pending status and set up an Amazon CloudWatch event to monitor the Terminating:Pending status - Terminating:Pending is not a valid state. The following are the transitions between instance states in the Amazon EC2 Auto Scaling lifecycle.

Amazon EC2 Auto Scaling instance lifecycle:

via - https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html

Add an AWS Systems Manager Patch Manager as a CloudWatch Event target. The automation document runs a Windows PowerShell script to remove the computer from the domain and creates an AMI of the EC2 instance - Patch Manager is a capability of AWS Systems Manager that automates the process of patching managed nodes with both security-related updates and other types of updates. It cannot be used for the processing of custom logic/code.

Configure an AWS Systems Manager Maintenance Window to schedule an action to run a Windows PowerShell script to remove the computer from the domain and creates an AMI of the EC2 instance - Maintenance Windows is a capability of AWS Systems Manager that helps you define a schedule for when to perform potentially disruptive actions on your nodes such as patching an operating system, updating drivers, or installing software or patches. Maintenance Windows is not relevant for the given use case, since we want the custom logic to run immediately and return to the instance termination triggered by Auto Scaling Group.

References:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html#lifecycle-hooks-availability

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html

Domain

Domain 4: Monitoring and Logging

Question 31Skipped

A company wants to enforce regulations to prevent frequent logins by DevOps engineers to the Amazon EC2 instances, with the added condition that immediate notification must be sent to the security team if any login occurs.

What solution would you suggest to meet these requirements?

Set up the Amazon Inspector Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch metric filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected

Correct answer

Set up the Amazon CloudWatch Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch metric filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected

Set up the Amazon CloudWatch Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch subscription filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected

Configure AWS CloudTrail to track AWS API calls and log them to Amazon CloudWatch Logs. Subscribe CloudWatch Logs to Amazon Kinesis. Set up an AWS Lambda function as a consumer for the Kinesis stream to process the logs and detect any user logins. Use Amazon SNS to send notifications to the security team upon detecting a login event

Overall explanation

Correct option:

Set up the Amazon CloudWatch Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch metric filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected

The Amazon CloudWatch agent can be installed on EC2 instances to collect and send log data to CloudWatch Logs. By setting up a metric filter within CloudWatch Logs, it is possible to search for specific patterns, such as user login events. If a user login is found in the log data, Amazon SNS is used to send an immediate notification to the security team.

You can use CloudWatch Logs to monitor applications and systems using log data in near real-time. For example, CloudWatch Logs can track the number of errors that occur in your application logs and send you a notification whenever the rate of errors exceeds a threshold you specify. The CloudWatch Logs Agent will send log data every five seconds by default and is configurable by the user. You can monitor log events as they are sent to CloudWatch Logs by creating Metric Filters. Metric Filters turn log data into Amazon CloudWatch Metrics for graphing or alarming.

via - https://aws.amazon.com/cloudwatch/faqs/

Incorrect options:

Set up the Amazon CloudWatch Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch subscription filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected - You can use subscriptions to get access to a real-time feed of log events from CloudWatch Logs and have it delivered to other services such as an Amazon Kinesis stream, an Amazon Kinesis Data Firehose stream, or AWS Lambda for custom processing, analysis, or loading to other systems. A subscription filter defines the filter pattern to use for filtering which logs events get delivered to your AWS resource, as well as information about where to send matching log events to. You need to use metric Filters (not subscription filters) to turn log data into Amazon CloudWatch Metrics for graphing or alarming. Therefore, this option is incorrect.

Configure AWS CloudTrail to track AWS API calls and log them to Amazon CloudWatch Logs. Subscribe CloudWatch Logs to Amazon Kinesis. Set up an AWS Lambda function as a consumer for the Kinesis stream to process the logs and detect any user logins. Use Amazon SNS to send notifications to the security team upon detecting a login event - AWS CloudTrail enables the logging of AWS API calls, including login events, which are then sent to CloudWatch Logs. By subscribing CloudWatch Logs to Amazon Kinesis, the logs can be processed in real-time. An AWS Lambda function attached to Kinesis can parse the logs and identify user logins. If a login is detected, Amazon SNS is used to immediately notify the security team. While AWS CloudTrail captures login events, it typically delivers logs within an average of about 5 minutes of an API call. However, this time is not guaranteed. Therefore, this option is incorrect.

Set up the Amazon Inspector Agent on each Amazon EC2 instance with the configuration to push all logs to Amazon CloudWatch Logs. Create a CloudWatch metric filter to detect user logins. Use Amazon SNS to notify the security team when a login is detected - Amazon Inspector is a vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure. Amazon Inspector automatically discovers and scans running Amazon EC2 instances, container images in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions for known software vulnerabilities and unintended network exposure. You cannot use Amazon Inspector to detect user login events in real time, so this option is incorrect.

References:

https://aws.amazon.com/cloudwatch/faqs/

https://aws.amazon.com/cloudwatch/features/#CloudWatch_Logs

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html

Domain

Domain 4: Monitoring and Logging

Question 32Skipped

The DevOps team for an e-commerce company wants to implement a patching plan on AWS Cloud for a large mixed fleet of Windows and Linux servers. The patching plan has to be auditable and must be implemented securely to ensure compliance with the company's business requirements.

Which of the following options would you recommend to address these requirements with MINIMAL effort? (Select two)

Correct selection

Apply patch baselines using the AWS-RunPatchBaseline SSM document

Set up an OS-native patching service to manage the update frequency and release approval for all instances. Set up AWS Config to provide audit and compliance reporting

Configure CloudFormation automatic patching support for all applications which will keep the OS up-to-date following the initial installation. Set up AWS Config to provide audit and compliance reporting

Apply patch baselines using the AWS-ApplyPatchBaseline SSM document

Correct selection

Set up Systems Manager Agent on all instances to manage patching. Test patches in pre-production and then deploy as a maintenance window task with the appropriate approval

Overall explanation

Correct options:

Set up Systems Manager Agent on all instances to manage patching. Test patches in pre-production and then deploy as a maintenance window task with the appropriate approval

Apply patch baselines using the AWS-RunPatchBaseline SSM document

Systems Manager is an AWS service that you can use to view and control your infrastructure on AWS. Using the Systems Manager console, you can view operational data from multiple AWS services and automate operational tasks across your AWS resources. Systems Manager helps you maintain security and compliance by scanning your managed instances and reporting on (or taking corrective action on) any policy violations it detects. AWS Systems Manager Agent (SSM Agent) is Amazon software that can be installed and configured on an EC2 instance, an on-premises server, or a virtual machine (VM). SSM Agent makes it possible for the Systems Manager to update, manage, and configure these resources.

via - https://aws.amazon.com/systems-manager/

You can use Patch Manager to apply patches for both operating systems and applications. (On Windows Server, application support is limited to updates for Microsoft applications). Patch Manager uses patch baselines, which include rules for auto-approving patches within days of their release, as well as a list of approved and rejected patches. You can install patches individually or to large groups of instances by using Amazon EC2 tags.

For the given use case, you can install patches on a regular basis by scheduling patching to run as a Systems Manager maintenance window task.

Systems Manager supports an SSM document for Patch Manager, AWS-RunPatchBaseline, which performs patching operations on instances for both security-related and other types of updates. When the document is run, it uses the patch baseline currently specified as the "default" for an operating system type.

The AWS-ApplyPatchBaseline SSM document supports patching on Windows instances only and doesn't support Linux instances. For applying patch baselines to both Windows Server and Linux instances, the recommended SSM document is AWS-RunPatchBaseline.

via - https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html

via - https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-differences.html

Incorrect options:

Configure CloudFormation automatic patching support for all applications which will keep the OS up-to-date following the initial installation. Set up AWS Config to provide audit and compliance reporting - AWS CloudFormation is designed to allow resource lifecycles to be managed repeatably, predictable, and safely, while allowing for automatic rollbacks, automated state management, and management of resources across accounts and regions.

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. With Config, you can review changes in configurations and relationships between AWS resources, dive into detailed resource configuration histories, and determine your overall compliance against the configurations specified in your internal guidelines. You can use Config to answer questions such as - “What did my AWS resource look like at xyz point in time?”.

There is no such thing as CloudFormation automatic patching support, as you need to use Systems Manager for patch management. So, this option acts as a distractor.

Set up an OS-native patching service to manage the update frequency and release approval for all instances. Set up AWS Config to provide audit and compliance reporting - You could use an OS-native patching service to manage the update frequency and release approval for all instances but it would take considerable effort to set up and configure this solution. This violates the minimal effort requirement of the given use case.

Apply patch baselines using the AWS-ApplyPatchBaseline SSM document - As mentioned in the explanation above, the AWS-ApplyPatchBaseline SSM document supports patching on Windows instances only and doesn't support Linux instances. For applying patch baselines to both Windows Server and Linux instances, the recommended SSM document is AWS-RunPatchBaseline.

References:

https://aws.amazon.com/systems-manager/

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html

https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-differences.html

Domain

Domain 6: Security and Compliance

Question 33Skipped

For deployments across AWS accounts, an e-commerce company has decided to use AWS CodePipeline to deploy an AWS CloudFormation stack in an AWS account (account A) to a different AWS account (account B).

What combination of steps will you take to configure this requirement? (Select three)

In account A, create a service role for the CloudFormation stack that includes the required permissions for the services deployed by the stack. In account B, update the CodePipeline configuration to include the resources associated with account A

In account B, add the AssumeRole permission to account A's CodePipeline service role to allow it to assume the cross-account role in account A

Correct selection

In account B, create a service role for the CloudFormation stack that includes the required permissions for the services deployed by the stack. In account A, update the CodePipeline configuration to include the resources associated with account B

Correct selection

In account B, create a cross-account IAM role. In account A, add the AssumeRole permission to account A's CodePipeline service role to allow it to assume the cross-account role in account B

Correct selection

In account A, create a customer-managed AWS KMS key that grants usage permissions to account A's CodePipeline service role and account B. Also, create an Amazon Simple Storage Service (Amazon S3) bucket with a bucket policy that grants account B access to the bucket

In account A, create a customer-managed AWS KMS key that grants usage permissions to account A's CodePipeline service role and account B. In account B, create an Amazon Simple Storage Service (Amazon S3) bucket with a bucket policy that grants account A access to the bucket

Overall explanation

Correct options:

In account A, create a customer-managed AWS KMS key that grants usage permissions to account A's CodePipeline service role and account B. Also, create an Amazon Simple Storage Service (Amazon S3) bucket with a bucket policy that grants account B access to the bucket

In account B, create a cross-account IAM role. In account A, add the AssumeRole permission to account A's CodePipeline service role to allow it to assume the cross-account role in account B

In account B, create a service role for the CloudFormation stack that includes the required permissions for the services deployed by the stack. In account A, update the CodePipeline configuration to include the resources associated with account B

Complete list of steps for configuring the requirement:

via - https://aws.amazon.com/premiumsupport/knowledge-center/codepipeline-deploy-cloudformation/

Incorrect options:

In account A, create a customer-managed AWS KMS key that grants usage permissions to account A's CodePipeline service role and account B. In account B, create an Amazon Simple Storage Service (Amazon S3) bucket with a bucket policy that grants account A access to the bucket

In account A, create a service role for the CloudFormation stack that includes the required permissions for the services deployed by the stack. In account B, update the CodePipeline configuration to include the resources associated with account A

In account B, add the AssumeRole permission to account A's CodePipeline service role to allow it to assume the cross-account role in account A

These three options contradict the explanation provided above, so these are incorrect.

Reference:

https://aws.amazon.com/premiumsupport/knowledge-center/codepipeline-deploy-cloudformation/

Domain

Domain 2: Configuration Management and IaC

Question 34Skipped

An application runs on a fleet of Amazon EC2 instances that are configured with an Auto Scaling group (ASG). Both Spot and On-Demand instances are utilized as per the ASG configuration. For the most part, the ASG seems to be working fine as expected. There are a few issues that the DevOps team has flagged:

a) During a scale-in activity, ASG has terminated instance in the Availability Zone (AZ) that already had fewer instances than the other b) For some duration, ASG exceeded the specified maximum capacity of the group

What reasons can you identify for this behavior? (Select two)

The instance that was launched from the oldest launch template or launch configuration is terminated first. This can temporarily lead to an unbalanced group

With Default termination policy, instances that are closest to the next billing hour are terminated first. This can temporarily cause instance distribution imbalance among the AZs

You can only specify one Lambda function in the termination policies for an Auto Scaling group. If more than one Lambda functions are configured, the ASG behavior is ambiguous

Correct selection

When an Auto Scaling group with a mixed instances policy scales in, Amazon EC2 Auto Scaling will first identify which of the two types (Spot or On-Demand) should be terminated. This can temporarily cause a misbalance between the AZs

Correct selection

Amazon EC2 Auto Scaling can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a margin of one instance, whichever is greater) during a rebalancing activity

Overall explanation

Correct options:

Amazon EC2 Auto Scaling can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a margin of one instance, whichever is greater) during a rebalancing activity

When rebalancing, Amazon EC2 Auto Scaling launches new instances before terminating the old ones, so that rebalancing does not compromise the performance or availability of your application.

Because Amazon EC2 Auto Scaling attempts to launch new instances before terminating the old ones, being at or near the specified maximum capacity could impede or completely stop rebalancing activities. To avoid this problem, the system can temporarily exceed the specified maximum capacity of a group by a 10 percent margin (or by a margin of one instance, whichever is greater) during a rebalancing activity. The margin is extended only if the group is at or near maximum capacity and needs rebalancing, either because of user-requested rezoning or to compensate for zone availability issues. The extension lasts only as long as needed to rebalance the group.

When an Auto Scaling group with a mixed instances policy scales in, Amazon EC2 Auto Scaling will first identify which of the two types (Spot or On-Demand) should be terminated. This can temporarily cause a misbalance between the AZs

When an Auto Scaling group with a mixed instances policy scales in, Amazon EC2 Auto Scaling still uses termination policies to prioritize which instances to terminate, but first it identifies which of the two types (Spot or On-Demand) should be terminated. It then applies the termination policies in each Availability Zone individually. It also identifies which instances (within the identified purchase option) in which Availability Zones to terminate that will result in the Availability Zones being most balanced.

Understanding ASG termination policy for mixed instances groups:

via - https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html#default-termination-policy-mixed-instances-groups

Incorrect options:

The instance that was launched from the oldest launch template or launch configuration is terminated first. This can temporarily lead to an unbalanced group - Amazon EC2 Auto Scaling always balances instances across Availability Zones first, regardless of which termination policy is used. As a result, you might encounter situations in which some newer instances are terminated before older instances. So this option is incorrect.

You can only specify one Lambda function in the termination policies for an Auto Scaling group. If more than one Lambda functions are configured, the ASG behavior is ambiguous - It is not possible to configure more than one AWS Lambda function in the termination policies for an Auto Scaling group. Also, the AWS Lambda function is used to configure custom termination policy and hence is not related to the given use case.

With the Default termination policy, instances that are closest to the next billing hour are terminated first. This can temporarily cause instance distribution imbalance among the AZs - This statement is incorrect. ASG uses multiple termination criteria before selecting an instance for termination, and not just the next billing hour as the only criterion.

Understanding the default termination policy of ASG:

via - https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html#default-termination-policy-mixed-instances-groups

References:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html#default-termination-policy-mixed-instances-groups

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html

Domain

Domain 5: Incident and Event Response

Question 35Skipped

A company has hundreds of AWS accounts and has also created an organization in AWS Organizations to manage the accounts. The company wants a dashboard to seamlessly search, visualize, and analyze CloudWatch metrics data, logs data, and traces (from AWS X-Ray) from all the linked accounts into a single security and operations account. The solution should automatically onboard any new AWS accounts created later in the organization.

As a DevOps Engineer, what solution do you suggest to address the given requirements?

Configure CloudWatch Metric Streams to stream real-time metrics data to Kinesis Data Firehose. Firehose will push the metrics data to Amazon Simple Storage Service (Amazon S3) bucket. configure Amazon Athena to create a dashboard with the metrics data

Correct answer

Use Amazon CloudWatch cross-account observability to set up security and operations account as the monitoring account and link it with rest of the member accounts of the organization using AWS Organizations

Use the Amazon CloudWatch cross-account observability feature from the CloudWatch console to create the monitoring account and connect the individual AWS accounts to the monitoring account

Create a CloudWatch alarm for the CloudWatch metrics and trigger an event on Amazon EventBridge. Write the metrics data to the Amazon S3 bucket. Use Amazon Athena to create visualizations and dashboards from CloudWatch metrics data, logs data, and traces

Overall explanation

Correct option:

Use Amazon CloudWatch cross-account observability to set up a security and operations account as the monitoring account and link it with the rest of the member accounts of the organization using AWS Organizations

With Amazon CloudWatch cross-account observability, you can monitor and troubleshoot applications that span multiple accounts within a Region. Seamlessly search, visualize, and analyze your metrics, logs, and traces in any of the linked accounts without account boundaries.

Set up one or more AWS accounts as monitoring accounts and link them with multiple source accounts. A monitoring account is a central AWS account that can view and interact with observability data generated from source accounts. A source account is an individual AWS account that generates observability data for the resources that reside in it. Source accounts share their observability data with the monitoring account.

The shared observability data can include the following types of telemetry: 1. Metrics in Amazon CloudWatch 2. Log groups in Amazon CloudWatch Logs 3. Traces in AWS X-Ray

There are two options for linking source accounts to your monitoring account. You can use one or both options. 1. Use AWS Organizations to link accounts in an organization or organizational unit to the monitoring account. 2. Connect individual AWS accounts to the monitoring account.

AWS recommends that you use Organizations so that new AWS accounts created later in the organization are automatically onboarded to cross-account observability as source accounts. This is our use case requirement and hence choosing Organizations to implement the requirements.

Demonstration of setting up CloudWatch cross-account observability:

via - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html

Incorrect options:

Use the Amazon CloudWatch cross-account observability feature from the CloudWatch console to create the monitoring account and connect the individual AWS accounts to the monitoring account - While this option is correct, it cannot automatically onboard any new AWS accounts created later in the organization.

Create a CloudWatch alarm for the CloudWatch metrics and trigger an event on Amazon EventBridge. Write the metrics data to the Amazon S3 bucket. Use Amazon Athena to create visualizations and dashboards from CloudWatch metrics data, logs data, and traces - Amazon EventBridge does not support Amazon S3 bucket as a target. Hence, this option is incorrect.

Configure CloudWatch Metric Streams to stream real-time metrics data to Kinesis Data Firehose. Firehose will push the metrics data to Amazon Simple Storage Service (Amazon S3) bucket. configure Amazon Athena to create a dashboard with the metrics data - You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. The use case does not talk about real-time data, so configuring CloudWatch Metric Streams with Firehose is not the best fit.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html

https://aws.amazon.com/blogs/aws/cloudwatch-metric-streams-send-aws-metrics-to-partners-and-to-your-apps-in-real-time/

Domain

Domain 4: Monitoring and Logging

Question 36Skipped

Consider a multi-account setup within AWS Organizations where a company is running a data ingestion application on Amazon EC2 instances through several Auto Scaling groups. These instances lack internet access due to sensitive data handling, and VPC endpoints have been deployed accordingly. The application operates on a custom AMI designed specifically for its needs.

To effectively manage and troubleshoot the application, system administrators require automated and centralized login access to the EC2 instances. Additionally, the company's security team needs to be notified whenever such instances are accessed.

As an AWS Certified DevOps Engineer - Professional, what solution will you suggest to satisfy these requirements?

Set up a NAT gateway and a bastion host with internet access. Configure a security group that permits incoming traffic from the bastion host to all EC2 instances. Set up AWS Systems Manager Agent on the EC2 instances for monitoring and troubleshooting. Leverage Auto Scaling group lifecycle hooks for monitoring access. Utilize Systems Manager Session Manager for centralized login. Direct EC2 instance logs to an Amazon CloudWatch Logs log group. For auditing purposes, export data to Amazon S3 and notify the security team through S3 event notifications

Correct answer

Utilize EC2 Image Builder to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Set up the Auto Scaling group to attach the AmazonSSMManagedInstanceCore role to EC2 instances. Leverage Systems Manager Session Manager for centralized and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic

Utilize EC2 Image Builder to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Set up the Auto Scaling group to attach the AmazonSSMManagedInstanceCore role to EC2 instances. Leverage EC2 Instance Connect for centralized access and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic

Utilize AWS Systems Manager Automation to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Configure AWS Config to attach an SCP to the root organization account to allow the EC2 instances to connect to Systems Manager and grant access to centralized and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic

Overall explanation

Correct option:

Utilize EC2 Image Builder to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Set up the Auto Scaling group to attach the AmazonSSMManagedInstanceCore role to EC2 instances. Leverage Systems Manager Session Manager for centralized and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic

This option suggests using EC2 Image Builder to create an updated custom AMI with AWS Systems Manager Agent included. The Auto Scaling group is configured to attach the AmazonSSMManagedInstanceCore role to the instances, thereby enabling centralized management through Systems Manager, as it grants the EC2 instances the permissions needed for core Systems Manager functionality. Session Manager can be used for secure logins, and session details can be logged to Amazon S3. Additionally, an S3 event notification can be set up to alert the security team about new file uploads using Amazon SNS. This option aligns well with the requirement for centralized access and monitoring.

via - https://aws.amazon.com/image-builder/

Incorrect options:

Set up a NAT gateway and a bastion host with internet access. Configure a security group that permits incoming traffic from the bastion host to all EC2 instances. Set up AWS Systems Manager Agent on the EC2 instances for monitoring and troubleshooting. Leverage Auto Scaling group lifecycle hooks for monitoring access. Utilize Systems Manager Session Manager for centralized login. Direct EC2 instance logs to an Amazon CloudWatch Logs log group. For auditing purposes, export data to Amazon S3 and notify the security team through S3 event notifications - This option includes unnecessary internet access for sensitive data via the combination of NAT Gateway and bastion host, so it is not the best fit for the given use case.

Utilize EC2 Image Builder to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Set up the Auto Scaling group to attach the AmazonSSMManagedInstanceCore role to EC2 instances. Leverage EC2 Instance Connect for centralized access and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic - EC2 Instance Connect is a way to distribute short-lived SSH keys and control access by IAM policies. The actual connection is created with SSH client and all normal requirements (network connectivity, user on host etc) apply. The host must also have ec2-instance-connect “agent” installed. EC2 Instance Connect still requires public IP and network connectivity, so it is not the best fit for the given use case.

Utilize AWS Systems Manager Automation to rebuild the custom AMI that includes the latest AWS Systems Manager Agent version. Configure AWS Config to attach an SCP to the root organization account to allow the EC2 instances to connect to Systems Manager and grant access to centralized and automated login. Configure logging of session details to Amazon S3. Set up an S3 event notification for new file uploads to notify the security team via an Amazon Simple Notification Service (Amazon SNS) topic - SCPs are similar to AWS Identity and Access Management (IAM) permission policies and use almost the same syntax. However, an SCP never grants permissions. Instead, SCPs are JSON policies that specify the maximum permissions for the affected accounts. So, for the given use case, you cannot use SCP for granting EC2 instance access to centralized and automated login for the Systems Manager.

References:

https://aws.amazon.com/image-builder/

https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Domain

Domain 6: Security and Compliance

Question 37Skipped

An e-commerce company is deploying its flagship application on Amazon EC2 instances. The DevOps team at the company needs a solution to query both the application logs as well as the AWS account API activity.

As an AWS Certified DevOps Engineer - Professional, what solution will you recommend to meet these requirements?

Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize Amazon Athena to query both sets of logs

Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon S3. Utilize Amazon Athena to query both sets of logs

Correct answer

Set up AWS CloudTrail to deliver the API logs to CloudWatch Logs. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize the CloudWatch Logs Insights to query both sets of logs

Set up AWS CloudTrail to deliver the API logs to Kinesis Data Streams. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Kinesis Data Streams. Direct both the Kinesis Data Streams to direct the stream output to Kinesis Data Analytics for running near-real-time queries on both sets of logs

Overall explanation

Correct option:

Set up AWS CloudTrail to deliver the API logs to CloudWatch Logs. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize the CloudWatch Logs Insights to query both sets of logs

CloudTrail is enabled by default for your AWS account. You can use Event history in the CloudTrail console to view, search, download, archive, analyze, and respond to account activity across your AWS infrastructure. This includes activity made through the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs. For an ongoing record of events in your AWS account, you can create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs.

You can also configure CloudTrail with CloudWatch Logs to monitor your trail API logs and be notified when specific activity occurs. When you configure your trail to send events to CloudWatch Logs, CloudTrail sends only the events that match your trail settings. For example, if you configure your trail to log data events only, your trail sends data events only to your CloudWatch Logs log group. CloudTrail supports sending data, Insights, and management events to CloudWatch Logs.

You can collect metrics and logs from Amazon EC2 instances and on-premises servers with the CloudWatch agent. You can store and view the metrics that you collect with the CloudWatch agent in CloudWatch just as you can with any other CloudWatch metrics. The default namespace for metrics collected by the CloudWatch agent is CWAgent, although you can specify a different namespace when you configure the agent. The logs collected by the unified CloudWatch agent are processed and stored in Amazon CloudWatch Logs

For the given use case, you can have both AWS CloudTrail as well as the Amazon CloudWatch Agent deliver the respective logs to CloudWatch Logs. You can then use the CloudWatch Logs Insights to query both sets of logs.

Incorrect options:

Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon S3. Utilize Amazon Athena to query both sets of logs - You cannot use the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon S3. So, this option is incorrect.

Set up AWS CloudTrail to deliver the API logs to Kinesis Data Streams. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Kinesis Data Streams. Direct both the Kinesis Data Streams to direct the stream output to Kinesis Data Analytics for running near-real-time queries on both sets of logs - You cannot deliver the API logs from AWS CloudTrail to Kinesis Data Streams. Similarly, you cannot have the Amazon CloudWatch Agent deliver logs from the EC2 instances to Kinesis Data Streams. So, both these options are incorrect.

Set up AWS CloudTrail to deliver the API logs to Amazon S3. Leverage the Amazon CloudWatch Agent to deliver logs from the EC2 instances to Amazon CloudWatch Logs. Utilize Amazon Athena to query both sets of logs - You cannot use Amazon Athena to query logs published to Amazon CloudWatch Logs, so this option is incorrect.

References:

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-getting-started.html

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html

Domain

Domain 4: Monitoring and Logging

Question 38Skipped

A media company extensively uses Amazon S3 buckets for storing images files, documents, and other business-specific data. The company has mandated enabling logging for all Amazon S3 buckets. The audit team publishes the reports of all AWS resources failing company security standards. Until recently, the security team would pick the list of noncompliant Amazon S3 buckets from the audit list and execute remediation actions manually for each resource. This process is not only time-consuming but also leaves noncompliant resources vulnerable for a long duration.

Which combination of steps should a DevOps Engineer take to meet these requirements using an automated solution? (Select two)

Configure AWS Config Auto Remediation for the AWS Config rule s3-logging-enabled. Create your own custom remediation action using AWS Systems Manager Automation documents to enable logging on the S3 bucket

Correct selection

The AutomationAssumeRole in the remediation action parameters should be assumable by SSM. The user must have pass-role permissions for that role when they create the remediation action in AWS Config

Correct selection

Configure AWS Config Auto Remediation for the AWS Config rule s3-bucket-logging-enabled. From the remediation action list choose AWS-ConfigureS3BucketLogging

While setting up remediation action, pass the resource ID of non-compliant resources to the remediation action. This configuration is mandatory for auto-remediation to work

Configure AWS Config Auto Remediation for the AWS Config rule s3-bucket-logging-enabled. From the remediation action list choose AWS Lambda to implement a custom function that will enable S3 logging for the S3 bucket ID passed

Overall explanation

Correct options:

Configure AWS Config Auto Remediation for the AWS Config rule s3-bucket-logging-enabled. From the remediation action list choose AWS-ConfigureS3BucketLogging

The AutomationAssumeRole in the remediation action parameters should be assumable by SSM. The user must have pass-role permissions for that role when they create the remediation action in AWS Config

The AWS Config Auto Remediation feature automatically remediates non-compliant resources evaluated by AWS Config rules. You can associate remediation actions with AWS Config rules and choose to execute them automatically to address non-compliant resources without manual intervention. You can:

Choose the remediation action you want to associate from a pre-populated list.

Create your own custom remediation actions using AWS Systems Manager Automation documents.

If a resource is still non-compliant after auto-remediation, you can set the rule to try auto-remediation again.

For the above use case: You must have AWS Config enabled in your AWS account. The AutomationAssumeRole in the remediation action parameters should be assumable by SSM. The user must have pass-role permissions for that role when they create the remediation action in AWS Config, and that role must have whatever permissions the SSM document requires.

Steps to set up Auto Remediation for s3-bucket-logging-enabled:

via - https://aws.amazon.com/blogs/mt/aws-config-auto-remediation-s3-compliance/

Incorrect options:

Configure AWS Config Auto Remediation for the AWS Config rule s3-logging-enabled. Create your own custom remediation action using AWS Systems Manager Automation documents to enable logging on the S3 bucket - While you can create a custom remediation action using SSM, for this particular use case, it is not required since auto-remediation for S3 server logging is already present in the remediation action list of AWS Config rules.

Configure AWS Config Auto Remediation for the AWS Config rule s3-bucket-logging-enabled. From the remediation action list choose AWS Lambda to implement a custom function that will enable S3 logging for the S3 bucket ID passed - As discussed above, the AWS config remediation action pre-populated list already has an action defined for enabling S3 logging. Hence, custom code is unnecessary for this use case.

While setting up remediation action, pass the resource ID of non-compliant resources to the remediation action. This configuration is mandatory for auto-remediation to work- While setting up remediation action if you want to pass the resource ID of non-compliant resources to the remediation action, choose the Resource ID parameter. If selected at runtime, the parameter is substituted with the ID of the resource to be remediated. This is not mandatory though.

Reference:

https://aws.amazon.com/blogs/mt/aws-config-auto-remediation-s3-compliance/

Domain

Domain 6: Security and Compliance

Question 39Skipped

A developer configured an AWS CloudFormation template to create custom resource necessary for the project. The AWS Lambda function for the custom resource executed successfully as seen by the successful creation of the custom resource. But, the CloudFormation stack is not transitioning from in-progress status (CREATE_IN_PROGRESS) to completion status (CREATE_COMPLETE).

Which step did the developer possibly miss for the successful completion of the CloudFormation stack?

If the template developer and custom resource provider are configured to the same person or entity then CloudFormation stack completion fails

After executing the send method in the cfn-response module, the Lambda function terminates, so anything written after this method is ignored

The AWS CloudFormation resource AWS::CloudFormation::CustomResource should be used to specify a custom resource in the template

Correct answer

Configure the AWS Lambda function to send the response(SUCCESS or FAILED) of the custom resource creation to a pre-signed Amazon Simple Storage Service URL

Overall explanation

Correct option:

Configure the AWS Lambda function to send the response(SUCCESS or FAILED) of the custom resource creation to a pre-signed Amazon Simple Storage Service URL

Custom resources enable you to write custom provisioning logic in templates that AWS CloudFormation runs anytime you create, update (if you changed the custom resource), or delete stacks. Use the AWS::CloudFormation::CustomResource or Custom::MyCustomResourceTypeName resource type to define custom resources in your templates. Custom resources require one property: the service token, which specifies where AWS CloudFormation sends requests to, such as an Amazon SNS topic.

The custom resource provider processes the AWS CloudFormation request and returns a response of SUCCESS or FAILED to the pre-signed URL. The custom resource provider responds with a JSON-formatted file and uploads it to the pre-signed S3 URL. If this URL is not provided, the calling template will not get an update of the status of the Lambda function and will remain in an in-progress state.

How custom resources work:

via - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

Incorrect options:

The AWS CloudFormation resource AWS::CloudFormation::CustomResource should be used to specify a custom resource in the template - You can use the AWS::CloudFormation::CustomResource or Custom::MyCustomResourceTypeName resource type to define custom resources in your templates. However, this has no bearing on the given use case.

If the template developer and custom resource provider are configured to the same person or entity then CloudFormation stack completion fails - This statement is incorrect. The template developer and custom resource provider can be the same person or entity.

After executing the send method in the cfn-response module, the Lambda function terminates, so anything written after this method is ignored - The cfn-response module is available only when you use the ZipFile property to write your source code. This is irrelevant to the given use case.

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources-lambda.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-lambda-function-code-cfnresponsemodule.html

Domain

Domain 5: Incident and Event Response

Question 40Skipped

An AWS managed cloudformation-stack-drift-detection-check rule is defined in AWS Config for drift detection in AWS CloudFormation resources. The DevOps team is facing two issues:

a) How to detect drifts of Cloudformation custom resources b) Drift status of the stack shows as IN_SYNC in the CloudFormation console, the following is the drift detection error - 'While AWS CloudFormation failed to detect drift, defaulting to NON_COMPLIANT. Re-evaluate the rule and try again. If the problem persists contact AWS CloudFormation support'

As a DevOps Engineer, which steps will you combine to fix the aforementioned issues? (Select two)

AWS CloudFormation only determines drift for property values that are explicitly set. Explicitly set the property values for your custom resource to be included in drift

Correct selection

AWS Config rule depends on the availability of DetectStackDrift action of CloudFormation API. AWS Config defaults the rule to NON_COMPLIANT when throttling occurs

This error is a false positive and can be ignored for this scenario

Correct selection

AWS CloudFormation does not support drift detection of custom resources

You receive the error when the AWS Identity and Access Management (IAM) role for the required cloudformationRoleArn parameter doesn't have sufficient service permissions

Overall explanation

Correct options:

The cloudformation-stack-drift-detection-check rule checks if the actual configuration of a Cloud Formation stack differs, or has drifted, from the expected configuration. A stack is considered to have drifted if one or more of its resources differ from their expected configuration. The rule and the stack are COMPLIANT when the stack drift status is IN_SYNC. The rule is NON_COMPLIANT if the stack drift status is DRIFTED.

CloudFormation offers a drift detection feature to detect unmanaged configuration changes to stacks and resources. This will let you take corrective action to put the stack resources back in sync with their definitions in the stack template. To return a resource to compliance, the resource definition changes can be reverted directly.

AWS Config rule depends on the availability of DetectStackDrift action of CloudFormation API. AWS Config defaults the rule to NON_COMPLIANT when throttling occurs

AWS Config rule depends on the availability of DetectStackDrift. You receive a throttling or "Rate Exceeded" error because AWS Config defaults the rule to NON_COMPLIANT when throttling occurs.

Resolve the error resulting from the availability of DetectStackDrift:

via - https://repost.aws/knowledge-center/config-cloudformation-drift-detection

AWS CloudFormation does not support drift detection of custom resources

AWS CloudFormation supports resource import and drift detection operations for only supported resource types. Custom resource types are not currently supported.

Incorrect options:

You receive the error when the AWS Identity and Access Management (IAM) role for the required cloudformationRoleArn parameter doesn't have sufficient service permissions - Any issues with permissions will not result in the shown error. Permissions error looks something like this: "Your stack drift detection operation for the specific stack has failed. Check your existing AWS CloudFormation role permissions and add the missing permissions."

This error is a false positive and can be ignored for this scenario - This option just acts as a distractor.

AWS CloudFormation only determines drift for property values that are explicitly set. Explicitly set the property values for your custom resource to be included in drift - It is true that CloudFormation only determines drift for property values that are explicitly set, either through the stack template or by specifying template parameters. However, custom resources are not currently supported for drift.

References:

[[https://repost.aws/questions/QUolH-EWnHRNGDbnUiu3chXw/how-to-detect-drifts-of-cloudformation-custom-resource](https://repost.aws/questions/QUolH-EWnHRNGDbnUiu3chXw/how-to-detect-drifts-of-cloudformation-custom-resource)]

https://repost.aws/knowledge-center/config-cloudformation-drift-detection

https://docs.aws.amazon.com/config/latest/developerguide/cloudformation-stack-drift-detection-check.html

Domain

Domain 6: Security and Compliance

Question 41Skipped

A developer has uploaded an object of size 100 MB to an Amazon S3 bucket as a single-part direct upload using the REST API that has checksum enabled. The checksum of the object uploaded via the REST API was the checksum of the entire object. Later that day, the developer used the AWS Management Console to rename the object, copy it and edit its metadata. Later, when the developer checked for the checksum of the object updated via the AWS Management Console, the checksum was not the checksum of the entire object. Confused by the behavior, the developer has reached out to you for a possible solution.

As an AWS Certified DevOps Engineer - Professional, which of the following options would you identify as the reason for this behavior?

If an object is greater than 16 MB in size, checksum will be a calculation based on the checksum values of each individual parts. The developer's initial calculation for the REST API based checksum was incorrect. This resulted in the mismatch of the two checksum values

If an object is greater than 50 MB in size, checksum will be a calculation based on the checksum values of each individual parts. The developer's initial calculation for the REST API based checksum was incorrect. This resulted in the mismatch of the two checksum values

Correct answer

A new checksum value for the object, that is calculated based on the checksum values of the individual parts, has been created. This behavior is expected

When you change metadata of an object in S3, the checksum algorithm of the objects changes by default. This is an expected behavior

Overall explanation

Correct option:

A new checksum value for the object that is calculated based on the checksum values of the individual parts has been created. This behavior is expected

When you perform some operations using the AWS Management Console, Amazon S3 uses a multipart upload if the object is greater than 16 MB in size. In this case, the checksum is not a direct checksum of the full object, but rather a calculation based on the checksum values of each individual part.

For example, consider an object 100 MB in size that you uploaded as a single-part direct upload using the REST API. The checksum in this case is a checksum of the entire object. If you later use the console to rename that object, copy it, change the storage class, or edit the metadata, Amazon S3 uses the multipart upload functionality to update the object. As a result, Amazon S3 creates a new checksum value for the object that is calculated based on the checksum values of the individual parts.

Incorrect options:

If an object is greater than 50 MB in size, checksum will be a calculation based on the checksum values of each individual parts. The developer's initial calculation for the REST API based checksum was incorrect. This resulted in the mismatch of the two checksum values - This option is incorrect. When you perform some operations using the AWS Management Console, Amazon S3 uses a multipart upload if the object is greater than 16 MB (NOT 50 MB) in size.

When you change metadata of an object in S3, the checksum algorithm of the objects changes by default. This is an expected behavior - The checksum algorithm does not change when you change the metadata of the S3 object, so this option is incorrect.

If an object is greater than 16 MB in size, checksum will be a calculation based on the checksum values of each individual parts. The developer's initial calculation for the REST API based checksum was incorrect. This resulted in the mismatch of the two checksum values - This option is incorrect. When you perform some operations using the AWS Management Console, Amazon S3 uses a multipart upload if the object is greater than 16 MB in size. In this case, the checksum is not a direct checksum of the full object, but rather a calculation based on the checksum values of each individual part. On the other hand, when you upload an object as a single-part direct upload using the REST API, the checksum in this case is a checksum of the entire object. So you can say that the developer's initial calculation for the REST API based checksum was indeed correct.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html

Domain

Domain 5: Incident and Event Response

Question 42Skipped

A company having hundreds of AWS accounts manages its operations and security through a single organization created in AWS Organizations. As per the company's policy, AWS Config and AWS CloudTrail are enabled for all accounts. The security policy mandates configuring AWS Web Application Firewall (AWS WAF) web ACLs for all internet-facing Application Load Balancers (ALBs) and Amazon API Gateway APIs. However, monthly audit reports consistently report unsecured ALBs and API Gateway APIs.

As a DevOps engineer, the security team has requested you to automate these configurations for all accounts to avoid oversight. What steps will you recommend?

Configure a managed rule in AWS Config to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs

Create an Amazon Systems Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs

Correct answer

Designate one of the AWS accounts in your organization as the administrator for Firewall Manager in AWS Organizations. Create an AWS Firewall Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs

Create an Amazon GuardDuty policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs

Overall explanation

Correct option:

AWS Firewall Manager offers the freedom to use multiple AWS accounts and to host applications in any desired region while maintaining centralized control over their organization’s security settings and profile. Developers can develop and innovators can innovate, while the security team gains the ability to respond quickly, uniformly, and globally to potential threats and actual attacks.

Firewall Manager is built around named policies that contain WAF rule sets and optional AWS Shield advanced protection. Each policy applies to a specific set of AWS resources, specified by account, resource type, resource identifier, or tag. Policies can be applied automatically to all matching resources, or to a subset that you select. Policies can include WAF rules drawn from within the organization, and also those created by AWS Partners such as Imperva, F5, Trend Micro, and other AWS Marketplace vendors. This gives your security team the power to duplicate their existing on-premises security posture in the cloud.

Firewall Manager has three prerequisites:

AWS Organizations – Your organization must be using AWS Organizations to manage your accounts and all features must be enabled.

Firewall Administrator – You must designate one of the AWS accounts in your organization as the administrator for Firewall Manager. This gives the account permission to deploy AWS WAF rules across the organization.

AWS Config – You must enable AWS Config for all of the accounts in the Organization so that Firewall Manager can detect newly created resources.

Using AWS Firewall Manager to centrally manage your Web Application Portfolio:

via - https://aws.amazon.com/blogs/aws/aws-firewall-manager-central-management-for-your-web-application-portfolio/

Incorrect options:

Create an Amazon GuardDuty policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs - Amazon GuardDuty can automatically update the AWS Web Application Firewall Web Access Control Lists (WebACLs) and VPC Network Access Control Lists (NACLs) in response to GuardDuty findings. But, Amazon GuardDuty is a continuous security monitoring and threat detection service and not a security management service like AWS Firewall Manager. Even though GuardDuty can update web ACLs, it's a reaction to a threat. It cannot be used to proactively define rules for web ACLs across accounts to centrally manage the security infrastructure of an organization.

Configure a managed rule in AWS Config to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs - Enabling AWS Config is a prerequisite for using AWS Firewall Manager. AWS Config can track the status of resources, but AWS Firewall Manager is needed for centrally managing the security infrastructure.

AWS Firewall Manager and AWS Config:

via - https://aws.amazon.com/firewall-manager/

Create an Amazon Systems Manager policy to attach AWS WAF web ACLs to any newly created ALBs and API Gateway APIs - This option has been added as a distractor and is irrelevant to the given use case.

References:

https://docs.aws.amazon.com/waf/latest/developerguide/get-started-fms-create-security-policy.html

https://docs.aws.amazon.com/waf/latest/developerguide/get-started-fms-create-security-policy.html

Domain

Domain 6: Security and Compliance

Question 43Skipped

A CloudFormation stack consists of the following AWS resources - Amazon Simple Storage Service (Amazon S3) bucket, Amazon Amazon Elastic Compute Cloud (Amazon EC2) instance, and an Amazon EBS Volume. Due to a high-impact security issue, the DevOps team has been asked to rename the AWS CloudFormation stack. However, the resources created by the stack cannot be deleted for business purposes.

What steps will you take to rename the CloudFormation stack without deleting the resources created?

Launch a new CloudFormation stack that deploys all the resources of the stack. Launch another CloudFormation stack that deploys all the resources of the stack with a new name. In the second CloudFormation stack use, the DependsOn attribute to create the resource dependency on the first stack. Delete both the stacks while retaining the resources

Launch a CloudFormation stack that deploys all the resources of the stack. Add a Retain attribute to the deletion policy of the S3 bucket and EC2 instance. Add a 'Snapshot' attribute to the deletion policy of Amazon EBS Volume. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove the Retain and 'Snapshot' attribute from the stack to revert to the original template

Use CloudFormation registry to create custom hooks for all the resources of the CloudFormation stack. Then, delete the original CloudFormation stack and recreate a new one with the updated name. Using the hooks created earlier, import the resources back into the newly created stack

Correct answer

Launch a CloudFormation stack that deploys all the resources of the stack. Add a Retain attribute to the deletion policy of each of these resources. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove the Retain attribute from the stack to revert to the original template

Overall explanation

Correct options:

Launch a CloudFormation stack that deploys all the resources of the stack. Add a Retain attribute to the deletion policy of each of these resources. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove the Retain attribute from the stack to revert to the original template

With the DeletionPolicy attribute, you can preserve, and in some cases, backup a resource when its stack is deleted. You specify a DeletionPolicy attribute for each resource that you want to control. If a resource has no DeletionPolicy attribute, AWS CloudFormation deletes the resource by default. To keep a resource when its stack is deleted, specify Retain for that resource. You can use Retain for any resource. For resources that support snapshots, such as AWS::EC2::Volume, specify Snapshot to have CloudFormation create a snapshot before deleting the resource.

These steps need to be followed: 1. Launch a CloudFormation stack that deploys the necessary resources. 2. Add a Retain attribute to the deletion policy of all the resources deployed by the stack. 3. Delete the stack and verify that the resources are retained. 4. Create a new stack and import the resources that were retained from the original stack. This stack is created with a new name. 5. Remove the Retain attribute from the stack to revert to the original template.

Refer to the example that walks through the process of retaining a single resource—a VPC—when changing the name of a CloudFormation stack:

Process overview:

via - https://aws.amazon.com/blogs/infrastructure-and-automation/keep-your-aws-resources-when-you-rename-an-aws-cloudformation-stack/

Incorrect options:

Launch a CloudFormation stack that deploys all the resources of the stack. Add a Retain attribute to the deletion policy of S3 bucket and EC2 instance. Add a 'Snapshot' attribute to the deletion policy of Amazon EBS Volume. Delete the original stack. Create a new stack with a different name and import the resources that were retained from the original stack. Remove the Retain and 'Snapshot' attribute from the stack to revert to the original template - 'Snapshot' attribute will still delete the resource after taking its snapshot. So this option is incorrect.

Use the CloudFormation registry to create custom hooks for all the resources of the CloudFormation stack. Then, delete the original CloudFormation stack and recreate a new one with the updated name. Using the hooks created earlier, import the resources back into the newly created stack - A hook is an executable custom logic that automatically inspects resources before they're provisioned. Hooks can inspect the resources that CloudFormation is about to provision. If a hook finds any resource that doesn't comply with your organizational guidelines, it can prevent CloudFormation from continuing the provisioning process. Any hook based logic is not useful for the given use case.

Launch a new CloudFormation stack that deploys all the resources of the stack. Launch another CloudFormation stack that deploys all the resources of the stack with a new name. In the second CloudFormation stack use, DependsOn attribute to create the resource dependency on the first stack. Delete both stacks while retaining the resources - This option just acts as a distractor, as it does not solve the given issue.

References:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html

https://aws.amazon.com/blogs/infrastructure-and-automation/keep-your-aws-resources-when-you-rename-an-aws-cloudformation-stack/

https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks.html

Domain

Domain 2: Configuration Management and IaC

Question 44Skipped

A company uses multiple AWS accounts to help isolate and manage business applications. This multi-account environment consists of an AWS Transit Gateway to route all outbound traffic through a common network account. A firewall appliance inspects all traffic before it is forwarded to an internet gateway. The firewall appliance is configured to send logs to Amazon CloudWatch Logs for all events generated.

Recently, the security team has advised about probable illegal access of resources. As DevOps Engineer, you have been advised to configure an alert to the security team if the firewall appliance generates an event of Critical severity.

How should a DevOps engineer configure this requirement?

Create a Transit Gateway Flow Log to capture all the information sent by the firewall appliance. Publish the flow log data to Amazon CloudWatch logs. Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding and configure a CloudWatch alarm on this custom metric to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Configure a metric stream using Kinesis Data Firehose delivery stream and AWS Lambda as the destination. Process the stream data with Lambda and send notification to an Amazon Simple Notification Service (Amazon SNS) topic if Critical event is detected. Subscribe the email address of the security team to the SNS topic

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding. Use CloudWatch Lambda Insights to filter out the Critical event and send a notification using an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic

Correct answer

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding and configure a CloudWatch alarm on this custom metric to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic

Overall explanation

Correct option:

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding and configure a CloudWatch alarm on this custom metric to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic

You can search and filter the log data coming into CloudWatch Logs by creating one or more metric filters. Metric filters define the terms and patterns to look for in log data as it is sent to CloudWatch Logs. CloudWatch Logs uses these metric filters to turn log data into numerical CloudWatch metrics that you can graph or set an alarm on.

A metric alarm watches a single CloudWatch metric or the result of a math expression based on CloudWatch metrics. The alarm performs one or more actions based on the value of the metric or expression relative to a threshold over a number of time periods. The action can be sending a notification to an Amazon SNS topic, performing an Amazon EC2 action or an Amazon EC2 Auto Scaling action, or creating an OpsItem or incident in Systems Manager.

Amazon CloudWatch metrics and alarms:

via - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html

Incorrect options:

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Configure a metric stream using Kinesis Data Firehose delivery stream and AWS Lambda as the destination. Process the stream data with Lambda and send a notification to an Amazon Simple Notification Service (Amazon SNS) topic if a Critical event is detected. Subscribe the email address of the security team to the SNS topic - You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. Supported destinations include AWS destinations such as Amazon Simple Storage Service and several third-party service provider destinations. Kinesis Data Firehose is not supported as a destination for the metric streams.

Create a Transit Gateway Flow Log to capture all the information sent by the firewall appliance. Publish the flow log data to Amazon CloudWatch logs. Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding and configure a CloudWatch alarm on this custom metric to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic - Transit Gateway Flow Logs is a feature that enables you to capture information about the IP traffic going to and from your transit gateways. This does not meet our objective of analyzing firewall log data.

Create a metric filter on Amazon CloudWatch by filtering the log data to match the term Critical from log events. Publish a custom metric for the finding. Use CloudWatch Lambda Insights to filter out the Critical event and send a notification using an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the email address of the security team to the SNS topic - CloudWatch Lambda Insights is a monitoring and troubleshooting solution for serverless applications running on AWS Lambda. The solution collects, aggregates, and summarizes system-level metrics including CPU time, memory, disk, and network. This option acts as a distractor for the given use case.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html

https://docs.aws.amazon.com/vpc/latest/tgw/tgw-flow-logs.html

Domain

Domain 5: Incident and Event Response

Question 45Skipped

A company hosts all its web applications on Amazon EC2 instances. The company is looking for a security solution that will proactively detect software vulnerabilities and unintended network exposure of the instances. The solution should also include an audit trail of all login activities on the instances.

Which solution will meet these requirements?

Configure AWS Systems Manager's Systems Manager (SSM) agent to collect software vulnerabilities of the Amazon EC2 instances. Configure a Systems Manager Automation runbook to automatically patch the vulnerabilities identified by the SSM agent

Correct answer

Configure Amazon Inspector to detect vulnerabilities on the EC2 instances. Install the Amazon CloudWatch Agent to capture system logs and record them via Amazon CloudWatch Logs. Configure your trail to send log events to CloudWatch Logs

Configure Amazon ECR image scanning to scan for vulnerabilities on the EC2 instances. Amazon ECR sends an event to Amazon EventBridge when an image scan is completed. Configure CloudTrail to send its trail data to Amazon EventBridge for further processing/notification

Configure Amazon GuardDuty to detect vulnerabilities and threats on the EC2 instances. Integrate with a workflow system to review the findings and trigger an AWS Lambda function to automate the remediation process

Overall explanation

Correct option:

Configure Amazon Inspector to detect vulnerabilities on the EC2 instances. Install the Amazon CloudWatch Agent to capture system logs and record them via Amazon CloudWatch Logs. Configure your trail to send log events to CloudWatch Logs

Amazon Inspector is an automated vulnerability management service that continually scans Amazon Elastic Compute Cloud (EC2), AWS Lambda functions, and container workloads for software vulnerabilities and unintended network exposure. To successfully scan Amazon EC2 instances for software vulnerabilities, Amazon Inspector requires that these instances have the SSM agent installed. Amazon Inspector uses SSM Agent to collect application inventory, which can be set up as Amazon Virtual Private Cloud (VPC) endpoints to avoid sending information over the internet.

You can use Amazon CloudWatch Logs to monitor, store, and access your log files from Amazon Elastic Compute Cloud (Amazon EC2) instances, AWS CloudTrail, Route 53, and other sources.

CloudWatch Logs enables you to centralize the logs from all of your systems, applications, and AWS services that you use, in a single, highly scalable service. You can then easily view them, search them for specific error codes or patterns, filter them based on specific fields, or archive them securely for future analysis. CloudWatch Logs enables you to see all of your logs, regardless of their source, as a single and consistent flow of events ordered by time.

Configure CloudTrail with CloudWatch Logs to monitor your trail logs and be notified when specific activity occurs.

How Amazon Inspector Works:

via - https://aws.amazon.com/inspector/

Incorrect options:

Configure AWS Systems Manager's Systems Manager (SSM) agent to collect software vulnerabilities of the Amazon EC2 instances. Configure a Systems Manager Automation runbook to automatically patch the vulnerabilities identified by the SSM agent - SSM agent does not scan or detect vulnerabilities on Amazon EC2 instances.

Configure Amazon ECR image scanning to scan for vulnerabilities on the EC2 instances. Amazon ECR sends an event to Amazon EventBridge when an image scan is completed. Configure CloudTrail to send its trail data to Amazon EventBridge for further processing/notification - Amazon ECR provides basic scanning type which uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project. It is for container applications alone. Also, ECR image scanning identifies software vulnerabilities only in operating system packages.

Configure Amazon GuardDuty to detect vulnerabilities and threats on the EC2 instances. Integrate with a workflow system to review the findings and trigger an AWS Lambda function to automate the remediation process - Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, Amazon Elastic Compute Cloud (EC2) workloads, container applications, Amazon Aurora databases, and data stored in Amazon Simple Storage Service (S3). It is not a vulnerability management service.

References:

https://docs.aws.amazon.com/inspector/v1/userguide/inspector_introduction.html

https://aws.amazon.com/inspector/faqs/

Domain

Domain 6: Security and Compliance

Back to result overview Scroll back to top

Continue
Retake test

Fullscreen

Progress cannot be changed for this item

Progress cannot be changed for this item

Practice Test 1: Mini Practice Test: AWS Certified DevOps Engineer Professional - DOP-C02

Practice Test 2: Full Practice Test - AWS Certified DevOps Engineer Professional - DOP-C02

Expanded view

Beta

0 / 10used queries