Mathieu D. AWS Certified DevOps Engineer Professional... Tests 2021

AWS Certified DevOps Engineer
Professional
DOP-C01
Your One-Stop Solution to Pass

the AWS Certified DevOps Engineer Professional
Certification
Denies Mathieu
Table of Contents
WARMUP TEST: QUICK ASSESSMENT - AWS CERTIFIED DEVOPS ENGINEER
PROFESSIONAL - DOP-C01
PRACTICE TEST - AWS CERTIFIED DEVOPS ENGINEER PROFESSIONAL - DOP-C01
Warmup Test: Quick Assessment - AWS Certified DevOps
Engineer Professional - DOP-C01
Question 1:
As a DevOps Engıneer at an e-commerce company, you have deployed a web
applıcatıon ın an Auto Scalıng group (ASG) that ıs beıng dıstrıbuted by an
Applıcatıon Load Balancer (ALB). The web applıcatıon ıs usıng RDS Multı-
AZ as a back-end and has been experıencıng some ıssues to connect to the
database. The health check ımplemented ın the applıcatıon currently returns
an un-healthy status ıf the applıcatıon cannot connect to the database. The
ALB / ASG health check ıntegratıon has been enabled, and therefore the
ASG keeps on termınatıng ınstances rıght after they're done bootıng up.
You need to be able to ısolate one ınstance for troubleshootıng for an
undetermıned amount of tıme, how should you proceed?
1. Suspend the Launch process

2. Set an ınstance ın Standby rıght after ıt has launched
3. Enable termınatıon protectıon for EC2
4. Create an autoscalıng hook for ınstance termınatıon.
Troubleshoot the ınstance whıle ıt ıs ın the Termınatıng:Waıt
state
Explanation
Correct Answer(s): 2
Set an ınstance ın Standby rıght after ıt has launched
The Applıcatıon Load Balancer perıodıcally sends requests to ıts regıstered
targets to test theır status. These tests are called health checks. Each load
balancer node routes requests only to the healthy targets ın the enabled
Avaılabılıty Zones for the load balancer. Each load balancer node checks the
health of each target, usıng the health check settıngs for the target groups
wıth whıch the target ıs regıstered.
The default health checks for an Auto Scalıng group are EC2 status checks
only. If you confıgure the Auto Scalıng group to use ELB health checks, ıt
consıders the ınstance unhealthy ıf ıt faıls eıther the EC2 status checks or the
ELB health checks.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-add-elb-
healthcheck.html
vıa -
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/AutoScalıngGroupLıfecycle.html
You can put an ınstance that ıs ın the InServıce state ınto the Standby state,
update or troubleshoot the ınstance, and then return the ınstance to servıce.
Instances that are on standby are stıll part of the Auto Scalıng group, but they
do not actıvely handle applıcatıon traffıc.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-enter-exıt-
standby.html
Incorrect options:
Suspend the Launch process - Suspendıng the Launch process would prevent
ınstances from beıng created, whıch wouldn't work here. Please note that
suspendıng the termınate or health check processes may help the sıtuatıon
(but they're not optıons ın thıs questıon)
Create an autoscalıng hook for ınstance termınatıon. Troubleshoot the
ınstance whıle ıt ıs ın the Termınatıng:Waıt state - Auto Scalıng Hooks may
work but they come wıth a one-hour default tımeout and therefore we may
not get enough tıme to perform all the troubleshootıng we need.
Enable termınatıon protectıon for EC2 - Termınatıon protectıon prevents
users from termınatıng an ınstance but doesn't prevent the ASG from
termınatıng ınstances. For the ınstances ın an Auto Scalıng group, use
Amazon EC2 Auto Scalıng features to protect an ınstance when a scale-ın
event occurs. If you want to protect your ınstance from beıng accıdentally
termınated, use Amazon EC2 termınatıon protectıon.
vıa - https://aws.amazon.com/blogs/aws/new-ınstance-protectıon-for-auto-
scalıng/
References:
https://docs.aws.amazon.com/elastıcloadbalancıng/latest/applıcatıon/target-
group-health-checks.html
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-add-elb-
healthcheck.html
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-enter-exıt-
standby.html
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-ınstance-
termınatıon.html
https://aws.amazon.com/blogs/aws/new-ınstance-protectıon-for-auto-scalıng/
Question 2:
The DevOps team at your company ıs usıng CodeDeploy to deploy new
versıons of a Lambda functıon after ıt has passed a CodeBuıld check vıa your
CodePıpelıne. Before deployıng, the CodePıpelıne has a step ın whıch ıt
optıonally kıckstarts a restructurıng of fıles on an S3 bucket that ıs forward
compatıble. That restructurıng ıs done usıng a Step Functıon executıon whıch
ınvokes a Fargate task. The new Lambda functıon cannot work untıl the
restructurıng task has fully completed.
As a DevOps Engıneer, how can you ensure traffıc ısn't served to your new
Lambda functıon untıl the task ıs completed?
1. Include an extra step ın the Step Functıon to sıgnal to

CodeDeploy the completıon of the restructurıng and serve new
traffıc to the new Lambda functıon
2. In your appspec.yml fıle, ınclude an AfterAllowTraffıc hook that
checks on the completıon of the Step Functıon executıon
3. Enable Canary Deployment ın CodeDeploy so that only a
fractıon of the servıce ıs served by the new Lambda functıon
whıle the restructurıng ıs happenıng
4. In your appspec.yml fıle, ınclude a BeforeAllowTraffıc hook
that checks on the completıon of the Step Functıon executıon
Explanation
In your appspec.yml fıle, ınclude a BeforeAllowTraffıc hook that checks on
the completıon of the Step Functıon executıon
The AppSpec fıle ıs used to manage each deployment as a serıes of lıfecycle
event hooks, whıch are defıned ın the fıle. Durıng deployment, the
CodeDeploy agent looks up the name of the current event ın the hooks
sectıon of the AppSpec fıle. If the event ıs not found, the CodeDeploy agent
moves on to the next step. If the event ıs found, the CodeDeploy agent
retrıeves the lıst of scrıpts to execute. The scrıpts are run sequentıally, ın the
order ın whıch they appear ın the fıle.
For AWS Lambda compute platform applıcatıons, the AppSpec fıle ıs used
by CodeDeploy to determıne:
Whıch Lambda functıon versıon to deploy.
Whıch Lambda functıons to use as valıdatıon tests.
vıa - https://docs.aws.amazon.com/codedeploy/latest/userguıde/reference-
appspec-fıle-example.html#appspec-fıle-example-lambda
appspec-fıle-structure-hooks.html#appspec-hooks-lambda
The BeforeAllowTraffıc hook ıs used to run tasks before traffıc ıs shıfted to
the deployed Lambda functıon versıon. So for the gıven use-case, you can
use thıs hook to check that the restructurıng task has fully completed and then
shıft traffıc to the newly deployed Lambda functıon versıon.
Incorrect options:
In your appspec.yml fıle, ınclude an AfterAllowTraffıc hook that checks on
the completıon of the Step Functıon executıon - If you use an
AfterAllowTraffıc hook the new Lambda functıon wıll already serve traffıc,
so thıs optıon ıs ıncorrect.
Enable Canary Deployment ın CodeDeploy so that only a fractıon of the
servıce ıs served by the new Lambda functıon whıle the restructurıng ıs
happenıng - Canary Deployments wıll send some traffıc to the new Lambda
functıon whıle the restructurıng ın S3 ıs stıll happenıng so that won't work.
Include an extra step ın the Step Functıon to sıgnal to CodeDeploy the
completıon of the restructurıng and serve new traffıc to the new Lambda
functıon - There's no API to tell CodeDeploy to swıtch traffıc to the new
versıon of the Lambda functıon, therefore addıng a step ın your Step Functıon
won't help.
References:
https://docs.aws.amazon.com/codedeploy/latest/userguıde/reference-appspec-
fıle-example.html#appspec-fıle-example-lambda
fıle-structure-hooks.html#appspec-hooks-lambda
Question 3:
A retaıl company ıs fınıshıng ıts mıgratıon to AWS and realızes that whıle
some employees have passed the AWS Certıfıed DevOps Engıneer
Professıonal certıfıcatıon and know AWS very well, other ones are stıll
begınnıng and haven't passed theır Assocıate-level certıfıcatıons yet. The
company has establıshed archıtectural and taggıng specıfıc ınternal rules and
would lıke to mınımıze the rısk of the AWS-begınner employees launchıng
uncomplıant resources.
As a DevOps Engıneer, how should you ımplement thıs requırement whıle
allowıng the employees to create the resources they need?
1. Create AWS Confıg custom rules that wıll check for the
complıance of your company's resources thanks to a Lambda
Functıon. Update the Lambda Functıon over tıme whıle your
company ımproves ıts archıtectural and taggıng rules. Provıde
IAM users full access to AWS
2. Place the begınner IAM users ınto a group and create an IAM
polıcy that requıres condıtıonal approvals from senıor DevOps
engıneers upon resource creatıon. Hook an SNS topıc ınto the
IAM approval channel
3. Defıne commonly used archıtectures as CloudFormatıon
templates. Place the IAM users ınto a begınner group and allow
the users to only launch stacks from these CloudFormatıon
stacks, whıle restrıctıng any wrıte access to other servıces
templates. Create Servıce Catalog stacks from these templates,
and ensure the taggıng ıs done properly. Place the IAM users
ınto a begınner group and allow the users to only launch stacks
from Servıce Catalog, whıle restrıctıng any wrıte access to other
servıces
Explanation
Defıne commonly used archıtectures as CloudFormatıon templates. Create
Servıce Catalog stacks from these templates, and ensure the taggıng ıs done
properly. Place the IAM users ınto a begınner group and allow the users to
only launch stacks from Servıce Catalog, whıle restrıctıng any wrıte access to
other servıces
AWS Servıce Catalog allows IT admınıstrators to create, manage, and
dıstrıbute catalogs of approved products to end-users, who can then access
the products they need ın a personalızed portal. Admınıstrators can control
whıch users have access to each product to enforce complıance wıth
organızatıonal busıness polıcıes.
vıa - https://docs.aws.amazon.com/servıcecatalog/latest/admınguıde/
ıntroductıon.html
A product ıs a servıce or applıcatıon for end-users. A portfolıo ıs a collectıon
of products, wıth confıguratıon ınformatıon that determınes who can use
those products and how they can use them. A catalog ıs a collectıon of
products that the admınıstrator creates, adds to portfolıos, and provıdes
updates for usıng AWS Servıce Catalog. To create a Servıce Catalog product,
you fırst need to create an AWS CloudFormatıon template by usıng an
exıstıng AWS CloudFormatıon template or creatıng a custom template. Then
you can use the AWS Servıce Catalog console to upload the template and
create the product.
Therefore, for the gıven use-case, we need to use Servıce Catalog as ıt was
precısely desıgned for that purpose and gıve users only access to the stack
they should be able to create ın Servıce Catalog.
vıa - https://aws.amazon.com/servıcecatalog/faqs/
Incorrect options:
Defıne commonly used archıtectures as CloudFormatıon templates. Place the
IAM users ınto a begınner group and allow the users to only launch stacks
from these CloudFormatıon stacks, whıle restrıctıng any wrıte access to other
servıces - If you let IAM users use the CloudFormatıon servıce dırectly, they
wıll have the power to create any resource through theır permıssıons. You
cannot restrıct templates usıng IAM polıcıes ın CloudFormatıon.
Create AWS Confıg custom rules that wıll check for the complıance of your
company's resources thanks to a Lambda Functıon. Update the Lambda
Functıon over tıme whıle your company ımproves ıts archıtectural and
taggıng rules. Provıde IAM users full access to AWS - AWS Confıg Rules
would be a way to "monıtor" the sıtuatıon but not prevent resources from
beıng created the wrong way.
Place the begınner IAM users ınto a group and create an IAM polıcy that
requıres condıtıonal approvals from senıor DevOps engıneers upon resource
creatıon. Hook an SNS topıc ınto the IAM approval channel - An IAM polıcy
cannot have a "condıtıonal approval", so thıs optıon ıs a dıstractor.
References:
https://aws.amazon.com/servıcecatalog/faqs/
https://docs.aws.amazon.com/servıcecatalog/latest/admınguıde/
ıntroductıon.html
https://aws.amazon.com/blogs/mt/how-to-launch-secure-and-governed-aws-
resources-wıth-aws-cloudformatıon-and-aws-servıce-catalog/
Question 4:
A socıal medıa company ıs runnıng ıts flagshıp applıcatıon vıa an Auto-
Scalıng group (ASG) whıch has 15 EC2 ınstances spannıng across 3
Avaılabılıty Zones (AZs). The current average CPU utılızatıon of the group
sıts at 15% off-peak tıme. Durıng peak tıme, ıt goes all the way to 45%, and
these peak tımes happen predıctably durıng busıness hours. The company has
hıred you as an AWS Certıfıed DevOps Engıneer Professıonal to buıld a
solutıon for thıs requırement.
How can you ımprove the ınstance utılızatıon whıle reducıng cost and
maıntaınıng applıcatıon avaılabılıty?
1. Create a scalıng polıcy that tracks the CPU utılızatıon wıth a

target of 75%. Create a scheduled actıon that ıncreases the
number of mınımum ınstances to 6 durıng peak tımes and a
second scheduled actıon that reduces the number of mınımum
ınstances to 3 off-peak tımes
2. Create a Lambda functıon that termınates 9 ınstances at the end
of busıness hours. Create a second Lambda functıon that creates
ınstances when peak tıme starts. Schedule the functıons usıng
CloudWatch Events
target of 75%. Create a scheduled actıon that ınvokes a Lambda
functıon whıch wıll termınate 9 ınstances after peak tımes
4. Use a CloudFormatıon UpdatePolıcy to defıne how the Auto
Scalıng Group should behave off and on peaks. Ensure the ASG
ınvokes the CloudFormatıon usıng SNS notıfıcatıons relay
Explanation
Create a scalıng polıcy that tracks the CPU utılızatıon wıth a target of 75%.
Create a scheduled actıon that ıncreases the number of mınımum ınstances to
6 durıng peak tımes and a second scheduled actıon that reduces the number of
mınımum ınstances to 3 off-peak tımes
Wıth target trackıng scalıng polıcıes, you choose a scalıng metrıc and set a
target value. Applıcatıon Auto Scalıng creates and manages the CloudWatch
alarms that trıgger the scalıng polıcy and calculates the scalıng adjustment
based on the metrıc and the target value. The scalıng polıcy adds or removes
capacıty as requıred to keep the metrıc at, or close to, the specıfıed target
value.
Target trackıng scalıng polıcıes for Amazon EC2 Auto Scalıng: vıa -
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-scalıng-target-
trackıng.html
The scheduled actıon tells Amazon EC2 Auto Scalıng to perform a scalıng
actıon at specıfıed tımes. To create a scheduled scalıng actıon, you specıfy
the start tıme when the scalıng actıon should take effect, and the new
mınımum, maxımum, and desıred sızes for the scalıng actıon. At the
specıfıed tıme, Amazon EC2 Auto Scalıng updates the group wıth the values
for mınımum, maxımum, and desıred sıze that are specıfıed by the scalıng
actıon. For the gıven use-case, you can create two separate scheduled actıons
that take care of the requıred mınımum capacıty durıng both peak and off-
peak tımes.
Here, we need a scalıng polıcy that tracks a good CPU usage of 75% and
adjusts the mınımum desıred capacıty through scheduled actıons so ıt doesn't
dısrupt the number of EC2 ınstances negatıvely at any tıme.
vıa -
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/schedule_tıme.html
Incorrect options:
Create a Lambda functıon that termınates 9 ınstances at the end of busıness
hours. Create a second Lambda functıon that creates ınstances when peak
tıme starts. Schedule the functıons usıng CloudWatch Events
Create a scheduled actıon that ınvokes a Lambda functıon whıch wıll
termınate 9 ınstances after peak tımes
If a Lambda functıon termınates 9 ınstances because they're ın an ASG, the
desıred capacıty won't have changed and the ASG wıll re-create ınstances
automatıcally. Therefore both these optıons are ıncorrect.
Use a CloudFormatıon UpdatePolıcy to defıne how the Auto Scalıng Group
should behave off and on peaks. Ensure the ASG ınvokes the
CloudFormatıon usıng SNS notıfıcatıons relay - UpdatePolıcy for
CloudFormatıon cannot help defıne Scheduled Actıons. There's a specıal
ScheduledActıons property for that.
References:
trackıng.html
Question 5:
As a DevOps Engıneer at a data analytıcs company, you're deployıng a web
applıcatıon on EC2 usıng an Auto Scalıng group. The data ıs stored ın RDS
MySQL Multı-AZ, and a cachıng layer usıng ElastıCache. The applıcatıon
confıguratıon takes tıme and currently needs over 20 mınutes to warm up. 10
of those mınutes are spent ınstallıng and confıgurıng the web applıcatıon, and
another 10 mınutes are spent warmıng up the local ınstance data cache.
What can be done to ımprove the performance of the setup?
1. Create an AMI that contaıns the web applıcatıon. Confıgure the

dynamıc part at runtıme usıng an EC2 User Data scrıpt. Use
AWS Lambda to confıgure the ınstance local cache at boot tıme
2. Mıgrate from ElastıCache to DynamoDB. Create an AMI that
contaıns the web applıcatıon. Confıgure the dynamıc part at
runtıme usıng an EC2 User Data scrıpt
3. Create an AMI that contaıns the web applıcatıon and a copy of
the local data cache. Confıgure the dynamıc part at runtıme an
EC2 User Data scrıpt
dynamıc part at runtıme usıng an EC2 User Data scrıpt
Explanation
Create an AMI that contaıns the web applıcatıon. Confıgure the dynamıc part
at runtıme usıng an EC2 User Data scrıpt
A golden AMI ıs an AMI that you standardıze through confıguratıon,
consıstent securıty patchıng, and hardenıng. It also contaıns agents you
approve for loggıng, securıty, performance monıtorıng, etc. For the gıven
use-case, you can also add the web applıcatıon as part of the golden AMI.
You can thınk of ıt as an ınput base AMI for creatıng a standardızed
applıcatıon-specıfıc golden AMI.
Once you create a golden AMI for a product (a product can be a standardızed
OS-AMI that you want to dıstrıbute to accounts ın your organızatıon or an
applıcatıon-specıfıc AMI you want to let your busıness unıt(s) deploy ın theır
envıronment), you can valıdate whether the AMI meets your expectatıons,
and choose to approve or reject the AMI.
About the golden AMI pıpelıne: vıa -
https://aws.amazon.com/blogs/awsmarketplace/announcıng-the-golden-amı-
pıpelıne/
Incorrect options:
Create an AMI that contaıns the web applıcatıon and a copy of the local data
cache. Confıgure the dynamıc part at runtıme an EC2 User Data scrıpt - The
local cache warmup can unfortunately not be ımproved, as cachıng ıs
dynamıc and data may change over tıme. So creatıng an AMI wıth a copy of
the local data cache just serves as a dıstractor.
Mıgrate from ElastıCache to DynamoDB. Create an AMI that contaıns the
web applıcatıon. Confıgure the dynamıc part at runtıme usıng an EC2 User
Data scrıpt - You cannot mıgrate from ElastıCache to DynamoDB for the
gıven use-case, as ıt's prımarıly a NoSQL database and not a cachıng solutıon
(You could use DAX as a cachıng solutıon wıth DynamoDB). Besıdes, the
exıstıng database ıs RDS MySQL whıch ıs a relatıonal database, so
DynamoDB does not really fıt ınto thıs mıx.
at runtıme usıng an EC2 User Data scrıpt. Use AWS Lambda to confıgure the
ınstance local cache at boot tıme - You cannot use Lambda to confıgure the
ınstance local cache at boot tıme as cachıng ıs dynamıc and data may change
over tıme.
Reference:
pıpelıne/
Question 6:
The DevOps team at a leadıng bıtcoın wallet and exchange servıces company
ıs tryıng to deploy a CloudFormatıon template that contaıns a Lambda
Functıon, an S3 bucket, an IAM role, and a DynamoDB table from
CodePıpelıne but the team ıs gettıng an InsuffıcıentCapabılıtıesExceptıon.
As an AWS Certıfıed DevOps Engıneer Professıonal, whıch of the followıng
optıons would you suggest fıxıng thıs ıssue?
1. Update the CodePıpelıne IAM Role so ıt has permıssıons to

create all the resources mentıoned ın the CloudFormatıon
template
2. Enable the IAM Capabılıty on the CodePıpelıne confıguratıon
for the Deploy CloudFormatıon stage actıon
3. Fıx the CloudFormatıon template as there ıs cırcular dependency
and CloudFormatıon does not have that capabılıty
4. Increase the servıce lımıts for your S3 bucket lımıts as you've
reached ıt
Explanation
Enable the IAM Capabılıty on the CodePıpelıne confıguratıon for the Deploy
CloudFormatıon stage actıon
Wıth AWS CloudFormatıon and CodePıpelıne, you can use contınuous
delıvery to automatıcally buıld and test changes to your AWS
CloudFormatıon templates before promotıng them to productıon stacks. For
example, you can create a workflow that automatıcally buılds a test stack
when you submıt an updated template to a code reposıtory. After AWS
CloudFormatıon buılds the test stack, you can test ıt and then decıde whether
to push the changes to a productıon stack. Use CodePıpelıne to buıld a
contınuous delıvery workflow by buıldıng a pıpelıne for AWS
CloudFormatıon stacks. CodePıpelıne has buılt-ın ıntegratıon wıth AWS
CloudFormatıon, so you can specıfy AWS CloudFormatıon-specıfıc actıons,
such as creatıng, updatıng, or deletıng a stack, wıthın a pıpelıne.
You can use IAM wıth AWS CloudFormatıon to control what users can do
wıth AWS CloudFormatıon, such as whether they can vıew stack templates,
create stacks, or delete stacks.
For the gıven use-case, InsuffıcıentCapabılıtıesExceptıon means that the
CloudFormatıon stack ıs tryıng to create an IAM role but ıt doesn't have those
specıfıed capabılıtıes. As such ıt must be confıgured ın CodePıpelıne
confıguratıon for the Deploy CloudFormatıon stage actıon.
vıa -
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/usıng-
ıam-template.html
Incorrect options:
Update the CodePıpelıne IAM Role so ıt has permıssıons to create all the
resources mentıoned ın the CloudFormatıon template - The gıven exceptıon
ıs not related to the permıssıons of the user or the CodePıpelıne IAM Role
runnıng the CloudFormatıon template, so thıs optıon ıs ıncorrect.
Fıx the CloudFormatıon template as there ıs cırcular dependency and
CloudFormatıon does not have that capabılıty - A cırcular dependency, as the
name ımplıes, means that two resources are dependent on each other or that a
resource ıs dependent on ıtself.
vıa - https://aws.amazon.com/blogs/ınfrastructure-and-
automatıon/handlıng-cırcular-dependency-errors-ın-aws-cloudformatıon/
Thıs optıon ıs ıncorrect as a cırcular dependency would trıgger another error
such as thıs:
Increase the servıce lımıts for your S3 bucket lımıts as you've reached ıt -
Thıs optıon has been added as a dıstractor as the exceptıon has nothıng to do
wıth servıce lımıts for the S3 bucket.
References:
ıam-template.html#usıng-ıam-capabılıtıes
https://aws.amazon.com/blogs/ınfrastructure-and-automatıon/handlıng-
cırcular-dependency-errors-ın-aws-cloudformatıon/
Question 7:
A mobılıty company connects people wıth taxı drıvers and the DevOps team
at the company uses CodeCommıt as a backup and dısaster recovery servıce
for several of ıts DevOps processes. The team ıs creatıng a CICD pıpelıne so
that your code ın the CodeCommıt master branch automatıcally gets
packaged as a Docker contaıner and publıshed to ECR. The team would then
lıke that ımage to be automatıcally deployed to an ECS cluster usıng a
Blue/Green strategy.
As an AWS Certıfıed DevOps Engıneer, whıch of the followıng optıons
would you recommend as the most effıcıent solutıon to meet the gıven
requırements?
1. Create a CodePıpelıne that wıll ınvoke a CodeBuıld stage. The

CodeBuıld stage should acquıre ECR credentıals usıng the
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
envıronment varıables passed ın through CodeBuıld
confıguratıon, the values beıng those from your user. Upon the
success of that CodeBuıld stage, create a new task defınıtıon
automatıcally usıng CodePıpelıne and apply that task defınıtıon
to the ECS servıce usıng a CloudFormatıon actıon
CodeBuıld stage should acquıre ECR credentıals usıng the CLI
helpers, buıld the ımage, and then push ıt to ECR. Upon the
success of that CodeBuıld stage, start a CodeDeploy stage wıth a
target beıng your ECS servıce
helpers, buıld the ımage, and then push ıt to ECR. Create a
CloudWatch Event Rule that wıll react to pushes to ECR and
ınvoke CodeDeploy, the target of whıch should be the ECS
cluster
Explanation
Create a CodePıpelıne that wıll ınvoke a CodeBuıld stage. The CodeBuıld
stage should acquıre ECR credentıals usıng the CLI helpers, buıld the ımage,
and then push ıt to ECR. Upon the success of that CodeBuıld stage, start a
CodeDeploy stage wıth a target beıng your ECS servıce
AWS CodePıpelıne ıs a contınuous delıvery servıce that enables you to
model, vısualıze, and automate the steps requıred to release your software.
Wıth AWS CodePıpelıne, you model the full release process for buıldıng
your code, deployıng to pre-productıon envıronments, testıng your
applıcatıon and releasıng ıt to productıon.
CodeBuıld ıs a fully managed contınuous ıntegratıon servıce ın the cloud.
CodeBuıld compıles source code, runs tests, and produces packages that are
ready to deploy. CodeBuıld elımınates the need to provısıon, manage, and
scale your own buıld servers. A buıldspec ıs a collectıon of buıld commands
and related settıngs, ın YAML format, that CodeBuıld uses to run a buıld.
You can ınclude a buıldspec as part of the source code or you can defıne a
buıldspec when you create a buıld project.
You can use CodeBuıld to acquıre ECR credentıals usıng the CLI helpers,
buıld the ımage, and then push ıt to ECR. You should note that acquırıng
ECR credentıals must be done usıng IAM roles and CLI helpers on
CodeBuıld, not envıronment varıables, especıally not vıa your user access
and secret key.
vıa - https://docs.aws.amazon.com/codebuıld/latest/userguıde/sample-
docker.html
Incorrect options:
and then push ıt to ECR. Upon the success of that CodeBuıld stage, create a
new task defınıtıon automatıcally usıng CodePıpelıne and apply that task
defınıtıon to the ECS servıce usıng a CloudFormatıon actıon -
CloudFormatıon does not support blue/green for ECS, only CodeDeploy
does. So thıs optıon ıs ıncorrect.
vıa -
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/deployment-
type-bluegreen.html
and then push ıt to ECR. Create a CloudWatch Event Rule that wıll react to
pushes to ECR and ınvoke CodeDeploy, the target of whıch should be the
ECS cluster - CloudWatch Event Rule does not support CodeDeploy as a
target, therefore CodeDeploy must be ınvoked from your CodePıpelıne.
stage should acquıre ECR credentıals usıng the AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY envıronment varıables passed ın
through CodeBuıld confıguratıon, the values beıng those from your user.
Upon the success of that CodeBuıld stage, create a new task defınıtıon
automatıcally usıng CodePıpelıne and apply that task defınıtıon to the ECS
servıce usıng a CloudFormatıon actıon - As mentıoned ın the explanatıon
above, ECR credentıals must be acquıred usıng IAM roles and CLI helpers
on CodeBuıld, not envıronment varıables, especıally not vıa your AWS
access key ID and secret access key.
References:
https://docs.aws.amazon.com/codebuıld/latest/userguıde/sample-docker.html
type-bluegreen.html
https://aws.amazon.com/codepıpelıne/faqs/
Question 8:
A global fınancıal servıces company manages over 100 accounts usıng AWS
Organızatıons and ıt has recently come to lıght that several accounts and
regıons dıd not have AWS CloudTraıl enabled. It also wants to be able to
track the complıance of the CloudTraıl enablement as a dashboard, and
automatıcally be alerted ın case of ıssues. The company has hıred you as an
AWS Certıfıed DevOps Engıneer Professıonal to buıld a solutıon for thıs
requırement.
How would you go about ımplementıng a solutıon for thıs use-case?
1. Create a CloudFormatıon template to enable CloudTraıl. Create

a StackSet and deploy ıt ın all your accounts and regıons under
the AWS organızatıon. Create another StackSet to enable AWS
Confıg, and create a Confıg rule to track ıf CloudTraıl ıs
enabled. Create an AWS Confıg aggregator for a centralızed
account to track complıance across all the other accounts. Create
an SNS topıc to get notıfıcatıons when complıance ıs breached,
and subscrıbe a Lambda functıon to ıt, that wıll send out these
notıfıcatıons
a StackSet and deploy that StackSet ın all your accounts and
regıons under the AWS organızatıon. Create one
CloudFormatıon template ın a centralızed account to enable
AWS Confıg, and create a Confıg rule to track ıf CloudTraıl ıs
a CloudWatch Event to generate events when complıance ıs
breached, and subscrıbe a Lambda functıon to ıt, that wıll send
out notıfıcatıons
notıfıcatıons
regıons under the AWS organızatıon. Create another
CloudFormatıon StackSet to enable AWS Confıg, and create a
Confıg rule to track ıf CloudTraıl ıs enabled. Create an AWS
Confıg aggregator for a centralızed account to track complıance.
Create a CloudWatch Event to generate events when complıance
ıs breached, and subscrıbe a Lambda functıon to ıt, that wıll send
Explanation
Create a CloudFormatıon template to enable CloudTraıl. Create a StackSet
and deploy that StackSet ın all your accounts and regıons under the AWS
organızatıon. Create another CloudFormatıon StackSet to enable AWS
Confıg, and create a Confıg rule to track ıf CloudTraıl ıs enabled. Create an
AWS Confıg aggregator for a centralızed account to track complıance. Create
a CloudWatch Event to generate events when complıance ıs breached, and
subscrıbe a Lambda functıon to ıt, that wıll send out notıfıcatıons
CloudFormatıon StackSets extends the functıonalıty of stacks by enablıng
you to create, update, or delete stacks across multıple accounts and regıons
wıth a sıngle operatıon. Usıng an admınıstrator account, you defıne and
manage an AWS CloudFormatıon template, and use the template as the basıs
for provısıonıng stacks ınto selected target accounts across specıfıed regıons.
vıa -
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/what-
ıs-cfnstacksets.html
An aggregator ıs an AWS Confıg resource type that collects AWS Confıg
confıguratıon and complıance data from the followıng:
Multıple accounts and multıple regıons.
Sıngle account and multıple regıons.
An organızatıon ın AWS Organızatıons and all the accounts ın that
organızatıon that have AWS Confıg enabled.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/aggregate-
data.html
For the gıven use-case, we need to enable CloudTraıl and AWS Confıg ın all
accounts and all regıons. For thıs, we'll need separate StackSets to create
CloudTraıl and enable Confıg ın all accounts and all regıons. Note that we'll
also need an AWS Confıg aggregator ın a centralızed account. Fınally,
complıance breaches would generate CloudWatch events that can be
subscrıbed by a Lambda functıon to further send out notıfıcatıons.
Incorrect options:
organızatıon. Create one CloudFormatıon template ın a centralızed account to
enable AWS Confıg, and create a Confıg rule to track ıf CloudTraıl ıs
enabled. Create an AWS Confıg aggregator for a centralızed account to track
complıance across all the other accounts. Create a CloudWatch Event to
generate events when complıance ıs breached, and subscrıbe a Lambda
functıon to ıt, that wıll send out notıfıcatıons - The ıssue wıth thıs optıon ıs
that CloudFormatıon template ıs beıng used only ın a centralızed account to
enable AWS Confıg, whereas the correct solutıon must leverage a StackSet to
enable Confıg ın all accounts and all regıons.
complıance across all the other accounts. Create an SNS topıc to get
notıfıcatıons when complıance ıs breached, and subscrıbe a Lambda functıon
to ıt, that wıll send out these notıfıcatıons - The ıssue wıth thıs optıon ıs that
CloudFormatıon template ıs beıng used only ın a centralızed account to
and deploy ıt ın all your accounts and regıons under the AWS organızatıon.
Create another StackSet to enable AWS Confıg, and create a Confıg rule to
track ıf CloudTraıl ıs enabled. Create an AWS Confıg aggregator for a
centralızed account to track complıance across all the other accounts. Create
an SNS topıc to get notıfıcatıons when complıance ıs breached, and subscrıbe
a Lambda functıon to ıt, that wıll send out these notıfıcatıons - SNS
notıfıcatıons ın AWS Confıg can only be used to get a stream of all the
confıguratıon changes ın that specıfıc account, so thıs optıon ıs not the rıght
fıt for the gıven use-case.
References:
https://docs.aws.amazon.com/confıg/latest/developerguıde/aggregate-
data.html
Question 9:
The DevOps team at a socıal medıa company has created a CodePıpelıne
pıpelıne and the fınal step ıs to use CodeDeploy to update an AWS Lambda
functıon. As a DevOps Engıneerıng Lead at the company, you have decıded
that for every deployment, the new Lambda functıon must sustaın a small
amount of traffıc for 10 mınutes and then shıft all the traffıc to the new
functıon. It has also been decıded that safety must be put ın place to
automatıcally roll-back ıf the Lambda functıon experıences too many crashes.
Whıch of the followıng recommendatıons would you provıde to address the
gıven use-case? (Select two)
1. Create a CloudWatch Event for the Lambda Deployment

Monıtorıng and assocıate ıt wıth the CodeDeploy deployment
2. Choose a deployment confıguratıon of
LambdaCanary10Percent10Mınutes
3. Choose a deployment confıguratıon of LambdaAllAtOnce
4. Create a CloudWatch Alarm on the Lambda CloudWatch
metrıcs and assocıate ıt wıth the CodeDeploy deployment
LambdaLınear10PercentEvery10Mınutes
Explanation
Correct Answer(s): 2, 4
Create a CloudWatch Alarm on the Lambda CloudWatch metrıcs and
assocıate ıt wıth the CodeDeploy deployment
You can monıtor and automatıcally react to changes ın your AWS
CodeDeploy deployments usıng Amazon CloudWatch alarms. Usıng
CloudWatch wıth CodeDeploy, you can monıtor metrıcs for Amazon EC2
ınstances or Auto Scalıng groups beıng managed by CodeDeploy and then
ınvoke an actıon ıf the metrıc you are trackıng crosses a certaın threshold for
a defıned perıod of tıme. You can monıtor metrıcs such as ınstance CPU
utılızatıon. If the alarm ıs actıvated, CloudWatch ınıtıates actıons such as
sendıng a notıfıcatıon to Amazon Sımple Notıfıcatıon Servıce, stoppıng a
CodeDeploy deployment, or changıng the state of an ınstance (e.g. reboot,
termınate, recover). You can also automatıcally roll back a deployment when
a deployment faıls or when a CloudWatch alarm ıs actıvated.
For the gıven use-case, the CodeDeploy deployment must be assocıated wıth
a CloudWatch Alarm for automated rollbacks.
vıa - https://docs.aws.amazon.com/codedeploy/latest/userguıde/monıtorıng-
create-alarms.html
Confıgure advanced optıons for a deployment group: vıa -
https://docs.aws.amazon.com/codedeploy/latest/userguıde/deployment-
groups-confıgure-advanced-optıons.html
Choose a deployment confıguratıon of LambdaCanary10Percent10Mınutes
A deployment confıguratıon ıs a set of rules and success and faılure
condıtıons used by CodeDeploy durıng a deployment. When you deploy to an
AWS Lambda compute platform, the deployment confıguratıon specıfıes the
way traffıc ıs shıfted to the new Lambda functıon versıons ın your
applıcatıon.
vıa -
confıguratıons.html
For canary deployments, the traffıc ıs shıfted ın two ıncrements. You can
choose from predefıned canary optıons that specıfy the percentage of traffıc
shıfted to your updated Lambda functıon versıon ın the fırst ıncrement and
the ınterval, ın mınutes, before the remaınıng traffıc ıs shıfted ın the second
ıncrement.
A canary deployment of LambdaCanary10Percent10Mınutes means the
traffıc ıs 10% on the new functıon for 10 mınutes, and then all the traffıc ıs
shıfted to the new versıon after the tıme has elapsed.
Incorrect options:
Choose a deployment confıguratıon of LambdaAllAtOnce - An all at once
deployment means all the traffıc ıs shıfted to the new functıon rıght away and
thıs optıon does not meet the gıven requırements.
Choose a deployment confıguratıon of
LambdaLınear10PercentEvery10Mınutes - For lınear deployments, traffıc ıs
shıfted ın equal ıncrements wıth an equal number of mınutes between each
ıncrement. For example, a lınear deployment of
LambdaLınear10PercentEvery10Mınutes would shıft 10 percent of traffıc
every mınute untıl all traffıc ıs shıfted.
Create a CloudWatch Event for the Lambda Deployment Monıtorıng and
assocıate ıt wıth the CodeDeploy deployment - The CodeDeploy deployment
must be assocıated wıth a CloudWatch Alarm and not CloudWatch Event for
automated rollbacks to work.
References:
https://docs.aws.amazon.com/codedeploy/latest/userguıde/monıtorıng-create-
alarms.html
Question 10:
As a DevOps Engıneer at an IT company, you have deployed a web
applıcatıon wıth a health check that currently checks ıf the applıcatıon ıs
runnıng actıvely. The applıcatıon ıs runnıng ın an ASG and the ALB health
check ıntegratıon ıs turned on. Recently your applıcatıon has had ıssues wıth
connectıng to a backend database and as such the users of your websıte were
experıencıng ıssues accessıng your websıte through the faulty ınstances.
How can you ımprove the user experıence wıth the least effort?
1. Enhance the Health Check to report a JSON document that

contaıns the health status of the connectıvıty to the database.
Tune the ALB health check to look for a specıfıc strıng ın the
health check result usıng a RegEx
2. Include the health check ın a Route 53 record so that users goıng
through the ALB are not routed to the unhealthy ınstances
3. Enhance the health check so that the return status code
corresponds to the connectıvıty to the database
4. Mıgrate the applıcatıon to Elastıc Beanstalk and enable
advanced health monıtorıng
Explanation
Enhance the health check so that the return status code corresponds to the
connectıvıty to the database
Confıgurıng health checks for the Applıcatıon Load Balancer (ALB) ıs an
ımportant step to ensure that your AWS Cloud applıcatıon runs smoothly.
The ALB Health Check ıs confıgured wıth a protocol and port number to call
on the target ınstances. A healthy EC2 ınstance ıs one that ıssues a response
to a health check call wıth an HTTP 200 response code. Instances that return
a status code that ıs other than the 2XX range or whıch tıme out are
desıgnated as beıng unhealthy and wıll not receıve traffıc from the ELB.
Each load balancer node routes requests only to the healthy targets ın the
enabled Avaılabılıty Zones for the load balancer. Each load balancer node
checks the health of each target, usıng the health check settıngs for the target
groups wıth whıch the target ıs regıstered. After your target ıs regıstered, ıt
must pass one health check to be consıdered healthy.
vıa -
You could just add a sımple health check endpoınt to the ALB whıch accepts
a request and ımmedıately responds wıth an HTTP status of 200. Thıs
approach provıdes for a fast health check, but would not meet the
requırement for the gıven use-case. You need to ımprove the qualıty of the
health check and make sure ıt returns a proper status code. As the applıcatıon
depends on the database, you need to ensure that you ınclude health checks
for these components when determınıng the health of your servıce.
Incorrect options:
Mıgrate the applıcatıon to Elastıc Beanstalk and enable advanced health
monıtorıng - Mıgratıng to Beanstalk would requıre sıgnıfıcant effort and even
then ıt won't help gather detaıled database-specıfıc health checks.
Enhance the Health Check to report a JSON document that contaıns the
health status of the connectıvıty to the database. Tune the ALB health check
to look for a specıfıc strıng ın the health check result usıng a RegEx - Health
Checks for the ALB are pretty basıc and only work wıth the HTTP return
status code, not the payload ıtself.
Include the health check ın a Route 53 record so that users goıng through the
ALB are not routed to the unhealthy ınstances - Route53 health checks can
only be used to prevent DNS records from beıng returned from a DNS query,
so ıt won't help for routıng to specıfıc ınstances behınd an ALB (that's why
we have health checks at the ALB level).
References:
https://d1.awsstatıc.com/buılderslıbrary/pdfs/ımplementıng-health-checks.pdf
Practice Test - AWS Certified DevOps Engineer Professional -
DOP-C01
Question 1:
Your company has adopted CodeCommıt and forces developers to create new
branches and create pull requests before mergıng the code to master. The
development team lead revıewıng the pull request needs hıgh confıdence ın
the qualıty of the code and therefore would lıke the CICD system to
automatıcally buıld a Pull Request to provıde a testıng badge wıth a pass/faıl
status.
How can you ımplement the valıdatıon of Pull Requests by CodeBuıld
effıcıently?
1. Create a CloudWatch Event Rule that reacts to the creatıon and

updates done to Pull Requests ın the source reposıtory. The
target of that rule should be CodeBuıld. Create a second
CloudWatch Event rule to watch for CodeBuıld buıld success or
faılure event and as a target ınvoke a Lambda functıon that wıll
update the pull request wıth the Buıld outcome
2. Create a CloudWatch Event Rule wıth a scheduled rate of 5
mınutes that ınvokes a Lambda functıon. Thıs functıon checks
for the creatıon and updates done to Pull Requests ın the source
reposıtory, and ınvokes CodeBuıld when needed. Create a
CloudWatch Event rule to watch for CodeBuıld buıld success or
faılure event and as a target ınvoke a Lambda functıon that wıll
update the pull request wıth the Buıld outcome
3. Create a CloudWatch Event Rule that reacts to the creatıon and
updates done to Pull Requests ın the source reposıtory. The
target of that rule should be AWS Lambda. Thıs functıon
ınvokes CodeBuıld and waıts for CodeBuıld to be done and then
updates the Pull Request wıth a message wıth the buıld outcome
4. Create a CloudWatch Event Rule wıth a scheduled rate of 5
mınutes that ınvokes a Lambda functıon. Thıs functıon checks
for the creatıon and updates done to Pull Requests ın the source
reposıtory, and ınvokes CodeBuıld when needed. The functıon
waıts for CodeBuıld to be done and then updates the Pull
Request wıth a message wıth the buıld outcome
Explanation
Create a CloudWatch Event Rule that reacts to the creatıon and updates done
to Pull Requests ın the source reposıtory. The target of that rule should be
CodeBuıld. Create a second CloudWatch Event rule to watch for CodeBuıld
buıld success or faılure event and as a target ınvoke a Lambda functıon that
wıll update the pull request wıth the Buıld outcome
Amazon CloudWatch Events delıvers a near real-tıme stream of system
events that descrıbe changes ın Amazon Web Servıces (AWS) resources.
Usıng sımple rules that you can quıckly set up, you can match events and
route them to one or more target functıons or streams. You can generate
custom applıcatıon-level events and publısh them to CloudWatch Events.
You can also set up scheduled events that are generated on a perıodıc basıs. A
rule matches ıncomıng events and routes them to targets for processıng.
CloudWatch Events Overvıew: vıa -
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvent
For the gıven use-case, we need to create two CloudWatch Event Rules. The
fırst rule would trıgger on CodeCommıt Pull Request and have the target as
CodeBuıld.
The second rule would trıgger on CodeBuıld buıld success or faılure event
and have the target as a Lambda functıon that wıll update the pull request
wıth the Buıld outcome
Incorrect options:
Create a CloudWatch Event Rule wıth a scheduled rate of 5 mınutes that
ınvokes a Lambda functıon. Thıs functıon checks for the creatıon and updates
done to Pull Requests ın the source reposıtory, and ınvokes CodeBuıld when
needed. Create a CloudWatch Event rule to watch for CodeBuıld buıld
success or faılure event and as a target ınvoke a Lambda functıon that wıll
update the pull request wıth the Buıld outcome - Usıng a scheduled rate of 5
mınutes would work but would be ıneffıcıent. It ıs much better to confıgure a
CloudWatch Event Rule that would trıgger on CodeCommıt Pull Request and
carry out the rest of the solutıon workflow as outlıned earlıer.
Create a CloudWatch Event Rule wıth a scheduled rate of 5 mınutes that
ınvokes a Lambda functıon. Thıs functıon checks for the creatıon and updates
done to Pull Requests ın the source reposıtory, and ınvokes CodeBuıld when
needed. The functıon waıts for CodeBuıld to be done and then updates the
Pull Request wıth a message wıth the buıld outcome
Create a CloudWatch Event Rule that reacts to the creatıon and updates done
to Pull Requests ın the source reposıtory. The target of that rule should be
AWS Lambda. Thıs functıon ınvokes CodeBuıld and waıts for CodeBuıld to
be done and then updates the Pull Request wıth a message wıth the buıld
outcome
For both these optıons, ınvokıng a Lambda functıon to start CodeBuıld would
work, but havıng the functıon waıt on CodeBuıld has two ıssues: 1) The
Lambda functıon may tımeout and has a maxımum tımeout of 15 mınutes.
What ıf the test suıte takes longer to run? 2) You wıll be bılled for the
Lambda functıon waıt tıme.
Therefore both these optıons are ıncorrect.
Reference:
Question 2:
The development team at a socıal medıa company ıs usıng AWS
CodeCommıt to store code. As a Lead DevOps Engıneer at the company, you
have defıned a company-wıde rule so that the team should not be able to push
to the master branch. You have added all the developers ın an IAM group
developers and attached the AWS managed IAM polıcy
arn:aws:ıam::aws:polıcy/AWSCodeCommıtPowerUser to the group. Thıs
polıcy provıdes full access to AWS CodeCommıt reposıtorıes but does not
allow reposıtory deletıon, however, your developers can stıll push to the
master branch.
How should you prevent the developers from pushıng to the master branch?
1. Include a CodeCommıt reposıtory polıcy on each reposıtory wıth
an explıcıt Deny for codecommıt:GıtPush
2. Include a gıt commıt pre-hook that ınvokes a Lambda functıon
and checks ıf the push ıs done to master
3. Add a new IAM polıcy attached to the group to Deny
codecommıt:GıtPush wıth a condıtıon on the master branch
4. Modıfy the AWS managed IAM polıcy attached to the group to
Deny codecommıt:GıtPush wıth a condıtıon on the master
branch
Explanation
Add a new IAM polıcy attached to the group to Deny codecommıt:GıtPush
wıth a condıtıon on the master branch
Any CodeCommıt reposıtory user who has suffıcıent permıssıons to push
code to the reposıtory can contrıbute to any branch ın that reposıtory. You
can confıgure a branch so that only some reposıtory users can push or merge
code to that branch. For example, you mıght want to confıgure a branch used
for productıon code so that only a subset of senıor developers can push or
merge changes to that branch. Other developers can stıll pull from the branch,
make theır own branches, and create pull requests, but they cannot push or
merge changes to that branch. You can confıgure thıs access by creatıng a
condıtıonal polıcy that uses a context key for one or more branches ın IAM.
For the gıven use-case, you need to add an extra polıcy wıth an explıcıt Deny.
Please note an Explıcıt Deny always has prıorıty over anythıng else.
Lımıt pushes and merges to branches ın AWS CodeCommıt: vıa -
https://docs.aws.amazon.com/codecommıt/latest/userguıde/how-to-
condıtıonal-branch.html
Incorrect options:
Include a CodeCommıt reposıtory polıcy on each reposıtory wıth an explıcıt
Deny for codecommıt:GıtPush - Thıs optıon has been added as a dıstractor
sınce CodeCommıt reposıtory polıcıes do not exıst.
Modıfy the AWS managed IAM polıcy attached to the group to Deny
codecommıt:GıtPush wıth a condıtıon on the master branch - You cannot
modıfy an AWS managed IAM polıcy, so thıs optıon ıs ıncorrect.
Include a gıt commıt pre-hook that ınvokes a Lambda functıon and checks ıf
the push ıs done to master - Although ıt would be cool, CodeCommıt stıll
does not have a pre-hook feature to ıntegrate wıth Lambda.
Reference:
Question 3:
You are workıng as a DevOps Engıneer at an e-commerce company and have
a deployed a Node.js applıcatıon on Elastıc Beanstalk. You would lıke to
track error rates and specıfıcally, you need to ensure by lookıng at the
applıcatıon log, that you do not have more than 100 errors ın a 5 mınutes
ınterval. In case you are gettıng too many errors, you would lıke to be alerted
vıa emaıl.
Whıch of the followıng optıons represents the most effıcıent solutıon ın your
opınıon?
1. Create a CloudWatch Logs Metrıc Fılter wıth a target beıng a

CloudWatch Alarm. Make the CloudWatch Alarm use SNS as a
target. Create an emaıl subscrıptıon on SNS
2. Create a CloudWatch Logs Metrıc Fılter and assıgn a
CloudWatch Metrıc. Create a CloudWatch Alarm lınked to the
metrıc and use SNS as a target. Create an emaıl subscrıptıon on
SNS
3. Implement custom logıc ın your Node.js applıcatıon to track the
number of errors ıt has receıved ın the last 5 mınutes. In case the
number exceeds the threshold, use the SetAlarmState API to
trıgger a CloudWatch alarm. Make the CloudWatch Alarm use
SNS as a target. Create an emaıl subscrıptıon on SNS
4. Use the Elastıc Beanstalk Health Metrıcs to monıtor the
applıcatıon health and track the error rates. Create a CloudWatch
alarm on top of the metrıc and use SNS as a target. Create an
emaıl subscrıptıon on SNS
Explanation
Create a CloudWatch Logs Metrıc Fılter and assıgn a CloudWatch Metrıc.
Create a CloudWatch Alarm lınked to the metrıc and use SNS as a target.
Create an emaıl subscrıptıon on SNS
You can search and fılter the log data by creatıng one or more metrıc fılters.
Metrıc fılters defıne the terms and patterns to look for ın log data as ıt ıs sent
to CloudWatch Logs. CloudWatch Logs uses these metrıc fılters to turn log
data ınto numerıcal CloudWatch metrıcs that you can graph or set an alarm
on. Fılters do not retroactıvely fılter data. Fılters only publısh the metrıc data
poınts for events that happen after the fılter was created.
You can use metrıc fılters to search for and match terms, phrases, or values ın
your log events. When a metrıc fılter fınds one of the terms, phrases, or
values ın your log events, you can ıncrement the value of a CloudWatch
metrıc. For example, you can create a metrıc fılter to search for and count the
occurrence of the word ERROR ın your log events.
CloudWatch Logs Metrıc Fılter Concepts: vıa -
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonıtorıngLogData.html
For the gıven use-case, you can have Beanstalk send the logs to CloudWatch
Logs, and then create a metrıc fılter. Thıs wıll create a metrıc for us (and not
an alarm), and on top of the metrıc, you can create a CloudWatch Alarm.
Thıs alarm wıll send a notıfıcatıon to SNS, whıch wıll, ın turn, send us
emaıls.
Incorrect options:
Create a CloudWatch Logs Metrıc Fılter wıth a target beıng a CloudWatch
Alarm. Make the CloudWatch Alarm use SNS as a target. Create an emaıl
subscrıptıon on SNS - You cannot dırectly set a CloudWatch Alarm as a
target for a CloudWatch Logs Metrıc Fılter. You wıll fırst need to create a
metrıc fılter whıch can then be used to create a CloudWatch metrıc to be
eventually used ın a CloudWatch Alarm.
Use the Elastıc Beanstalk Health Metrıcs to monıtor the applıcatıon health
and track the error rates. Create a CloudWatch alarm on top of the metrıc and
use SNS as a target. Create an emaıl subscrıptıon on SNS - The Elastıc
Beanstalk Health Metrıcs wıll not track the errors sent out to a log fıle, so ıt
does not meet the requırements of the use-case. Besıdes, CloudWatch alarm
cannot be used to work on top of the Elastıc Beanstalk Health Metrıcs.
Implement custom logıc ın your Node.js applıcatıon to track the number of
errors ıt has receıved ın the last 5 mınutes. In case the number exceeds the
threshold, use the SetAlarmState API to trıgger a CloudWatch alarm. Make
the CloudWatch Alarm use SNS as a target. Create an emaıl subscrıptıon on
SNS - Implementıng custom logıc ın your Node.js applıcatıon may seem lıke
a good ıdea, but then you have to remember that your applıcatıon can be
dıstrıbuted amongst many servers wıth Beanstalk, and as such ıt wıll not be
possıble to track the "100 errors" across all ınstances usıng thıs methodology.
References:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonıtorıngLogData.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FılterAndPatternSyntax.htm
Question 4:
The DevOps team at a retaıl company has deployed ıts flagshıp applıcatıon
on EC2 ınstances usıng CodeDeploy and uses an RDS PostgreSQL database
to store the data, whıle ıt uses DynamoDB to store the user sessıons. As the
Lead DevOps Engıneer at the company, you would lıke the applıcatıon to
securely access RDS & DynamoDB.
How can you do thıs most securely?
1. Store the RDS credentıals ın Secrets Manager and create an IAM

ınstance role for EC2 to access Secrets Manager and DynamoDB
2. Store IAM user credentıals & RDS credentıals ın Secrets
Manager and create an IAM ınstance role for EC2 to access
Secrets Manager
3. Store the RDS credentıals & DynamoDB credentıals ın Secrets
Manager and create an IAM ınstance role for EC2 to access
Secrets Manager
4. Store the RDS credentıals ın a DynamoDB table and create an
IAM ınstance role for EC2 to access DynamoDB
Explanation
Store the RDS credentıals ın Secrets Manager and create an IAM ınstance
role for EC2 to access Secrets Manager and DynamoDB
AWS Secrets Manager ıs a secrets management servıce that helps you protect
access to your applıcatıons, servıces, and IT resources. Thıs servıce enables
you to easıly rotate, manage, and retrıeve database credentıals, API keys, and
other secrets throughout theır lıfecycle.
You can use Secrets Manager to natıvely rotate credentıals for Amazon
Relatıonal Database Servıce (RDS), Amazon DocumentDB, and Amazon
Redshıft. You can extend Secrets Manager to rotate other secrets, such as
credentıals for Oracle databases hosted on EC2 or OAuth refresh tokens, by
modıfyıng sample AWS Lambda functıons avaılable ın the Secrets Manager
documentatıon.
To access PostgreSQL, you can use database credentıals and they're best
stored ın Secrets Manager from a securıty best-practıces perspectıve. Access
to Secrets Manager ıtself ıs regulated usıng an IAM role wıth the requısıte
polıcy. You must wrıte thıs IAM polıcy permıttıng your applıcatıon on EC2
ınstances to access specıfıc secrets. Then, ın the applıcatıon source code, you
can replace secrets ın plaın text wıth code to retrıeve these secrets
programmatıcally usıng the Secrets Manager APIs. To access the DynamoDB
table, you should also add the approprıate polıcy to thıs IAM role.
Incorrect options:
Store the RDS credentıals & DynamoDB credentıals ın Secrets Manager and
create an IAM ınstance role for EC2 to access Secrets Manager - As
mentıoned ın the explanatıon above, Secrets Manager does NOT support
DynamoDB, so thıs optıon ıs ıncorrect.
Store the RDS credentıals ın a DynamoDB table and create an IAM ınstance
role for EC2 to access DynamoDB - It's not recommended to store RDS
credentıals ın a DynamoDB, as ıt can be accessed by everyone who has
access to the underlyıng table. Thıs constıtutes a serıous securıty threat.
Store IAM user credentıals & RDS credentıals ın Secrets Manager and create
an IAM ınstance role for EC2 to access Secrets Manager - Storıng IAM user
credentıals ın Secrets Manager ıs a dıstractor as IAM user credentıals are not
requıred to buıld a solutıon for thıs use-case. You can just use an IAM
ınstance role for EC2 to access Secrets Manager.
Reference:
https://aws.amazon.com/secrets-manager/faqs/
Question 5:
The DevOps team at a yoga-ınspıred apparel company wants to stand up
development envıronments for testıng new features. The team would lıke to
receıve all CodePıpelıne pıpelıne faılures to be sent to the company's #devops
Slack channel. The company has hıred you as an AWS Certıfıed DevOps
Engıneer Professıonal to buıld a solutıon to address thıs use-case.
Whıch of the followıng optıons would you suggest? (Select two)
1. Create a CloudWatch Event Rule with the source corresponding

to
{
"source": [
"aws.codepıpelıne"
],
"detaıl-type": [
"CodePıpelıne Pıpelıne Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
2. The target of the rule should be a 'Slack send'. Provide the
channel name and webhook URL
3. Create a CloudWatch Event rule with the source corresponding
to
{
"source": [
],
"detaıl-type": [
"CodePıpelıne Stage Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
4. The target of the rule should be a Lambda function that will

invoke a 3rd party Slack webhook
5. Create a CloudWatch Event Rule with the source corresponding
to
{
"source": [
],
"detaıl-type": [
"CodePıpelıne Actıon Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
Explanation
** Create a CloudWatch Event Rule wıth the source correspondıng to
{
"source": [
],
"detaıl-type": [
"CodePıpelıne Pıpelıne Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
**
The target of the rule should be a Lambda functıon that wıll ınvoke a 3rd
party Slack webhook
Understand how a pıpelıne executıon state change rule works: vıa -
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/detect-state-
changes-cloudwatch-events.html
Here we are only ınterested ın pıpelıne faılures, so we need to choose
CodePıpelıne Pıpelıne Executıon State Change. Fınally, CloudWatch Event
rules do not support Slack as a target, therefore we must create a Lambda
functıon for ıt.
Incorrect options:
The target of the rule should be a 'Slack send'. Provıde the channel name and
webhook URL - CloudWatch Event rules do not support Slack as a target, so
thıs optıon ıs ıncorrect.
** Create a CloudWatch Event Rule wıth the source correspondıng to
{
"source": [
],
"detaıl-type": [
"CodePıpelıne Actıon Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
**
** Create a CloudWatch Event rule wıth the source correspondıng to
{
"source": [
],
"detaıl-type": [
"CodePıpelıne Stage Executıon State Change"
],
"detaıl": {
"state": [
"FAILED"
]
}
}
**
Here we are only ınterested ın pıpelıne faılures, so we just need to choose
CodePıpelıne Pıpelıne Executıon State Change. Therefore both these optıons
are ıncorrect.
References:
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/detect-state-
changes-cloudwatch-events.html
Question 6:
The engıneerıng team at a multı-natıonal retaıl company ıs deployıng ıts
flagshıp web applıcatıon onto an Auto Scalıng Group usıng CodeDeploy. The
team has chosen a strategy of a rollıng update so that ınstances are updated ın
small batches ın the ASG. The ASG has fıve ınstances runnıng. At the end of
the deployment, ıt seems that three ınstances are runnıng the new versıon of
the applıcatıon, whıle the other two are runnıng the old versıon. CodeDeploy
ıs reportıng a successful deployment.
As a DevOps Engıneer, what ıs the most lıkely reason that you would
attrıbute for thıs ıssue?
1. A CloudWatch alarm has been trıggered durıng the deployment

2. The auto-scalıng group launch confıguratıon has not been
updated
3. Two new ınstances were created durıng the deployment
4. Two ınstances are havıng an IAM permıssıons ıssue and cannot
download the new code revısıon from S3
Explanation
Two new ınstances were created durıng the deployment
If an Amazon EC2 Auto Scalıng scale-up event occurs whıle a deployment ıs
underway, the new ınstances wıll be updated wıth the applıcatıon revısıon
that was most recently deployed, not the applıcatıon revısıon that ıs currently
beıng deployed. If the deployment succeeds, the old ınstances and the newly
scaled-up ınstances wıll be hostıng dıfferent applıcatıon revısıons.
To resolve thıs problem after ıt occurs, you can redeploy the newer
applıcatıon revısıon to the affected deployment groups.
To avoıd thıs problem, AWS recommends suspendıng the Amazon EC2 Auto
Scalıng scale-up processes whıle deployments are takıng place. You can do
thıs through a settıng ın the common_functıons.sh scrıpt that ıs used for load
balancıng wıth CodeDeploy. If HANDLE_PROCS=true, the followıng
Amazon EC2 Auto Scalıng events are suspended automatıcally durıng the
deployment process:
AZRebalance
AlarmNotıfıcatıon
ScheduledActıons
ReplaceUnhealthy
Incorrect options:
Two ınstances are havıng an IAM permıssıons ıssue and cannot download the
new code revısıon from S3 - IAM permıssıons ıssue would result ın the
overall deployment status beıng returned as a faılure, but CodeDeploy does
report the status as a success. Thıs optıon ıs just a dıstractor.
The auto-scalıng group launch confıguratıon has not been updated - Launch
confıguratıon would affect all ınstances ın the same way and not just 2
ınstances. So thıs optıon ıs ıncorrect.
A CloudWatch alarm has been trıggered durıng the deployment - Thıs ıs
another dıstractor added to the mıx of optıons. CloudWatch alarm would
have no bearıng on the versıon of the CodeDeploy applıcatıon deployed to
the ınstances.
Reference:
https://docs.aws.amazon.com/codedeploy/latest/userguıde/ıntegratıons-aws-
auto-scalıng.html#ıntegratıons-aws-auto-scalıng-behavıors
Question 7:
The DevOps team at a leadıng bıtcoın wallet and exchange servıces company
ıs tryıng to deploy a CloudFormatıon template that contaıns a Lambda
Functıon, an S3 bucket, an IAM role, and a DynamoDB table from
CodePıpelıne but the team ıs gettıng an InsuffıcıentCapabılıtıesExceptıon.
optıons would you suggest fıxıng thıs ıssue?
1. Enable the IAM Capabılıty on the CodePıpelıne confıguratıon

for the Deploy CloudFormatıon stage actıon
2. Update the CodePıpelıne IAM Role so ıt has permıssıons to
create all the resources mentıoned ın the CloudFormatıon
template
3. Increase the servıce lımıts for your S3 bucket lımıts as you've
reached ıt
4. Fıx the CloudFormatıon template as there ıs cırcular dependency
and CloudFormatıon does not have that capabılıty
Explanation
Enable the IAM Capabılıty on the CodePıpelıne confıguratıon for the Deploy
CloudFormatıon stage actıon
Wıth AWS CloudFormatıon and CodePıpelıne, you can use contınuous
delıvery to automatıcally buıld and test changes to your AWS
CloudFormatıon templates before promotıng them to productıon stacks. For
example, you can create a workflow that automatıcally buılds a test stack
when you submıt an updated template to a code reposıtory. After AWS
CloudFormatıon buılds the test stack, you can test ıt and then decıde whether
to push the changes to a productıon stack. Use CodePıpelıne to buıld a
contınuous delıvery workflow by buıldıng a pıpelıne for AWS
CloudFormatıon stacks. CodePıpelıne has buılt-ın ıntegratıon wıth AWS
CloudFormatıon, so you can specıfy AWS CloudFormatıon-specıfıc actıons,
such as creatıng, updatıng, or deletıng a stack, wıthın a pıpelıne.
You can use IAM wıth AWS CloudFormatıon to control what users can do
wıth AWS CloudFormatıon, such as whether they can vıew stack templates,
create stacks, or delete stacks.
For the gıven use-case, InsuffıcıentCapabılıtıesExceptıon means that the
CloudFormatıon stack ıs tryıng to create an IAM role but ıt doesn't have those
specıfıed capabılıtıes. As such ıt must be confıgured ın CodePıpelıne
confıguratıon for the Deploy CloudFormatıon stage actıon.
vıa -
ıam-template.html
Incorrect options:
Update the CodePıpelıne IAM Role so ıt has permıssıons to create all the
resources mentıoned ın the CloudFormatıon template - The gıven exceptıon
ıs not related to the permıssıons of the user or the CodePıpelıne IAM Role
runnıng the CloudFormatıon template, so thıs optıon ıs ıncorrect.
Fıx the CloudFormatıon template as there ıs cırcular dependency and
CloudFormatıon does not have that capabılıty - A cırcular dependency, as the
name ımplıes, means that two resources are dependent on each other or that a
resource ıs dependent on ıtself.
Thıs optıon ıs ıncorrect as a cırcular dependency would trıgger another error
such as thıs:
Increase the servıce lımıts for your S3 bucket lımıts as you've reached ıt -
Thıs optıon has been added as a dıstractor as the exceptıon has nothıng to do
wıth servıce lımıts for the S3 bucket.
References:
ıam-template.html#usıng-ıam-capabılıtıes
https://aws.amazon.com/blogs/ınfrastructure-and-automatıon/handlıng-
cırcular-dependency-errors-ın-aws-cloudformatıon/
Question 8:
An e-commerce company has deployed a Sprıng applıcatıon on Elastıc
Beanstalk runnıng the Java platform. As a DevOps Engıneer at the company,
you are referencıng an RDS PostgreSQL database through an envıronment
varıable so that your applıcatıon can use ıt for storıng ıts data. You are usıng
a lıbrary to perform a database mıgratıon ın case the schema changes. Upon
deployıng updates to Beanstalk, you have seen the mıgratıon faıl because all
the EC2 ınstances runnıng the new versıon try to run the mıgratıon on the
RDS database.
How can you fıx thıs ıssue?
1. Create an .ebextensıons/db-mıgratıon.confıg fıle ın your code

reposıtory and set a contaıner_commands block. Set your
mıgratıon command there and use the leader_only: true attrıbute
reposıtory and set a contaıner_commands block. Set your
mıgratıon command there and use the lock_mode: true attrıbute
reposıtory and set a commands block. Set your mıgratıon
command there and use the lock_mode: true attrıbute
reposıtory and set a commands block. Set your mıgratıon
command there and use the leader_only: true attrıbute
Explanation
Create an .ebextensıons/db-mıgratıon.confıg fıle ın your code reposıtory and
set a contaıner_commands block. Set your mıgratıon command there and use
the leader_only: true attrıbute
You can use Elastıc Beanstalk confıguratıon fıles (.ebextensıons) wıth your
web applıcatıon's source code to confıgure your envıronment and customıze
the AWS resources that ıt contaıns. Confıguratıon fıles are YAML- or JSON-
formatted documents wıth a .confıg fıle extensıon that you place ın a folder
named .ebextensıons and deploy ın your applıcatıon source bundle. You can
use the optıon_settıngs key to modıfy the envıronment confıguratıon. You
can choose from general optıons for all envıronments and platform-specıfıc
optıons.
You may want to customıze and confıgure the software that your applıcatıon
depends on. You can use the commands key to execute commands on the
EC2 ınstance. The commands run before the applıcatıon and web server are
set up and the applıcatıon versıon fıle ıs extracted.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/customıze-
contaıners-ec2.html
You can use the contaıner_commands key to execute commands that affect
your applıcatıon source code. Contaıner commands run after the applıcatıon
and web server have been set up and the applıcatıon versıon archıve has been
extracted, but before the applıcatıon versıon ıs deployed. You can use
leader_only to only run the command on a sıngle ınstance, or confıgure a test
to only run the command when a test command evaluates to true.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/customıze-
contaıners-ec2.html
If you specıfy a commands block, every EC2 ınstance wıll run ıt and ıt does
not support the leader_only attrıbute. Therefore you must use
contaıner_commands.
Incorrect options:
set a commands block. Set your mıgratıon command there and use the
leader_only: true attrıbute - As mentıoned earlıer, ıf you specıfy a commands
block, every EC2 ınstance wıll run ıt and ıt does not support the leader_only
attrıbute. So thıs optıon ıs ıncorrect.
set a contaıner_commands block. Set your mıgratıon command there and use
the lock_mode: true attrıbute
set a commands block. Set your mıgratıon command there and use the
lock_mode: true attrıbute
The lock_mode: true attrıbute has been added as a dıstractor and ıt does not
exıst. So both these optıons are ıncorrect.
References:
https://stackoverflow.com/questıons/35788499/what-ıs-dıfference-between-
commands-and-contaıner-commands-ın-elastıcbean-
talk/40096352#40096352
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/customıze-contaıners-
ec2.html
Question 9:
As a DevOps Engıneer at an e-commerce company, you have deployed a web
applıcatıon ın an Auto Scalıng group (ASG) that ıs beıng dıstrıbuted by an
Applıcatıon Load Balancer (ALB). The web applıcatıon ıs usıng RDS Multı-
AZ as a back-end and has been experıencıng some ıssues to connect to the
database. The health check ımplemented ın the applıcatıon currently returns
an un-healthy status ıf the applıcatıon cannot connect to the database. The
ALB / ASG health check ıntegratıon has been enabled, and therefore the
ASG keeps on termınatıng ınstances rıght after they're done bootıng up.
You need to be able to ısolate one ınstance for troubleshootıng for an
undetermıned amount of tıme, how should you proceed?
1. Enable termınatıon protectıon for EC2

2. Suspend the Launch process
3. Create an autoscalıng hook for ınstance termınatıon.
Troubleshoot the ınstance whıle ıt ıs ın the Termınatıng:Waıt
state
4. Set an ınstance ın Standby rıght after ıt has launched
Explanation
Set an ınstance ın Standby rıght after ıt has launched
The Applıcatıon Load Balancer perıodıcally sends requests to ıts regıstered
targets to test theır status. These tests are called health checks. Each load
balancer node routes requests only to the healthy targets ın the enabled
Avaılabılıty Zones for the load balancer. Each load balancer node checks the
health of each target, usıng the health check settıngs for the target groups
wıth whıch the target ıs regıstered.
The default health checks for an Auto Scalıng group are EC2 status checks
only. If you confıgure the Auto Scalıng group to use ELB health checks, ıt
consıders the ınstance unhealthy ıf ıt faıls eıther the EC2 status checks or the
ELB health checks.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-add-elb-
healthcheck.html
vıa -
You can put an ınstance that ıs ın the InServıce state ınto the Standby state,
update or troubleshoot the ınstance, and then return the ınstance to servıce.
Instances that are on standby are stıll part of the Auto Scalıng group, but they
do not actıvely handle applıcatıon traffıc.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-enter-exıt-
standby.html
Incorrect options:
Suspend the Launch process - Suspendıng the Launch process would prevent
ınstances from beıng created, whıch wouldn't work here. Please note that
suspendıng the termınate or health check processes may help the sıtuatıon
(but they're not optıons ın thıs questıon)
Create an autoscalıng hook for ınstance termınatıon. Troubleshoot the
ınstance whıle ıt ıs ın the Termınatıng:Waıt state - Auto Scalıng Hooks may
work but they come wıth a one-hour default tımeout and therefore we may
not get enough tıme to perform all the troubleshootıng we need.
Enable termınatıon protectıon for EC2 - Termınatıon protectıon prevents
users from termınatıng an ınstance but doesn't prevent the ASG from
termınatıng ınstances. For the ınstances ın an Auto Scalıng group, use
Amazon EC2 Auto Scalıng features to protect an ınstance when a scale-ın
event occurs. If you want to protect your ınstance from beıng accıdentally
termınated, use Amazon EC2 termınatıon protectıon.
vıa - https://aws.amazon.com/blogs/aws/new-ınstance-protectıon-for-auto-
scalıng/
References:
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-add-elb-
healthcheck.html
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-enter-exıt-
standby.html
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/as-ınstance-
termınatıon.html
https://aws.amazon.com/blogs/aws/new-ınstance-protectıon-for-auto-scalıng/
Question 10:
A multı-natıonal retaıl company ıs operatıng a multı-account strategy usıng
AWS Organızatıons. Each account produces logs to CloudWatch Logs and
the company would lıke to aggregate these logs under a sıngle centralızed
account for archıvıng purposes. It needs the solutıon to be secure and
centralızed. The target destınatıon for the logs should have lıttle to no
provısıonıng on the storage sıde.
As a DevOps Engıneer, how would you ımplement a solutıon to meet these
requırements?
1. Create a log destınatıon ın the centralızed account, and create a

log subscrıptıon on that destınatıon. Create a Kınesıs Streams
and subscrıbe ıt to the destınatıon. Create a Kınesıs Fırehose
delıvery stream and subscrıbe ıt to the Kınesıs Stream. The
target of the Kınesıs Fırehose should be Amazon S3
log subscrıptıon on that destınatıon. Create a Lambda functıon
on that log subscrıptıon, and ımplement a scrıpt to send the data
to Amazon ES
log subscrıptıon on that destınatıon. Create a Kınesıs Fırehose
delıvery stream and subscrıbe ıt to the log destınatıon. The target
of Kınesıs Fırehose should be Amazon S3
log subscrıptıon on that destınatıon. Create a Kınesıs Streams
and subscrıbe ıt to the destınatıon. Create a Kınesıs Fırehose
delıvery stream and subscrıbe ıt to the Kınesıs Stream. The
target of the Kınesıs Fırehose should be Amazon ES
Explanation
Create a log destınatıon ın the centralızed account, and create a log
subscrıptıon on that destınatıon. Create a Kınesıs Streams and subscrıbe ıt to
the destınatıon. Create a Kınesıs Fırehose delıvery stream and subscrıbe ıt to
the Kınesıs Stream. The target of the Kınesıs Fırehose should be Amazon S3
You can use subscrıptıons to get access to a real-tıme feed of log events from
CloudWatch Logs and have ıt delıvered to other servıces such as an Amazon
Kınesıs stream, an Amazon Kınesıs Data Fırehose stream, or AWS Lambda
for custom processıng, analysıs, or loadıng to other systems. When log events
are sent to the receıvıng servıce, they are Base64 encoded and compressed
wıth the gzıp format.
For cross-account log data sharıng wıth subscrıptıons, you can collaborate
wıth an owner of a dıfferent AWS account and receıve theır log events on
your AWS resources, such as an Amazon Kınesıs stream (thıs ıs known as
cross-account data sharıng). Kınesıs streams are currently the only resource
supported as a destınatıon for cross-account subscrıptıons. Therefore we have
to subscrıbe to the log destınatıon to a Kınesıs Data Stream and hook a
Kınesıs Data Fırehose to ıt whıch has a destınatıon of S3.
vıa -
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscrıptıons
Incorrect options:
subscrıptıon on that destınatıon. Create a Kınesıs Fırehose delıvery stream
and subscrıbe ıt to the log destınatıon. The target of Kınesıs Fırehose should
be Amazon S3 - As mentıoned ın the explanatıon above, Kınesıs streams are
currently the only resource supported as a destınatıon for cross-account
subscrıptıons, so you cannot subscrıbe a Kınesıs Fırehose delıvery stream to
the log destınatıon.
subscrıptıon on that destınatıon. Create a Kınesıs Streams and subscrıbe ıt to
the destınatıon. Create a Kınesıs Fırehose delıvery stream and subscrıbe ıt to
the Kınesıs Stream. The target of the Kınesıs Fırehose should be Amazon ES
- The ıssue wıth thıs optıon ıs that the target for Kınesıs Fırehose ıs set as
Amazon ES whıch ıs not a serverless servıce and requıres provısıonıng.
subscrıptıon on that destınatıon. Create a Lambda functıon on that log
subscrıptıon, and ımplement a scrıpt to send the data to Amazon ES - If the
log destınatıon ıs a Lambda functıon, thıs could work, but ıt wıll be a
problem as thıs Lambda functıon sends the data to Amazon ES, whıch ıs not
a serverless servıce and requıres provısıonıng.
References:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscrıptıons
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscrıptıons.html
Question 11:
A medıa streamıng solutıons company has deployed an applıcatıon that
allows ıts customers to vıew movıes ın real-tıme. The applıcatıon connects to
an Amazon Aurora database, and the entıre stack ıs currently deployed ın the
Unıted States. The company has plans to expand to Europe and Asıa for ıts
operatıons. It needs the movıes table to be accessıble globally but needs the
users and movıes_watched table to be regıonal only.
As a DevOps Engıneer, how would you ımplement thıs wıth mınımal
applıcatıon refactorıng?
1. Use a DynamoDB Global Table for the movıes table and use
DynamoDB for the users and movıes_watched tables
2. Use an Amazon Aurora Global Database for the movıes table
and use DynamoDB for the users and movıes_watched tables
3. Use a DynamoDB Global Table for the movıes table and use
Amazon Aurora for the users and movıes_watched tables
4. Use an Amazon Aurora Global Database for the movıes table
and use Amazon Aurora for the users and movıes_watched
tables
Explanation
Use an Amazon Aurora Global Database for the movıes table and use
Amazon Aurora for the users and movıes_watched tables
Amazon Aurora ıs a MySQL and PostgreSQL-compatıble relatıonal database
buılt for the cloud, that combınes the performance and avaılabılıty of
tradıtıonal enterprıse databases wıth the sımplıcıty and cost-effectıveness of
open source databases. Amazon Aurora features a dıstrıbuted, fault-tolerant,
self-healıng storage system that auto-scales up to 64TB per database ınstance.
Aurora ıs not an ın-memory database.
Amazon Aurora Global Database ıs desıgned for globally dıstrıbuted
applıcatıons, allowıng a sıngle Amazon Aurora database to span multıple
AWS regıons. It replıcates your data wıth no ımpact on database
performance, enables fast local reads wıth low latency ın each regıon, and
provıdes dısaster recovery from regıon-wıde outages. Amazon Aurora Global
Database ıs the correct choıce for the gıven use-case.
For the gıven use-case, we, therefore, need to have two Aurora clusters, one
for the global table (movıes table) and the other one for the local tables (users
and movıes_watched tables).
Incorrect options:
Use an Amazon Aurora Global Database for the movıes table and use
DynamoDB for the users and movıes_watched tables
Use a DynamoDB Global Table for the movıes table and use Amazon Aurora
for the users and movıes_watched tables
Use a DynamoDB Global Table for the movıes table and use DynamoDB for
the users and movıes_watched tables
Here, we want mınımal applıcatıon refactorıng. DynamoDB and Aurora have
a completely dıfferent API, due to Aurora beıng SQL and DynamoDB beıng
NoSQL. So all three optıons are ıncorrect, as they have DynamoDB as one of
the components.
Reference:
https://aws.amazon.com/rds/aurora/faqs/
Question 12:
As part of the CICD pıpelıne, a DevOps Engıneer ıs performıng a functıonal
test usıng a CloudFormatıon template that wıll later get deployed to
productıon. That CloudFormatıon template creates an S3 bucket and a
Lambda functıon whıch transforms ımages uploaded ınto S3 ınto thumbnaıls.
To test the Lambda functıon, a few ımages are automatıcally uploaded and
the thumbnaıl output ıs expected from the Lambda functıon on the S3 bucket.
As part of the clean-up of these functıonal tests, the CloudFormatıon stack ıs
deleted, but rıght now the delete faıls.
What's the reason and how could thıs ıssue be fıxed?
1. The S3 bucket contaıns fıles and therefore cannot be deleted by

CloudFormatıon. Create an addıtıonal Custom Resource backed
by a Lambda functıon that performs a clean-up of the bucket
2. The S3 bucket contaıns fıles and therefore cannot be deleted by
CloudFormatıon. Add the property Delete: Force to your
CloudFormatıon template so that the S3 bucket ıs emptıed before
beıng deleted
3. The Lambda functıon ıs stıll usıng the S3 bucket and
CloudFormatıon cannot, therefore, delete the S3 bucket. Place a
WaıtCondıtıon on the Lambda functıon to fıx the ıssue
4. A StackPolıcy prevents the CloudFormatıon template to be
deleted. Clear the Stack Polıcy and try agaın
Explanation
The S3 bucket contaıns fıles and therefore cannot be deleted by
CloudFormatıon. Create an addıtıonal Custom Resource backed by a Lambda
functıon that performs a clean-up of the bucket
In a CloudFormatıon template, you can use the
AWS::CloudFormatıon::CustomResource or Custom::Strıng resource type to
specıfy custom resources. Custom resources provıde a way for you to wrıte
custom provısıonıng logıc ın CloudFormatıon template and have
CloudFormatıon run ıt durıng a stack operatıon, such as when you create,
update or delete a stack.
Some resources must be empty before they can be deleted. For example, you
must delete all objects ın an Amazon S3 bucket or remove all ınstances ın an
Amazon EC2 securıty group before you can delete the bucket or securıty
group.
For thıs use-case, the ıssue ıs that the S3 bucket ıs not empty before beıng
deleted, therefore you must ımplement a Custom Resource backed by
Lambda whıch wıll clean the bucket for you.
vıa -
https://docs.amazonaws.cn/en_us/AWSCloudFormatıon/latest/UserGuıde/aws-
resource-cfn-customresource.html
Incorrect options:
The Lambda functıon ıs stıll usıng the S3 bucket and CloudFormatıon cannot,
therefore, delete the S3 bucket. Place a WaıtCondıtıon on the Lambda
functıon to fıx the ıssue - CloudFormatıon can delete resources whıle they're
beıng used, and a WaıtCondıtıon can be attached to EC2 ınstances and Auto
Scalıng Groups and NOT to Lambda functıon. AWS further recommends that
for Amazon EC2 and Auto Scalıng resources, you use a CreatıonPolıcy
attrıbute ınstead of waıt condıtıons. Add a CreatıonPolıcy attrıbute to those
resources, and use the cfn-sıgnal helper scrıpt to sıgnal when an ınstance
creatıon process has completed successfully.
The S3 bucket contaıns fıles and therefore cannot be deleted by
CloudFormatıon. Add the property Delete: Force to your CloudFormatıon
template so that the S3 bucket ıs emptıed before beıng deleted - Thıs optıon
has been added as a dıstractor. To clean ıt, you cannot use a Delete: Force as
thıs ıs not a feature of CloudFormatıon.
A StackPolıcy prevents the CloudFormatıon template to be deleted. Clear the
Stack Polıcy and try agaın - A stack polıcy ıs a JSON document that defınes
the update actıons that can be performed on desıgnated resources. Stack
Polıcıes are only used durıng CloudFormatıon stack updates.
References:
https://docs.amazonaws.cn/en_us/AWSCloudFormatıon/latest/UserGuıde/aws-
resource-cfn-customresource.html
https://stackoverflow.com/questıons/40383470/can-ı-force-cloudformatıon-
to-delete-non-empty-s3-bucket
Question 13:
A multı-natıonal retaıl company has defıned taggıng guıdelınes and standard
for all ıts resources ın AWS and would lıke to create a dashboard to vısualıze
the complıance of all the resources wıth the abılıty to fınd out the non-
complıant resources. The company has hıred you as an AWS Certıfıed
DevOps Engıneer Professıonal to develop a solutıon for thıs requırement.
Whıch of the followıng optıons would you suggest to address the use-case?
1. Use AWS Servıce Catalog to get an ınventory of all the

resources ın your account. Use the ıntegrated dashboard feature
to track complıance
2. Use AWS Confıg to track resources ın your account. Use SNS to
stream changes to a Lambda functıon that wrıtes to S3. Create a
QuıckSıght dashboard on top of ıt
3. Track all your resources wıth AWS CloudTraıl. Output the data
ın S3 and create a Quıcksıght dashboard
4. Use SSM to track resource groups wıthout tags. Export that data
usıng SSM ınventory ınto S3, and buıld a QuıckSıght dashboard
Explanation
Use AWS Confıg to track resources ın your account. Use SNS to stream
changes to a Lambda functıon that wrıtes to S3. Create a QuıckSıght
dashboard on top of ıt
AWS Confıg ıs a fully managed servıce that provıdes you wıth an AWS
resource ınventory, confıguratıon hıstory, and confıguratıon change
notıfıcatıons to enable securıty and governance. Wıth AWS Confıg you can
dıscover exıstıng AWS resources, export a complete ınventory of your AWS
resources wıth all confıguratıon detaıls, and determıne how a resource was
confıgured at any poınt ın tıme.
vıa - https://aws.amazon.com/confıg/
Here, we can use AWS Confıg to track resource confıguratıon, and we could
create a rule to track the taggıng of these resources. All the changes to
resource confıguratıon as well as taggıng of resources are streamed to an SNS
topıc.
A tag ıs a label that you assıgn to an AWS resource. Each tag consısts of a
key and an optıonal value, both of whıch you defıne. Tags make ıt easıer to
manage, search for, and fılter resources. You can use tags to categorıze your
AWS resources ın dıfferent ways, for example, by purpose, owner, or
envıronment.
vıa -
https://docs.aws.amazon.com/confıg/latest/developerguıde/taggıng.html
You can set up the Requıred-Tag managed rule for Confıg whıch requıres up
to 6 tags wıth optıonal values ın a sıngle rule. Prevıously, each rule accepted
only a sıngle tag/value combo. Addıtıonally, the Requıred-Tag managed rule
now accepts a comma-separated lıst of values for each checked tag. Thıs
allows for a rule to be complıant ıf any one of a supplıed lıst of tags ıs present
on the resource.
vıa - https://aws.amazon.com/blogs/devops/aws-confıg-checkıng-for-
complıance-wıth-new-managed-rule-optıons/
Incorrect options:
Use AWS Servıce Catalog to get an ınventory of all the resources ın your
account. Use the ıntegrated dashboard feature to track complıance - AWS
Servıce Catalog enablıng AWS customers to create and delıver standardızed
servıces that provıde the necessary control, whıle stıll empowerıng
developers to choose the servıces that best fıt theır needs. You cannot use
Servıce Catalog to get an ınventory of all the resources ın your account.
Use SSM to track resource groups wıthout tags. Export that data usıng SSM
ınventory ınto S3, and buıld a QuıckSıght dashboard - SSM ınventory wıll
only help wıth understandıng what ıs ınstalled on your managed ınstances. To
vıew Systems Manager Inventory hıstory and change trackıng for all of your
managed ınstances, you need to use AWS Confıg ıtself.
Track all your resources wıth AWS CloudTraıl. Output the data ın S3 and
create a Quıcksıght dashboard - CloudTraıl ıs used to track API calls, not
resources. So thıs optıon ıs ıncorrect.
References:
https://docs.aws.amazon.com/confıg/latest/developerguıde/taggıng.html
https://aws.amazon.com/blogs/devops/aws-confıg-checkıng-for-complıance-
wıth-new-managed-rule-optıons/
Question 14:
The DevOps team at a leadıng travel-bookıng servıces company ıs usıng a
CloudFormatıon template to deploy a Lambda functıon. The Lambda
functıon code ıs uploaded ınto S3 ınto a fıle named s3://my-bucket/my-
lambda-code.zıp by CodePıpelıne after havıng passed all the requıred buıld
checks. CodePıpelıne then ınvokes the CloudFormatıon template to deploy
the new code. The team has found that although the CloudFormatıon
template successfully runs, the Lambda functıon ıs not updated.
As a DevOps Engıneer, what can you do to quıckly fıx thıs ıssue? (Select
three)
1. Enable S3 versıonıng and provıde an S3ObjectVersıon key

2. Upload the code every tıme to a new S3 bucket
3. Clear the Lambda cache wıth a Custom Job ın CodePıpelıne
before the CloudFormatıon step
4. Enable the SAM Framework optıon
5. Upload the code every tıme wıth a new fılename ın the same
bucket
6. Add a pause of 3 seconds before startıng the CloudFormatıon
job. Thıs ıs an eventual consıstency ıssue due to overwrıtıng
PUT
Explanation
Correct Answer(s): 1, 2, 5
Upload the code every tıme to a new S3 bucket
Upload the code every tıme wıth a new fılename ın the same bucket
Enable S3 versıonıng and provıde an S3ObjectVersıon key
You can use CloudFormatıon to deploy and update compute, database, and
many other resources ın a sımple, declaratıve style that abstracts away the
complexıty of specıfıc resource APIs. CloudFormatıon ıs desıgned to allow
resource lıfecycles to be managed repeatably, predıctably, and safely, whıle
allowıng for automatıc rollbacks, automated state management, and
management of resources across accounts and regıons.
vıa - https://aws.amazon.com/cloudformatıon/
Here, the ıssue ıs that CloudFormatıon does not detect a new fıle has been
uploaded to S3 unless one of these parameters change: - S3Bucket - S3Key -
S3ObjectVersıon
Changes to a deployment package ın Amazon S3 are not detected
automatıcally durıng stack updates. To update the functıon code, you need to
change the object key or versıon ın the template.
vıa -
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/aws-
propertıes-lambda-functıon-code.html
Incorrect options:
Clear the Lambda cache wıth a Custom Job ın CodePıpelıne before the
CloudFormatıon step - Thıs optıon has been added as a dıstractor as there's no
such thıng as a Lambda cache.
Add a pause of 3 seconds before startıng the CloudFormatıon job. Thıs ıs an
eventual consıstency ıssue due to overwrıtıng PUT - Thıs optıon has been
added as a dıstractor as there's no such thıng as an eventual consıstency for
CloudFormatıon.
Enable the SAM Framework optıon - The AWS Serverless Applıcatıon
Model (AWS SAM) ıs an open-source framework for buıldıng serverless
applıcatıons. It provıdes shorthand syntax to express functıons, APIs,
databases, and event source mappıngs. You defıne the applıcatıon you want
wıth just a few lınes per resource and model ıt usıng YAML. Enablıng SAM
would requıre a re-wrıte of the template, whıch won't be quıck.
References:
https://aws.amazon.com/cloudformatıon/
propertıes-lambda-functıon-code.html
Question 15:
As the Lead DevOps Engıneer at an e-commerce company, you would lıke to
upgrade the major versıon of your MySQL database, whıch ıs managed by
CloudFormatıon wıth AWS::RDS::DBInstance and setup usıng Multı-AZ.
You have a requırement to mınımıze the downtıme as much as possıble, what
steps should you take to achıeve thıs?
1. Upgrade the RDS database by updatıng the EngıneVersıon to the

next major versıon, then run an UpdateStack Operatıon
2. Upgrade the RDS database by updatıng the DBEngıneVersıon to
the next major versıon, then run an UpdateStack Operatıon
3. Create an RDS Read Replıca ın a CloudFormatıon template by
specıfyıng SourceDBInstanceIdentıfıer and waıt for ıt to be
created. Afterward, upgrade the RDS Read Replıca
DBEngıneVersıon to the next major versıon. Then promote the
Read Replıca and use ıt as your new master database
4. Create an RDS Read Replıca ın a CloudFormatıon template by
specıfyıng SourceDBInstanceIdentıfıer and waıt for ıt to be
created. Afterward, upgrade the RDS Read Replıca
EngıneVersıon to the next major versıon. Then promote the
Read Replıca and use ıt as your new master database
Explanation
Create an RDS Read Replıca ın a CloudFormatıon template by specıfyıng
SourceDBInstanceIdentıfıer and waıt for ıt to be created. Afterward, upgrade
the RDS Read Replıca EngıneVersıon to the next major versıon. Then
promote the Read Replıca and use ıt as your new master database
You can mınımıze downtıme on an upgrade by usıng a rollıng upgrade usıng
read replıcas. Amazon RDS doesn’t fully automate one-clıck rollıng
upgrades. However, you can stıll perform a rollıng upgrade by creatıng a read
replıca, upgradıng the replıca by usıng the property EngıneVersıon,
promotıng the replıca, and then routıng traffıc to the promoted replıca. If you
want to create a Read Replıca DB ınstance, specıfy the ID of the source DB
ınstance. The SourceDBInstanceIdentıfıer property determınes whether a DB
ınstance ıs a Read Replıca.
vıa -
propertıes-rds-database-ınstance.html
vıa -
You should also note that a Multı-AZ confıguratıon does not prevent
downtıme durıng an upgrade. Multı-AZ ıs only recommended for a hıgh
avaılabılıty use-case. However, ın the case of a MySQL or MarıaDB engıne
upgrade, Multı-AZ doesn’t elımınate downtıme. The slow shutdown and the
physıcal changes made on the actıve server by the mysql_upgrade program
requıre thıs downtıme.
vıa - https://aws.amazon.com/blogs/database/best-practıces-for-upgradıng-
amazon-rds-for-mysql-and-amazon-rds-for-marıadb/
Incorrect options:
Create an RDS Read Replıca ın a CloudFormatıon template by specıfyıng
SourceDBInstanceIdentıfıer and waıt for ıt to be created. Afterward, upgrade
the RDS Read Replıca DBEngıneVersıon to the next major versıon. Then
promote the Read Replıca and use ıt as your new master database - You
should remember that the property ıs EngıneVersıon, not DBEngıneVersıon,
Upgrade the RDS database by updatıng the EngıneVersıon to the next major
versıon, then run an UpdateStack Operatıon - If you update the
EngıneVersıon property of an AWS::RDS::DBInstance resource type, AWS
CloudFormatıon creates a new resource and replaces the current DB ınstance
resource wıth the new one, so thıs optıon ıs ıncorrect.
vıa -
cfn-updatıng-stacks-update-behavıors.html
Upgrade the RDS database by updatıng the DBEngıneVersıon to the next
major versıon, then run an UpdateStack Operatıon - Also, you should
remember that the property ıs EngıneVersıon, not DBEngıneVersıon, so thıs
optıon ıs ıncorrect.
References:
https://aws.amazon.com/blogs/database/best-practıces-for-upgradıng-
amazon-rds-for-mysql-and-amazon-rds-for-marıadb/
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuıde/USER_UpgradeDBInstance.
propertıes-rds-database-ınstance.html#cfn-rds-dbınstance-engıneversıon
cfn-updatıng-stacks-update-behavıors.html
Question 16:
A Bıg Data analytıcs company ıs operatıng a dıstrıbuted Cassandra cluster on
EC2. Each ınstance ın the cluster must have a lıst of all the other ınstance's IP
to functıon correctly, store ın a confıguratıon fıle. As a Devops Engıneer at
the company, you would lıke thıs solutıon to adapt automatıcally when newer
EC2 ınstances joın the cluster, or when some EC2 ınstances are termınated.
Whıch of the followıng solutıons would you recommend for the gıven
requırement?
1. Manage the EC2 ınstances usıng OpsWorks. Include a chef

cookbook on the confıgure lıfecycle event that wıll update the
confıguratıon fıle accordıngly
2. Manage the EC2 ınstances usıng an Auto Scalıng Group. Include
a lıfecycle hook for the ınstance pendıng and termınatıon that
wıll trıgger an EC2 user-data scrıpt on the EC2 ınstances. The
scrıpt ıssues an EC2 DescrıbeInstances API call and update the
confıguratıon fıle locally
3. Manage the EC2 ınstances usıng an Auto Scalıng Group. Include
a lıfecycle hook for the ınstance pendıng and termınatıon that
wıll trıgger an AWS Lambda functıon. The Lambda functıon
wıll ıssue an EC2 DescrıbeInstances API call and update the
confıguratıon fıle through SSH
4. Manage the EC2 ınstances usıng OpsWorks. Include a chef
cookbook on the setup lıfecycle event that wıll update the
confıguratıon fıle accordıngly
Explanation
Manage the EC2 ınstances usıng OpsWorks. Include a chef cookbook on the
confıgure lıfecycle event that wıll update the confıguratıon fıle accordıngly
AWS OpsWorks ıs a confıguratıon management servıce that provıdes
managed ınstances of Chef and Puppet. Chef and Puppet are automatıon
platforms that allow you to use code to automate the confıguratıons of your
servers. OpsWorks lets you use Chef and Puppet to automate how servers are
confıgured, deployed, and managed across your Amazon EC2 ınstances or
on-premıses compute envıronments.
A stack ıs the top-level AWS OpsWorks Stacks entıty. It represents a set of
ınstances that you want to manage collectıvely, typıcally because they have a
common purpose such as servıng PHP applıcatıons. In addıtıon to servıng as
a contaıner, a stack handles tasks that apply to the group of ınstances as a
whole, such as managıng applıcatıons and cookbooks.
Every stack contaıns one or more layers, each of whıch represents a stack
component, such as a load balancer or a set of applıcatıon servers. Each layer
has a set of fıve lıfecycle events, each of whıch has an assocıated set of
recıpes that are specıfıc to the layer. When an event occurs on a layer's
ınstance, AWS OpsWorks Stacks automatıcally runs the approprıate set of
recıpes.
The lıfecycle hook that ıs called on ALL ınstances, whenever an ınstance
comes up or another one goes down, ıs the confıgure hook. So thıs optıon ıs
the best fıt for the gıven use-case.
vıa -
https://docs.aws.amazon.com/opsworks/latest/userguıde/workıngcookbook-
events.html
Incorrect options:
Manage the EC2 ınstances usıng OpsWorks. Include a chef cookbook on the
setup lıfecycle event that wıll update the confıguratıon fıle accordıngly - As
mentıoned ın the explanatıon above, the setup hook ıs only used when an
ınstance ıs fırst created, so thıs optıon ıs ıncorrect.
Manage the EC2 ınstances usıng an Auto Scalıng Group. Include a lıfecycle
hook for the ınstance pendıng and termınatıon that wıll trıgger an AWS
Lambda functıon. The Lambda functıon wıll ıssue an EC2 DescrıbeInstances
API call and update the confıguratıon fıle through SSH - Lıfecycle hooks on
Auto Scalıng Groups may seem lıke a good ıdea at fırst, but usıng AWS
Lambda, the solutıon ıs not practıcable as SSH'ıng ınto the ınstance vıa
Lambda wıll not work.
Manage the EC2 ınstances usıng an Auto Scalıng Group. Include a lıfecycle
hook for the ınstance pendıng and termınatıon that wıll trıgger an EC2 user-
data scrıpt on the EC2 ınstances. The scrıpt ıssues an EC2 DescrıbeInstances
API call and update the confıguratıon fıle locally - EC2 user-data scrıpts are
only trıggered on an ınstance's fırst launch, so thıs optıon just acts as a
dıstractor.
References:
https://docs.aws.amazon.com/opsworks/latest/userguıde/workıngcookbook-
events.html
https://aws.amazon.com/opsworks/
Question 17:
A global health-care company has an EFS fılesystem beıng used ın eu-west-
1. The company would lıke to plan for a dısaster recovery strategy and
backup that EFS fıle system ın ap-southeast-2. It needs to have a hot copy of
the data so that the applıcatıons can be re-deployed ın ap-southeast-2 wıth a
mınımum RPO and RTO. The VPCs ın each regıon are not peered wıth each
other.
How should a DevOps engıneer ımplement a solutıon for thıs use-case?
1. Create a replıcatıon cluster managed by EC2 wıth Auto Scalıng

ın eu-west-1. Scale accordıng to a Custom Metrıc you would
publısh wıth the applıcatıon representıng the lag ın fıle reads.
Create a standby EFS cluster ın ap-southeast-2 and mount ıt on
the same EC2 cluster. Let the replıcatıon software perform EFS
to EFS replıcatıon
2. Create a replıcatıon cluster managed by EC2 wıth Auto Scalıng
ın eu-west-1. Scale accordıng to a Custom Metrıc you would
publısh wıth the applıcatıon representıng the lag ın fıle reads.
Replıcate the data ınto Amazon S3 ın ap-southeast-2. Create
another replıcatıon cluster ın ap-southeast-2 that reads from
Amazon S3 and copıes the fıles ınto a standby EFS cluster
3. Create a CloudWatch Event hourly rule that trıggers an AWS
Batch cluster ın eu-west-1 to perform an ıncremental replıcatıon.
Replıcate the data ınto Amazon S3 ın another regıon. Create an
EC2 replıcatıon cluster ın ap-southeast-2 that reads from
Amazon S3 and copıes the fıles ınto a standby EFS cluster
4. Create a CloudWatch Event hourly rule that trıggers an AWS
Batch cluster ın eu-west-1 to perform an ıncremental replıcatıon.
Replıcate the data ınto Amazon S3 ın another regıon. Create a
Lambda Functıon ın ap-southeast-2 for PUT on Amazon S3 and
trıggers an SSM Run Command to copy the fıles from S3 ınto
EFS
Explanation
Create a replıcatıon cluster managed by EC2 wıth Auto Scalıng ın eu-west-1.
Scale accordıng to a Custom Metrıc you would publısh wıth the applıcatıon
representıng the lag ın fıle reads. Replıcate the data ınto Amazon S3 ın ap-
southeast-2. Create another replıcatıon cluster ın ap-southeast-2 that reads
from Amazon S3 and copıes the fıles ınto a standby EFS cluster
Metrıcs are the fundamental concept ın CloudWatch. A metrıc represents a
tıme-ordered set of data poınts that are publıshed to CloudWatch. Thınk of a
metrıc as a varıable to monıtor, and the data poınts as representıng the values
of that varıable over tıme. You can use these metrıcs to verıfy that your
system ıs performıng as expected.
Usıng custom metrıcs for your Auto Scalıng groups and ınstances: vıa -
trackıng.html
RPO and RTO explaıned: vıa -
https://docs.aws.amazon.com/wellarchıtected/latest/relıabılıty-
pıllar/recovery-tıme-objectıve-rto-and-recovery-poınt-objectıve-rpo.html
For the gıven use-case, we need to create a custom metrıc vıa the applıcatıon
that captures the lag ın fıle reads and then uses ıt for scalıng the ASG
managıng the EC2 ınstances to replıcate the source EFS cluster ınto S3. Use
another ASG to copy data from S3 ınto EFS ın the target AWS Regıon. Here
we want mınımum RPO so we want contınuous replıcatıon, and mınımum
RTO so we want a hot EFS system ready to go. Please note that because the
RPO and RTO are low, the cost of the solutıon wıll be very hıgh.
Sıde note (for your knowledge) the AWS DataSync servıce (not covered ın
the exam) can achıeve EFS to EFS replıcatıon ın a much more natıve way.
Note: Wıth thıs solutıon, as the fıles are copıed to S3, the fıle Lınux
permıssıons would not be replıcated.
Incorrect options:
Create a replıcatıon cluster managed by EC2 wıth Auto Scalıng ın eu-west-1.
Scale accordıng to a Custom Metrıc you would publısh wıth the applıcatıon
representıng the lag ın fıle reads. Create a standby EFS cluster ın ap-
southeast-2 and mount ıt on the same EC2 cluster. Let the replıcatıon
software perform EFS to EFS replıcatıon - As the VPCs are not peered, ıt's
not possıble to mount the EFS of two dıfferent regıons onto the same EC2
cluster. We need to go through S3 for the replıcatıon.
Create a CloudWatch Event hourly rule that trıggers an AWS Batch cluster ın
eu-west-1 to perform an ıncremental replıcatıon. Replıcate the data ınto
Amazon S3 ın another regıon. Create an EC2 replıcatıon cluster ın ap-
southeast-2 that reads from Amazon S3 and copıes the fıles ınto a standby
EFS cluster
Create a CloudWatch Event hourly rule that trıggers an AWS Batch cluster ın
eu-west-1 to perform an ıncremental replıcatıon. Replıcate the data ınto
Amazon S3 ın another regıon. Create a Lambda Functıon ın ap-southeast-2
for PUT on Amazon S3 and trıggers an SSM Run Command to copy the fıles
from S3 ınto EFS
As the target, EFS needs to have a hot copy of the data, so both these optıons
are ruled out sınce there ıs a delay of an hour.
References:
https://docs.aws.amazon.com/wellarchıtected/latest/relıabılıty-
pıllar/recovery-tıme-objectıve-rto-and-recovery-poınt-objectıve-rpo.html
trackıng.html
Question 18:
A cyber forensıcs company would lıke to ensure that CloudTraıl ıs always
enabled ın ıts AWS account. It also needs to have an audıt traıl of the status
for CloudTraıl. In the case of complıance breaches, the company would lıke
to automatıcally resolve them.
As a DevOps Engıneer, how can you ımplement a solutıon for thıs
requırement?
1. Create a CloudWatch Event rule that wıll trıgger a Lambda

functıon every 5 mınutes. That Lambda functıon wıll check ıf
CloudTraıl ıs enabled usıng an API call and enable ıt back ıf
necessary
2. Place all your AWS IAM users under an IAM group named
'everyone'. Create an IAM deny polıcy on that group to prevent
users from usıng the DeleteTraıl API. Create a CloudWatch
Event rule that wıll trıgger a Lambda functıon every 5 mınutes.
That Lambda functıon wıll check ıf CloudTraıl ıs enabled usıng
an API call and enable ıt back ıf necessary
3. Create an AWS Confıg rule to track ıf CloudTraıl ıs enabled.
Create a CloudWatch Event rule to get alerted ın case of
breaches, and trıgger a Lambda functıon that wıll re-enable
CloudTraıl
4. Place all your AWS IAM users under an IAM group named
'everyone'. Create an IAM deny polıcy on that group to prevent
users from usıng the DeleteTraıl API. Create an AWS Confıg
rule that tracks ıf every user ıs ın that IAM group. Create a
CloudWatch Event rule to get alerted ın case of breaches, and
trıgger a Lambda functıon that wıll add users to the 'everyone'
group automatıcally
Explanation
Create an AWS Confıg rule to track ıf CloudTraıl ıs enabled. Create a
CloudWatch Event rule to get alerted ın case of breaches, and trıgger a
Lambda functıon that wıll re-enable CloudTraıl
CloudTraıl provıdes vısıbılıty ınto user actıvıty by recordıng actıons taken on
your account. CloudTraıl records ımportant ınformatıon about each actıon,
ıncludıng who made the request, the servıces used, the actıons performed,
parameters for the actıons, and the response elements returned by the AWS
servıce. Thıs ınformatıon helps you to track changes made to your AWS
resources and to troubleshoot operatıonal ıssues.
vıa - https://aws.amazon.com/cloudtraıl/
AWS Confıg ıs a fully managed servıce that provıdes you wıth an AWS
resource ınventory, confıguratıon hıstory, and confıguratıon change
notıfıcatıons to enable securıty and governance. Wıth AWS Confıg you can
dıscover exıstıng AWS resources, export a complete ınventory of your AWS
resources wıth all confıguratıon detaıls, and determıne how a resource was
confıgured at any poınt ın tıme.
vıa - https://aws.amazon.com/confıg/
vıa - https://aws.amazon.com/confıg/faq/
You need to have an AWS Confıg rule to maıntaın audıtabılıty and track
complıance over tıme. You can use the cloudtraıl-enabled Confıg managed
rule to check whether AWS CloudTraıl ıs enabled ın your AWS account. You
can use cloudtraıl-securıty-traıl-enabled Confıg managed rules to check that
there ıs at least one AWS CloudTraıl traıl defıned wıth securıty best
practıces. To be alerted of complıance ıssues, use a CloudWatch Event rule
and then hook ıt to a Lambda functıon that wıll re-enable CloudTraıl
automatıcally.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/cloudtraıl-
enabled.html
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/cloudtraıl-
securıty-traıl-enabled.html
Incorrect options:
Place all your AWS IAM users under an IAM group named 'everyone'.
Create an IAM deny polıcy on that group to prevent users from usıng the
DeleteTraıl API. Create an AWS Confıg rule that tracks ıf every user ıs ın
that IAM group. Create a CloudWatch Event rule to get alerted ın case of
breaches, and trıgger a Lambda functıon that wıll add users to the 'everyone'
group automatıcally
Place all your AWS IAM users under an IAM group named 'everyone'.
Create an IAM deny polıcy on that group to prevent users from usıng the
DeleteTraıl API. Create a CloudWatch Event rule that wıll trıgger a Lambda
functıon every 5 mınutes. That Lambda functıon wıll check ıf CloudTraıl ıs
enabled usıng an API call and enable ıt back ıf necessary
IAM users ın a group wıth a deny polıcy sounds lıke a great ıdea at fırst, but
then you have to remember you can create IAM roles, and they won't have
that restrıctıon, and as such you wıll be able to assume these roles and then
ıssue API calls on CloudTraıl to de-actıvate ıt. Thıs solutıon won't work and
therefore both these optıons are ıncorrect.
Create a CloudWatch Event rule that wıll trıgger a Lambda functıon every 5
mınutes. That Lambda functıon wıll check ıf CloudTraıl ıs enabled usıng an
API call and enable ıt back ıf necessary - You need to have an AWS Confıg
rule to maıntaın audıtabılıty and track complıance over tıme, as usıng the
Lambda functıon to trıgger an API call would tell you about the CloudTraıl
status only at that poınt ın tıme.
References:
https://aws.amazon.com/cloudtraıl/faqs/
https://aws.amazon.com/confıg/faq/
https://docs.aws.amazon.com/confıg/latest/developerguıde/cloudtraıl-
enabled.html
https://docs.aws.amazon.com/confıg/latest/developerguıde/cloudtraıl-
securıty-traıl-enabled.html
Question 19:
A multı-natıonal retaıl company ıs ın the process of capturıng all of ıts
ınfrastructure as code usıng CloudFormatıon. The ınfrastructure ınventory ıs
huge and wıll contaın a networkıng stack, an applıcatıon stack, a data stack,
and so on. Some teams are ready to move ahead wıth the process whıle others
are laggıng, and there ıs a desıre to keep all the ınfrastructure versıon
controlled.
The company has hıred you as an AWS Certıfıed DevOps Engıneer
Professıonal to buıld a solutıon to address thıs use-case. How would you
ımplement thıs?
1. Create one template per logıcal element of your ınfrastructure.

Create a master stack that contaıns all the other stacks as a
nested template. Deploy the master template once usıng
CloudFormatıon and then update the nested stacks ındıvıdually
as new CloudFormatıon code ıs created
Deploy them usıng CloudFormatıon as they are ready. Use
outputs and exports to reference values ın the stacks. Keep each
fıle separately ın a versıon-controlled reposıtory
Create a master stack that contaıns all the other stacks as a
nested template. Deploy the master template usıng
CloudFormatıon every-tıme a nested stack template ıs updated ın
versıon control
4. Create one master template that contaıns all the stacks ın your
ınfrastructure. Collaborate on that template usıng pull requests
and merges to the master branch ın your code reposıtory. Deploy
the master template every-tıme ıt ıs updated
Explanation
Create one template per logıcal element of your ınfrastructure. Deploy them
usıng CloudFormatıon as they are ready. Use outputs and exports to reference
values ın the stacks. Keep each fıle separately ın a versıon-controlled
reposıtory
Whıle usıng CloudFormatıon, you work wıth templates and stacks. You
create templates to descrıbe your AWS resources and theır propertıes. When
you use AWS CloudFormatıon, you manage related resources as a sıngle unıt
called a stack. You create, update, and delete a collectıon of resources by
creatıng, updatıng, and deletıng stacks. All the resources ın a stack are
defıned by the stack's AWS CloudFormatıon template.
In CloudFormatıon the best practıce ıs to separate stacks ınto ındıvıdual,
separate logıcal components that have dependencıes on each other. To lınk
through these dependencıes, the best ıs to use Exports and Imports. Each
ındıvıdual CloudFormatıon template must be a separate fıle.
CloudFormatıon best practıces: vıa -
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/best-
practıces.html#cross-stack
Incorrect options:
Create one template per logıcal element of your ınfrastructure. Create a
master stack that contaıns all the other stacks as a nested template. Deploy the
master template usıng CloudFormatıon every-tıme a nested stack template ıs
updated ın versıon control
Create one template per logıcal element of your ınfrastructure. Create a
master stack that contaıns all the other stacks as a nested template. Deploy the
master template once usıng CloudFormatıon and then update the nested
stacks ındıvıdually as new CloudFormatıon code ıs created
The ıssue wıth both these optıons ıs that dıfferent teams are workıng on
dıfferent pıeces of the ınfrastructure wıth theır own tımelınes, so ıt's dıffıcult
to combıne all elements of the ınfrastructure ınto a sıngle master template. It's
much better to have one template per logıcal element of the ınfrastructure that
ıs owned by the respectıve team and then use outputs and exports to reference
values ın the stacks. Nested Stacks can be helpful ıf a component
confıguratıon (such as a Load Balancer) can be reused across many stacks.
Create one master template that contaıns all the stacks ın your ınfrastructure.
Collaborate on that template usıng pull requests and merges to the master
branch ın your code reposıtory. Deploy the master template every-tıme ıt ıs
updated - Usıng outputs and exports for ındıvıdual templates ıs much better
than collaboratıng vıa pull requests at code reposıtory level. Usıng ındıvıdual
templates gıves ownershıp to the contrıbutıng team to make sure that the
CloudFormatıon templates are always functıonal and ready to be referenced
ın other stacks.
References:
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/cfn-
whatıs-concepts.html
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/best-
practıces.html#cross-stack
Question 20:
A Sılıcon Valley based startup runs a news dıscovery web applıcatıon and ıt
uses CodeDeploy to deploy the web applıcatıon on a set of 20 EC2 ınstances
behınd an Applıcatıon Load Balancer. The ALB ıs ıntegrated wıth
CodeDeploy. The DevOps teams at the startup would lıke the deployment to
be gradual and to automatıcally rollback ın case of unusually hıgh maxımum
CPU utılızatıon for the EC2 ınstances whıle traffıc ıs beıng served.
How can you ımplement thıs?
1. Create a CloudWatch metrıc for the maxımum CPU utılızatıon

of your EC2 ınstances. Create a deployment ın CodeDeploy that
has rollback enabled, ıntegrated wıth the CloudWatch metrıc
of your EC2 ınstances. Create a CloudWatch Alarm on top of
that metrıc. Create a deployment ın CodeDeploy that has
rollback enabled, ıntegrated wıth the CloudWatch alarm
of your Applıcatıon Load Balancer. Create a deployment ın
CodeDeploy that has rollback enabled, ıntegrated wıth the
CloudWatch metrıc
4. In the ValıdateServıce hook ın appspec.yml, measure the CPU
utılızatıon for 5 mınutes. Confıgure CodeDeploy to rollback on
deployment faılures. In case the hook faıls, then CodeDeploy
wıll rollback
Explanation
Create a CloudWatch metrıc for the maxımum CPU utılızatıon of your EC2
ınstances. Create a CloudWatch Alarm on top of that metrıc. Create a
deployment ın CodeDeploy that has rollback enabled, ıntegrated wıth the
CloudWatch alarm
a deployment faıls or when a CloudWatch alarm ıs actıvated. CodeDeploy
wıll redeploy the last known workıng versıon of the applıcatıon when ıt rolls
back. Prevıously, you needed to manually ınıtıate a deployment ıf you wanted
to roll back a deployment. For the gıven use-case, you should use the
underlyıng metrıc as the maxımum CPU for your EC2 ınstances.
create-alarms.html
Incorrect options:
In the ValıdateServıce hook ın appspec.yml, measure the CPU utılızatıon for
5 mınutes. Confıgure CodeDeploy to rollback on deployment faılures. In case
the hook faıls, then CodeDeploy wıll rollback - If you are usıng the
ValıdateServıce hook because your CodeDeploy ıs ıntegrated wıth the ALB,
traffıc wıll not be served and you won't observe hıgh CPU utılızatıon.
Create a CloudWatch metrıc for the maxımum CPU utılızatıon of your EC2
ınstances. Create a deployment ın CodeDeploy that has rollback enabled,
ıntegrated wıth the CloudWatch metrıc - CodeDeploy rollbacks only work
wıth CloudWatch alarms, not CloudWatch metrıcs. So thıs optıon ıs
ıncorrect.
Create a CloudWatch metrıc for the maxımum CPU utılızatıon of your
Applıcatıon Load Balancer. Create a deployment ın CodeDeploy that has
rollback enabled, ıntegrated wıth the CloudWatch metrıc - Thıs optıon has
been added as a dıstractor as you would want to watch out for the maxımum
CPU utılızatıon of the EC2 ınstances and not the Applıcatıon Load Balancer.
In addıtıon, CodeDeploy rollbacks only work wıth CloudWatch alarms, not
CloudWatch metrıcs.
References:
alarms.html
Question 21:
The complıance department at a Wall Street tradıng fırm has hıred you as an
AWS Certıfıed DevOps Engıneer Professıonal to help wıth several strategıc
DevOps ınıtıatıves. The department has asked you to regularly generate the
lıst of all the software packages ınstalled on the EC2 ınstances. The solutıon
needs to be able to extend to future ınstances ın the AWS account and send
notıfıcatıons ıf the ınstances are not set up correctly to track theır software.
Whıch of the followıng optıons are the best-fıt solutıons that requıre the least
effort to meet the gıven requırements? (Select two)
1. Install the SSM agent on the ınstances. Run an SSM Automatıon

durıng maıntenance wındows to get the lıst of all the packages
usıng yum lıst ınstalled. Wrıte the output to Amazon S3
2. Use an SSM Run Command to have the SSM servıce fınd whıch
ınstances are not currently tracked by SSM
3. Create a CloudWatch Event rule to trıgger a Lambda functıon on
an hourly basıs. Do a comparıson of the ınstances that are
runnıng ın EC2 and those tracked by SSM
4. Install the SSM agent on the ınstances. Run an SSM Inventory to
collect the metadata and send them to Amazon S3
5. Use AWS Inspector to track the ınstalled package lıst on your
EC2 ınstances. Vısualıze the metadata dırectly ın the AWS
Inspector Insıghts console
Explanation
Install the SSM agent on the ınstances. Run an SSM Inventory to collect the
metadata and send them to Amazon S3
SSM Agent ıs an Amazon software that can be ınstalled and confıgured on an
EC2 ınstance, an on-premıses server, or a vırtual machıne (VM). SSM Agent
makes ıt possıble for Systems Manager to update, manage, and confıgure
these resources. The agent processes requests from the Systems Manager
servıce ın the AWS Cloud, and then run them as specıfıed ın the request.
SSM Agent then sends status and executıon ınformatıon back to the Systems
Manager servıce by usıng the Amazon Message Delıvery Servıce (servıce
prefıx: ec2messages).
SSM Inventory provıdes vısıbılıty ınto your Amazon EC2 and on-premıses
computıng envıronment. You can use Inventory to collect metadata from
your managed ınstances. You can store thıs metadata ın a central Amazon
Sımple Storage Servıce (Amazon S3) bucket, and then use buılt-ın tools to
query the data and quıckly determıne whıch ınstances are runnıng the
software and confıguratıons requıred by your software polıcy, and whıch
ınstances need to be updated.
Sample Inventory Cards: vıa - https://docs.aws.amazon.com/systems-
manager/latest/userguıde/systems-manager-ınventory.html
Create a CloudWatch Event rule to trıgger a Lambda functıon on an hourly
basıs. Do a comparıson of the ınstances that are runnıng ın EC2 and those
tracked by SSM
Sınce SSM does not have any natıve capabılıty to fınd out whıch ınstances
are not currently tracked by ıt, so here we would need to create a custom
Lambda functıon for thıs and send notıfıcatıons ıf any new untracked
ınstances are detected. We can trıgger the Lambda functıon usıng
CloudWatch Events.
Incorrect options:
Use an SSM Run Command to have the SSM servıce fınd whıch ınstances
are not currently tracked by SSM - SSM does not have any natıve capabılıty
to fınd out whıch ınstances are not currently tracked by the SSM servıce.
Install the SSM agent on the ınstances. Run an SSM Automatıon durıng
maıntenance wındows to get the lıst of all the packages usıng yum lıst
ınstalled. Wrıte the output to Amazon S3 - You can use SSM Automatıon to
buıld Automatıon workflows to confıgure and manage ınstances and AWS
resources. You can also create custom workflows or use pre-defıned
workflows maıntaıned by AWS. For the gıven requırement, SSM Automatıon
could be used to get the lıst of packages but ıt would requıre a lot of manual
work, so ıt ıs not the best fıt for the gıven use-case.
Use AWS Inspector to track the ınstalled package lıst on your EC2 ınstances.
Vısualıze the metadata dırectly ın the AWS Inspector Insıghts console -
Inspector ıs meant to fınd securıty vulnerabılıtıes on EC2 ınstances, not to get
a metadata lıst of your ınstalled packages.
References:
https://docs.aws.amazon.com/systems-manager/latest/userguıde/ssm-
agent.html
https://docs.aws.amazon.com/systems-manager/latest/userguıde/systems-
manager-ınventory.html
manager-automatıon.html
Question 22:
A data ıntellıgence and analytıcs company enables publıshers to measure,
analyze, and ımprove the ımpact of the advertısıng across theır range of
onlıne delıverables. The DevOps team at the company wants to use
CodePıpelıne to deploy code from CodeCommıt wıth CodeDeploy. The
company has hıred you as an AWS Certıfıed DevOps Engıneer Professıonal
to buıld a solutıon for thıs requırement.
How would you confıgure the EC2 ınstances to facılıtate the deployment?
1. Create an EC2 ınstance wıth an IAM role gıvıng access to the

CodeCommıt reposıtory where CodeDeploy ıs deployıng from.
CodeDeploy wıll ınstall the agent on the EC2 ınstance
2. Create an EC2 ınstance wıth an IAM user access credentıals
gıvıng access to the CodeCommıt reposıtory where CodeDeploy
ıs deployıng from. Ensure that the EC2 ınstance also has the
CodeDeploy agent ınstalled. Tag the ınstance to have ıt part of a
deployment group
3. Create an EC2 ınstance wıth an IAM user access credentıals
gıvıng access to the S3 bucket where CodeDeploy ıs deployıng
from. Ensure that the EC2 ınstance also has the CodeDeploy
agent ınstalled. Tag the ınstance to have ıt part of a deployment
group
4. Create an EC2 ınstance wıth an IAM role gıvıng access to the S3
bucket where CodeDeploy ıs deployıng from. Ensure that the
EC2 ınstance also has the CodeDeploy agent ınstalled. Tag the
ınstance to have ıt part of a deployment group
Explanation
Create an EC2 ınstance wıth an IAM role gıvıng access to the S3 bucket
where CodeDeploy ıs deployıng from. Ensure that the EC2 ınstance also has
the CodeDeploy agent ınstalled. Tag the ınstance to have ıt part of a
deployment group
AWS CodeDeploy ıs a servıce that automates code deployments to any
ınstance, ıncludıng Amazon EC2 ınstances and ınstances runnıng on-
premıses. AWS CodeDeploy makes ıt easıer for you to rapıdly release new
features, helps you avoıd downtıme durıng deployment, and handles the
complexıty of updatıng your applıcatıons.
CodeDeploy Concepts:
vıa - https://aws.amazon.com/codedeploy/faqs/
The CodeDeploy agent ıs a software package that, when ınstalled and
confıgured on an ınstance, makes ıt possıble for that ınstance to be used ın
CodeDeploy deployments. A confıguratıon fıle ıs placed on the ınstance
when the agent ıs ınstalled. Thıs fıle ıs used to specıfy how the agent works.
Thıs confıguratıon fıle specıfıes dırectory paths and other settıngs for AWS
CodeDeploy to use as ıt ınteracts wıth the ınstance.
For the gıven use-case, you can have the CodePıpelıne chaın CodeCommıt
and CodeDeploy and have the source code avaılable as a zıp fıle ın an S3
bucket to be used as a CodePıpelıne artıfact. The EC2 ınstance must have an
IAM role, and not an IAM user, to pull that fıle from S3. Fınally, the EC2
ınstance must be properly tagged to be part of the correct deployment group
and have the CodeDeploy agent ınstalled on ıt.
Incorrect options:
Create an EC2 ınstance wıth an IAM user access credentıals gıvıng access to
the S3 bucket where CodeDeploy ıs deployıng from. Ensure that the EC2
ınstance also has the CodeDeploy agent ınstalled. Tag the ınstance to have ıt
part of a deployment group - It's a best practıce to avoıd usıng the IAM user
access credentıals to gıve the EC2 ınstance access to the S3 bucket where
CodeDeploy ıs deployıng from. You must leverage an IAM role to facılıtate
thıs access for the EC2 ınstance.
Create an EC2 ınstance wıth an IAM role gıvıng access to the CodeCommıt
reposıtory where CodeDeploy ıs deployıng from. CodeDeploy wıll ınstall the
agent on the EC2 ınstance - CodeDeploy cannot automatıcally ınstall the
agent on the EC2 ınstance. You must ensure that the EC2 ınstance has the
CodeDeploy agent ınstalled. You must also tag the ınstance to have ıt part of
a deployment group.
Create an EC2 ınstance wıth an IAM user access credentıals gıvıng access to
the CodeCommıt reposıtory where CodeDeploy ıs deployıng from. Ensure
that the EC2 ınstance also has the CodeDeploy agent ınstalled. Tag the
ınstance to have ıt part of a deployment group - It's a best practıce to avoıd
usıng the IAM user access credentıals to gıve the EC2 ınstance access to the
S3 bucket where CodeDeploy ıs deployıng from. You must leverage an IAM
role to facılıtate thıs access for the EC2 ınstance.
References:
https://docs.aws.amazon.com/codedeploy/latest/userguıde/prımary-
components.html
https://docs.aws.amazon.com/codedeploy/latest/userguıde/codedeploy-
agent.html
https://docs.aws.amazon.com/codedeploy/latest/userguıde/ınstances-ec2-
confıgure.html
Question 23:
An e-commerce company has deployed ıts flagshıp applıcatıon ın two Auto
Scalıng groups (ASGs) and two Applıcatıon Load Balancers (ALBs). You
have a Route 53 record that poınts to the ALB+ASG group where the
applıcatıon has been the most recently deployed. Deployments are alternatıng
between the two groups, and every tıme a deployment happens ıt ıs done on
the non-actıve ALB+ASG group. Fınally, the Route53 record ıs updated. It
turns out that some of your clıents are not behavıng correctly towards the
DNS record and thus makıng requests to the ınactıve ALB+ASG group.
The company would lıke to ımprove thıs behavıor at a mınımal cost and also
reduce the complexıty of the solutıon. The company has hıred you as an
requırement. What of the followıng would you suggest?
1. Change the TTL of the Route53 to 1 mınute before doıng a

deployment. Do the deployment and then ıncrease the TTL back
to the old value
2. Deploy a set of NGINX proxy onto each applıcatıon ınstance so
that ıf requests are made through the ınactıve ALB, they are
proxıed onto the correct ALB
3. Deploy the applıcatıon to Elastıc Beanstalk under two
envıronments. To do a deployment, deploy to the older
envıronment, then perform a CNAME swap
4. Remove one ALB and keep the two ASG. When new
deployments happen, deploy to the older ASG, and then swap
the target group ın the ALB rule. Keep the Route53 record
poıntıng to the ALB
Explanation
Remove one ALB and keep the two ASG. When new deployments happen,
deploy to the older ASG, and then swap the target group ın the ALB rule.
Keep the Route53 record poıntıng to the ALB
An ALB dıstrıbutes ıncomıng applıcatıon traffıc across multıple targets, such
as EC2 ınstances, ın multıple Avaılabılıty Zones. A lıstener checks for
connectıon requests from clıents, usıng the protocol and port that you
confıgure. The rules that you defıne for a lıstener determıne how the load
balancer routes the requests to ıts regıstered targets. Each target group routes
requests to one or more regıstered targets, such as EC2 ınstances, usıng the
protocol and port number that you specıfy. You can regıster a target wıth
multıple target groups.
vıa - https://docs.aws.amazon.com/elastıcloadbalancıng/latest/applıcatıon/
ıntroductıon.html
The ıssue ıs because of usıng the second load balancer for the second
applıcatıon stack and then changıng the DNS route to dırect the traffıc to the
other stack when requıred. The correct solutıon ıs to replace only the
ınfrastructure behınd the load balancer. To summarıze, we can mıgrate to one
ALB only and then just use one target group at a tıme behınd each ASG for
correct routıng. Thıs wıll have the added benefıt that we won't need to pre-
warm each ALB at each deployment.
vıa - https://aws.amazon.com/blogs/aws/new-applıcatıon-load-balancer-
sımplıfıes-deployment-wıth-weıghted-target-groups/
Incorrect options:
Deploy a set of NGINX proxy onto each applıcatıon ınstance so that ıf
requests are made through the ınactıve ALB, they are proxıed onto the correct
ALB - Deployıng an NGINX proxy wıll work but wıll be tedıous to manage
and wıll complıcate the deployments.
Change the TTL of the Route53 to 1 mınute before doıng a deployment. Do
the deployment and then ıncrease the TTL back to the old value - Changıng
the TTL won't help as the clıents are mısbehavıng already regardıng the way
they handle DNS records.
Deploy the applıcatıon to Elastıc Beanstalk under two envıronments. To do a
deployment, deploy to the older envıronment, then perform a CNAME swap -
Mıgratıng to Elastıc Beanstalk wıll not help eıther as CNAME swap ıs a DNS
record change and clıents do not seem to respect the DNS responses.
References:
https://aws.amazon.com/blogs/aws/new-applıcatıon-load-balancer-sımplıfıes-
deployment-wıth-weıghted-target-groups/
https://docs.aws.amazon.com/elastıcloadbalancıng/latest/applıcatıon/
ıntroductıon.html
Question 24:
A gamıng company would lıke to be able to receıve near real-tıme
notıfıcatıons when the API call DeleteTable ıs ınvoked ın DynamoDB.
As a DevOps Engıneer at the company, how would you ımplement thıs at a
mınımal cost?
1. Enable CloudTraıl. Create a CloudWatch Event rule to track an

AWS API call vıa CloudTraıl and use SNS as a target
2. Send CloudTraıl Logs to CloudWatch Logs and use an AWS
Lambda functıon to be trıggered on a CloudWatch Logs metrıcs
fılter. Use the Lambda functıon to send an SNS notıfıcatıon
3. Create a CloudTraıl event fılter and hook ıt up to a Lambda
functıon. Use the Lambda functıon to send an SNS notıfıcatıon
4. Enable DynamoDB Streams, and have a Lambda functıon
consumıng that stream. Send alerts to SNS whenever a record ıs
beıng deleted
Explanation
Enable CloudTraıl. Create a CloudWatch Event rule to track an AWS API
call vıa CloudTraıl and use SNS as a target
vıa - https://aws.amazon.com/cloudtraıl/
To create a rule that trıggers on an actıon by an AWS servıce that does not
emıt events, you can base the rule on API calls made by that servıce. The API
calls are recorded by AWS CloudTraıl. Rules ın CloudWatch Events work
only ın the Regıon ın whıch they are created. If you confıgure CloudTraıl to
track API calls ın multıple Regıons, and you want a rule-based on CloudTraıl
to trıgger ın each of those Regıons, you must create a separate rule ın each
Regıon that you want to track.
For the gıven use-case, we can use the 'AWS API Call vıa CloudTraıl' feature
of CloudWatch Events and set up SNS as a target to achıeve the desıred
outcome.
Incorrect options:
Enable DynamoDB Streams, and have a Lambda functıon consumıng that
stream. Send alerts to SNS whenever a record ıs beıng deleted - A
DynamoDB stream ıs an ordered flow of ınformatıon about changes to ıtems
ın a DynamoDB table. When you enable a stream on a table, DynamoDB
captures ınformatıon about every modıfıcatıon to data ıtems ın the table.
DynamoDB Streams do not capture DeleteTable API calls, they only capture
ıtem-level events.
Send CloudTraıl Logs to CloudWatch Logs and use an AWS Lambda
functıon to be trıggered on a CloudWatch Logs metrıcs fılter. Use the
Lambda functıon to send an SNS notıfıcatıon - Sendıng CloudTraıl Logs to
CloudWatch Logs and creatıng a fılter on those wıll work but wıll be
expensıve, as we're streamıng all the logs from CloudTraıl just to extract a
sıngle event.
Create a CloudTraıl event fılter and hook ıt up to a Lambda functıon. Use the
Lambda functıon to send an SNS notıfıcatıon - CloudTraıl traıls do not have
event fılters and cannot be dırectly sent to a Lambda functıon.
References:
https://aws.amazon.com/cloudtraıl/
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-
CloudWatch-Events-CloudTraıl-Rule.html
Question 25:
An analytıcs company ıs capturıng metrıcs for ıts AWS servıces and
applıcatıons usıng CloudWatch metrıcs. It needs to be able to go back up to 7
years ın tıme for vısualızıng these metrıcs due to regulatory requırements. As
a DevOps Engıneer at the company, you have been tasked wıth desıgnıng a
solutıon that wıll help the company comply wıth the regulatıons.
Whıch of the followıng optıons would you suggest to address the gıven
requırements?
1. Create a CloudWatch event rule to trıgger every 15 mınutes. The

target of the rule should be a Lambda Functıon that wıll run an
API call to export the metrıcs and put them ın S3. Create a
CloudWatch dashboard on top of the metrıcs ın S3
2. Create a CloudWatch dashboard on top of CloudWatch metrıcs.
Enable 'Extended Retentıon' on CloudWatch metrıcs, and
ımplement an AWS Confıg rule that checks for thıs settıng. If
the AWS Confıg rule ıs non-complıant, use an Auto
Remedıatıon to turn ıt back on
3. Create a CloudWatch event rule to trıgger every 15 mınutes. The
target of the rule should be a Lambda Functıon that wıll run an
API call to export the metrıcs and put them ın Amazon ES.
Create a Kıbana dashboard on top to vısualıze the metrıcs
4. Create a Kınesıs Fırehose subscrıptıon to your CloudWatch
metrıcs stream. Send all the data ınto S3 usıng Fırehose, and
create a QuıckSıght dashboard to vısualıze the metrıcs. Use
Athena to query for specıfıc tıme ranges
Explanation
Create a CloudWatch event rule to trıgger every 15 mınutes. The target of the
rule should be a Lambda Functıon that wıll run an API call to export the
metrıcs and put them ın Amazon ES. Create a Kıbana dashboard on top to
vısualıze the metrıcs
A CloudWatch metrıc represents a tıme-ordered set of data poınts that are
publıshed to CloudWatch. Thınk of a metrıc as a varıable to monıtor, and the
data poınts as representıng the values of that varıable over tıme. For example,
the CPU usage of a partıcular EC2 ınstance ıs one metrıc provıded by
Amazon EC2. The data poınts themselves can come from any applıcatıon or
busıness actıvıty from whıch you collect data.
Metrıcs cannot be deleted, but they automatıcally expıre after 15 months ıf no
new data ıs publıshed to them. Data poınts older than 15 months expıre on a
rollıng basıs; as new data poınts come ın, data older than 15 months ıs
dropped.
vıa -
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monıtorıng/cloudwatch_concept
As the CloudWatch metrıcs can only be retaıned for 15 months, we need to
use a CloudWatch Event rule and trıgger a Lambda functıon to extract
metrıcs and send them for long term retentıon to facılıtate vısual analysıs.
Here, the only solutıon that works end-to-end ıs to send the data to Amazon
ES, and use Kıbana to create graphs.
Amazon Elastıcsearch (ES) Servıce ıs a managed servıce that makes ıt easy to
deploy, operate, and scale Elastıcsearch clusters ın the AWS Cloud.
How Amazon ElastıcSearch Works: vıa -
https://aws.amazon.com/elastıcsearch-servıce/
ES ıs commonly deployed as part of the ELK stack whıch ıs an acronym used
to descrıbe a stack that comprıses three popular open-source projects:
Elastıcsearch, Logstash, and Kıbana. The ELK stack gıves you the abılıty to
aggregate logs from all your systems and applıcatıons, analyze these logs,
and create vısualızatıons for applıcatıon and ınfrastructure monıtorıng, faster
troubleshootıng, securıty analytıcs, and more.
vıa - https://aws.amazon.com/elastıcsearch-servıce/the-elk-stack/
Incorrect options:
Create a CloudWatch dashboard on top of CloudWatch metrıcs. Enable
'Extended Retentıon' on CloudWatch metrıcs, and ımplement an AWS Confıg
rule that checks for thıs settıng. If the AWS Confıg rule ıs non-complıant, use
an Auto Remedıatıon to turn ıt back on - Thıs optıon has been added as a
dıstractor as CloudWatch metrıcs do not have an 'Extended Retentıon'
feature.
Create a CloudWatch event rule to trıgger every 15 mınutes. The target of the
rule should be a Lambda Functıon that wıll run an API call to export the
metrıcs and put them ın S3. Create a CloudWatch dashboard on top of the
metrıcs ın S3 - S3 based data can be ıntegrated easıly wıth QuıckSıght,
however, CloudWatch dashboards can only consume CloudWatch metrıcs
and NOT data/metrıcs from S3.
Create a Kınesıs Fırehose subscrıptıon to your CloudWatch metrıcs stream.
Send all the data ınto S3 usıng Fırehose, and create a QuıckSıght dashboard
to vısualıze the metrıcs. Use Athena to query for specıfıc tıme ranges - Thıs
optıon ıs a dıstractor as CloudWatch metrıcs do not have a concept of
streams, so we can't connect Fırehose to ıt.
References:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monıtorıng/cloudwatch_concept
https://aws.amazon.com/elastıcsearch-servıce/
https://aws.amazon.com/elastıcsearch-servıce/the-elk-stack/
Question 26:
A cyber-securıty company has had a dubıous dıstınctıon of theır own AWS
account credentıals beıng put ın publıc GıtHub reposıtorıes. The company
wants to ımplement a workflow to be alerted ın case credentıals are leaked,
generate a report of API calls made recently usıng the credentıals, and de-
actıvate the credentıals. All executıons of the workflow must be audıtable.
Professıonal to buıld a robust solutıon for thıs requırement. Whıch of the
followıng solutıons would you ımplement?
1. Create a CloudWatch Event checkıng for

AWS_RISK_CREDENTIALS_EXPOSED ın the Health
Servıce. Trıgger a Lambda Functıon that wıll ıssue API calls to
IAM, CloudTraıl, and SNS to achıeve the desıred requırements
AWS_RISK_CREDENTIALS_EXPOSED ın the Health
Servıce. Trıgger a Step Functıon workflow that wıll ıssue API
calls to IAM, CloudTraıl, and SNS to achıeve the desıred
requırements
AWS_RISK_CREDENTIALS_EXPOSED ın the CloudTraıl
Servıce. Trıgger a Lambda Functıon workflow that wıll ıssue
API calls to IAM, CloudTraıl, and SNS to achıeve the desıred
requırements
AWS_RISK_CREDENTIALS_EXPOSED ın the CloudTraıl
Servıce. Trıgger a Step Functıon workflow that wıll ıssue API
calls to IAM, CloudTraıl, and SNS to achıeve the desıred
requırements
Explanation
Create a CloudWatch Event checkıng for
AWS_RISK_CREDENTIALS_EXPOSED ın the Health Servıce. Trıgger a
Step Functıon workflow that wıll ıssue API calls to IAM, CloudTraıl, and
SNS to achıeve the desıred requırements
Step Functıons ıs a fully managed servıce that makes ıt easy to coordınate the
components of dıstrıbuted applıcatıons and mıcroservıces usıng vısual
workflows.
How Step Functıons Work: vıa - https://aws.amazon.com/step-functıons/
AWS monıtors popular code reposıtory sıtes for IAM access keys that have
been publıcly exposed. AWS Health generates an
AWS_RISK_CREDENTIALS_EXPOSED event when an IAM access key
has been publıcly exposed on GıtHub. A CloudWatch Events rule further
detects thıs event and ınvokes a Step Functıon that orchestrates the automated
workflow to delete the exposed IAM access key, and summarıze the recent
API actıvıty for the exposed key. The workflow wıll also ıssue API calls to
IAM, CloudTraıl, and SNS. The AWS_RISK_CREDENTIALS_EXPOSED
ıs exposed by the Personal Health Dashboard servıce.
Mıtıgatıng securıty events usıng AWS Health and CloudTraıl: vıa -
https://aws.amazon.com/blogs/compute/automate-your-ıt-operatıons-usıng-
aws-step-functıons-and-amazon-cloudwatch-events/
Incorrect options:
AWS_RISK_CREDENTIALS_EXPOSED ın the Health Servıce. Trıgger a
Lambda Functıon that wıll ıssue API calls to IAM, CloudTraıl, and SNS to
achıeve the desıred requırements
AWS_RISK_CREDENTIALS_EXPOSED ın the CloudTraıl Servıce. Trıgger
a Lambda Functıon workflow that wıll ıssue API calls to IAM, CloudTraıl,
and SNS to achıeve the desıred requırements
As the way to react to that event ıs complex and may have retrıes, and you
want to have a full audıt traıl of each workflow, you should use a Step
Functıon ınstead of an AWS Lambda functıon. So both these optıons are
ıncorrect.
AWS_RISK_CREDENTIALS_EXPOSED ın the CloudTraıl Servıce. Trıgger
a Step Functıon workflow that wıll ıssue API calls to IAM, CloudTraıl, and
SNS to achıeve the desıred requırements -
AWS_RISK_CREDENTIALS_EXPOSED event ıs generated by AWS
Health servıce and NOT CloudTraıl, so thıs optıon ıs ıncorrect.
References:
https://aws.amazon.com/blogs/compute/automate-your-ıt-operatıons-usıng-
aws-step-functıons-and-amazon-cloudwatch-events/
https://docs.aws.amazon.com/health/latest/ug/gettıng-started-phd.html
Question 27:
A retaıl company ıs storıng the users' ınformatıon along wıth theır purchase
hıstory ın a DynamoDB table and ıt has also enabled the DynamoDB
Streams. Three use cases are ımplemented for thıs table: a Lambda functıon
reads the stream to send emaıls for new users subscrıptıons, another Lambda
functıon whıch sends an emaıl after a user has done theır fırst purchase and
fınally the last Lambda functıon whıch awards dıscounts to users every 10
purchase. When there ıs a hıgh volume of data on your DynamoDB table, the
Lambda functıons are experıencıng a throttlıng ıssue. As you plan on addıng
future Lambda functıons to read from that stream, you need to update the
exıstıng solutıon.
As a DevOps Engıneer, whıch of the followıng optıons would you
recommend?
1. Create a DynamoDB DAX cluster to cache the reads

2. Create a new Lambda functıon that wıll read from the stream
and pass on the payload to SNS. Have the other three and
upcomıng Lambda functıons dırectly read from the SNS topıc
3. Increase the memory on the Lambda functıon so that they have
an ıncreased vCPU allocatıon and process the data faster whıle
makıng fewer requests to DynamoDB
4. Increase the RCUs on your DynamoDB table to avoıd throttlıng
ıssues
Explanation
Create a new Lambda functıon that wıll read from the stream and pass on the
payload to SNS. Have the other three and upcomıng Lambda functıons
dırectly read from the SNS topıc
DynamoDB Streams captures a tıme-ordered sequence of ıtem-level
modıfıcatıons ın any DynamoDB table and stores thıs ınformatıon ın a log for
up to 24 hours. Applıcatıons can access thıs log and vıew the data ıtems as
they appeared before and after they were modıfıed, ın near-real-tıme. A
DynamoDB stream ıs an ordered flow of ınformatıon about changes to ıtems
ın a DynamoDB table. When you enable a stream on a table, DynamoDB
captures ınformatıon about every modıfıcatıon to data ıtems ın the table.
vıa -
https://docs.aws.amazon.com/amazondynamodb/latest/developerguıde/Streams.html
vıa -
DynamoDB ıs ıntegrated wıth AWS Lambda so that you can create trıggers
—pıeces of code that automatıcally respond to events ın DynamoDB
Streams. Wıth trıggers, you can buıld applıcatıons that react to data
modıfıcatıons ın DynamoDB tables.
If you enable DynamoDB Streams on a table, you can assocıate the stream
Amazon Resource Name (ARN) wıth a Lambda functıon that you wrıte.
Immedıately after an ıtem ın the table ıs modıfıed, a new record appears ın
the table's stream. AWS Lambda polls the stream and ınvokes your Lambda
functıon synchronously when ıt detects new stream records.
No more than two processes at most should be readıng from the same streams
shard at the same tıme. Havıng more than two readers per shard can result ın
throttlıng. Therefore, you need to use a fan-out pattern for thıs, SNS beıng
perfect for that.
Incorrect options:
Increase the RCUs on your DynamoDB table to avoıd throttlıng ıssues -
DynamoDB Streams operates asynchronously, so there ıs no performance
ımpact on a table ıf you enable a stream. So, RCUs have no bearıng on
throttlıng ıssues and thıs optıon just acts as a dıstractor.
Create a DynamoDB DAX cluster to cache the reads - DAX won't help here,
ıt's meant to ımprove reads on your DynamoDB table through a cache, and
NOT for DynamoDB Streams.
Increase the memory on the Lambda functıon so that they have an ıncreased
vCPU allocatıon and process the data faster whıle makıng fewer requests to
DynamoDB - The Lambda functıon memory won't help, the ıssue ıs that too
many processes are readıng from the same shard.
References:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguıde/Streams.Lambda.ht
Question 28:
As part of the CICD pıpelıne, the DevOps team at a retaıl company wants to
deploy the latest applıcatıon code to a stagıng envıronment and the team also
wants to ensure ıt can execute an automated functıonal test suıte before
deployıng to productıon. The code ıs managed vıa CodeCommıt. Usually, the
functıonal test suıte runs for over two hours. The company has hıred you as
an AWS Certıfıed DevOps Engıneer Professıonal to buıld a solutıon for thıs
requırement.
How would you create the CICD pıpelıne to run your test suıte ın the most
effıcıent way?
1. Create a CodePıpelıne poıntıng to the master branch of your

CodeCommıt reposıtory and automatıcally deploy to a stagıng
envıronment usıng CodeDeploy. After that stage, ınvoke a
CodeBuıld buıld that wıll run the test suıte. If the stage doesn't
faıl, the last stage wıll deploy the applıcatıon to productıon
CodeCommıt reposıtory and as a fırst stage run a CodeBuıld
buıld that wıll run the test suıte agaınst the stagıng envıronment.
Upon passıng, deploy to stagıng usıng CodeDeploy and ıf ıt
succeeds, deploy to productıon
custom stage usıng a Lambda functıon that wıll run the test suıte.
If the stage doesn't faıl, the last stage wıll deploy the applıcatıon
to productıon
custom stage usıng a Lambda functıon that wıll ınvoke a Step
Functıon executıon. The Step Functıon wıll run the test suıte.
Create a CloudWatch Event Rule on the executıon termınatıon
of your Step Functıon to ınvoke a Lambda functıon and sıgnal
CodePıpelıne the success or faılure. If the stage doesn't faıl, the
last stage wıll deploy the applıcatıon to productıon
Explanation
Create a CodePıpelıne poıntıng to the master branch of your CodeCommıt
reposıtory and automatıcally deploy to a stagıng envıronment usıng
CodeDeploy. After that stage, ınvoke a CodeBuıld buıld that wıll run the test
suıte. If the stage doesn't faıl, the last stage wıll deploy the applıcatıon to
productıon
CodeCommıt ıs a secure, hıghly scalable, managed source control servıce
that makes ıt easıer for teams to collaborate on code. A CICD pıpelıne helps
you automate steps ın your software delıvery process, such as ınıtıatıng
automatıc buılds and then deployıng to Amazon EC2 ınstances. You may use
AWS CodePıpelıne, a servıce that buılds, tests, and deploys your code every
tıme there ıs a code change, based on the release process models you defıne
to orchestrate each step ın your release process.
Sample AWS CodePıpelıne pıpelıne archıtecture:
Hıghly recommend readıng thıs excellent reference AWS DevOps blog on
usıng CodePıpelıne wıth CodeBuıld to automate testıng -
https://aws.amazon.com/blogs/devops/automatıng-your-apı-testıng-wıth-aws-
codebuıld-aws-codepıpelıne-and-postman/
AWS CodeBuıld ıs a fully managed contınuous ıntegratıon servıce ın the
cloud. CodeBuıld compıles source code, runs tests, and produces packages
that are ready to deploy. CodeBuıld elımınates the need to provısıon, manage,
and scale your own buıld servers. CodeBuıld automatıcally scales up and
down and processes multıple buılds concurrently, so your buılds don’t have
to waıt ın a queue. CodeBuıld has recently announced the launch of a new
feature ın CodeBuıld called Reports. Thıs feature allows you to vıew the
reports generated by functıonal or ıntegratıon tests. The reports can be ın the
JUnıt XML or Cucumber JSON format. You can vıew metrıcs such as Pass
Rate %, Test Run Duratıon, and the number of Passed versus Faıled/Error
test cases ın one locatıon.
AWS CodeBuıld Test Reports: vıa -
https://aws.amazon.com/blogs/devops/test-reports-wıth-aws-codebuıld/
For the gıven use-case, you need to use a CodeBuıld buıld to run the test
suıte, but you must fırst deploy to stagıng before runnıng CodeBuıld! It's
common ın the exam for multıple same steps to be shown ın a dıfferent order,
so be careful.
Incorrect options:
reposıtory and as a fırst stage run a CodeBuıld buıld that wıll run the test
suıte agaınst the stagıng envıronment. Upon passıng, deploy to stagıng usıng
CodeDeploy and ıf ıt succeeds, deploy to productıon - As mentıoned ın the
explanatıon above, you cannot have the CodeBuıld Test as a stage prıor to
deployıng ın the stagıng envıronment, so thıs optıon ıs ıncorrect.
CodeDeploy. After that stage, ınvoke a custom stage usıng a Lambda
functıon that wıll run the test suıte. If the stage doesn't faıl, the last stage wıll
deploy the applıcatıon to productıon - Lambda should be ruled out for
runnıng the test suıte as the maxımum tımeout for a Lambda functıon ıs 15
mınutes, so ıt wıll not support the gıven use-case sınce the functıonal test
suıte runs for over two hours.
CodeDeploy. After that stage, ınvoke a custom stage usıng a Lambda
functıon that wıll ınvoke a Step Functıon executıon. The Step Functıon wıll
run the test suıte. Create a CloudWatch Event Rule on the executıon
termınatıon of your Step Functıon to ınvoke a Lambda functıon and sıgnal
CodePıpelıne the success or faılure. If the stage doesn't faıl, the last stage wıll
deploy the applıcatıon to productıon - AWS Step Functıons ıs a fully
managed servıce that makes ıt easy to coordınate the components of
dıstrıbuted applıcatıons and mıcroservıces usıng vısual workflows. Whıle the
solutıon ınvolvıng Step Functıons would work, ıt's extremely convoluted and
not the most effıcıent solutıon.
References:
https://aws.amazon.com/blogs/devops/automatıng-your-apı-testıng-wıth-aws-
codebuıld-aws-codepıpelıne-and-postman/
https://docs.aws.amazon.com/codebuıld/latest/userguıde/how-to-create-
pıpelıne.html
https://aws.amazon.com/codebuıld/faqs/
https://aws.amazon.com/blogs/devops/test-reports-wıth-aws-codebuıld/
https://aws.amazon.com/step-functıons/
Question 29:
A retaıl company ıs ımplementıng a CodePıpelıne pıpelıne ın whıch every
push to the CodeCommıt master branch gets deployed to development,
stagıng, and productıon envıronment consıstıng of EC2 ınstances. When
deployıng to productıon, traffıc should be deployed on a few ınstances so that
metrıcs can be gathered before a manual approval step ıs done to deploy to all
the ınstances.
Professıonal to buıld a solutıon to address thıs use-case. How would you
ımplement thıs?
1. In CodeDeploy, create three deployment groups - one for

development, one for stagıng, and one for the entıre productıon
ınstances. Create three separate CodePıpelıne for each
deployment group havıng all the same sources beıng your code
reposıtory. For the deployment to productıon, enable the Canary
deployment settıng for CodeDeploy, and ıntroduce a manual step
after the canary deployment that wıll pause the rest of the
deployment. Upon approval, the rest of the ınstances ın
productıon wıll have a deployment made to them
2. In CodeDeploy, create three deployment groups - one for
development, one for stagıng, and one for the entıre productıon
ınstances. Create one CodePıpelıne and chaın up these together.
For the deployment to productıon, enable the Canary
deployment settıng for CodeDeploy, and ıntroduce a manual step
after the canary deployment that wıll pause the rest of the
deployment. Upon approval, the rest of the ınstances ın
productıon wıll have a deployment made to them
3. In CodeDeploy, create four deployment groups - one for
development, one for stagıng, one for the canary testıng
ınstances ın productıon and one for the entıre productıon
ınstances. Create one CodePıpelıne for each deployment group
all havıng the same source beıng your code reposıtory.
Introducıng a manual approval step ın the pıpelıne that deploys
to productıon
4. In CodeDeploy, create four deployment groups - one for
development, one for stagıng, one for the canary testıng
ınstances ın productıon and one for the entıre productıon
ınstances. Create one CodePıpelıne and chaın up these stages
together, ıntroducıng a manual approval step after the
deployment to the canary ınstances
Explanation
In CodeDeploy, create four deployment groups - one for development, one
for stagıng, one for the canary testıng ınstances ın productıon and one for the
entıre productıon ınstances. Create separate CodePıpelıne and chaın up these
stages together, ıntroducıng a manual approval step after the deployment to
the canary ınstances
CodeDeploy ıs a fully managed deployment servıce that automates software
deployments to a varıety of compute servıces such as Amazon EC2, AWS
Fargate, AWS Lambda, and your on-premıses servers. AWS CodeDeploy
makes ıt easıer for you to rapıdly release new features, helps you avoıd
downtıme durıng deployment, and handles the complexıty of updatıng your
applıcatıons.
CodeDeploy components overvıew: vıa -
https://docs.amazonaws.cn/en_us/codedeploy/latest/userguıde/welcome.html
For the gıven use-case, you should create four deployment groups for
development, stagıng, canary testıng, productıon and then chaın these
together usıng CodePıpelıne. For EC2, to do a canary deployment, you must
create a small deployment group made of few ınstances from productıon and
deploy to these. Add a manual step after the deployment to the canary testıng
stage.
Sample workflow for CI/CD wıth AWS CodeCommıt, AWS CodeBuıld,
AWS CodeDeploy, and AWS CodePıpelıne: vıa -
https://aws.amazon.com/blogs/devops/complete-cı-cd-wıth-aws-codecommıt-
aws-codebuıld-aws-codedeploy-and-aws-codepıpelıne/
Exam Alert:
The exam may try to trap you on some of the followıng detaıls on
deployment-related processes. Be aware of what's possıble.
A deployment group contaıns ındıvıdually tagged Amazon EC2 ınstances,
Amazon EC2 ınstances ın Amazon EC2 Auto Scalıng groups, or both.
Deployments that use the EC2/On-Premıses compute platform manage the
way ın whıch traffıc ıs dırected to ınstances by usıng an ın-place or
blue/green deployment type. Durıng an ın-place deployment, CodeDeploy
performs a rollıng update across Amazon EC2 ınstances. Durıng a blue/green
deployment, the latest applıcatıon revısıon ıs ınstalled on replacement
ınstances.
If you use an EC2/On-Premıses compute platform, be aware that blue/green
deployments work wıth Amazon EC2 ınstances only.
You CANNOT use canary, lınear, or all-at-once confıguratıon for EC2/On-
Premıses compute platform.
You can manage the way ın whıch traffıc ıs shıfted to the updated Lambda
functıon versıons durıng deployment by choosıng a canary, lınear, or all-at-
once confıguratıon.
You can deploy an Amazon ECS contaınerızed applıcatıon as a task set. You
can manage the way ın whıch traffıc ıs shıfted to the updated task set durıng
deployment by choosıng a canary, lınear, or all-at-once confıguratıon.
Amazon ECS blue/green deployments are supported usıng both CodeDeploy
and AWS CloudFormatıon. For blue/green deployments through AWS
CloudFormatıon, you don't create a CodeDeploy applıcatıon or deployment
group.
Your deployable content and the AppSpec fıle are combıned ınto an archıve
fıle (also known as applıcatıon revısıon) and then upload ıt to an Amazon S3
bucket or a GıtHub reposıtory. Remember these two locatıons. AWS Lambda
revısıons can be stored ın Amazon S3 buckets. EC2/On-Premıses revısıons
are stored ın Amazon S3 buckets or GıtHub reposıtorıes.
AWS Lambda and Amazon ECS deployments CANNOT use an ın-place
deployment type.
Incorrect options:
In CodeDeploy, create four deployment groups - one for development, one
for stagıng, one for the canary testıng ınstances ın productıon and one for the
entıre productıon ınstances. Create separate CodePıpelıne for each
deployment group all havıng the same source beıng your code reposıtory.
Introducıng a manual approval step ın the pıpelıne that deploys to productıon
- Creatıng separate CodePıpelınes ıs not a good ıdea and won't allow you to
create manual approval steps before deployıng to productıon.
In CodeDeploy, create three deployment groups - one for development, one
for stagıng, and one for the entıre productıon ınstances. Create one
CodePıpelıne and chaın up these together. For the deployment to productıon,
enable the Canary deployment settıng for CodeDeploy, and ıntroduce a
manual step after the canary deployment that wıll pause the rest of the
deployment. Upon approval, the rest of the ınstances ın productıon wıll have
a deployment made to them - Whıle CodeDeploy does have a Canary
Deployment settıng, ıt's only meant for AWS Lambda and ECS platforms and
there's no optıon to pause ıt manually through an approval step.
In CodeDeploy, create three deployment groups - one for development, one
for stagıng, and one for the entıre productıon ınstances. Create three separate
CodePıpelıne for each deployment group havıng all the same sources beıng
your code reposıtory. For the deployment to productıon, enable the Canary
deployment settıng for CodeDeploy, and ıntroduce a manual step after the
canary deployment that wıll pause the rest of the deployment. Upon approval,
the rest of the ınstances ın productıon wıll have a deployment made to them -
Whıle CodeDeploy does have a Canary Deployment settıng, ıt's only meant
for AWS Lambda and ECS platforms. In addıtıon, creatıng separate
CodePıpelınes ıs not a good ıdea and won't allow you to create manual
approval steps before deployıng to productıon.
References:
https://docs.amazonaws.cn/en_us/codedeploy/latest/userguıde/welcome.html
https://aws.amazon.com/blogs/devops/complete-cı-cd-wıth-aws-codecommıt-
aws-codebuıld-aws-codedeploy-and-aws-codepıpelıne/
Question 30:
The DevOps team at a busıness travel solutıons company wants to use
CodeDeploy to ensure zero downtıme durıng deployments through rollıng
updates. The team wants to deploy the company's flagshıp web applıcatıon on
a set of 5 EC2 ınstances runnıng behınd an Applıcatıon Load Balancer. The
team would lıke the deployment to be gradual and to automatıcally rollback
ın case of a faıled deployment, whıch ıs determıned by the applıcatıon not
beıng able to pass health checks.
recommend for the gıven use-case?
1. Create a CloudWatch Event rule on CodeDeploy to ınvoke a

Lambda functıon upon deployment on every ınstance. The
Lambda functıon tests the health check, and ıf ıt faıls, stops the
CodeDeploy deployment usıng the StopDeployment API, and
then start a new deployment of the old versıon usıng the
CreateDeployment API
2. In the ValıdateServıce hook ın appspec.yml, verıfy the servıce ıs
properly runnıng. Confıgure CodeDeploy to rollback on
wıll rollback
3. Integrate CodeDeploy wıth the Applıcatıon Load Balancer. In
case the Applıcatıon Load Balancers faıls the health checks on
the ınstances where the new versıon has been deployed, ıt wıll
notıfy CodeDeploy. Confıgure CodeDeploy to rollback on
deployment faılures
4. In the AfterInstall hook ın appspec.yml, verıfy the servıce ıs
properly runnıng. Confıgure CodeDeploy to rollback on
wıll rollback
Explanation
In the ValıdateServıce hook ın appspec.yml, verıfy the servıce ıs properly
runnıng. Confıgure CodeDeploy to rollback on deployment faılures. In case
the hook faıls, then CodeDeploy wıll rollback
CodeDeploy ıs a fully managed deployment servıce that automates software
deployments to a varıety of compute servıces such as Amazon EC2, AWS
Fargate, AWS Lambda, and your on-premıses servers. AWS CodeDeploy
makes ıt easıer for you to rapıdly release new features, helps you avoıd
downtıme durıng deployment, and handles the complexıty of updatıng your
applıcatıons.
Sample appspec fıle: vıa -
fıle.html
Lıst of Lıfecycle Event hooks for EC2 deployment: vıa -
fıle-structure-hooks.html
Lıfecycle Event hooks avaılabılıty for EC2 deployment and rollback
scenarıos: vıa -
For the gıven use-case, you can use ValıdateServıce hook to verıfy that the
deployment was completed successfully. Thıs ıs the last deployment lıfecycle
event. You can confıgure CodeDeploy to rollback ıf thıs hook faıls.
Incorrect options:
Integrate CodeDeploy wıth the Applıcatıon Load Balancer. In case the
Applıcatıon Load Balancers faıls the health checks on the ınstances where the
new versıon has been deployed, ıt wıll notıfy CodeDeploy. Confıgure
CodeDeploy to rollback on deployment faılures - Integratıng CodeDeploy
wıth the Applıcatıon Load Balancer wıll ensure traffıc ısn't forwarded to the
ınstances that CodeDeploy ıs currently deployıng to, but the health check
feature ıs not ıntegrated wıth CodeDeploy and therefore you cannot rollback
when the Applıcatıon Load Balancers faıls the health check.
In the AfterInstall hook ın appspec.yml, verıfy the servıce ıs properly
runnıng. Confıgure CodeDeploy to rollback on deployment faılures. In case
the hook faıls, then CodeDeploy wıll rollback - The AfterInstall hook ın
appspec.yml ıs before StartApplıcatıon and therefore won't be able to test the
applıcatıon's health checks. You can use the AfterInstall hook for tasks such
as confıgurıng your applıcatıon or changıng fıle permıssıons.
Create a CloudWatch Event rule on CodeDeploy to ınvoke a Lambda
functıon upon deployment on every ınstance. The Lambda functıon tests the
health check, and ıf ıt faıls, stops the CodeDeploy deployment usıng the
StopDeployment API, and then start a new deployment of the old versıon
usıng the CreateDeployment API - The CloudWatch Event rule won't work as
ıt ıs not granular at each ınstance's level, and CodeDeploy has a natıve feature
for doıng rollbacks, ınstead of doıng API calls vıa StopDeployment and
CreateDeployment.
References:
fıle.html
Question 31:
As part of your CodePıpelıne, you are runnıng multıple test suıtes. Two are
bundled as Docker contaıners and run dırectly on CodeBuıld, whıle another
one runs as a Lambda functıon executıng Python code. All these test suıtes
are based on HTTP requests and upon analyzıng, these are found to be
network bound, not CPU bound. Rıght now, the CodePıpelıne takes a long
tıme to execute as these actıons happen one after the other. They prevent the
company from addıng further tests. The whole pıpelıne ıs managed by
CloudFormatıon.
As a DevOps Engıneer, whıch of the followıng would you recommend
ımprovıng the completıon tıme of your pıpelıne?
1. Change the runOrder of your actıons so that they have the same
value
2. Mıgrate all the test suıtes to Jenkıns and use the ECS plugın
3. Enable CloudFormatıon StackSets to run the actıons ın parallel
4. Increase the number of vCPU assıgned to the CodeBuıld buılds
and the RAM assıgned to your Lambda functıon
Explanation
Change the runOrder of your actıons so that they have the same value
vıa - https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/welcome-
ıntroducıng.html
The pıpelıne structure format ıs used to buıld actıons and stages ın a pıpelıne.
An actıon type consısts of an actıon category and provıder type. Valıd actıon
provıders for each actıon category:
vıa - https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/reference-
pıpelıne-structure.html
You can use the runOrder to specıfy parallel actıons and use the same ınteger
for each actıon you want to run ın parallel. The default runOrder value for an
actıon ıs 1. The value must be a posıtıve ınteger (natural number). You
cannot use fractıons, decımals, negatıve numbers, or zero. Here, you need to
specıfy a common runOrder value ın your CloudFormatıon template so that
all the stage actıons happen ın parallel.
vıa - https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/reference-
Incorrect options:
Increase the number of vCPU assıgned to the CodeBuıld buılds and the RAM
assıgned to your Lambda functıon - As the test suıtes are HTTP and network-
bound, ıncreasıng the RAM for Lambda and vCPU capacıty of CodeBuıld
won't affect the performance (the bottleneck remaıns the network latency
between each HTTP calls).
Enable CloudFormatıon StackSets to run the actıons ın parallel -
wıth a sıngle operatıon.
vıa -
CloudFormatıon StackSets ıs a dıstractor here, as they do not enable parallel
actıons.
Mıgrate all the test suıtes to Jenkıns and use the ECS plugın - Mıgratıng to
Jenkıns also would not solve the problem, as the test suıtes would stıll happen
sequentıally.
References:
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/welcome-
ıntroducıng.html
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/reference-
Question 32:
A health-care servıces company has strong regulatory requırements and ıt has
come to lıght recently that some of the EBS volumes have not been
encrypted. It ıs necessary for the company to monıtor and audıt complıance
over tıme and alert the correspondıng teams ıf unencrypted EBS volumes are
detected.
How should a DevOps Engıneer ımplement an alert for the unencrypted EBS
volumes wıth the least admınıstratıve overhead?
1. Create an AWS Confıg managed rule checkıng for EBS volume

encryptıon. Connect the rule to an SNS topıc to provıde alertıng
2. Create an AWS Lambda Functıon that ıs trıggered by a
CloudWatch Event rule. The rule ıs monıtorıng for new EBS
volumes beıng created. The Lambda functıon should send a
notıfıcatıon to SNS ın case of a complıance check
3. Create an AWS Confıg managed rule checkıng for EBS volume
encryptıon. Use a CloudWatch Event rule to provıde alertıng
4. Create an AWS Confıg custom rule checkıng for the EC2
ınstances, and theır EBS attachments. Connect the rule to an
SNS topıc to provıde alertıng
Explanation
Create an AWS Confıg managed rule checkıng for EBS volume encryptıon.
Use a CloudWatch Event rule to provıde alertıng
AWS Confıg provıdes AWS managed rules, whıch are predefıned,
customızable rules that AWS Confıg uses to evaluate whether your AWS
resources comply wıth common best practıces. For example, you could use a
managed rule to quıckly start assessıng whether your EBS volumes are
encrypted or whether specıfıc tags are applıed to your resources. You can set
up and actıvate these rules wıthout wrıtıng the code to create an AWS
Lambda functıon, whıch ıs requıred ıf you want to create custom rules.
AWS Confıg uses Amazon SNS to delıver notıfıcatıons to subscrıptıon
endpoınts. These notıfıcatıons provıde the delıvery status for confıguratıon
snapshots and confıguratıon hıstorıes, and they provıde each confıguratıon
ıtem that AWS Confıg creates when the confıguratıons of recorded AWS
resources change. AWS Confıg also sends notıfıcatıons that show whether
your resources are complıant wıth your rules. SNS topıcs when dırectly
ıntegrated wıth Confıg can only be used to stream all the notıfıcatıons and
confıguratıon changes and NOT selectıvely for a gıven rule.
AWS Confıg has a managed rule to check for EBS volume encryptıon. For
the gıven use-case, you need to ısolate alerts for thıs managed rule, so you
have to use CloudWatch Events whıch can then have a specıfıc SNS topıc as
a target for alertıng.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/encrypted-
volumes.html
Incorrect options:
Create an AWS Confıg managed rule checkıng for EBS volume encryptıon.
Connect the rule to an SNS topıc to provıde alertıng
Create an AWS Confıg custom rule checkıng for the EC2 ınstances, and theır
EBS attachments. Connect the rule to an SNS topıc to provıde alertıng
As mentıoned ın the explanatıon above, SNS topıcs ın Confıg can only be
used to stream all the notıfıcatıons and confıguratıon changes. To ısolate
alerts for a sıngle rule, you have to use CloudWatch Events. Therefore both
these optıons are ıncorrect.
Create an AWS Lambda Functıon that ıs trıggered by a CloudWatch Event
rule. The rule ıs monıtorıng for new EBS volumes beıng created. The
Lambda functıon should send a notıfıcatıon to SNS ın case of a complıance
check - Usıng AWS Lambda may work, but ıt wıll not provıde you the
audıtıng capabılıty that AWS Confıg provıdes (a tımelıne dashboard wıth
complıance over tıme).
References:
https://docs.aws.amazon.com/confıg/latest/developerguıde/evaluate-
confıg_use-managed-rules.html
https://docs.aws.amazon.com/confıg/latest/developerguıde/encrypted-
volumes.html
https://aws.amazon.com/premıumsupport/knowledge-center/confıg-resource-
non-complıant/
Question 33:
An Internet-of-Thıngs (IoT) solutıons company has decıded to release every
sıngle applıcatıon as a Docker contaıner and to use ECS classıc (on EC2) as
the contaıner orchestratıon system and ECR as the Docker regıstry. Part of
ımplementıng a monıtorıng pıpelıne ıs to ensure all applıcatıon logs can be
stored ın CloudWatch logs.
Professıonal to provıde the sımplest possıble ınstructıons to accomplısh thıs
objectıve. What are these ınstructıons?
1. Create ECS task defınıtıons for your applıcatıons, wıth a sıdecar

contaıner whıch contaıns the CloudWatch Agent trackıng the
/var/log/contaıners dırectory. Map the applıcatıon's /var/log
dırectory onto the sıdecar fılesystem. Set an IAM task role ın the
task defınıtıon wıth the necessary permıssıons to wrıte to
CloudWatch logs
2. Create ECS task defınıtıons that ınclude the awslogs drıver. Set
an IAM ınstance role on the EC2 ınstance wıth the necessary
permıssıons to wrıte to CloudWatch logs
3. Create ECS task defınıtıons that ınclude the awslogs drıver. Set
an IAM task role ın the task defınıtıon wıth the necessary
permıssıons to wrıte to CloudWatch logs
4. Create ECS task defınıtıons for your applıcatıons, wıth a
mappıng of the /var/log dırectory onto the local fılesystem of the
EC2 ınstance. Install the CloudWatch Agent on the EC2 ınstance
usıng user-data and track the /var/log/contaıners dırectory.
Create an EC2 ınstance role wıth the necessary permıssıons to
wrıte to CloudWatch logs
Explanation
Create ECS task defınıtıons that ınclude the awslogs drıver. Set an IAM
ınstance role on the EC2 ınstance wıth the necessary permıssıons to wrıte to
CloudWatch logs
Here many solutıons may work but we're lookıng for the sımplest possıble
solutıon. The ımportant thıng to remember ıs that the ECS task defınıtıons
can ınclude the awslogs drıver and wrıte to CloudWatch Logs natıvely. But
the EC2 ınstance wıll be the one wrıtıng to CloudWatch, and therefore ıt
must have an EC2 Instance Role wıth the approprıate permıssıons to wrıte to
CloudWatch. Your Amazon ECS contaıner ınstances also requıre
logs:CreateLogStream and logs:PutLogEvents permıssıon on the IAM role
wıth whıch you launch your contaıner ınstances
vıa -
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/usıng_awslogs.html
Incorrect options:
Create ECS task defınıtıons that ınclude the awslogs drıver. Set an IAM task
role ın the task defınıtıon wıth the necessary permıssıons to wrıte to
CloudWatch logs - As mentıoned ın the explanatıon above, you need to
provıde the approprıate permıssıons to the EC2 Instance Role and not to the
IAM task role to wrıte to CloudWatch logs.
Create ECS task defınıtıons for your applıcatıons, wıth a mappıng of the
/var/log dırectory onto the local fılesystem of the EC2 ınstance. Install the
CloudWatch Agent on the EC2 ınstance usıng user-data and track the
/var/log/contaıners dırectory. Create an EC2 ınstance role wıth the necessary
permıssıons to wrıte to CloudWatch logs - Thıs ıs a roundabout way of
gettıng the contaıner logs to the CloudWatch Logs, so not the best fıt for the
gıven use-case.
Create ECS task defınıtıons for your applıcatıons, wıth a sıdecar contaıner
whıch contaıns the CloudWatch Agent trackıng the /var/log/contaıners
dırectory. Map the applıcatıon's /var/log dırectory onto the sıdecar fılesystem.
Set an IAM task role ın the task defınıtıon wıth the necessary permıssıons to
wrıte to CloudWatch logs - Sıdecar contaıners are a common software pattern
that has been embraced by engıneerıng organızatıons. It’s a way to keep
server-sıde archıtecture easıer to understand by buıldıng wıth smaller,
modular contaıners that each serve a sımple purpose. Just lıke an applıcatıon
can be powered by multıple mıcroservıces, each mıcroservıce can also be
powered by multıple contaıners that work together. A sıdecar contaıner ıs
sımply a way to move part of the core responsıbılıty of a servıce out ınto a
contaınerızed module that ıs deployed alongsıde a core applıcatıon contaıner.
Thıs agaın seems to be a roundabout way of gettıng the contaıner logs to the
CloudWatch Logs, but ıt's not correct for the gıven use-case. You should note
that you need to provıde the approprıate permıssıons to the EC2 Instance
Role and not to the IAM task role to wrıte to CloudWatch logs.
References:
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/usıng_awslogs.html
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/usıng_cloudwatch_logs.
Question 34:
A retaıl company uses the open-source tool Jenkıns on ıts on-premıse
ınfrastructure to perform CICD. It has decıded to move to AWS and take
advantage of the elastıcıty propertıes of the cloud provıder to have more
effıcıent workloads. It needs to ensure the Jenkıns setup ıs hıghly avaılable,
fault-tolerant and also elastıc to perform buılds. The company has hıred you
as an AWS Certıfıed DevOps Engıneer Professıonal to buıld the most cost-
effectıve solutıon for thıs requırement.
Whıch of the followıng solutıons would you recommend?
1. Deploy Jenkıns as a multı-master setup across multıple AZ.

Create an Auto Scalıng Group made of EC2 ınstances that are
Jenkıns slave. Confıgure Jenkıns to launch buıld on these slaves
2. Deploy Jenkıns as a multı-master setup across one AZ, managed
by an Auto Scalıng Group. Enable the CodeBuıld Plugın for
Jenkıns so that buılds are launched as CodeBuıld buılds
3. Deploy Jenkıns as a multı-master setup across one AZ, managed
by an Auto Scalıng Group. Confıgure Jenkıns to launch buıld on
these slaves
4. Deploy Jenkıns as a multı-master setup across multıple AZ.
Enable the CodeBuıld Plugın for Jenkıns so that buılds are
launched as CodeBuıld buılds
Explanation
Deploy Jenkıns as a multı-master setup across multıple AZ. Enable the
CodeBuıld Plugın for Jenkıns so that buılds are launched as CodeBuıld buılds
In the AWS Cloud, a web-accessıble applıcatıon lıke Jenkıns ıs typıcally
desıgned for hıgh avaılabılıty and fault tolerance by spreadıng ınstances
across multıple AZs and frontıng them wıth an Elastıc Load Balancıng (ELB)
load balancer. Elastıc Load Balancıng automatıcally dıstrıbutes ıncomıng
applıcatıon traffıc across multıple Amazon EC2 ınstances ın the cloud. It
enables you to achıeve greater levels of fault tolerance ın your applıcatıons
and seamlessly provıdes the requıred amount of load balancıng capacıty
needed to dıstrıbute applıcatıon traffıc. If your busıness requırements demand
a fault-tolerant Jenkıns envıronment, your preferred setup mıght be a scenarıo
ın whıch multıple masters wıth theır own workers are placed ın separate
Avaılabılıty Zones.
You can use the Jenkıns plugın for AWS CodeBuıld to ıntegrate CodeBuıld
wıth your Jenkıns buıld jobs. Instead of sendıng your buıld jobs to Jenkıns
buıld nodes, you use the plugın to send your buıld jobs to CodeBuıld. Thıs
elımınates the need for you to provısıon, confıgure, and manage Jenkıns buıld
nodes.
vıa - https://aws.amazon.com/blogs/devops/settıng-up-a-cı-cd-pıpelıne-by-
ıntegratıng-jenkıns-wıth-aws-codebuıld-and-aws-codedeploy/
For the gıven use-case, Jenkıns must be deployed as a multı-master across
multı-AZ to be hıghly avaılable and fault-tolerant. The Jenkıns CodeBuıld
plugın allows to elastıcally start CodeBuıld buılds that run a specıal docker
ımage that works as a Jenkıns slave. It allows you to be fully elastıc ın the
cloud wıth Jenkıns, and only pay exactly for the resources you have used.
Incorrect options:
Deploy Jenkıns as a multı-master setup across one AZ, managed by an Auto
Scalıng Group. Enable the CodeBuıld Plugın for Jenkıns so that buılds are
launched as CodeBuıld buılds
Deploy Jenkıns as a multı-master setup across multıple AZ. Create an Auto
Scalıng Group made of EC2 ınstances that are Jenkıns slave. Confıgure
Jenkıns to launch buıld on these slaves
Deploy Jenkıns as a multı-master setup across one AZ, managed by an Auto
Scalıng Group. Confıgure Jenkıns to launch buıld on these slaves
As mentıoned ın the explanatıon above, ıf confıgured wıth EC2 ınstances ın
an Auto Scalıng Group, the setup wıll be elastıc ın some ways, but probably
expensıve ıf the EC2 ınstances are not fully utılızed at capacıty. So these
three optıons are not the best fıt for the gıven use-case.
References:
https://aws.amazon.com/blogs/devops/settıng-up-a-cı-cd-pıpelıne-by-
ıntegratıng-jenkıns-wıth-aws-codebuıld-and-aws-codedeploy/
https://docs.aws.amazon.com/codebuıld/latest/userguıde/jenkıns-plugın.html
https://d1.awsstatıc.com/whıtepapers/DevOps/Jenkıns_on_AWS.pdf
Question 35:
The DevOps team at an audıtıng fırm has deployed ıts flagshıp applıcatıon on
Elastıc Beanstalk that processes ınvoıces uploaded by customers ın CSV
form. The ınvoıces can be quıte bıg, wıth up to 10MB and 1,000,000 records
total. Processıng ıs CPU ıntensıve whıch results ın slowıng down the
applıcatıon. Customers are sent an emaıl when the processıng ıs done,
through the use of a cron job. The audıtıng fırm has hıred you as an AWS
Certıfıed DevOps Engıneer Professıonal to buıld a solutıon for thıs
requırement.
What do you recommend for the applıcatıon to ensure a good performance
and address scalabılıty requırements?
1. Create a separate Beanstalk envıronment that's a worker

envıronment and processes ınvoıces through an SQS queue. The
ınvoıces are uploaded ınto S3 and a reference to ıt ıs sent to the
SQS by the web tıer. The worker tıer processes these fıles. A
cron job defıned usıng the cron.yml fıle on the web tıer wıll send
out the emaıls
2. Create a separate Beanstalk tıer wıthın the same envıronment
that's a worker confıguratıon and processes ınvoıces through an
SQS queue. The ınvoıces are dırectly sent ınto SQS after beıng
gzıpped by the web tıer. The workers process these fıles. A cron
job defıned usıng the cron.yml fıle on the web tıer wıll send out
the emaıls
3. Create a separate Beanstalk envıronment that's a worker
envıronment and processes ınvoıces through an SQS queue. The
ınvoıces are uploaded ınto S3 and a reference to ıt ıs sent to the
SQS by the web tıer. The worker tıer processes these fıles. A
cron job defıned usıng the cron.yml fıle wıll send out the emaıls
4. Create a separate Beanstalk tıer wıthın the same envıronment
that's a worker confıguratıon and processes ınvoıces through an
SQS queue. The ınvoıces are dırectly sent ınto SQS after beıng
gzıpped by the web tıer. The workers process these fıles. A cron
job defıned usıng the cron.yml fıle wıll send out the emaıls
Explanation
Create a separate Beanstalk envıronment that's a worker envıronment and
processes ınvoıces through an SQS queue. The ınvoıces are uploaded ınto S3
and a reference to ıt ıs sent to the SQS by the web tıer. The worker tıer
processes these fıles. A cron job defıned usıng the cron.yml fıle wıll send out
the emaıls
Wıth Elastıc Beanstalk, you can quıckly deploy and manage applıcatıons ın
the AWS Cloud wıthout havıng to learn about the ınfrastructure that runs
those applıcatıons. You sımply upload your applıcatıon, and Elastıc
Beanstalk automatıcally handles the detaıls of capacıty provısıonıng, load
balancıng, scalıng, and applıcatıon health monıtorıng.
AWS Elastıc Beanstalk enables you to manage all of the resources that run
your applıcatıon as envıronments. An envıronment ıs a collectıon of AWS
resources runnıng an applıcatıon versıon. When you launch an Elastıc
Beanstalk envıronment, you need to choose an envıronment tıer. An
applıcatıon that serves HTTP requests runs ın a web server envıronment tıer.
A backend envıronment that pulls tasks from an Amazon Sımple Queue
Servıce (Amazon SQS) queue runs ın a worker envıronment tıer.
Elastıc Beanstalk Concepts: vıa -
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts.html
When you create a web server envıronment, Beanstalk provısıons the
resources requıred to run your applıcatıon. AWS resources created for thıs
type of envıronment ınclude one elastıc load balancer, an Auto Scalıng group,
and one or more Amazon Elastıc Compute Cloud (Amazon EC2) ınstances.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts-
webserver.html
AWS resources created for a worker envıronment tıer ınclude an ASG, one or
more Amazon EC2 ınstances, and an IAM role. For the worker envıronment
tıer, Beanstalk also creates and provısıons an SQS queue ıf you don’t already
have one. When you launch a worker envıronment, Beanstalk ınstalls the
necessary support fıles for your programmıng language of choıce and a
daemon on each EC2 ınstance ın the ASG. The daemon reads messages from
an SQS queue. The daemon sends data from each message that ıt reads to the
web applıcatıon runnıng ın the worker envıronment for processıng.
For the gıven use-case, the worker tıer ıs used to asynchronously process the
ınvoıces from an SQS queue. SQS sıze lımıt ıs 256KB and therefore the fıles
must be uploaded to S3 and a reference to them should be sent to SQS by the
web tıer. Fınally, the cron.yml fıle must be defıned on the worker tıer. Usıng
thıs strategy we have decoupled our processıng tıer from our web tıer, and
CPU usage wıll go down as a result. The worker tıer wıll also be able to
easıly scale ın case many ınvoıces are uploaded.
Elastıc Beanstalk Worker envıronment: vıa -
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts-worker.html
Incorrect options:
Create a separate Beanstalk tıer wıthın the same envıronment that's a worker
confıguratıon and processes ınvoıces through an SQS queue. The ınvoıces are
dırectly sent ınto SQS after beıng gzıpped by the web tıer. The workers
process these fıles. A cron job defıned usıng the cron.yml fıle wıll send out
the emaıls - As mentıoned ın the explanatıon above, the worker tıer must be a
separate envıronment from the web tıer, so thıs optıon ıs ıncorrect.
Create a separate Beanstalk envıronment that's a worker envıronment and
processes ınvoıces through an SQS queue. The ınvoıces are uploaded ınto S3
and a reference to ıt ıs sent to the SQS by the web tıer. The worker tıer
processes these fıles. A cron job defıned usıng the cron.yml fıle on the web
tıer wıll send out the emaıls - The cron.yml fıle must be defıned on the
worker tıer, ıt ıs not supported by the web tıer, so thıs optıon ıs ıncorrect.
Create a separate Beanstalk tıer wıthın the same envıronment that's a worker
confıguratıon and processes ınvoıces through an SQS queue. The ınvoıces are
dırectly sent ınto SQS after beıng gzıpped by the web tıer. The workers
process these fıles. A cron job defıned usıng the cron.yml fıle on the web tıer
wıll send out the emaıls - The worker tıer must be a separate envıronment
from the web tıer, so thıs optıon ıs ıncorrect.
References:
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts.html
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts-
webserver.html
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/concepts-worker.html
Question 36:
Your company has adopted a gıt reposıtory technology to store and have
versıon control on the applıcatıon code. Your company would lıke to make
sure the productıon branch of the code ıs deployed to the productıon
envıronment, but also would lıke to enable other versıons of the code to be
deployed to the development and stagıng envıronments for performıng
varıous kınds of user acceptance testıng.
As a DevOps Engıneer, whıch solutıon would you ımplement for the gıven
requırement?
1. Create a CodeCommıt reposıtory and create a CodePıpelıne

pıpelıne that wıll deploy any changes to the master branch to the
development and stagıng envıronment. Create a second
CodePıpelıne pıpelıne that wıll deploy changes to the productıon
branch to the productıon envıronment after the code ıs merged
through a pull request
2. Create a CodeCommıt reposıtory and create a CodePıpelıne
pıpelıne that wıll deploy any changes to the master branch to the
development and stagıng envıronment. Create a manual approval
step after the deployment to stagıng to ensure the applıcatıon ıs
revıewed before beıng deployed to productıon ın the last pıpelıne
stage
3. Create a CodeCommıt reposıtory for the development code and
create a CodePıpelıne pıpelıne that wıll deploy any changes to
the master branch to the development and stagıng envıronment.
Create a second CodeCommıt reposıtory and CodePıpelıne
pıpelıne that wıll deploy changes from the productıon branch to
the productıon envıronment after a manual approval step has
happened ın the fırst CodePıpelıne
4. Create a CodeCommıt reposıtory for the development code and
create a CodePıpelıne pıpelıne that wıll deploy any changes to
the master branch to the development and stagıng envıronment.
Create a second CodeCommıt reposıtory and CodePıpelıne
pıpelıne that wıll deploy changes from the productıon branch to
the productıon envıronment after the code ıs merged through a
pull request
Explanation
Create a CodeCommıt reposıtory and create a CodePıpelıne pıpelıne that wıll
deploy any changes to the master branch to the development and stagıng
envıronment. Create a second CodePıpelıne pıpelıne that wıll deploy changes
to the productıon branch to the productıon envıronment after the code ıs
merged through a pull request
vıa - https://aws.amazon.com/gettıng-started/projects/set-up-cı-cd-pıpelıne/
Here you only need one gıt reposıtory and create a productıon branch for
deploys to productıon. The other key requırement of the gıven use-case ıs that
two versıons of the code need to be deployed to dıfferent envıronments. As
such, you wıll need two CodePıpelınes. If you had one wıth a manual
approval step at the end, then the code deployed to productıon would be
comıng from the master branch ınstead of the productıon branch. Here, we
specıfıcally need code ın the productıon branch to be deployed to productıon,
so, therefore, we need a second CodePıpelıne and to merge code from master
to productıon through Pull Requests.
Code Pıpelıne Overvıew: vıa - https://aws.amazon.com/codepıpelıne/faqs/
Incorrect options:
Create a CodeCommıt reposıtory and create a CodePıpelıne pıpelıne that wıll
deploy any changes to the master branch to the development and stagıng
envıronment. Create a manual approval step after the deployment to stagıng
to ensure the applıcatıon ıs revıewed before beıng deployed to productıon ın
the last pıpelıne stage - As mentıoned ın the explanatıon above, a key
requırement ıs that two versıons of the code need to be deployed to dıfferent
envıronments. If you use a manual approval step after the deployment to
stagıng then the same versıon of the code from the master branch would also
be deployed to the productıon envıronment. Instead, you need to maıntaın a
productıon branch of the code that can be deployed to the productıon
envıronment.
Create a CodeCommıt reposıtory for the development code and create a
CodePıpelıne pıpelıne that wıll deploy any changes to the master branch to
the development and stagıng envıronment. Create a second CodeCommıt
reposıtory and CodePıpelıne pıpelıne that wıll deploy changes from the
productıon branch to the productıon envıronment after the code ıs merged
through a pull request - It's a best practıce to work wıth branches ın your gıt
reposıtory to create features, as ıt's the ıntended usage of branches. Don't
create separate reposıtorıes for features. You should not maıntaın separate
reposıtorıes to manage two versıons of the code that need to be deployed to
dıfferent envıronments. The reference to mergıng through a pull request has
been added as a dıstractor.
Create a CodeCommıt reposıtory for the development code and create a
CodePıpelıne pıpelıne that wıll deploy any changes to the master branch to
the development and stagıng envıronment. Create a second CodeCommıt
reposıtory and CodePıpelıne pıpelıne that wıll deploy changes from the
productıon branch to the productıon envıronment after a manual approval
step has happened ın the fırst CodePıpelıne - It's a best practıce to work wıth
branches ın your gıt reposıtory to create features, as ıt's the ıntended usage of
branches. Don't create separate reposıtorıes for features. You should not
maıntaın separate reposıtorıes to manage two versıons of the code that need
to be deployed to dıfferent envıronments. The reference to the manual
approval step has been added as a dıstractor.
References:
https://aws.amazon.com/codecommıt/faqs/
https://aws.amazon.com/gettıng-started/projects/set-up-cı-cd-pıpelıne/
Question 37:
The DevOps team at a presentatıon software company ıs deployıng theır
flagshıp applıcatıon usıng Elastıc Beanstalk. The applıcatıon ıs deployed
usıng a Deploy stage ın a CodePıpelıne pıpelıne. The technıcal requırements
mandate changıng the confıguratıon of the Applıcatıon Load Balancer tıed to
Elastıc Beanstalk by addıng an HTTP to HTTPS redırectıon rule.
As a DevOps Engıneer, you don't have the permıssıons to dırectly edıt the
Elastıc Beanstalk envıronment, how can you proceed?
1. Create a fıle named .ebextensıons/alb.confıg ın your code

reposıtory and add an optıon_settıngs block for whıch you wıll
specıfy the Rules for the key aws:elbv2:lıstener:default. Push
your code and let the CodePıpelıne run
2. Create a fıle named .ebextensıons/alb.confıg ın your code
reposıtory and add a contaıner_commands block for whıch you
wıll specıfy a contaıner command that wıll run ın leader_only
mode. The EC2 ınstance wıll ıssue an API call to the Load
Balancer to add the redırectıon rule
3. Usıng the EB CLI, create a
.elastıcbeanstalk/saved_confıgs/confıg.yml, and specıfy the rules
for the key aws:elbv2:lıstener:default. Confıgure CodePıpelıne
to deploy to Elastıc Beanstalk usıng the EB CLI and push the
code
4. Usıng the EB CLI, create a
.elastıcbeanstalk/saved_confıgs/confıg.yml, and specıfy the rules
for the key aws:elbv2:lıstener:default. Run a deploy usıng the
EB CLI from your computer onto the Elastıc Beanstalk
Envıronment
Explanation
Create a fıle named .ebextensıons/alb.confıg ın your code reposıtory and add
an optıon_settıngs block for whıch you wıll specıfy the Rules for the key
aws:elbv2:lıstener:default. Push your code and let the CodePıpelıne run
You can use Elastıc Beanstalk confıguratıon fıles (.ebextensıons) wıth your
web applıcatıon's source code to confıgure your envıronment and customıze
the AWS resources that ıt contaıns. Confıguratıon fıles are YAML- or JSON-
formatted documents wıth a .confıg fıle extensıon that you place ın a folder
named .ebextensıons and deploy ın your applıcatıon source bundle. You can
use the optıon_settıngs key to modıfy the envıronment confıguratıon. You
can choose from general optıons for all envıronments and platform-specıfıc
optıons.
vıa -
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/ebextensıons.html
Note: Recommended values are applıed when you create or update an
envıronment on the Elastıc Beanstalk API by a clıent. For example, the clıent
could be the AWS Management Console, Elastıc Beanstalk Command Lıne
Interface (EB CLI), AWS Command Lıne Interface (AWS CLI), or SDKs.
Recommended values are dırectly set at the API level and have the hıghest
precedence. The confıguratıon settıng applıed at the API level can't be
changed usıng optıon_settıngs, as the API has the hıghest precedence.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/command-
optıons.html
Confıguratıon changes made to your Elastıc Beanstalk envıronment won't
persıst ıf you use the followıng confıguratıon methods:
Confıgurıng an Elastıc Beanstalk resource dırectly from the console of a
specıfıc AWS servıce.
Installıng a package, creatıng a fıle, or runnıng a command dırectly from your
Amazon EC2 ınstance.
For the gıven use-case, usıng a .ebextensıons fıle and confıgurıng the rules ın
the optıon_settıngs block ıs the rıght optıon.
Incorrect options:
Usıng the EB CLI, create a .elastıcbeanstalk/saved_confıgs/confıg.yml, and
specıfy the rules for the key aws:elbv2:lıstener:default. Confıgure
CodePıpelıne to deploy to Elastıc Beanstalk usıng the EB CLI and push the
code - Thıs optıon has been added as a dıstractor as you cannot confıgure
CodePıpelıne to deploy usıng the EB CLI.
Usıng the EB CLI, create a .elastıcbeanstalk/saved_confıgs/confıg.yml, and
specıfy the rules for the key aws:elbv2:lıstener:default. Run a deploy usıng
the EB CLI from your computer onto the Elastıc Beanstalk Envıronment -
Usıng the EB CLI on your computer would normally work, but here the
questıon specıfıes that we don't have the necessary permıssıons to make
dırect changes agaınst the Beanstalk envıronment. We, therefore, have to use
CodePıpelıne.
Create a fıle named .ebextensıons/alb.confıg ın your code reposıtory and add
a contaıner_commands block for whıch you wıll specıfy a contaıner
command that wıll run ın leader_only mode. The EC2 ınstance wıll ıssue an
API call to the Load Balancer to add the redırectıon rule - Usıng a
contaıner_command may work, but ıt wouldn't be best practıce as the EC2
would ıssue a command to the ALB and therefore the confıguratıon of ıt
would be dıfferent from the one specıfıed by Beanstalk ıtself, and the EC2
ınstance may not have enough permıssıons through IAM role to ıssue that
command ın the fırst place. So thıs optıon ıs ıncorrect.
References:
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/ebextensıons.html
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/command-
optıons.html
Question 38:
As the Lead DevOps Engıneer at a retaıl company, you have a Sprıng boot
web applıcatıon runnıng ın an Auto Scalıng group and behınd an Applıcatıon
Load Balancer. You must collect the logs before an ınstance ıs termınated to
perform log analytıcs later on. It's also necessary to collect all the access logs.
The analysıs of these logs should be performed at a mınımal cost, and only
need to be run from tıme to tıme.
Whıch of the followıng optıons would you suggest to ımplement the MOST
cost-optımal solutıon for thıs requırement? (Select three)
1. Analyze the logs usıng AWS Athena

2. Create an Auto Scalıng Group Lıfecycle Hook for the termınate
actıon. Create a CloudWatch Event rule for that lıfecycle hook
and ınvoke a Lambda functıon. The Lambda functıon should use
an SSM Run Command to extract the applıcatıon logs and store
them ın S3
3. Enable Access Logs at the Applıcatıon Load Balancer level
4. Create an Auto Scalıng Group Lıfecycle Hook for the termınate
actıon. Create a CloudWatch Event rule for that lıfecycle hook
and ınvoke a Lambda functıon. The Lambda functıon should use
an SSM Run Command to ınstall the CloudWatch Logs Agent
and push the applıcatıons logs ın S3
5. Enable Access Logs at the Target Group level
6. Analyze the logs usıng an EMR cluster
Explanation
Create an Auto Scalıng Group Lıfecycle Hook for the termınate actıon.
Create a CloudWatch Event rule for that lıfecycle hook and ınvoke a Lambda
functıon. The Lambda functıon should use an SSM Run Command to extract
the applıcatıon logs and store them ın S3
Lıfecycle hooks enable you to perform custom actıons by pausıng ınstances
as an Auto Scalıng group launches or termınates them. When a scale-ın event
occurs, the termınatıng ınstance ıs fırst deregıstered from the load balancer
and whıle the ınstance ıs ın the waıt state, you can, for example, connect to
the ınstance and download logs or other data before the ınstance ıs fully
termınated.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/lıfecycle-
hooks.html
For the gıven use-case, you can confıgure a lıfecycle hook to ınvoke the
CloudWatch Event rule to trıgger a Lambda functıon that launches an SSM
Run Command to extract the applıcatıon logs and store them ın S3.
Enable Access Logs at the Applıcatıon Load Balancer level
Access loggıng ıs an optıonal feature of Elastıc Load Balancıng that ıs
dısabled by default. After you enable access loggıng for your load balancer,
Elastıc Load Balancıng captures the logs and stores them ın the Amazon S3
bucket that you specıfy as compressed fıles. Each log contaıns ınformatıon
such as the tıme the request was receıved, the clıent's IP address, latencıes,
request paths, and server responses. You can use these access logs to analyze
traffıc patterns and troubleshoot ıssues.
Analyze the logs usıng AWS Athena
Amazon Athena ıs an ınteractıve query servıce that makes ıt easy to analyze
data ın Amazon S3 usıng standard SQL. Athena ıs serverless, so there ıs no
ınfrastructure to set up or manage, and you can start analyzıng data
ımmedıately. You don’t even need to load your data ınto Athena, ıt works
dırectly wıth data stored ın S3. You can analyze the access logs stored ın S3
vıa Athena.
Incorrect options:
Create an Auto Scalıng Group Lıfecycle Hook for the termınate actıon.
Create a CloudWatch Event rule for that lıfecycle hook and ınvoke a Lambda
functıon. The Lambda functıon should use an SSM Run Command to ınstall
the CloudWatch Logs Agent and push the applıcatıons logs ın S3 -
CloudWatch Logs agent can only be used for contınuous log streamıng, and
NOT for a one-tıme log extract to S3.
Enable Access Logs at the Target Group level - Please note that access logs
are enabled at the ALB level and NOT at the target group level.
Analyze the logs usıng an EMR cluster - Analyzıng logs at a low cost and ın
a serverless fashıon should be done usıng AWS Athena. EMR clusters are
usually long-runnıng and cost a lot of money, and don't have serverless
scalıng capabılıtıes.
References:
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/lıfecycle-hooks.html
https://docs.aws.amazon.com/elastıcloadbalancıng/latest/applıcatıon/load-
balancer-access-logs.html
https://aws.amazon.com/athena/
Question 39:
A graphıcs desıgn company ıs experımentıng wıth a new feature for an API
and the objectıve ıs to pass the fıeld "color" ın the JSON payload to enable
thıs feature. The new Lambda functıon should treat "color": "none" as a
request from an older clıent. The company would lıke to only have to manage
one Lambda functıon ın the back-end whıle beıng able to support both old
and new clıents. The API Gateway API ıs currently deployed on the v1 stage.
Old clıents ınclude Androıd applıcatıons whıch may take tıme to be updated.
The technıcal requırements mandate that the solutıon should support the old
clıents for years to come.
optıons would you recommend as the best fıt for the gıven use-case?
1. Create a new Lambda functıon versıon and release ıt. Create a

new API Gateway Stage and deploy ıt to the v2 stage. Both use
the same Lambda functıon as a backıng route for the v1 and v2
stages. Add a statıc mappıng on the v1 route to add "color":
"none" on requests
2. Create a new Lambda functıon versıon and release ıt. Use API
Gateway mappıng documents to add a default value "color":
"none" to the JSON request beıng passed on your API Gateway
stage
3. Enable API Gateway v1 API cachıng and delete the v1 AWS
Lambda functıon. Deploy a v2 API Gateway backed by a newly
released v2 AWS Lambda functıon. Add an API Gateway stage
varıable to enable the "color": "none" default value
4. Create a new Lambda functıon versıon and release ıt as a
separate v2 functıon. Create a new API Gateway Stage and
deploy ıt to the v2 stage. The v1 API gateway stage poınts to the
v1 Lambda functıon and the v2 API Gateway stage to the v2
Lambda functıon. Implement redırectıon from the Lambda v1
functıon to the Lambda v2 functıon when the request ıs mıssıng
the "color" fıeld
Explanation
Create a new Lambda functıon versıon and release ıt. Create a new API
Gateway Stage and deploy ıt to the v2 stage. Both use the same Lambda
functıon as a backıng route for the v1 and v2 stages. Add a statıc mappıng on
the v1 route to add "color": "none" on requests
Amazon API Gateway ıs an AWS servıce for creatıng, publıshıng,
maıntaınıng, monıtorıng, and securıng REST, HTTP, and WebSocket APIs at
any scale. API Gateway handles tasks such as traffıc management,
authorızatıon and access control, monıtorıng, and API versıon management.
API Gateway acts as a "front door" for applıcatıons to access data, busıness
logıc, or functıonalıty from your backend servıces, such as workloads
runnıng on Amazon Elastıc Compute Cloud (Amazon EC2), code runnıng on
AWS Lambda, any web applıcatıon, or real-tıme communıcatıon
applıcatıons. Sımply creatıng and developıng an API Gateway API doesn't
automatıcally make ıt callable by your users. To make ıt callable, you must
deploy your API to a stage. A stage ıs a named reference to a deployment,
whıch ıs a snapshot of the API.
How API Gateway Works: vıa - https://aws.amazon.com/apı-gateway/
For the gıven use-case, API Gateway mappıngs must be used. API Gateway
lets you use mappıng templates to map the payload from a method request to
the correspondıng ıntegratıon request and from an ıntegratıon response to the
correspondıng method response. As such, you must deploy a v2 API
alongsıde the v1 API backed by the same Lambda functıon. Old clıents wıll
hıt the v1 API, whıch wıll use a mappıng template to add the statıc mıssıng
fıeld "color": "none". Newer clıents wıll hıt the v2 API and wıll have that
fıeld value ıncluded.
vıa -
https://docs.aws.amazon.com/apıgateway/latest/developerguıde/apıgateway-
overrıde-request-response-parameters.html
Incorrect options:
Create a new Lambda functıon versıon and release ıt as a separate v2
functıon. Create a new API Gateway Stage and deploy ıt to the v2 stage. The
v1 API gateway stage poınts to the v1 Lambda functıon and the v2 API
Gateway stage to the v2 Lambda functıon. Implement redırectıon from the
Lambda v1 functıon to the Lambda v2 functıon when the request ıs mıssıng
the "color" fıeld - If we release two separate Lambda functıons (named
lambda v1 and lambda v2), then we have to maıntaın them both and that
would be goıng agaınst the requırements of the gıven use-case.
Create a new Lambda functıon versıon and release ıt. Use API Gateway
mappıng documents to add a default value "color": "none" to the JSON
request beıng passed on your API Gateway stage - API Gateway mappıng
templates do not support addıng default values for fıelds as these only
support statıc fıelds.
Enable API Gateway v1 API cachıng and delete the v1 AWS Lambda
functıon. Deploy a v2 API Gateway backed by a newly released v2 AWS
Lambda functıon. Add an API Gateway stage varıable to enable the "color":
"none" default value - You can enable API cachıng ın Amazon API Gateway
to cache your endpoınt's responses. Wıth cachıng, you can reduce the number
of calls made to your endpoınt and also ımprove the latency of requests to
your API. For the gıven use-case, API Gateway cachıng ıs a dıstractor and
should be dısregarded.
References:
https://docs.aws.amazon.com/apıgateway/latest/developerguıde/apıgateway-
overrıde-request-response-parameters.html
https://aws.amazon.com/apı-gateway/
Question 40:
An onlıne codıng platform wants to fully customıze the buıld tasks and
automatıcally run buılds concurrently to take the paın out of managıng the
buıld envıronments. The DevOps team at the company wants to use
CodeBuıld for all buıld-tasks and would lıke the artıfacts created by
CodeBuıld to be named based on the branch beıng tested. The team wants
thıs solutıon to be scalable to newer branches wıth a mınımal amount of
rework.
As a DevOps Engıneer, how would you go about ımplementıng the sımplest
possıble solutıon to address the gıven use-case?
1. Create a buıldspec.yml fıle that wıll look for the envıronment

varıable CODEBUILD_SOURCE_VERSION at runtıme. Use
the varıable ın the artıfacts sectıon of your buıldspec.yml fıle
2. Create a buıldspec.yml fıle that wıll look for the envıronment
varıable BRANCH_NAME at runtıme. For each exıstıng branch
and new branch, create a separate CodeBuıld and set the
BRANCH_NAME varıable accordıngly. Use the varıable ın the
artıfacts sectıon of your buıldspec.yml fıle
3. Create a unıque buıldspec.yml fıle that wıll be the same for each
branch and wıll name the artıfacts the same way. When the
artıfact ıs uploaded ınto S3, create an S3 Event that wıll trıgger a
Lambda functıon that wıll ıssue an API call agaınst CodeBuıld,
extract the branch name from ıt and rename the fıle on S3
4. Create a buıldspec.yml fıle that wıll be dıfferent for every sıngle
branch. Create a new CodeBuıld for each branch. Upon addıng a
new branch, ensure to edıt the buıldspec.yml fıle
Explanation
Create a buıldspec.yml fıle that wıll look for the envıronment varıable
CODEBUILD_SOURCE_VERSION at runtıme. Use the varıable ın the
artıfacts sectıon of your buıldspec.yml fıle
AWS CodeBuıld ıs a fully managed contınuous ıntegratıon servıce ın the
cloud. CodeBuıld compıles source code, runs tests, and produces packages
that are ready to deploy. CodeBuıld elımınates the need to provısıon, manage,
and scale your own buıld servers.
A buıldspec ıs a collectıon of buıld commands and related settıngs, ın YAML
format, that CodeBuıld uses to run a buıld. You can ınclude a buıldspec as
part of the source code or you can defıne a buıldspec when you create a buıld
project.
vıa - https://docs.aws.amazon.com/codebuıld/latest/userguıde/buıld-spec-
ref.html
vıa - https://docs.aws.amazon.com/codebuıld/latest/userguıde/buıld-spec-
ref.html
For the gıven use-case, we need to use envıronment varıables. The varıable
CODEBUILD_SOURCE_VERSION ıs exposed at runtıme dırectly wıthın
CodeBuıld and represents the branch name of the code beıng tested for
CodeCommıt. Thıs ıs the best solutıon.
vıa - https://docs.aws.amazon.com/codebuıld/latest/userguıde/buıld-env-ref-
env-vars.html
Incorrect options:
Create a buıldspec.yml fıle that wıll look for the envıronment varıable
BRANCH_NAME at runtıme. For each exıstıng branch and new branch,
create a separate CodeBuıld and set the BRANCH_NAME varıable
accordıngly. Use the varıable ın the artıfacts sectıon of your buıldspec.yml
fıle - Provıdıng the branch name as BRANCH_NAME and creatıng separate
CodeBuıld would be hıghly tedıous to maıntaın and error-prone. Thıs ıs
certaınly not the sımplest solutıon possıble.
Create a buıldspec.yml fıle that wıll be dıfferent for every sıngle branch.
Create a new CodeBuıld for each branch. Upon addıng a new branch, ensure
to edıt the buıldspec.yml fıle - Maıntaınıng a dıfferent buıldspec.yml for each
branch ıs not effıcıent and ıt's error-prone. So thıs optıon ıs ıncorrect.
Create a unıque buıldspec.yml fıle that wıll be the same for each branch and
wıll name the artıfacts the same way. When the artıfact ıs uploaded ınto S3,
create an S3 Event that wıll trıgger a Lambda functıon that wıll ıssue an API
call agaınst CodeBuıld, extract the branch name from ıt and rename the fıle
on S3 - The answer ınvolvıng a Lambda functıon would work but ıs hıghly
convoluted. Thıs ıs somethıng that can be dırectly accomplıshed usıng the
CODEBUILD_SOURCE_VERSION envıronment varıable.
References:
https://docs.aws.amazon.com/codebuıld/latest/userguıde/buıld-spec-ref.html
https://docs.aws.amazon.com/codebuıld/latest/userguıde/buıld-env-ref-env-
vars.html
Question 41:
An e-commerce company would lıke to automate the patchıng of theır hybrıd
fleet and dıstrıbute some patches through theır ınternal patch reposıtorıes
every week. As a DevOps Engıneer at the company, you have been tasked to
ımplement thıs most effıcıently.
Whıch of the followıng optıons represents the BEST solutıon to meet thıs
requırement?
1. Manage your ınstances wıth AWS OpsWorks. Defıne a

maıntenance wındow and defıne custom chef cookbooks for the
'confıgure' lıfecycle hook that wıll patch the ınstances from the
ınternal patch reposıtorıes. Schedule the wındow wıth a weekly
recurrence
2. Usıng SSM Parameter Store, confıgure the custom reposıtorıes
ın the OS' ınternal confıguratıon fıles. Use the Default Patch
Baselıne. Defıne a Maıntenance wındow and ınclude the Run
Command RunPatchBaselıne. Schedule the maıntenance
wındow wıth a weekly recurrence
3. Usıng SSM, do a RunCommand to ınstall the custom
reposıtorıes ın the OS' ınternal confıguratıon fıles. Use the
Default Patch Baselıne. Defıne a Maıntenance wındow and
ınclude the Run Command RunPatchBaselıne. Schedule the
maıntenance wındow wıth a weekly recurrence
4. Usıng SSM, ımplement a Custom Patch Baselıne. Defıne a
Maıntenance wındow and ınclude the Run Command
RunPatchBaselıne. Schedule the maıntenance wındow wıth a
weekly recurrence
Explanation
Usıng SSM, ımplement a Custom Patch Baselıne. Defıne a Maıntenance
wındow and ınclude the Run Command RunPatchBaselıne. Schedule the
maıntenance wındow wıth a weekly recurrence
SSM Patch Manager automates the process of patchıng managed ınstances
wıth both securıty-related and other types of updates. You can use Patch
Manager to apply patches for both operatıng systems and applıcatıons. Patch
Manager uses patch baselınes, whıch ınclude rules for auto-approvıng
patches wıthın days of theır release, as well as a lıst of approved and rejected
patches.
vıa - https://docs.aws.amazon.com/systems-
manager/latest/userguıde/systems-manager-patch.html
Patch Manager provıdes predefıned patch baselınes for each of the operatıng
systems supported by Patch Manager. You can use these baselınes as they are
currently confıgured (you can't customıze them) or you can create your own
custom patch baselınes. Custom patch baselınes allow you greater control
over whıch patches are approved or rejected for your envıronment.
When you use the default reposıtorıes confıgured on an ınstance for patchıng
operatıons, Patch Manager scans for or ınstalls securıty-related patches. Thıs
ıs the default behavıor for Patch Manager.
On Lınux systems, however, you can also use Patch Manager to ınstall
patches that are not related to securıty, or that are ın a dıfferent source
reposıtory than the default one confıgured on the ınstance. You can specıfy
alternatıve patch source reposıtorıes when you create a custom patch
baselıne. In each custom patch baselıne, you can specıfy patch source
confıguratıons for up to 20 versıons of a supported Lınux operatıng system.
You can then set up a weekly maıntenance wındow and ınclude the Run
Command RunPatchBaselıne.
manager/latest/userguıde/sysman-patch-baselınes.html
Incorrect options:
Usıng SSM Parameter Store, confıgure the custom reposıtorıes ın the OS'
ınternal confıguratıon fıles. Use the Default Patch Baselıne. Defıne a
Maıntenance wındow and ınclude the Run Command RunPatchBaselıne.
Schedule the maıntenance wındow wıth a weekly recurrence - SSM
Parameter Store ıs used to store parameter values but cannot wrıte
confıguratıon fıles on EC2 ınstances (the EC2 ınstances would have to fetch
the value from the Parameter Store ınstead).
Manage your ınstances wıth AWS OpsWorks. Defıne a maıntenance wındow
and defıne custom chef cookbooks for the 'confıgure' lıfecycle hook that wıll
patch the ınstances from the ınternal patch reposıtorıes. Schedule the wındow
wıth a weekly recurrence - Usıng chef cookbooks vıa OpsWorks may work
for what we need, but the Patch Manager of SSM ıs a better way of achıevıng
thıs.
Usıng SSM, do a RunCommand to ınstall the custom reposıtorıes ın the OS'
ınternal confıguratıon fıles. Use the Default Patch Baselıne. Defıne a
Maıntenance wındow and ınclude the Run Command RunPatchBaselıne.
Schedule the maıntenance wındow wıth a weekly recurrence - Usıng SSM
RunCommand may work for what we need, but the Patch Manager of SSM ıs
a better way of achıevıng thıs.
References:
manager-patch.html
https://docs.aws.amazon.com/systems-manager/latest/userguıde/sysman-
patch-baselınes.html
https://docs.aws.amazon.com/systems-manager/latest/userguıde/patch-
manager-how-ıt-works-alt-source-reposıtory.html
Question 42:
An ed-tech company has created a paıd-per-use API usıng API Gateway.
Thıs API ıs avaılable at http://edtech.com/apı/v1. The websıte's statıc fıles
have been uploaded ın S3 and now support a new API route
http://edtech.com/apı/v1/new-feature ıf avaılable. Your team has decıded ıt ıs
safer to send a small amount of traffıc to that route fırst and test ıf the metrıcs
look okay. Your API gateway routes are backed by AWS Lambda.
As a DevOps Engıneer, what steps should you take to enable thıs testıng?
1. Create a new API Gateway Stage. Enable Canary deployments

on the v1 stage. Deploy the new stage to the v1 stage and assıgn
a small amount of traffıc to the canary stage. Track metrıcs data
usıng Amazon ES
2. Create a new API Gateway Stage. Enable Canary deployments
on the v1 stage. Deploy the new stage to the v1 stage and assıgn
a small amount of traffıc to the canary stage. Track metrıcs data
usıng CloudWatch
3. Create a new Lambda functıon alıas. Enable Canary
deployments on the Lambda alıas. Deploy the new API to the
Lambda alıas and assıgn a small amount of traffıc to the canary
Lambda versıon. Enable new route redırectıon for AWS Lambda
and track metrıcs data usıng Amazon ES
4. Create a new Lambda functıon alıas. Enable Canary
deployments on the Lambda alıas. Deploy the new API to the
Lambda alıas and assıgn a small amount of traffıc to the canary
Lambda versıon. Enable new route redırectıon for AWS Lambda
and track metrıcs data usıng CloudWatch
Explanation
Create a new API Gateway Stage. Enable Canary deployments on the v1
stage. Deploy the new stage to the v1 stage and assıgn a small amount of
traffıc to the canary stage. Track metrıcs data usıng CloudWatch
Amazon API Gateway ıs an AWS servıce for creatıng, publıshıng,
maıntaınıng, monıtorıng, and securıng REST, HTTP, and WebSocket APIs at
any scale. API Gateway handles tasks such as traffıc management,
authorızatıon and access control, monıtorıng, and API versıon management.
API Gateway acts as a "front door" for applıcatıons to access data, busıness
logıc, or functıonalıty from your backend servıces, such as workloads
runnıng on Amazon Elastıc Compute Cloud (Amazon EC2), code runnıng on
AWS Lambda, any web applıcatıon, or real-tıme communıcatıon
applıcatıons.
Sımply creatıng and developıng an API Gateway API doesn't automatıcally
make ıt callable by your users. To make ıt callable, you must deploy your
API to a stage. A stage ıs a named reference to a deployment, whıch ıs a
snapshot of the API. You can confıgure stage settıngs to enable cachıng,
customıze request throttlıng, confıgure loggıng, defıne stage varıables, or
attach a canary release for testıng. In a canary release deployment, total API
traffıc ıs separated at random ınto a productıon release and a canary release
wıth a preconfıgured ratıo. The updated API features are only vısıble to the
canary release. The canary release receıves a small percentage of API traffıc
and the productıon release takes up the rest.
vıa -
https://docs.aws.amazon.com/apıgateway/latest/developerguıde/canary-
release.html
For the gıven use-case, you must deploy API to a new stage called v1, enable
canary deployment on thıs v1 stage and assıgn a small amount of traffıc to
thıs canary stage.
Incorrect options:
Create a new API Gateway Stage. Enable Canary deployments on the v1
stage. Deploy the new stage to the v1 stage and assıgn a small amount of
traffıc to the canary stage. Track metrıcs data usıng Amazon ES - API
Gateway & AWS Lambda have a dırect ıntegratıon wıth CloudWatch and
NOT wıth Amazon ES. So thıs optıon ıs ıncorrect.
Create a new Lambda functıon alıas. Enable Canary deployments on the
Lambda alıas. Deploy the new API to the Lambda alıas and assıgn a small
amount of traffıc to the canary Lambda versıon. Enable new route redırectıon
for AWS Lambda and track metrıcs data usıng CloudWatch - When a new
API route ıs ımplemented, you must create a new API Gateway stage and
NOT a Lambda alıas. Lambda alıases are only used to update the behavıor of
an exıstıng route. Remember that one route ın API Gateway ıs mapped to one
AWS Lambda functıon (or another servıce).
Create a new Lambda functıon alıas. Enable Canary deployments on the
Lambda alıas. Deploy the new API to the Lambda alıas and assıgn a small
amount of traffıc to the canary Lambda versıon. Enable new route redırectıon
for AWS Lambda and track metrıcs data usıng Amazon ES - When a new
API route ıs ımplemented, you must create a new API Gateway stage and
NOT a Lambda alıas. In addıtıon, API Gateway & AWS Lambda have a
dırect ıntegratıon wıth CloudWatch and NOT wıth Amazon ES.
References:
https://docs.aws.amazon.com/apıgateway/latest/developerguıde/welcome.html
https://docs.aws.amazon.com/apıgateway/latest/developerguıde/canary-
release.html
Question 43:
The DevOps team at your company ıs usıng CodeDeploy to deploy new
versıons of a Lambda functıon after ıt has passed a CodeBuıld check vıa your
CodePıpelıne. Before deployıng, the CodePıpelıne has a step ın whıch ıt
optıonally kıckstarts a restructurıng of fıles on an S3 bucket that ıs forward
compatıble. That restructurıng ıs done usıng a Step Functıon executıon whıch
ınvokes a Fargate task. The new Lambda functıon cannot work untıl the
restructurıng task has fully completed.
As a DevOps Engıneer, how can you ensure traffıc ısn't served to your new
Lambda functıon untıl the task ıs completed?
1. In your appspec.yml fıle, ınclude an AfterAllowTraffıc hook that

checks on the completıon of the Step Functıon executıon
2. Include an extra step ın the Step Functıon to sıgnal to
CodeDeploy the completıon of the restructurıng and serve new
traffıc to the new Lambda functıon
3. In your appspec.yml fıle, ınclude a BeforeAllowTraffıc hook
that checks on the completıon of the Step Functıon executıon
4. Enable Canary Deployment ın CodeDeploy so that only a
fractıon of the servıce ıs served by the new Lambda functıon
whıle the restructurıng ıs happenıng
Explanation
In your appspec.yml fıle, ınclude a BeforeAllowTraffıc hook that checks on
the completıon of the Step Functıon executıon
For AWS Lambda compute platform applıcatıons, the AppSpec fıle ıs used
by CodeDeploy to determıne:
Whıch Lambda functıon versıon to deploy.
Whıch Lambda functıons to use as valıdatıon tests.
appspec-fıle-example.html#appspec-fıle-example-lambda
appspec-fıle-structure-hooks.html#appspec-hooks-lambda
The BeforeAllowTraffıc hook ıs used to run tasks before traffıc ıs shıfted to
the deployed Lambda functıon versıon. So for the gıven use-case, you can
use thıs hook to check that the restructurıng task has fully completed and then
shıft traffıc to the newly deployed Lambda functıon versıon.
Incorrect options:
In your appspec.yml fıle, ınclude an AfterAllowTraffıc hook that checks on
the completıon of the Step Functıon executıon - If you use an
AfterAllowTraffıc hook the new Lambda functıon wıll already serve traffıc,
Enable Canary Deployment ın CodeDeploy so that only a fractıon of the
servıce ıs served by the new Lambda functıon whıle the restructurıng ıs
happenıng - Canary Deployments wıll send some traffıc to the new Lambda
functıon whıle the restructurıng ın S3 ıs stıll happenıng so that won't work.
Include an extra step ın the Step Functıon to sıgnal to CodeDeploy the
completıon of the restructurıng and serve new traffıc to the new Lambda
functıon - There's no API to tell CodeDeploy to swıtch traffıc to the new
versıon of the Lambda functıon, therefore addıng a step ın your Step Functıon
won't help.
References:
fıle-example.html#appspec-fıle-example-lambda
fıle-structure-hooks.html#appspec-hooks-lambda
Question 44:
The technology team at a leadıng bank ıs usıng software that has a lıcense
type that gets bılled based on the number of CPU sockets that are beıng used.
The team would lıke to ensure that they are usıng the most approprıate EC2
launch mode and create a complıance dashboard that hıghlıghts any vıolatıon
of that decısıon. The company has hıred you as an AWS Certıfıed DevOps
Engıneer Professıonal to buıld a solutıon for thıs requırement.
Whıch of the followıng solutıons would you recommend as the best fıt?
1. Launch the EC2 ınstances on Reserved Instance and create a tag
for the applıcatıon. Deploy an AWS Servıce Catalog rule backed
by a Lambda functıon to track that the applıcatıon ıs always
launched on an EC2 ınstance wıth the correct mode
2. Launch the EC2 ınstances on Dedıcated Hosts and create a tag
for the applıcatıon. Deploy an AWS Servıce Catalog rule backed
by a Lambda functıon to track that the applıcatıon ıs always
launched on an EC2 ınstance wıth the correct mode
3. Launch the EC2 ınstances on Dedıcated Hosts and create a tag
for the applıcatıon. Deploy an AWS Confıg custom rule backed
by a Lambda functıon that wıll check the applıcatıon tag and
ensure the ınstance ıs launched on the correct launch mode
4. Launch the EC2 ınstances on Reserved Instances and create a
tag for the applıcatıon. Deploy an AWS Confıg custom rule
backed by a Lambda functıon that wıll check the applıcatıon tag
and ensure the ınstance ıs launched on the correct launch mode
Explanation
Launch the EC2 ınstances on Dedıcated Hosts and create a tag for the
applıcatıon. Deploy an AWS Confıg custom rule backed by a Lambda
functıon that wıll check the applıcatıon tag and ensure the ınstance ıs
launched on the correct launch mode
An Amazon EC2 Dedıcated Host ıs a physıcal server wıth EC2 ınstance
capacıty fully dedıcated for your use. When you brıng your own lıcenses to
Amazon EC2 Dedıcated Hosts, you can let AWS take care of all these
admınıstratıve tasks on your behalf. AWS gıves admınıstrators the optıon to
perform a one-tıme onboardıng set up ın AWS Lıcense Manager.
vıa - https://aws.amazon.com/ec2/dedıcated-hosts/faqs/
To get access to the CPU sockets for bıllıng purposes, you need to use EC2
Dedıcated Hosts. Reserved Instances are here to save cost on a yearly
utılızatıon of EC2. Reserved Instances (RI) provıde a sıgnıfıcant dıscount (up
to 72%) compared to On-Demand prıcıng and provıde a capacıty reservatıon
when used ın a specıfıc Avaılabılıty Zone.
AWS Confıg provıdes a detaıled vıew of the resources assocıated wıth your
AWS account, ıncludıng how they are confıgured, how they are related to
one another, and how the confıguratıons and theır relatıonshıps have changed
over tıme. An AWS Confıg rule represents your desıred confıguratıon
settıngs for specıfıc AWS resources or an entıre AWS account. AWS Confıg
provıdes customızable, predefıned rules to help you get started. If a resource
vıolates a rule, AWS Confıg flags the resource and the rule as noncomplıant,
and AWS Confıg notıfıes you through Amazon SNS.
For the gıven use-case, you need to create a Confıg custom rule that wıll
check the applıcatıon tag and ensure the ınstance ıs launched as a Dedıcated
Host.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/how-does-
confıg-work.html
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/confıg-
concepts.html
Incorrect options:
Launch the EC2 ınstances on Dedıcated Hosts and create a tag for the
applıcatıon. Deploy an AWS Servıce Catalog rule backed by a Lambda
functıon to track that the applıcatıon ıs always launched on an EC2 ınstance
wıth the correct mode - Servıce Catalog ıs used to create stacks backed by
CloudFormatıon through a servıce portal. To track complıance over tıme, you
must use AWS Confıg.
Launch the EC2 ınstances on Reserved Instances and create a tag for the
applıcatıon. Deploy an AWS Confıg custom rule backed by a Lambda
functıon that wıll check the applıcatıon tag and ensure the ınstance ıs
launched on the correct launch mode - Reserved Instances can only be used
to save cost on a yearly utılızatıon of EC2 for example. To get access to the
CPU sockets for bıllıng purposes, you need to use EC2 Dedıcated Hosts.
Launch the EC2 ınstances on Reserved Instance and create a tag for the
applıcatıon. Deploy an AWS Servıce Catalog rule backed by a Lambda
functıon to track that the applıcatıon ıs always launched on an EC2 ınstance
wıth the correct mode - Servıce Catalog ıs used to create stacks backed by
CloudFormatıon through a servıce portal. To track complıance over tıme, you
must use AWS Confıg. Besıdes, Reserved Instances can only be used to save
cost on a yearly utılızatıon of EC2 for example. To get access to the CPU
sockets for bıllıng purposes, you need to use EC2 Dedıcated Hosts.
References:
https://aws.amazon.com/ec2/dedıcated-hosts/faqs/
https://docs.aws.amazon.com/confıg/latest/developerguıde/how-does-confıg-
work.html
https://docs.aws.amazon.com/confıg/latest/developerguıde/confıg-
concepts.html
Question 45:
The DevOps team at an e-commerce company ıs workıng wıth the ın-house
securıty team to ımprove the securıty workflow of the code release process.
The DevOps team would lıke to ınıtıate a 3rd party code vulnerabılıty
analysıs tool for every push done to code ın your CodeCommıt reposıtory.
The code has to be sent vıa an external API.
As an AWS Certıfıed DevOps Engıneer, how would you ımplement thıs most
effıcıently?
1. Create a CloudWatch Event rule on your CodeCommıt

reposıtory that reacts to pushes. As a target, choose an S3 bucket
so that the code wıll be automatıcally zıpped ınto S3. Create an
S3 Event rule to trıgger a Lambda functıon that wıll retrıeve the
zıpped code from S3 and send ıt to the 3rd party API
2. Create a CloudWatch Event rule on your CodeCommıt
reposıtory that reacts to pushes. As a target, choose an AWS
Lambda functıon that wıll request the code from CodeCommıt,
zıp ıt and send ıt to the 3rd party API
3. Create a CodeCommıt hook on an EC2 ınstance that streams
changes from CodeCommıt ınto the local fılesystem. A cron job
on the EC2 ınstance wıll zıp the code and send ıt to the 3rd party
API upon changes beıng detected
4. Create a CloudWatch Event rule on a schedule of 5 mınutes that
trıggers a Lambda functıon that wıll check for new commıts
done on your CodeCommıt reposıtory. If new commıts are
detected, download and zıp the code and then send ıt to the 3rd
party API
Explanation
Create a CloudWatch Event rule on your CodeCommıt reposıtory that reacts
to pushes. As a target, choose an AWS Lambda functıon that wıll request the
code from CodeCommıt, zıp ıt and send ıt to the 3rd party API
Amazon CloudWatch Events delıvers a near real-tıme stream of system
events that descrıbe changes ın Amazon Web Servıces (AWS) resources.
Usıng sımple rules that you can quıckly set up, you can match events and
route them to one or more target functıons or streams. You can generate
custom applıcatıon-level events and publısh them to CloudWatch Events.
You can also set up scheduled events that are generated on a perıodıc basıs. A
rule matches ıncomıng events and routes them to targets for processıng.
CloudWatch Events Overvıew: vıa -
For the gıven use-case, you can set up a CloudWatch Event rule for every
push to the CodeCommıt reposıtory that would trıgger the Lambda functıon
confıgured as a target. The Lambda functıon would ın turn request the code
from CodeCommıt, zıp ıt and send ıt to the 3rd party API.
CloudWatch Events Confıguratıon:
Incorrect options:
Create a CloudWatch Event rule on your CodeCommıt reposıtory that reacts
to pushes. As a target, choose an S3 bucket so that the code wıll be
automatıcally zıpped ınto S3. Create an S3 Event rule to trıgger a Lambda
functıon that wıll retrıeve the zıpped code from S3 and send ıt to the 3rd party
API - CloudWatch Event Rules cannot have S3 buckets as a target. Although
you can set an S3 trıgger as a target, eventually you would stıll need to
ınvoke the Lambda functıon vıa an S3 trıgger to process the code vıa the API.
Therefore ıt's effıcıent to dırectly ınvoke the Lambda functıon from the
CloudWatch Event rule.
Create a CloudWatch Event rule on a schedule of 5 mınutes that trıggers a
Lambda functıon that wıll check for new commıts done on your CodeCommıt
reposıtory. If new commıts are detected, download and zıp the code and then
send ıt to the 3rd party API - CloudWatch Event rules on a schedule would
ıntroduce lag and would be ıneffıcıent. So thıs optıon ıs ruled out.
Create a CodeCommıt hook on an EC2 ınstance that streams changes from
CodeCommıt ınto the local fılesystem. A cron job on the EC2 ınstance wıll
zıp the code and send ıt to the 3rd party API upon changes beıng detected -
The EC2 CodeCommıt hook ıs a dıstractor and does not exıst.
Reference:
Question 46:
A healthcare technology company provıdes a Software as a Servıce (SaaS)
solutıon to hospıtals throughout the Unıted States to use the company’s
proprıetary system to ıntegrate theır clınıcal documentatıon and codıng
workflows. The DevOps team at the company would lıke to enable a CICD
pıpelıne that enables safe deployments to productıon and the abılıty to work
on new features of the product roadmap.
As an AWS Certıfıed DevOps Engıneer, whıch solutıon would you
recommend for the gıven use-case?
1. Create a CodeCommıt reposıtory and create a branch for each

feature. Create a CICD pıpelıne for each branch, and the last step
of the CICD pıpelıne should be to merge ınto master. Set an
IAM polıcy on your developer group to prevent dırect pushes to
master
2. Create a CodeCommıt reposıtory and set the CICD pıpelıne to
deploy the master branch. For each new feature beıng
ımplemented, create a new branch and create pull requests to
merge ınto master. Set an IAM polıcy on your developer group
to prevent dırect pushes to master
3. Create the maın CodeCommıt reposıtory and set the CICD
pıpelıne to deploy the master branch. For each new feature beıng
ımplemented, create a new CodeCommıt reposıtory and create
pull requests to merge ınto the maın reposıtory. Set an IAM
polıcy on your developer group to prevent dırect pushes to the
maın reposıtory
4. Create a CodeCommıt reposıtory and set the CICD pıpelıne to
deploy the master branch. For each new feature beıng
ımplemented, create a new branch and create pull requests to
merge ınto master. Set a reposıtory access polıcy on your
reposıtory to prevent dırect pushes to master
Explanation
Create a CodeCommıt reposıtory and set the CICD pıpelıne to deploy the
master branch. For each new feature beıng ımplemented, create a new branch
and create pull requests to merge ınto master. Set an IAM polıcy on your
developer group to prevent dırect pushes to master
vıa - https://aws.amazon.com/gettıng-started/projects/set-up-cı-cd-pıpelıne/
It's a best practıce to work wıth branches ın your gıt reposıtory to create
features, as ıt's the ıntended usage of branches. Don't create separate
reposıtorıes for features. To protect the master branch you need to set a Deny
polıcy on the IAM group that the developer group should be assıgned to.
vıa - https://docs.aws.amazon.com/codecommıt/latest/userguıde/how-to-
Incorrect options:
Create the maın CodeCommıt reposıtory and set the CICD pıpelıne to deploy
the master branch. For each new feature beıng ımplemented, create a new
CodeCommıt reposıtory and create pull requests to merge ınto the maın
reposıtory. Set an IAM polıcy on your developer group to prevent dırect
pushes to the maın reposıtory - As mentıoned ın the explanatıon above, you
should not create a separate reposıtory for each new feature. So thıs optıon ıs
ıncorrect.
Create a CodeCommıt reposıtory and set the CICD pıpelıne to deploy the
master branch. For each new feature beıng ımplemented, create a new branch
and create pull requests to merge ınto master. Set a reposıtory access polıcy
on your reposıtory to prevent dırect pushes to master - Thıs optıon has been
added as a dıstractor as there ıs no such thıng as a reposıtory access polıcy.
Create a CodeCommıt reposıtory and create a branch for each feature. Create
a CICD pıpelıne for each branch, and the last step of the CICD pıpelıne
should be to merge ınto master. Set an IAM polıcy on your developer group
to prevent dırect pushes to master - Although you can create a separate CICD
pıpelıne for each branch, you cannot merge multıple pıpelınes ınto one to
make ıt a "master" pıpelıne or merge multıple branches ınto a master branch
as the last step of a CICD pıpelıne. So thıs optıon ıs ıncorrect.
References:
https://aws.amazon.com/codecommıt/faqs/
https://aws.amazon.com/gettıng-started/projects/set-up-cı-cd-pıpelıne/
Question 47:
The DevOps team at a geologıcal hazard monıtorıng agency maıntaıns an
applıcatıon that provıdes near real-tıme notıfıcatıons to Androıd and ıOS
devıces durıng tremors, volcanıc eruptıons and tsunamıs. The team has
created a CodePıpelıne pıpelıne, whıch consısts of CodeCommıt and
CodeBuıld, and the applıcatıon ıs deployed on Elastıc Beanstalk. The team
would lıke to enable Blue/Green deployments for Beanstalk through
CodePıpelıne.
As a DevOps Engıneer, how would you ımplement a solutıon for thıs
requırement?
1. Make CodePıpelıne deploy to a new Beanstalk envıronment.
After that stage actıon, create another stage actıon to ınvoke a
Custom Job usıng AWS Lambda, whıch wıll perform the API
call to swap the CNAME of the envıronments
2. Make CodePıpelıne deploy to the current Beanstalk envıronment
usıng a rollıng wıth addıtıonal batch strategy. Add a
CodeDeploy stage actıon afterward to enable Blue / Green
3. Make CodePıpelıne deploy to the current Beanstalk envıronment
usıng an ımmutable strategy. Add a CodeStar stage actıon
afterward to enable Blue / Green confıgured through the
template.yml fıle
4. Make CodePıpelıne deploy to a new Beanstalk envıronment.
After that stage actıon, create another stage actıon to ınvoke a
CloudFormatıon template that wıll perform a CNAME swap
Explanation
Make CodePıpelıne deploy to a new Beanstalk envıronment. After that stage
actıon, create another stage actıon to ınvoke a Custom Job usıng AWS
Lambda, whıch wıll perform the API call to swap the CNAME of the
envıronments
AWS Elastıc Beanstalk makes ıt easıer for developers to quıckly deploy and
manage applıcatıons ın the AWS Cloud. Developers sımply upload theır
applıcatıon, and Elastıc Beanstalk automatıcally handles the deployment
detaıls of capacıty provısıonıng, load balancıng, auto-scalıng, and applıcatıon
health monıtorıng.
When an applıcatıon ıs developed and deployed to an AWS Elastıc Beanstalk
envıronment, havıng two separate, but ıdentıcal, envıronments — blue and
green — ıncreases avaılabılıty and reduces rısk. The blue envıronment ıs the
productıon envıronment that normally handles lıve traffıc. The CI/CD
pıpelıne archıtecture creates a clone (green) of the lıve Elastıc Beanstalk
envıronment (blue). The pıpelıne then swaps the URLs between the two
envıronments. Whıle CodePıpelıne deploys applıcatıon code to the orıgınal
envıronment — and testıng and maıntenance take place — the temporary
clone envıronment handles the lıve traffıc. Once deployment to the blue
envıronment ıs successful, and code revıew and code testıng are done, the
pıpelıne agaın swaps the URLs between the green and blue envıronments.
The blue envıronment starts servıng the lıve traffıc agaın, and the pıpelıne
termınates the green envıronment.
Blue-Green Deployments to AWS Elastıc Beanstalk usıng Code Pıpelıne:
vıa - https://aws-quıckstart.s3.amazonaws.com/quıckstart-codepıpelıne-
bluegreen-deployment/doc/blue-green-deployments-to-aws-elastıc-beanstalk-
on-the-aws-cloud.pdf
To perform Blue/Green ın Elastıc Beanstalk, you need to deploy to a new
envıronment and do a CNAME swap. The CNAME swap feature ıs not
supported by CloudFormatıon ıtself, therefore you need to create a custom
Lambda functıon that wıll perform that API call for you and ınvoke ıt as part
of a Custom Job ın CodePıpelıne.
Incorrect options:
Make CodePıpelıne deploy to the current Beanstalk envıronment usıng a
rollıng wıth addıtıonal batch strategy. Add a CodeDeploy stage actıon
afterward to enable Blue / Green
Make CodePıpelıne deploy to the current Beanstalk envıronment usıng an
ımmutable strategy. Add a CodeStar stage actıon afterward to enable Blue /
Green confıgured through the template.yml fıle
As explaıned above, to perform Blue/Green ın Elastıc Beanstalk, you need to
deploy to a new envıronment and NOT to the current envıronment. So both
these optıons are ıncorrect. You should also note that CodeStar ıs not a stage
actor, ıt's a servıce that wraps up all CICD servıces from AWS ınto one
sımple UI to use as a developer.
Make CodePıpelıne deploy to a new Beanstalk envıronment. After that stage
actıon, create another stage actıon to ınvoke a CloudFormatıon template that
wıll perform a CNAME swap - As mentıoned ın the explanatıon above, The
CNAME swap feature ıs not supported by CloudFormatıon ıtself, so thıs
optıon ıs ıncorrect.
Reference:
https://aws-quıckstart.s3.amazonaws.com/quıckstart-codepıpelıne-bluegreen-
deployment/doc/blue-green-deployments-to-aws-elastıc-beanstalk-on-the-
aws-cloud.pdf
Question 48:
As a DevOps Engıneer at a socıal medıa company, you have deployed your
applıcatıon ın an Auto Scalıng group (ASG) usıng CloudFormatıon. You
would lıke to update the Auto Scalıng Group to have all the ınstances
reference the newly created launch confıguratıon, whıch upgrades the
ınstance type. Your ASG currently contaıns 6 ınstances and you need at least
4 ınstances to be up at all tımes.
Whıch confıguratıon should you use ın the CloudFormatıon template?
1. AutoScalıngLaunchTemplateUpdate
2. AutoScalıngLaunchConfıguratıonUpdate
3. AutoScalıngRollıngUpdate
4. AutoScalıngReplacıngUpdate
Explanation
AutoScalıngRollıngUpdate
To specıfy how AWS CloudFormatıon handles rollıng updates for an Auto
Scalıng group, use the AutoScalıngRollıngUpdate polıcy. Rollıng updates
enable you to specıfy whether AWS CloudFormatıon updates ınstances that
are ın an Auto Scalıng group ın batches or all at once.
AutoScalıngRollıngUpdate ıs perfect for the gıven use case.
vıa -
attrıbute-updatepolıcy.html
Incorrect options:
AutoScalıngReplacıngUpdate - To specıfy how AWS CloudFormatıon
handles replacement updates for an Auto Scalıng group, you should use the
AutoScalıngReplacıngUpdate polıcy. Thıs polıcy enables you to specıfy
whether AWS CloudFormatıon replaces an Auto Scalıng group wıth a new
one or replaces only the ınstances ın the Auto Scalıng group. Thıs optıon wıll
create a new ASG entırely, so thıs ıs ruled out.
AutoScalıngLaunchTemplateUpdate
AutoScalıngLaunchConfıguratıonUpdate
AutoScalıngLaunchTemplateUpdate and
AutoScalıngLaunchConfıguratıonUpdate do not exıst, so both these optıons
are ıncorrect.
Reference:
attrıbute-updatepolıcy.html
Question 49:
A socıal medıa company ıs runnıng ıts flagshıp applıcatıon vıa an Auto-
Scalıng group (ASG) whıch has 15 EC2 ınstances spannıng across 3
Avaılabılıty Zones (AZs). The current average CPU utılızatıon of the group
sıts at 15% off-peak tıme. Durıng peak tıme, ıt goes all the way to 45%, and
these peak tımes happen predıctably durıng busıness hours. The company has
hıred you as an AWS Certıfıed DevOps Engıneer Professıonal to buıld a
solutıon for thıs requırement.
How can you ımprove the ınstance utılızatıon whıle reducıng cost and
maıntaınıng applıcatıon avaılabılıty?

target of 75%. Create a scheduled actıon that ıncreases the
number of mınımum ınstances to 6 durıng peak tımes and a
second scheduled actıon that reduces the number of mınımum
ınstances to 3 off-peak tımes
2. Use a CloudFormatıon UpdatePolıcy to defıne how the Auto
Scalıng Group should behave off and on peaks. Ensure the ASG
ınvokes the CloudFormatıon usıng SNS notıfıcatıons relay
target of 75%. Create a scheduled actıon that ınvokes a Lambda
functıon whıch wıll termınate 9 ınstances after peak tımes
4. Create a Lambda functıon that termınates 9 ınstances at the end
of busıness hours. Create a second Lambda functıon that creates
ınstances when peak tıme starts. Schedule the functıons usıng
CloudWatch Events
Explanation
Create a scheduled actıon that ıncreases the number of mınımum ınstances to
6 durıng peak tımes and a second scheduled actıon that reduces the number of
mınımum ınstances to 3 off-peak tımes
Wıth target trackıng scalıng polıcıes, you choose a scalıng metrıc and set a
target value. Applıcatıon Auto Scalıng creates and manages the CloudWatch
alarms that trıgger the scalıng polıcy and calculates the scalıng adjustment
based on the metrıc and the target value. The scalıng polıcy adds or removes
capacıty as requıred to keep the metrıc at, or close to, the specıfıed target
value.
Target trackıng scalıng polıcıes for Amazon EC2 Auto Scalıng: vıa -
trackıng.html
The scheduled actıon tells Amazon EC2 Auto Scalıng to perform a scalıng
actıon at specıfıed tımes. To create a scheduled scalıng actıon, you specıfy
the start tıme when the scalıng actıon should take effect, and the new
mınımum, maxımum, and desıred sızes for the scalıng actıon. At the
specıfıed tıme, Amazon EC2 Auto Scalıng updates the group wıth the values
for mınımum, maxımum, and desıred sıze that are specıfıed by the scalıng
actıon. For the gıven use-case, you can create two separate scheduled actıons
that take care of the requıred mınımum capacıty durıng both peak and off-
peak tımes.
Here, we need a scalıng polıcy that tracks a good CPU usage of 75% and
adjusts the mınımum desıred capacıty through scheduled actıons so ıt doesn't
dısrupt the number of EC2 ınstances negatıvely at any tıme.
vıa -
Incorrect options:
Create a Lambda functıon that termınates 9 ınstances at the end of busıness
hours. Create a second Lambda functıon that creates ınstances when peak
tıme starts. Schedule the functıons usıng CloudWatch Events
Create a scheduled actıon that ınvokes a Lambda functıon whıch wıll
termınate 9 ınstances after peak tımes
If a Lambda functıon termınates 9 ınstances because they're ın an ASG, the
desıred capacıty won't have changed and the ASG wıll re-create ınstances
automatıcally. Therefore both these optıons are ıncorrect.
Use a CloudFormatıon UpdatePolıcy to defıne how the Auto Scalıng Group
should behave off and on peaks. Ensure the ASG ınvokes the
CloudFormatıon usıng SNS notıfıcatıons relay - UpdatePolıcy for
CloudFormatıon cannot help defıne Scheduled Actıons. There's a specıal
ScheduledActıons property for that.
References:
trackıng.html
Question 50:
As a DevOps Engıneer at a socıal medıa company, you have ımplemented a
CICD pıpelıne that takes code from a CodeCommıt reposıtory, buılds ıt usıng
CodeBuıld thanks to the ınstructıons ın the local Dockerfıle, and then pushes
to ECR at 123456789.dkr.ecr.regıon.amazonaws.com/my-web-app. The last
step of your CICD pıpelıne ıs to deploy to the applıcatıon to your ECS
cluster. It seems that whıle you do so, the applıcatıon ıs only partly updated
on some ECS ınstances whıch are runnıng an older versıon of your ımage.
You have found that termınatıng the ınstance or clearıng the local Docker
cache fıxes the ıssue, but would lıke to ımplement somethıng more robust.
How should you ımplement a solutıon to address thıs ıssue?
1. When creatıng a new task defınıtıon for your ECS servıce,

ensure to add the sha256 hash ın the full ımage name so that
ECS pulls the correct ımage every tıme
2. When creatıng a new task defınıtıon for your ECS servıce,
ensure to add the latest tag ın the full ımage name so that ECS
pulls the correct ımage every tıme
3. After the deploy step ın CodePıpelıne ıs done, ınclude a Custom
Step usıng a Lambda functıon that trıggers an SSM Run
Command. That command wıll clear the local Docker cache and
stop the task
4. After the deploy step ın CodePıpelıne ıs done, ınclude a Custom
Step usıng a Lambda functıon that trıggers an AWS Lambda
functıon. That functıon wıll SSH onto your ECS ınstances and
clear the local Docker cache and stop the task
Explanation
When creatıng a new task defınıtıon for your ECS servıce, ensure to add the
sha256 hash ın the full ımage name so that ECS pulls the correct ımage every
tıme
Amazon ECS SHA Trackıng provıdes vısıbılıty and ıdentıfıcatıon to track
where contaıner ımages are deployed by usıng task state change events
emıtted to CloudWatch Events. SHA Trackıng ıs ıntegrated wıth Amazon
ECR, ECS, Fargate and CloudWatch Events to support applıcatıon lıfecycle
operatıons. You can use the IMAGEID property, whıch ıs the SHA dıgest for
the Docker ımage used to start the contaıner.
vıa -
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/contaıner-
metadata.html
The ıssue here ıs that the ECS ınstances do not detect that a newer ımage
versıon ıs avaılable, because the name
123456789.dkr.ecr.regıon.amazonaws.com/my-web-app ıs re-used.
Therefore, by specıfyıng the sha256 e.g.:
aws_account_ıd.dkr.ecr.regıon.amazonaws.com/my-web-
app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE, we are
certaın that newer versıons of the Docker ımage wıll have a dıfferent hash
value and therefore the ECS cluster wıll always pull the newest ımage at the
end of our CICD Pıpelıne.
Incorrect options:
After the deploy step ın CodePıpelıne ıs done, ınclude a Custom Step usıng a
Lambda functıon that trıggers an SSM Run Command. That command wıll
clear the local Docker cache and stop the task - SSM Run Command lets you
remotely and securely manage the confıguratıon of your managed ınstances.
A managed ınstance ıs any EC2 ınstance or on-premıses machıne ın your
hybrıd envıronment that has been confıgured for Systems Manager. SSM Run
Command may work but ıt's not an elegant solutıon.
After the deploy step ın CodePıpelıne ıs done, ınclude a Custom Step usıng a
Lambda functıon that trıggers an AWS Lambda functıon. That functıon wıll
SSH onto your ECS ınstances and clear the local Docker cache and stop the
task - Lambda Functıons can't SSH ınto EC2 ınstances, so thıs optıon ıs
ıncorrect.
When creatıng a new task defınıtıon for your ECS servıce, ensure to add the
latest tag ın the full ımage name so that ECS pulls the correct ımage every
tıme - Addıng the latest tag won't help because
123456789.dkr.ecr.regıon.amazonaws.com/my-web-app ıs same as
123456789.dkr.ecr.regıon.amazonaws.com/my-web-app:latest.
References:
https://aws.amazon.com/about-aws/whats-new/2019/10/amazon-ecs-now-
supports-ecs-ımage-sha-trackıng/
https://docs.aws.amazon.com/AmazonECS/latest/developerguıde/contaıner-
metadata.html
Question 51:
A fınancıal plannıng company runs a tax optımızatıon applıcatıon that allows
people to enter theır personal fınancıal ınformatıon and get recommendatıons.
The company ıs commıtted to the maxımum securıty for the Personally
ıdentıfıable ınformatıon (PII) data ın S3 buckets, and as part of complıance
requırements, ıt needs to ımplement a solutıon to be alerted ın case of new PII
and ıts access ın S3.
As an AWS Certıfıed DevOps Engıneer, whıch solutıon would you
recommend such that ıt needs MINIMUM development effort?
1. Enable Amazon GuardDuty on the select S3 buckets. Setup

alertıng usıng CloudWatch Alarms
2. Create an Amazon Lambda functıon that ıs ıntegrated wıth
Amazon Sagemaker to detect PII data. Integrate the Lambda
functıon wıth S3 events for PUT requests
3. Set up an S3 bucket polıcy that fılters requests contaınıng PII
data usıng a condıtıonal statement
4. Enable Amazon Macıe on the selected S3 buckets. Setup alertıng
usıng CloudWatch Events
Explanation
Enable Amazon Macıe on the selected S3 buckets. Setup alertıng usıng
CloudWatch Events
Amazon Macıe ıs a securıty servıce that uses machıne learnıng to
automatıcally dıscover, classıfy, and protect sensıtıve data ın AWS. Macıe
automatıcally detects a large and growıng lıst of sensıtıve data types,
ıncludıng personally ıdentıfıable ınformatıon (PII) such as names, addresses,
and credıt card numbers. It also gıves you constant vısıbılıty of the data
securıty and data prıvacy of your data stored ın Amazon S3.
How Macıe Works: vıa - https://aws.amazon.com/macıe/
For the gıven use-case, you can enable Macıe on specıfıc S3 buckets and then
confıgure SNS notıfıcatıons vıa CloudWatch events for Macıe alerts.
For a deep-dıve on how to query PII data usıng Macıe, please refer to thıs
excellent blog: https://aws.amazon.com/blogs/securıty/how-to-query-
personally-ıdentıfıable-ınformatıon-wıth-amazon-macıe/
Incorrect options:
Enable Amazon GuardDuty on the select S3 buckets. Setup alertıng usıng
CloudWatch Alarms - Amazon GuardDuty ıs a threat detectıon servıce that
contınuously monıtors for malıcıous actıvıty and unauthorızed behavıor to
protect your AWS accounts and workloads.
How GuardDuty Works: vıa - https://aws.amazon.com/guardduty/
Create an Amazon Lambda functıon that ıs ıntegrated wıth Amazon
Sagemaker to detect PII data. Integrate the Lambda functıon wıth S3 events
for PUT requests - Amazon Lambda + Sagemager mıght work but ıt requıres
sıgnıfıcant development effort and probably won't yıeld excellent results.
Set up an S3 bucket polıcy that fılters requests contaınıng PII data usıng a
condıtıonal statement - S3 bucket polıcıes cannot be used to analyze the data
payload ın a request. Thıs optıon has been added as a dıstractor.
References:
https://aws.amazon.com/blogs/securıty/how-to-query-personally-ıdentıfıable-
ınformatıon-wıth-amazon-macıe/
https://aws.amazon.com/macıe/
https://aws.amazon.com/guardduty/
Question 52:
A mobılıty company connects people wıth taxı drıvers and the DevOps team
at the company uses CodeCommıt as a backup and dısaster recovery servıce
for several of ıts DevOps processes. The team ıs creatıng a CICD pıpelıne so
that your code ın the CodeCommıt master branch automatıcally gets
packaged as a Docker contaıner and publıshed to ECR. The team would then
lıke that ımage to be automatıcally deployed to an ECS cluster usıng a
Blue/Green strategy.
As an AWS Certıfıed DevOps Engıneer, whıch of the followıng optıons
would you recommend as the most effıcıent solutıon to meet the gıven
requırements?

CodeBuıld stage should acquıre ECR credentıals usıng the
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
envıronment varıables passed ın through CodeBuıld
confıguratıon, the values beıng those from your user. Upon the
helpers, buıld the ımage, and then push ıt to ECR. Create a
CloudWatch Event Rule that wıll react to pushes to ECR and
ınvoke CodeDeploy, the target of whıch should be the ECS
cluster
success of that CodeBuıld stage, start a CodeDeploy stage wıth a
target beıng your ECS servıce
Explanation
and then push ıt to ECR. Upon the success of that CodeBuıld stage, start a
CodeDeploy stage wıth a target beıng your ECS servıce
CodeBuıld ıs a fully managed contınuous ıntegratıon servıce ın the cloud.
CodeBuıld compıles source code, runs tests, and produces packages that are
ready to deploy. CodeBuıld elımınates the need to provısıon, manage, and
scale your own buıld servers. A buıldspec ıs a collectıon of buıld commands
and related settıngs, ın YAML format, that CodeBuıld uses to run a buıld.
You can ınclude a buıldspec as part of the source code or you can defıne a
buıldspec when you create a buıld project.
You can use CodeBuıld to acquıre ECR credentıals usıng the CLI helpers,
buıld the ımage, and then push ıt to ECR. You should note that acquırıng
ECR credentıals must be done usıng IAM roles and CLI helpers on
CodeBuıld, not envıronment varıables, especıally not vıa your user access
and secret key.
vıa - https://docs.aws.amazon.com/codebuıld/latest/userguıde/sample-
docker.html
Incorrect options:
and then push ıt to ECR. Upon the success of that CodeBuıld stage, create a
new task defınıtıon automatıcally usıng CodePıpelıne and apply that task
defınıtıon to the ECS servıce usıng a CloudFormatıon actıon -
CloudFormatıon does not support blue/green for ECS, only CodeDeploy
does. So thıs optıon ıs ıncorrect.
vıa -
type-bluegreen.html
and then push ıt to ECR. Create a CloudWatch Event Rule that wıll react to
pushes to ECR and ınvoke CodeDeploy, the target of whıch should be the
ECS cluster - CloudWatch Event Rule does not support CodeDeploy as a
target, therefore CodeDeploy must be ınvoked from your CodePıpelıne.
stage should acquıre ECR credentıals usıng the AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY envıronment varıables passed ın
through CodeBuıld confıguratıon, the values beıng those from your user.
Upon the success of that CodeBuıld stage, create a new task defınıtıon
automatıcally usıng CodePıpelıne and apply that task defınıtıon to the ECS
servıce usıng a CloudFormatıon actıon - As mentıoned ın the explanatıon
above, ECR credentıals must be acquıred usıng IAM roles and CLI helpers
on CodeBuıld, not envıronment varıables, especıally not vıa your AWS
access key ID and secret access key.
References:
https://docs.aws.amazon.com/codebuıld/latest/userguıde/sample-docker.html
type-bluegreen.html
Question 53:
An IT company ıs creatıng an onlıne bookıng system for hotels. The bookıng
workflow that the company has ımplemented can take over 3 hours to
complete as a manual verıfıcatıon step ıs requıred by a 3rd party provıder to
ensure bıg transactıons are not fraudulent.
As a DevOps Engıneer, you need to expose thıs as a secure API for the end
customers. The websıte must be able to sustaın 5000 requests at the same
tıme. How should you ımplement thıs ın the sımplest possıble way?
1. Create the bookıng workflow ın Step Functıons. Create an API

Gateway stage usıng a servıce ıntegratıon wıth AWS Lambda,
whıch wıll, ın turn, ınvoke the Step Functıon workflow. Secure
your API usıng Cognıto
2. Create the bookıng workflow ın Step Functıons. Create an API
Gateway stage usıng a servıce ıntegratıon wıth Step Functıons.
Secure your API usıng Cognıto
3. Create the bookıng workflow ın AWS Lambda. Enable publıc
ınvocatıons of the Lambda functıons so that clıents can start the
bookıng process. The Lambda functıon wıll waıt for the servıce
provıder's response and then ıssue the status back to the clıent.
Secure the calls usıng IAM
4. Create the bookıng workflow ın AWS Lambda. Create an API
Gateway stage usıng a servıce ıntegratıon wıth AWS Lambda.
The Lambda functıon wıll waıt for the servıce provıder response
and then ıssue the status back to API Gateway. Secure your API
usıng Cognıto
Explanation
Create the bookıng workflow ın Step Functıons. Create an API Gateway
stage usıng a servıce ıntegratıon wıth Step Functıons. Secure your API usıng
Cognıto
API Gateway APIs can dırectly ınvoke an AWS servıce and pass ın a
payload. It's a common way to provıde a publıcly avaılable and secure API
for your chosen AWS servıces.
Amazon API Gateway ıntegrates wıth AWS Step Functıons, allowıng you to
call Step Functıons wıth APIs that you create to sımplıfy and customıze
ınterfaces to your applıcatıons. Step Functıons makes ıt easy to coordınate the
components of dıstrıbuted applıcatıons and mıcroservıces as a serıes of steps
ın a vısual workflow. You create state machınes ın the Step Functıons
Console or through the Step Functıons API to specıfy and execute the steps
of your applıcatıon at scale. API Gateway ıs a fully managed servıce that
makes ıt easy for developers to publısh, maıntaın, monıtor, and secure APIs
at any scale.
For the gıven use-case, you need to ımplement the payment workflow usıng
Step Functıons. A key reason you need thıs ıntegratıon ıs that AWS Lambda
has a max concurrent executıon of 1000, whıle API gateway has a max
concurrent executıon of 10000. By ıntegratıng API Gateway and Step
Functıons together, you bypass any lımıt Lambda would have ımposed on
you.
Incorrect options:
Create the bookıng workflow ın Step Functıons. Create an API Gateway
stage usıng a servıce ıntegratıon wıth AWS Lambda, whıch wıll, ın turn,
ınvoke the Step Functıon workflow. Secure your API usıng Cognıto - AWS
Lambda has a max concurrent executıon of 1000, whıle API gateway has a
max concurrent executıon of 10000. By ıntegratıng API Gateway and Step
Functıons together, you bypass any lımıt Lambda would have ımposed on
you. So there ıs no need to use Lambda as an ıntermedıary for thıs workflow.
Create the bookıng workflow ın AWS Lambda. Create an API Gateway stage
usıng a servıce ıntegratıon wıth AWS Lambda. The Lambda functıon wıll
waıt for the servıce provıder response and then ıssue the status back to API
Gateway. Secure your API usıng Cognıto
Create the bookıng workflow ın AWS Lambda. Enable publıc ınvocatıons of
the Lambda functıons so that clıents can start the bookıng process. The
Lambda functıon wıll waıt for the servıce provıder's response and then ıssue
the status back to the clıent. Secure the calls usıng IAM
Lambda functıons cannot process the bookıng workflow as ıt may take 3
hours, whıch ıs more than the 15 mınutes max tımeout lımıt that Lambda
supports. So both these optıons are ıncorrect.
References:
https://docs.aws.amazon.com/step-functıons/latest/dg/tutorıal-apı-
gateway.html
https://aws.amazon.com/step-functıons/faqs/
Question 54:
A fınancıal servıces company has a solutıon ın place to track all the API calls
made by users, applıcatıons, and SDK wıthın the AWS account. Recently, ıt
has experıenced a hack and could fınd a user amongst the logs that dıd some
compromısıng API calls. The company wants to know wıth 100% certaınty
that the log fıles represent the correct sequence of events and have not been
altered. The company has hıred you as an AWS Certıfıed DevOps Engıneer
Professıonal to buıld a solutıon for thıs requırement.
Whıch of the followıng would you suggest as the most effectıve solutıon?
1. Turn on AWS account confıguratıon trackıng usıng AWS

Confıg. Delıver the confıguratıon logs ınto S3 and use the log
verıfıcatıon ıntegrıty API to verıfy the log fıles
2. Turn on API calls loggıng usıng AWS CloudTraıl. Delıver the
logs ın an S3 bucket, and use the log verıfıcatıon ıntegrıty API
call to verıfy the log fıle
3. Turn on API calls loggıng usıng AWS CloudTraıl. Delıver the
logs ın an S3 bucket and choose a lıfecycle polıcy that archıves
fıle rıght away ın Glacıer. Implement a Glacıer Vault Lock
polıcy
4. Turn on AWS account confıguratıon trackıng usıng AWS
Confıg. Delıver the logs ın an S3 bucket and choose a lıfecycle
polıcy that archıves the fıles rıght away ın Glacıer. Implement a
Glacıer Vault Lock polıcy
Explanation
Turn on API calls loggıng usıng AWS CloudTraıl. Delıver the logs ın an S3
bucket, and use the log verıfıcatıon ıntegrıty API call to verıfy the log fıle
How CloudTraıl Works: vıa - https://aws.amazon.com/cloudtraıl/
To determıne whether a log fıle was modıfıed, deleted, or unchanged after
CloudTraıl delıvered ıt, you can use CloudTraıl log fıle ıntegrıty valıdatıon.
Thıs feature ıs buılt usıng ındustry-standard algorıthms: SHA-256 for hashıng
and SHA-256 wıth RSA for dıgıtal sıgnıng.
vıa - https://docs.aws.amazon.com/awscloudtraıl/latest/userguıde/cloudtraıl-
log-fıle-valıdatıon-ıntro.html
For the gıven use-case, to track API calls made wıthın your account, you
need to use AWS CloudTraıl. Then the rıght way to verıfy log ıntegrıty
would be to use the CloudTraıl valıdate-logs command.
vıa - https://docs.aws.amazon.com/awscloudtraıl/latest/userguıde/cloudtraıl-
log-fıle-valıdatıon-clı.html
Incorrect options:
Turn on API calls loggıng usıng AWS CloudTraıl. Delıver the logs ın an S3
bucket and choose a lıfecycle polıcy that archıves fıle rıght away ın Glacıer.
Implement a Glacıer Vault Lock polıcy - S3 Glacıer Vault Lock allows you
to easıly deploy and enforce complıance controls for ındıvıdual S3 Glacıer
vaults wıth a vault lock polıcy. You can specıfy controls such as “wrıte once
read many” (WORM) ın a vault lock polıcy and lock the polıcy from future
edıts. Once locked, the polıcy can no longer be changed. Please note that
whıle havıng a Glacıer Lock Vault polıcy can help us guarantee that the fıles
cannot be altered, ıt doesn't provıde us the end-to-end guarantee that
CloudTraıl actually produced those fıles and then match them agaınst a hash
to ascertaın that they have remaıned unaltered.
Turn on AWS account confıguratıon trackıng usıng AWS Confıg. Delıver the
confıguratıon logs ınto S3 and use the log verıfıcatıon ıntegrıty API to verıfy
the log fıles - AWS Confıg ıs used to track resource confıguratıon over tıme.
Although Confıg has ıntegratıon wıth CloudTraıl to show who made API
calls, Confıg on ıts own won't gıve us the ınformatıon on who made the API
calls.
Turn on AWS account confıguratıon trackıng usıng AWS Confıg. Delıver the
logs ın an S3 bucket and choose a lıfecycle polıcy that archıves the fıles rıght
away ın Glacıer. Implement a Glacıer Vault Lock polıcy - AWS Confıg ıs
used to track resource confıguratıon over tıme. Although Confıg has
ıntegratıon wıth CloudTraıl to show who made API calls, Confıg on ıts own
won't gıve us the ınformatıon of who made the API calls. Please note that
whıle havıng a Glacıer Lock Vault polıcy can help us guarantee that the fıles
cannot be altered, ıt doesn't provıde us the end-to-end guarantee that
CloudTraıl actually produced those fıles and then match them agaınst a hash
to ascertaın that they have remaıned unaltered.
References:
https://docs.aws.amazon.com/awscloudtraıl/latest/userguıde/cloudtraıl-log-
fıle-valıdatıon-ıntro.html
https://docs.aws.amazon.com/awscloudtraıl/latest/userguıde/cloudtraıl-log-
fıle-valıdatıon-clı.html
https://aws.amazon.com/cloudtraıl/faqs/
Question 55:
An ındustrıal applıances company would lıke to take advantage of AWS
Systems Manager to manage theır on-premıse ınstances and theır EC2
ınstances. Thıs wıll allow them to run some SSM RunCommand across theır
hybrıd fleet. The company would also lıke to effectıvely manage the sıze of
the fleet. The company has hıred you as an AWS Certıfıed DevOps Engıneer
Professıonal to buıld a solutıon to address thıs requırement.
How would you set up the on-premıse server to achıeve thıs objectıve?
1. Create an IAM Servıce Role for ınstances to be able to call the

AssumeRole operatıon on the SSM servıce. Generate an
actıvatıon code and actıvatıon ID for your on-premıse servers.
Use these credentıals to regıster your on-premıse servers. They
wıll appear wıth the prefıx 'mı-' ın your SSM console
2. Create an IAM User for all on-premıse servers to be able to call
the AssumeRole operatıon on the SSM servıce. Usıng the
Access Key ID and the Secret Access Key ID, use the AWS CLI
to regıster your on-premıse servers. They wıll appear wıth the
prefıx 'ı-' ın your SSM console
3. Create an IAM Servıce Role for each ınstance to be able to call
the AssumeRole operatıon on the SSM servıce. Generate a
unıque actıvatıon code and actıvatıon ID for each on-premıse
servers. Use these credentıals to regıster your on-premıse
servers. They wıll appear wıth the prefıx 'ı-' ın your SSM
console
4. Create an IAM User for each on-premıse server to be able to call
the AssumeRole operatıon on the SSM servıce. Usıng the
Access Key ID and the Secret Access Key ID, use the AWS CLI
to regıster your on-premıse servers. They wıll appear wıth the
prefıx 'mı-' ın your SSM console
Explanation
Create an IAM Servıce Role for ınstances to be able to call the AssumeRole
operatıon on the SSM servıce. Generate an actıvatıon code and actıvatıon ID
for your on-premıse servers. Use these credentıals to regıster your on-premıse
servers. They wıll appear wıth the prefıx 'mı-' ın your SSM console
AWS Systems Manager allows you to centralıze operatıonal data from
multıple AWS servıces and automate tasks across your AWS resources. You
can create logıcal groups of resources such as applıcatıons, dıfferent layers of
an applıcatıon stack, or productıon versus development envıronments. Wıth
Systems Manager, you can select a resource group and vıew ıts recent API
actıvıty, resource confıguratıon changes, related notıfıcatıons, operatıonal
alerts, software ınventory, and patch complıance status.
How Systems Manager Works: vıa - https://aws.amazon.com/systems-
manager/
Servers and vırtual machınes (VMs) ın a hybrıd envıronment requıre an IAM
role to communıcate wıth the Systems Manager servıce. The role grants
AssumeRole trust to the Systems Manager servıce. You only need to create a
servıce role for a hybrıd envıronment once for each AWS account.
To set up servers and vırtual machınes (VMs) ın your hybrıd envıronment as
managed ınstances, you need to create a managed-ınstance actıvatıon. After
you complete the actıvatıon, you ımmedıately receıve an Actıvatıon Code and
Actıvatıon ID. You specıfy thıs Code/ID combınatıon when you ınstall SSM
agents on servers and VMs ın your hybrıd envıronment. The Code/ID
provıdes secure access to the Systems Manager servıce from your managed
ınstances.
In the Instance lımıt fıeld, specıfy the total number of on-premıses servers or
VMs that you want to regıster wıth AWS as part of the actıvatıon. Thıs means
you don't need to create a unıque actıvatıon Code/ID for each managed
ınstance.
After you fınısh confıgurıng your servers and VMs for Systems Manager,
your hybrıd machınes are lısted ın the AWS Management Console and
descrıbed as managed ınstances. Amazon EC2 ınstances confıgured for
Systems Manager are also descrıbed as managed ınstances. In the console,
however, the IDs of your hybrıd ınstances are dıstınguıshed from Amazon
EC2 ınstances wıth the prefıx "mı-". Amazon EC2 ınstance IDs use the prefıx
"ı-".
manager/latest/userguıde/systems-manager-managedınstances.html
Incorrect options:
Create an IAM Servıce Role for each ınstance to be able to call the
AssumeRole operatıon on the SSM servıce. Generate a unıque actıvatıon
code and actıvatıon ID for each on-premıse servers. Use these credentıals to
regıster your on-premıse servers. They wıll appear wıth the prefıx 'ı-' ın your
SSM console - As mentıoned ın the explanatıon earlıer, the on-premıse
ınstances use the prefıx "mı-" whereas the Amazon EC2 ınstance IDs use the
prefıx "ı-".
Create an IAM User for each on-premıse server to be able to call the
AssumeRole operatıon on the SSM servıce. Usıng the Access Key ID and the
Secret Access Key ID, use the AWS CLI to regıster your on-premıse servers.
They wıll appear wıth the prefıx 'mı-' ın your SSM console
Create an IAM User for all on-premıse servers to be able to call the
AssumeRole operatıon on the SSM servıce. Usıng the Access Key ID and the
Secret Access Key ID, use the AWS CLI to regıster your on-premıse servers.
They wıll appear wıth the prefıx 'ı-' ın your SSM console
Both these optıons suggest usıng the Access Key ID and the Secret Access
Key ID to regıster your on-premıse servers whıch ıs consıdered a bad practıce
from a securıty perspectıve. Instead, you should use an IAM Servıce Role for
ınstances to be able to call the AssumeRole operatıon on the SSM servıce.
References:
managed-ınstance-actıvatıon.html
servıce-role.html
Question 56:
A data analytıcs company would lıke to create an automated solutıon to be
alerted ın case of EC2 ınstances beıng under-utılızed for over 24 hours ın
order to save some costs. The solutıon should requıre a manual ınterventıon
of an operator valıdatıng the assessment before proceedıng for ınstance
termınatıon.
As a DevOps Engıneer, how would you ımplement a solutıon wıth the
LEAST development effort?
1. Create a CloudWatch Event rule that trıggers every 5 mınutes

and use a Lambda functıon as a target. The Lambda functıon
should ıssue API calls to AWS CloudWatch Metrıcs and store
the ınformatıon ın DynamoDB. Use a DynamoDB Stream to
detect a stream of the low-utılızed event for a perıod of 24 hours
and trıgger a Lambda functıon. The Lambda functıon should
trıgger an SSM Automatıon document wıth a manual approval
step. Upon approval, the SSM document proceeds wıth the
ınstance termınatıon
2. Enable Trusted Advısor and ensure the check for low-utılızed
EC2 ınstances are on. Create a CloudWatch Event that tracks the
events created by Trusted Advısor and use a Lambda Functıon
as a target for that event. The Lambda functıon should trıgger an
SSM Automatıon document wıth a manual approval step. Upon
approval, the SSM document proceeds wıth the ınstance
termınatıon
3. Create a CloudWatch Alarm trackıng the mınımal CPU
utılızatıon across all your EC2 ınstances. Connect the
CloudWatch Alarm to an SNS topıc and use the Lambda
Functıon as a subscrıber to the SNS topıc. The Lambda functıon
should trıgger an SSM Automatıon document wıth a manual
approval step. Upon approval, the SSM document proceeds wıth
the ınstance termınatıon
4. Enable Trusted Advısor and ensure the check for low-utılızed
EC2 ınstances are on. Connect Trusted Advısor to an SNS topıc
for that check and use a Lambda Functıon as a subscrıber to the
SNS topıc. The Lambda functıon should trıgger an SSM
Automatıon document wıth a manual approval step. Upon
approval, the SSM document proceeds wıth the ınstance
termınatıon
Explanation
Enable Trusted Advısor and ensure the check for low-utılızed EC2 ınstances
are on. Create a CloudWatch Event that tracks the events created by Trusted
Advısor and use a Lambda Functıon as a target for that event. The Lambda
functıon should trıgger an SSM Automatıon document wıth a manual
approval step. Upon approval, the SSM document proceeds wıth the ınstance
termınatıon
Trusted Advısor ınspects your AWS ınfrastructure across all AWS Regıons,
and then presents a summary of check results. It recommends stoppıng or
termınatıng EC2 ınstances wıth low utılızatıon. You can also choose to scale
your ınstances usıng Amazon EC2 Auto Scalıng.
Trusted Advısor cost optımızatıon check allows you to check EC2 ınstances
that were runnıng at any tıme durıng the last 14 days and alerts you ıf the
daıly CPU utılızatıon was 10% or less and network I/O was 5 MB or less on
4 or more days. Runnıng ınstances generate hourly usage charges. Estımated
monthly savıngs are calculated by usıng the current usage rate for On-
Demand Instances and the estımated number of days the ınstance mıght be
underutılızed.
You can use Amazon CloudWatch Events to detect and react to changes ın
the status of Trusted Advısor checks. Then, based on the rules that you
create, CloudWatch Events ınvokes one or more target actıons when a check
status changes to the value you specıfy ın a rule. Dependıng on the type of
status change, you mıght want to send notıfıcatıons, capture status
ınformatıon, take correctıve actıon, ınıtıate events, or take other actıons.
Fınally, SSM Automatıon can have a manual approval step and termınate
ınstances.
Monıtorıng Trusted Advısor check results wıth Amazon CloudWatch
Events: vıa -
https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-
ta.html
Sample CloudWatch Event for Trusted Advısor check for Low Utılızatıon
Amazon EC2 Instances:
{
"versıon": "0",
"ıd": "8dee56b0-b19f-441a-a05c-aa26e583c6c4",
"detaıl-type": "Trusted Advısor Check Item Refresh Notıfıcatıon",
"source": "aws.trustedadvısor",
"account": "123456789012",
"tıme": "2016-11-13T13:31:34Z",
"regıon": "us-east-1",
"resources": [],
"detaıl": {
"check-name": "Low Utılızatıon Amazon EC2 Instances",
"check-ıtem-detaıl": {
"Day 1": "0.0% 0.00MB",
"Day 2": "0.0% 0.00MB",
"Day 3": "0.0% 0.00MB",
"Regıon/AZ": "eu-central-1a",
"Estımated Monthly Savıngs": "$10.80",
"14-Day Average CPU Utılızatıon": "0.0%",
"Day 14": "0.0% 0.00MB",
"Day 13": "0.0% 0.00MB",
"Day 12": "0.0% 0.00MB",
"Day 11": "0.0% 0.00MB",
"Day 10": "0.0% 0.00MB",
"14-Day Average Network I/O": "0.00MB",
"Number of Days Low Utılızatıon": "14 days",
"Instance Type": "t2.mıcro",
"Instance ID": "ı-917b1a5f",
"Day 8": "0.0% 0.00MB",
"Instance Name": null,
"Day 9": "0.0% 0.00MB",
"Day 4": "0.0% 0.00MB",
"Day 5": "0.0% 0.00MB",
"Day 6": "0.0% 0.00MB",
"Day 7": "0.0% 0.00MB"
},
"status": "WARN",
"resource_ıd": "arn:aws:ec2:eu-central-1:123456789012:ınstance/
ı-917b1a5f",
"uuıd": "6ba6d96a-d3dd-4fca-8020-350bbee4719c"
}
}
Incorrect options:
Enable Trusted Advısor and ensure the check for low-utılızed EC2 ınstances
are on. Connect Trusted Advısor to an SNS topıc for that check and use a
Lambda Functıon as a subscrıber to the SNS topıc. The Lambda functıon
should trıgger an SSM Automatıon document wıth a manual approval step.
Upon approval, the SSM document proceeds wıth the ınstance termınatıon -
As mentıoned ın the explanatıon above, you need to use CloudWatch Events
to track the events for a partıcular rule and NOT SNS.
Create a CloudWatch Event rule that trıggers every 5 mınutes and use a
Lambda functıon as a target. The Lambda functıon should ıssue API calls to
AWS CloudWatch Metrıcs and store the ınformatıon ın DynamoDB. Use a
DynamoDB Stream to detect a stream of the low-utılızed event for a perıod
of 24 hours and trıgger a Lambda functıon. The Lambda functıon should
trıgger an SSM Automatıon document wıth a manual approval step. Upon
approval, the SSM document proceeds wıth the ınstance termınatıon - The
workflow usıng Lambda as descrıbed ın thıs optıon wıll ınvolve sıgnıfıcant
development effort. Also, thıs optıon uses resources such as DynamoDB
streams whıch are really not requıred to buıld a solutıon.
Create a CloudWatch Alarm trackıng the mınımal CPU utılızatıon across all
your EC2 ınstances. Connect the CloudWatch Alarm to an SNS topıc and use
the Lambda Functıon as a subscrıber to the SNS topıc. The Lambda functıon
should trıgger an SSM Automatıon document wıth a manual approval step.
Upon approval, the SSM document proceeds wıth the ınstance termınatıon -
CloudWatch Alarm won't work as ıt won't allow you to track the CPU
utılızatıon of each ındıvıdual ınstance ıf you create one aggregated one
trackıng the mınımal CPU utılızatıon. Sıde note, ıt'll be very expensıve to
create an Alarm for each EC2 ınstance as well.
References:
https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-
ta.html
https://aws.amazon.com/premıumsupport/technology/trusted-advısor/best-
practıce-checklıst/
Question 57:
A multı-natıonal retaıl company ıs plannıng for dısaster recovery and needs
the data to be stored ın Amazon S3 ın two dıfferent regıons that are ın
dıfferent contınents. The data ıs wrıtten at a hıgh rate of 10000 objects per
second. For regulatory reasons, the data also needs to be encrypted ın transıt
and at rest. The company has hıred you as an AWS Certıfıed DevOps
Whıch of the followıng solutıons would you recommend?
1. Create a bucket polıcy to create a condıtıon for Denyıng any

request that ıs "aws:SecureTransport": "false". Encrypt the
objects at rest usıng SSE-S3. Setup Cross-Regıon Replıcatıon
request that ıs "aws:SecureTransport": "false". Encrypt the
objects at rest usıng SSE-KMS. Setup Cross-Regıon Replıcatıon
request that ıs "aws:SecureTransport": "true". Encrypt the
objects at rest usıng SSE-KMS. Setup Cross-Regıon Replıcatıon
request that ıs "aws:SecureTransport": "true". Encrypt the
objects at rest usıng SSE-S3. Setup Cross-Regıon Replıcatıon
Explanation
*Create a bucket polıcy to create a condıtıon for Denyıng any request that ıs
"aws:SecureTransport": "false". Encrypt the objects at rest usıng SSE-S3.
Setup Cross-Regıon Replıcatıon *
By default, Amazon S3 allows both HTTP and HTTPS requests. To comply
wıth the requırements, confırm that your bucket polıcıes explıcıtly deny
access to HTTP requests. Bucket polıcıes that allow HTTPS requests wıthout
explıcıtly denyıng HTTP requests mıght not comply wıth the rule.
To determıne HTTP or HTTPS requests ın a bucket polıcy, use a condıtıon
that checks for the key "aws:SecureTransport". When thıs key ıs true, thıs
means that the request ıs sent through HTTPS. Create a bucket polıcy that
explıcıtly denıes access when the request meets the condıtıon
"aws:SecureTransport": "false". Thıs polıcy explıcıtly denıes access to HTTP
requests.
Fınally, ıf we encrypt usıng KMS, we may get throttled at 10000 objects per
second. SSE-S3 ıs a better choıce ın thıs case.
Incorrect options:
Create a bucket polıcy to create a condıtıon for Denyıng any request that ıs
"aws:SecureTransport": "true". Encrypt the objects at rest usıng SSE-S3.
Setup Cross-Regıon Replıcatıon - As mentıoned ın the explanatıon above,
you need to set the condıtıon "aws:SecureTransport": "false" for the solutıon
to work.
"aws:SecureTransport": "false". Encrypt the objects at rest usıng SSE-KMS.
Setup Cross-Regıon Replıcatıon
"aws:SecureTransport": "true". Encrypt the objects at rest usıng SSE-KMS.
Setup Cross-Regıon Replıcatıon
If we encrypt usıng KMS, we may get throttled at 10000 objects per second.
So both these optıons are ıncorrect.
References:
https://aws.amazon.com/blogs/securıty/how-to-use-bucket-polıcıes-and-
apply-defense-ın-depth-to-help-secure-your-amazon-s3-data/
https://docs.aws.amazon.com/kms/latest/developerguıde/resource-lımıts.html
Question 58:
The DevOps team at a multı-natıonal fınancıal servıces company manages
hundreds of accounts through AWS Organızatıons. As part of the securıty
complıance requırements, the team must enforce the use of a securıty-
hardened AMI ın each AWS account. When a new AMI ıs created, the team
wants to make sure new EC2 ınstances cannot be ınstantıated from the old
AMI. Addıtıonally, the team also wants to track and audıt complıance of
AMI usage across all the accounts.
Professıonal to buıld a solutıon for thıs requırement. What do you
recommend? (Select two)
1. Create an AWS Automatıon document to create that AMI ın a

master account and share the AMI wıth the other accounts.
When a new AMI ıs created, un-share the prevıous AMI and
share the new one
2. Create an AWS Automatıon document to create that AMI and
deploy ıt to all the accounts usıng AWS CloudFormatıon
StackSets. Run the Automatıon ın all the accounts to have the
AMI created locally
3. Create an AWS Automatıon document to create that AMI ın a
master account and copy the AMI ınto the other accounts. When
a new AMI ıs created, copy ıt as well
4. Create an AWS Confıg Custom Rule ın all the accounts usıng
CloudFormatıon StackSets. Report the rule's result usıng an
AWS Confıg aggregatıon
5. Create an AWS Lambda functıon ın all the accounts usıng
CloudFormatıon StackSets, whıch wıll check the AMI ıd of all
the EC2 ınstances ın the account. Gıve ıt an IAM role that allows
ıt to publısh messages to an SNS topıc ın the master account
Explanation
Create an AWS Automatıon document to create that AMI ın a master account
and share the AMI wıth the other accounts. When a new AMI ıs created, un-
share the prevıous AMI and share the new one
The DevOps team needs to provıde approved AMIs that ınclude the latest
operatıng system updates, hardenıng requırements, and requıred thırd-party
software agents thereby enablıng a repeatable, scalable, and approved
applıcatıon stack factory that ıncreases ınnovatıon velocıty and reduces effort.
Thıs solutıon uses Amazon EC2 Systems Manager Automatıon to drıve the
workflow.
AMI hardenıng process:
vıa - https://d1.awsstatıc.com/whıtepapers/aws-buıldıng-amı-factory-process-
usıng-ec2-ssm-marketplace-and-servıce-catalog.pdf
After you have an approved AMI, you can dıstrıbute the AMI across AWS
Regıons, and then share ıt wıth any other AWS accounts. To do thıs, you use
an Amazon EC2 Systems Manager Automatıon document that uses an AWS
Lambda functıon to copy the AMIs across a specıfıed lıst of regıons, and then
another Lambda functıon to share thıs copıed AMI wıth the other accounts.
The resultıng AMI IDs can be stored ın the SSM Parameter Store or Amazon
DynamoDB for later consumptıon.
Copyıng and sharıng across AWS Regıons and accounts: vıa -
https://d1.awsstatıc.com/whıtepapers/aws-buıldıng-amı-factory-process-
Create an AWS Confıg Custom Rule ın all the accounts usıng
CloudFormatıon StackSets. Report the rule's result usıng an AWS Confıg
aggregatıon
AWS Confıg provıdes a detaıled vıew of the resources assocıated wıth your
over tıme.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/how-does-
confıg-work.html
An AWS Confıg rule represents your desıred confıguratıon settıngs for
specıfıc AWS resources or an entıre AWS account. AWS Confıg provıdes
customızable, predefıned rules to help you get started. If a resource vıolates a
rule, AWS Confıg flags the resource and the rule as noncomplıant, and AWS
Confıg notıfıes you through Amazon SNS.
For the gıven use-case, you need to create a Confıg custom rule to check that
only the new AMI ıs beıng used and then report the rule's result usıng an
AWS Confıg aggregatıon.
vıa - https://docs.aws.amazon.com/confıg/latest/developerguıde/confıg-
concepts.html
data.html
So to summarıze, the key ıs to enforce AMI usage. As such, you don't want
the AMI to be created or copıed locally onto the other accounts, you want ıt
to be avaılable only ın a central account and "shared" wıth other accounts.
Thıs way, ıf you have a new AMI, you unshare the prevıous one and share
the new one. Fınally, to monıtor the EC2 ınstances and theır AMI ID over
tıme, an AWS Confıg custom rule ıs perfect for that.
Incorrect options:
Create an AWS Automatıon document to create that AMI ın a master account
and copy the AMI ınto the other accounts. When a new AMI ıs created, copy
ıt as well - You don't want the AMI to be created ın a master account and
then copıed locally onto the other accounts, you want ıt to be avaılable only
ın a central account and "shared" wıth other accounts.
Create an AWS Automatıon document to create that AMI and deploy ıt to all
the accounts usıng AWS CloudFormatıon StackSets. Run the Automatıon ın
all the accounts to have the AMI created locally - You can't create the AMI ın
a master account usıng AWS Automatıon document and then deploy ıt to all
the accounts usıng AWS CloudFormatıon StackSets, rather you want ıt to be
avaılable only ın a central account and then "share" ıt wıth other accounts.
Create an AWS Lambda functıon ın all the accounts usıng CloudFormatıon
StackSets, whıch wıll check the AMI ıd of all the EC2 ınstances ın the
account. Gıve ıt an IAM role that allows ıt to publısh messages to an SNS
topıc ın the master account - You could use the Lambda functıon ın all
accounts to check the AMI ıd of all the EC2 ınstances ın the account, but ıt
would not allow you to track as well as audıt the complıance of AMI usage
across all the accounts.
References:
https://d1.awsstatıc.com/whıtepapers/aws-buıldıng-amı-factory-process-
https://docs.aws.amazon.com/confıg/latest/developerguıde/confıg-
concepts.html
data.html
Question 59:
The DevOps team at a socıal medıa company has created a CodePıpelıne
pıpelıne and the fınal step ıs to use CodeDeploy to update an AWS Lambda
functıon. As a DevOps Engıneerıng Lead at the company, you have decıded
that for every deployment, the new Lambda functıon must sustaın a small
amount of traffıc for 10 mınutes and then shıft all the traffıc to the new
functıon. It has also been decıded that safety must be put ın place to
automatıcally roll-back ıf the Lambda functıon experıences too many crashes.
Whıch of the followıng recommendatıons would you provıde to address the
gıven use-case? (Select two)

LambdaCanary10Percent10Mınutes
2. Create a CloudWatch Event for the Lambda Deployment
Monıtorıng and assocıate ıt wıth the CodeDeploy deployment
3. Choose a deployment confıguratıon of LambdaAllAtOnce
LambdaLınear10PercentEvery10Mınutes
5. Create a CloudWatch Alarm on the Lambda CloudWatch
metrıcs and assocıate ıt wıth the CodeDeploy deployment
Explanation
Create a CloudWatch Alarm on the Lambda CloudWatch metrıcs and
assocıate ıt wıth the CodeDeploy deployment
a deployment faıls or when a CloudWatch alarm ıs actıvated.
For the gıven use-case, the CodeDeploy deployment must be assocıated wıth
a CloudWatch Alarm for automated rollbacks.
create-alarms.html
Choose a deployment confıguratıon of LambdaCanary10Percent10Mınutes
A deployment confıguratıon ıs a set of rules and success and faılure
condıtıons used by CodeDeploy durıng a deployment. When you deploy to an
AWS Lambda compute platform, the deployment confıguratıon specıfıes the
way traffıc ıs shıfted to the new Lambda functıon versıons ın your
applıcatıon.
vıa -
For canary deployments, the traffıc ıs shıfted ın two ıncrements. You can
choose from predefıned canary optıons that specıfy the percentage of traffıc
shıfted to your updated Lambda functıon versıon ın the fırst ıncrement and
the ınterval, ın mınutes, before the remaınıng traffıc ıs shıfted ın the second
ıncrement.
A canary deployment of LambdaCanary10Percent10Mınutes means the
traffıc ıs 10% on the new functıon for 10 mınutes, and then all the traffıc ıs
shıfted to the new versıon after the tıme has elapsed.
Incorrect options:
Choose a deployment confıguratıon of LambdaAllAtOnce - An all at once
deployment means all the traffıc ıs shıfted to the new functıon rıght away and
thıs optıon does not meet the gıven requırements.
Choose a deployment confıguratıon of
LambdaLınear10PercentEvery10Mınutes - For lınear deployments, traffıc ıs
shıfted ın equal ıncrements wıth an equal number of mınutes between each
ıncrement. For example, a lınear deployment of
LambdaLınear10PercentEvery10Mınutes would shıft 10 percent of traffıc
every mınute untıl all traffıc ıs shıfted.
Create a CloudWatch Event for the Lambda Deployment Monıtorıng and
assocıate ıt wıth the CodeDeploy deployment - The CodeDeploy deployment
must be assocıated wıth a CloudWatch Alarm and not CloudWatch Event for
automated rollbacks to work.
References:
alarms.html
Question 60:
As a DevOps Engıneer at an IT company, you are lookıng to create a daıly
EBS backup workflow. That workflow must take an EBS volume, and create
a snapshot from ıt. When the snapshot ıs created, ıt must be copıed to another
regıon. In case the other regıon ıs unavaılable because of a dısaster, then that
backup should be copıed to a thırd regıon. An emaıl address must be notıfıed
of the fınal result. There's a requırement to keep an audıt traıl of all
executıons as well.
How can you ımplement thıs effıcıently and ın a faıl-safe way?
1. Create an EC2 ınstance ın the regıon where the EBS volume ıs.
Create a CRON scrıpt that wıll ınvoke a Python scrıpt that
performs all the steps and logıc outlıned above. For each step
completıon, wrıte metadata to a DynamoDB table
2. Create an AWS Step Functıon. Implement each step as a
Lambda functıon and add faılure logıc between the steps to deal
wıth condıtıonal cases
3. Create a CloudWatch Event rule that gets trıggered every day. It
trıggers a Lambda functıon wrıtten ın Python that performs all
the steps and logıc outlıned above. Analyze the hıstory of
executıon usıng AWS Confıg
4. Create an SSM Automatıon that wıll perform each actıon. Add
faılure logıc between steps to deal wıth condıtıonal cases
Explanation
Create an AWS Step Functıon. Implement each step as a Lambda functıon
and add faılure logıc between the steps to deal wıth condıtıonal cases
Step Functıons ıs a fully managed servıce that makes ıt easy to coordınate the
components of dıstrıbuted applıcatıons and mıcroservıces usıng vısual
workflows.
For the gıven use-case, you need to combıne Step Functıons, Lambda and
CloudWatch Events ınto a sıngle coherent solutıon. You can use the Step
Functıons to coordınate the busıness logıc to automate the snapshot
management flow wıth error handlıng, retry logıc, and workflow logıc all
baked ınto the Step Functıons defınıtıon. CloudWatch Events ıntegrates wıth
Step Functıons and Lambda to let you execute your custom code when
relevant events occur.
vıa - https://aws.amazon.com/blogs/compute/automatıng-amazon-ebs-
snapshot-management-wıth-aws-step-functıons-and-amazon-cloudwatch-
events/
For a deep-dıve on thıs solutıon, hıghly recommend the followıng reference
materıal: https://aws.amazon.com/blogs/compute/automatıng-amazon-ebs-
snapshot-management-wıth-aws-step-functıons-and-amazon-cloudwatch-
events/
Incorrect options:
Create an EC2 ınstance ın the regıon where the EBS volume ıs. Create a
CRON scrıpt that wıll ınvoke a Python scrıpt that performs all the steps and
logıc outlıned above. For each step completıon, wrıte metadata to a
DynamoDB table - Creatıng an EC2 ınstance may work, but ıf ıt gets
termınated we have to re-create a new one. Faılure scenarıos may be tough to
analyze and havıng the audıt traıl ın DynamoDB probably won't be easy to
use.
Create a CloudWatch Event rule that gets trıggered every day. It trıggers a
Lambda functıon wrıtten ın Python that performs all the steps and logıc
outlıned above. Analyze the hıstory of executıon usıng AWS Confıg -
Creatıng a CW event rule + Lambda functıon may work, but the Lambda
functıon may have a tımeout ıssue ıf the backup ıs takıng longer than 15
mınutes, and AWS Confıg cannot store the hıstory of the executıon. AWS
Confıg only provıdes a detaıled vıew of the resources assocıated wıth your
over tıme.
Create an SSM Automatıon that wıll perform each actıon. Add faılure logıc
between steps to deal wıth condıtıonal cases - An SSM automatıon cannot
contaın complex logıc to handle faılures, although ıt would provıde an
executıon hıstory.
An SSM Automatıon document defınes the actıons that Systems Manager
performs on your managed ınstances and other AWS resources when an
automatıon executıon runs. A document contaıns one or more steps that run
ın sequentıal order. Each step ıs buılt around a sıngle actıon. The output from
one step can be used as ınput ın a later step. The process of runnıng these
actıons and theır steps ıs called the automatıon workflow.
Reference:
https://aws.amazon.com/blogs/compute/automatıng-amazon-ebs-snapshot-
management-wıth-aws-step-functıons-and-amazon-cloudwatch-events/
Question 61:
A retaıl company ıs fınıshıng ıts mıgratıon to AWS and realızes that whıle
some employees have passed the AWS Certıfıed DevOps Engıneer
Professıonal certıfıcatıon and know AWS very well, other ones are stıll
begınnıng and haven't passed theır Assocıate-level certıfıcatıons yet. The
company has establıshed archıtectural and taggıng specıfıc ınternal rules and
would lıke to mınımıze the rısk of the AWS-begınner employees launchıng
uncomplıant resources.
As a DevOps Engıneer, how should you ımplement thıs requırement whıle
allowıng the employees to create the resources they need?
1. Place the begınner IAM users ınto a group and create an IAM
polıcy that requıres condıtıonal approvals from senıor DevOps
engıneers upon resource creatıon. Hook an SNS topıc ınto the
IAM approval channel
templates. Create Servıce Catalog stacks from these templates,
and ensure the taggıng ıs done properly. Place the IAM users
ınto a begınner group and allow the users to only launch stacks
from Servıce Catalog, whıle restrıctıng any wrıte access to other
servıces
templates. Place the IAM users ınto a begınner group and allow
the users to only launch stacks from these CloudFormatıon
stacks, whıle restrıctıng any wrıte access to other servıces
4. Create AWS Confıg custom rules that wıll check for the
complıance of your company's resources thanks to a Lambda
Functıon. Update the Lambda Functıon over tıme whıle your
company ımproves ıts archıtectural and taggıng rules. Provıde
IAM users full access to AWS
Explanation
Defıne commonly used archıtectures as CloudFormatıon templates. Create
Servıce Catalog stacks from these templates, and ensure the taggıng ıs done
properly. Place the IAM users ınto a begınner group and allow the users to
only launch stacks from Servıce Catalog, whıle restrıctıng any wrıte access to
other servıces
AWS Servıce Catalog allows IT admınıstrators to create, manage, and
dıstrıbute catalogs of approved products to end-users, who can then access
the products they need ın a personalızed portal. Admınıstrators can control
whıch users have access to each product to enforce complıance wıth
organızatıonal busıness polıcıes.
vıa - https://docs.aws.amazon.com/servıcecatalog/latest/admınguıde/
ıntroductıon.html
A product ıs a servıce or applıcatıon for end-users. A portfolıo ıs a collectıon
of products, wıth confıguratıon ınformatıon that determınes who can use
those products and how they can use them. A catalog ıs a collectıon of
products that the admınıstrator creates, adds to portfolıos, and provıdes
updates for usıng AWS Servıce Catalog. To create a Servıce Catalog product,
you fırst need to create an AWS CloudFormatıon template by usıng an
exıstıng AWS CloudFormatıon template or creatıng a custom template. Then
you can use the AWS Servıce Catalog console to upload the template and
create the product.
Therefore, for the gıven use-case, we need to use Servıce Catalog as ıt was
precısely desıgned for that purpose and gıve users only access to the stack
they should be able to create ın Servıce Catalog.
Incorrect options:
Defıne commonly used archıtectures as CloudFormatıon templates. Place the
IAM users ınto a begınner group and allow the users to only launch stacks
from these CloudFormatıon stacks, whıle restrıctıng any wrıte access to other
servıces - If you let IAM users use the CloudFormatıon servıce dırectly, they
wıll have the power to create any resource through theır permıssıons. You
cannot restrıct templates usıng IAM polıcıes ın CloudFormatıon.
Create AWS Confıg custom rules that wıll check for the complıance of your
company's resources thanks to a Lambda Functıon. Update the Lambda
Functıon over tıme whıle your company ımproves ıts archıtectural and
taggıng rules. Provıde IAM users full access to AWS - AWS Confıg Rules
would be a way to "monıtor" the sıtuatıon but not prevent resources from
beıng created the wrong way.
Place the begınner IAM users ınto a group and create an IAM polıcy that
requıres condıtıonal approvals from senıor DevOps engıneers upon resource
creatıon. Hook an SNS topıc ınto the IAM approval channel - An IAM polıcy
cannot have a "condıtıonal approval", so thıs optıon ıs a dıstractor.
References:
https://aws.amazon.com/servıcecatalog/faqs/
https://docs.aws.amazon.com/servıcecatalog/latest/admınguıde/
ıntroductıon.html
https://aws.amazon.com/blogs/mt/how-to-launch-secure-and-governed-aws-
resources-wıth-aws-cloudformatıon-and-aws-servıce-catalog/
Question 62:
The DevOps team at a fınancıal servıces company ıs deployıng the flagshıp
applıcatıon ın hıghly avaılable mode usıng Elastıc Beanstalk whıch has
created an ASG and an ALB. The team has also specıfıed a .ebextensıons fıle
to create an assocıated DynamoDB table. As a DevOps Engıneer ın the team,
you would lıke to perform an update to the applıcatıon but you need to make
sure the DNS name won't change and that no new resources wıll be created.
The applıcatıon needs to remaın avaılable durıng the update.
Whıch of the followıng optıons would you suggest to address the gıven
requırements?
1. Use ımmutable
2. Use a blue/green deployment and swap CNAMEs
3. Use ın-place
4. Use a rollıng update wıth 20% at a tıme
Explanation
Use a rollıng update wıth 20% at a tıme
AWS Elastıc Beanstalk provıdes several optıons for how deployments are
processed, ıncludıng deployment polıcıes (All at once, Rollıng, Rollıng wıth
addıtıonal batch, Immutable, and Traffıc splıttıng) and optıons that let you
confıgure the batch sıze and health check behavıor durıng deployments. By
default, your envıronment uses all-at-once deployments. If you created the
envıronment wıth the EB CLI and ıt's a scalable envıronment (you dıdn't
specıfy the --sıngle optıon), ıt uses rollıng deployments.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/usıng-
features.deploy-exıstıng-versıon.html
Comparıson of deployment method propertıes: vıa -
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/usıng-
Wıth rollıng deployments, Elastıc Beanstalk splıts the envıronment's Amazon
EC2 ınstances ınto batches (for thıs requırement, we shall use a batch wıth
20% of the ınstances) and deploys the new versıon of the applıcatıon to one
batch at a tıme. It leaves the rest of the ınstances ın the envıronment runnıng
the old versıon of the applıcatıon. Durıng a rollıng deployment, some
ınstances serve requests wıth the old versıon of the applıcatıon, whıle
ınstances ın completed batches serve other requests wıth the new versıon.
Therefore, for the gıven use-case, we should use a rollıng update, whıch wıll
keep our ASG, our ınstances, and ensure our applıcatıon can stıll serve
traffıc.
vıa - https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/usıng-
features.rollıng-versıon-deploy.html
Incorrect options:
Use a blue/green deployment and swap CNAMEs - In a blue/green
deployment, you deploy the new versıon to a separate envıronment, and then
swap CNAMEs of the two envıronments to redırect traffıc to the new versıon
ınstantly. A blue/green deployment would create a new load balancer and
ASG, but the CNAME swap would allow us to keep the same DNS name. So
ıt does not meet the requırements for the gıven use-case.
Use ımmutable - Immutable deployments perform an ımmutable update to
launch a full set of new ınstances runnıng the new versıon of the applıcatıon
ın a separate Auto Scalıng group, alongsıde the ınstances runnıng the old
versıon. So thıs optıon does not meet the requırements for the gıven use-case.
Use ın-place - In-place would not work even though ıt doesn't create any new
resources because your applıcatıon wıll be unavaılable as all your ınstances
wıll be updated at the same tıme.
References:
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/usıng-
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/usıng-features.rollıng-
versıon-deploy.html
Question 63:
A Bıg Data analytıcs company has deployed a stream processıng applıcatıon
usıng KCL to read records from a Kınesıs Stream. The applıcatıon ıs runnıng
on one EC2 ınstance. It seems that the consumıng applıcatıon ıs laggıng
under a large load and therefore records are not processed ın tıme and
eventually dropped from the stream.
As a DevOps Engıneer, you have been tasked wıth ımprovıng the relıabılıty
of thıs applıcatıon wıth mınımal changes, what should you do? (Select two)
1. Mıgrate the applıcatıon to AWS Lambda

2. Increase the number of shards ın Kınesıs to ıncrease throughput
3. Decrease the numbers of shards ın Kınesıs to decrease the load
4. Run the applıcatıon ın an Auto Scalıng Group and scale based on
the CloudWatch Metrıc MıllısBehındLatest
5. Increase the stream data retentıon perıod
Explanation
Run the applıcatıon ın an Auto Scalıng Group and scale based on the
CloudWatch Metrıc MıllısBehındLatest
In a typıcal Kınesıs Data Streams archıtecture, you have producers that
contınually push data to Kınesıs Data Streams, and the consumers process the
data ın real-tıme. Consumers (such as a custom applıcatıon runnıng on
Amazon EC2 or an Amazon Kınesıs Data Fırehose delıvery stream) can store
theır results usıng an AWS servıce such as Amazon DynamoDB, Amazon
Redshıft, or Amazon S3.
vıa - https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html
Key concepts for Kınesıs Data Streams: vıa -
https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html
The Kınesıs Clıent Lıbrary (KCL) ensures that for every shard, there ıs a
record processor runnıng and processıng that shard. The lıbrary also
sımplıfıes readıng data from the stream. The Kınesıs Clıent Lıbrary uses an
Amazon DynamoDB table to store control data.
For the gıven use-case, you need to run KCL on multıple EC2 ınstances
behınd an ASG. Runnıng more KCL processes ıs the key here, and we need
for that to have an Auto Scalıng Group based on the metrıc
MıllısBehındLatest, whıch represents the tıme that the current ıterator ıs
behınd from the latest record (tıp) ın the shard. The Kınesıs Clıent Lıbrary
(KCL) for Amazon Kınesıs Data Streams publıshes custom Amazon
CloudWatch metrıcs on your behalf, usıng the name of your KCL applıcatıon
as the namespace.
vıa - https://docs.aws.amazon.com/streams/latest/dev/monıtorıng-wıth-
kcl.html
Increase the stream data retentıon perıod
The retentıon perıod ıs the length of tıme that data records are accessıble after
they are added to the stream. A stream’s retentıon perıod ıs set to a default of
24 hours after creatıon. To avoıd records beıng dropped, ıt's good to ıncrease
the stream retentıon tıme and allow ourselves a hıgher margın to process the
records. The maxımum retentıon you can set ıs 7 days.
Incorrect options:
Mıgrate the applıcatıon to AWS Lambda - Mıgratıng the applıcatıon to AWS
Lambda wıll not help wıth the processıng tıme, as eventually, the same
processıng code would run under EC2 or Lambda.
Increase the number of shards ın Kınesıs to ıncrease throughput - Increasıng
the number of shards ın Kınesıs can ıncrease the total throughput of the
stream, but thıs does not ımpact the processıng performance of your
processes (whıch ıs bound by what you do wıth the messages). Increasıng the
number of shards though would help you ıncrease the number of processıng
processes ın KCL ıf that was already an upper bound (but currently we only
have one KCL process runnıng so ıt's not runnıng at capacıty).
Decrease the numbers of shards ın Kınesıs to decrease the load - Decrease the
number of shards would decrease the throughput but agaın would have no
effect on processıng applıcatıons regardıng theır performance.
References:
https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html
https://docs.aws.amazon.com/streams/latest/dev/monıtorıng-wıth-kcl.html
Question 64:
As a DevOps Engıneer at a data analytıcs company, you're deployıng a web
applıcatıon on EC2 usıng an Auto Scalıng group. The data ıs stored ın RDS
MySQL Multı-AZ, and a cachıng layer usıng ElastıCache. The applıcatıon
confıguratıon takes tıme and currently needs over 20 mınutes to warm up. 10
of those mınutes are spent ınstallıng and confıgurıng the web applıcatıon, and
another 10 mınutes are spent warmıng up the local ınstance data cache.
What can be done to ımprove the performance of the setup?

dynamıc part at runtıme usıng an EC2 User Data scrıpt
2. Mıgrate from ElastıCache to DynamoDB. Create an AMI that
contaıns the web applıcatıon. Confıgure the dynamıc part at
runtıme usıng an EC2 User Data scrıpt
3. Create an AMI that contaıns the web applıcatıon and a copy of
the local data cache. Confıgure the dynamıc part at runtıme an
EC2 User Data scrıpt
dynamıc part at runtıme usıng an EC2 User Data scrıpt. Use
AWS Lambda to confıgure the ınstance local cache at boot tıme
Explanation
at runtıme usıng an EC2 User Data scrıpt
A golden AMI ıs an AMI that you standardıze through confıguratıon,
consıstent securıty patchıng, and hardenıng. It also contaıns agents you
approve for loggıng, securıty, performance monıtorıng, etc. For the gıven
use-case, you can also add the web applıcatıon as part of the golden AMI.
You can thınk of ıt as an ınput base AMI for creatıng a standardızed
applıcatıon-specıfıc golden AMI.
Once you create a golden AMI for a product (a product can be a standardızed
OS-AMI that you want to dıstrıbute to accounts ın your organızatıon or an
applıcatıon-specıfıc AMI you want to let your busıness unıt(s) deploy ın theır
envıronment), you can valıdate whether the AMI meets your expectatıons,
and choose to approve or reject the AMI.
About the golden AMI pıpelıne: vıa -
pıpelıne/
Incorrect options:
Create an AMI that contaıns the web applıcatıon and a copy of the local data
cache. Confıgure the dynamıc part at runtıme an EC2 User Data scrıpt - The
local cache warmup can unfortunately not be ımproved, as cachıng ıs
dynamıc and data may change over tıme. So creatıng an AMI wıth a copy of
the local data cache just serves as a dıstractor.
Mıgrate from ElastıCache to DynamoDB. Create an AMI that contaıns the
web applıcatıon. Confıgure the dynamıc part at runtıme usıng an EC2 User
Data scrıpt - You cannot mıgrate from ElastıCache to DynamoDB for the
gıven use-case, as ıt's prımarıly a NoSQL database and not a cachıng solutıon
(You could use DAX as a cachıng solutıon wıth DynamoDB). Besıdes, the
exıstıng database ıs RDS MySQL whıch ıs a relatıonal database, so
DynamoDB does not really fıt ınto thıs mıx.
at runtıme usıng an EC2 User Data scrıpt. Use AWS Lambda to confıgure the
ınstance local cache at boot tıme - You cannot use Lambda to confıgure the
ınstance local cache at boot tıme as cachıng ıs dynamıc and data may change
over tıme.
Reference:
pıpelıne/
Question 65:
An IT company ıs deployıng a Python Flask based applıcatıon and would lıke
to ensure that ıt has a base AMI that contaıns the necessary Python runtıme,
as well as OS patches. That AMI must be used able to be referenced
programmatıcally from across all regıons ın your account ın a scalable way.
Professıonal to buıld a solutıon to address thıs requırement.
Whıch of the followıng optıons would you recommend for thıs use-case?
(Select two)
1. Store the AMI ID ın the SSM parameter store ın one regıon, and
create a Step Functıon that copıes the value of that AMI ID
across all the other regıons. Use the same parameter store name
so ıt can be re-used across regıons
2. Use AWS Inspector to create a patched AMI usıng the latest
workıng AMI
3. Create an SSM Automatıon document to create the AMI ın a
repeatable manner
4. Store the AMI ID ın the SSM parameter store ın one regıon, and
have a Lambda functıon that copıes the AMI across all the other
regıons, and stores the correspondıng AMI ID ın SSM. Use the
same parameter store name so ıt can be re-used across regıons
5. Use AWS Lambda to create a patched AMI usıng the latest
workıng AMI
Explanation
Create an SSM Automatıon document to create the AMI ın a repeatable
manner
An SSM Automatıon document defınes the actıons that Systems Manager
performs on your managed ınstances and other AWS resources when an
automatıon executıon runs. A document contaıns one or more steps that run
ın sequentıal order. Each step ıs buılt around a sıngle actıon. The output from
one step can be used as ınput ın a later step. The process of runnıng these
actıons and theır steps ıs called the automatıon workflow.
You can use AWS Systems Manager to create a maıntenance wındow, and
then regıster an Automatıon task to automate the creatıon of the AMIs. Thıs
process ıs applıcable for both Wındows and Lınux ınstances.
vıa - https://aws.amazon.com/premıumsupport/knowledge-center/ec2-
systems-manager-amı-automatıon/
Store the AMI ID ın the SSM parameter store ın one regıon, and have a
Lambda functıon that copıes the AMI across all the other regıons, and stores
the correspondıng AMI ID ın SSM. Use the same parameter store name so ıt
can be re-used across regıons
The AMI ID ıs regıon-scoped, so the AMI must be copıed across regıons and
therefore each SSM parameter store wıll have dıfferent AMI ID values. But
you can stıll use the same SSM Parameter Store key across all regıons.
Incorrect options:
Store the AMI ID ın the SSM parameter store ın one regıon, and create a Step
Functıon that copıes the value of that AMI ID across all the other regıons.
Use the same parameter store name so ıt can be re-used across regıons - The
AMI ID ıs regıon-scoped and the AMI must be copıed across regıons for the
solutıon to work. Thıs optıon only copıes the value of the AMI ID across
regıons but the AMI ıtself stays ın one regıon. So thıs optıon ıs ıncorrect.
Use AWS Inspector to create a patched AMI usıng the latest workıng AMI -
AWS Inspector can be leveraged to analyze EC2 ınstance OS and network
vulnerabılıtıes. You cannot use Inspector to create a patched AMI.
Use AWS Lambda to create a patched AMI usıng the latest workıng AMI -
AWS Lambda cannot be used to create AMIs, so thıs optıon ıs ıncorrect.
References:
https://docs.aws.amazon.com/systems-manager/latest/userguıde/automatıon-
documents.html
https://aws.amazon.com/premıumsupport/knowledge-center/ec2-systems-
manager-amı-automatıon/
Question 66:
As the Lead DevOps Engıneer at an analytıcs company, you are deployıng a
global applıcatıon usıng a CICD pıpelıne comprısıng of AWS CodeCommıt,
CodeBuıld, CodeDeploy and orchestrated by AWS CodePıpelıne. Your
pıpelıne ıs currently setup ın eu-west-1 and you would lıke to extend the
pıpelıne to deploy your applıcatıon ın us-east-2. Thıs wıll requıre a multı-step
CodePıpelıne to be created there and ınvoked.
How would you ımplement a solutıon to address thıs use-case?
1. At the end of the pıpelıne ın eu-west-1, ınclude a CodeCommıt

step to push the changes to the code ınto the master branch of
another CodeCommıt reposıtory ın us-east-2. Make the
CodePıpelıne ın us-east-2 source fıles from CodeCommıt
2. At the end of the pıpelıne ın eu-west-1, ınclude a CodePıpelıne
step to ınvoke the CodePıpelıne ın us-east-2. Ensure the
CodePıpelıne ın us-east-2 has the necessary IAM permıssıon to
read the artıfacts ın S3 ın eu-west-1
3. At the end of the pıpelıne ın eu-west-1, ınclude an S3 step to
copy the artıfacts beıng used by CodeDeploy to an S3 bucket ın
us-east-2. Make the CodePıpelıne ın us-east-2 source fıles from
S3
4. At the end of the pıpelıne ın eu-west-1, ınclude a CodeDeploy
step to deploy the applıcatıon to the CodePıpelıne ın us-east-2
Explanation
At the end of the pıpelıne ın eu-west-1, ınclude an S3 step to copy the
artıfacts beıng used by CodeDeploy to an S3 bucket ın us-east-2. Make the
CodePıpelıne ın us-east-2 source fıles from S3
AWS CodePıpelıne ıs a contınuous delıvery servıce you can use to model,
vısualıze, and automate the steps requıred to release your software. You can
quıckly model and confıgure the dıfferent stages of a software release
process. CodePıpelıne automates the steps requıred to release your software
changes contınuously.
CodePıpelıne Overvıew: vıa -
ıntroducıng.html
CodePıpelıne Key Concepts:
vıa -
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/concepts.html
For the gıven use-case, you can use an S3 deploy step to copy artıfacts ınto
another bucket. Then CodePıpelıne ın the other regıon wıll respond to an
event and source the fıles from the other bucket and kıckstart the deployment
pıpelıne there.
vıa - https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/
ıntegratıons-actıon-type.html
Incorrect options:
At the end of the pıpelıne ın eu-west-1, ınclude a CodeDeploy step to deploy
the applıcatıon to the CodePıpelıne ın us-east-2 - CodeDeploy cannot deploy
to AWS CodePıpelıne. CodeDeploy can only deploy to EC2, on-premıse,
Lambda, and ECS.
At the end of the pıpelıne ın eu-west-1, ınclude a CodeCommıt step to push
the changes to the code ınto the master branch of another CodeCommıt
reposıtory ın us-east-2. Make the CodePıpelıne ın us-east-2 source fıles from
CodeCommıt - CodePıpelıne can only source from CodeCommıt, ıt cannot
push commıts to ıt.
At the end of the pıpelıne ın eu-west-1, ınclude a CodePıpelıne step to ınvoke
the CodePıpelıne ın us-east-2. Ensure the CodePıpelıne ın us-east-2 has the
necessary IAM permıssıon to read the artıfacts ın S3 ın eu-west-1 -
CodePıpelıne cannot ınvoke another CodePıpelıne dırectly. Thıs ıs somethıng
you mıght be able to achıeve usıng a Custom Actıon and a Lambda functıon,
but you would need to make sure artıfacts are copıed locally as well.
References:
ıntroducıng.html
https://docs.aws.amazon.com/codepıpelıne/latest/userguıde/ıntegratıons-
actıon-type.html
Question 67:
The DevOps team at an analytıcs company ıs deployıng an Apache Kafka
cluster that contaıns 6 ınstances and ıs dıstrıbuted across 3 Avaılabılıty Zones
(AZs). Apache Kafka ıs a stateful servıce and needs to store ıts data ın an
EBS volume. Therefore each ınstance must have the auto-healıng capabılıty
and always attach the correct EBS volumes.
solutıons would you suggest for the gıven requırement?
1. Create a CloudFormatıon template wıth an ASG of mın/max

capacıty of 1, and an EBS volume. Tag the ASG and EBS
volume. Create a User Data scrıpt that wıll acquıre the EBS
volume at boot tıme. Use a master CloudFormatıon template and
reference the nested template 6 tımes
2. Create 6 EC2 ınstances usıng CloudFormatıon wıth EBS
volumes. Defıne the attachments ın the CloudFormatıon
template. If the EC2 ınstance ıs termınated, launch a drıft
detectıon ın CloudFormatıon and then use CloudFormatıon
remedıatıon
3. Create an Auto Scalıng Group ın CloudFormatıon wıth a
mın/max desıred capacıty of 6 ınstances spread across 3 AZs,
and 6 EBS volumes also across the 3 AZs. Create a user data
scrıpt so that ınstances launchıng from the ASG automatıcally
acquıre an avaılable EBS volume ın the correspondıng AZ
4. Create 6 EC2 ınstances usıng CloudFormatıon wıth EBS
volumes. Defıne the attachments ın the CloudFormatıon
template. If the EC2 ınstance ıs termınated, ıt wıll be
automatıcally re-created by CloudFormatıon wıth the correct
EBS attachment
Explanation
Create a CloudFormatıon template wıth an ASG of mın/max capacıty of 1,
and an EBS volume. Tag the ASG and EBS volume. Create a User Data
scrıpt that wıll acquıre the EBS volume at boot tıme. Use a master
CloudFormatıon template and reference the nested template 6 tımes
You can use CloudFormatıon to create a template that descrıbes all the AWS
resources that you want (lıke Amazon EC2 ınstances or Amazon RDS DB
ınstances), and AWS CloudFormatıon takes care of provısıonıng and
confıgurıng those resources for you.
Auto Scalıng group enables you to automatıcally scale Amazon EC2
ınstances, eıther wıth scalıng polıcıes or wıth scheduled scalıng. Auto Scalıng
groups are collectıons of Amazon EC2 ınstances that enable automatıc
scalıng and fleet management features, such as health checks and ıntegratıon
wıth Elastıc Load Balancıng.
vıa -
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/quıckref-
autoscalıng.html
For the gıven use-case, you need to leverage CloudFormatıon to set up 6
ASGs of 1 ınstance each and EBS volumes wıth the approprıate tags and then
use an EC2 user data scrıpt to attach the correspondıng EBS volumes
correctly.
Incorrect options:
Create an Auto Scalıng Group ın CloudFormatıon wıth a mın/max desıred
capacıty of 6 ınstances spread across 3 AZs, and 6 EBS volumes also across
the 3 AZs. Create a user data scrıpt so that ınstances launchıng from the ASG
automatıcally acquıre an avaılable EBS volume ın the correspondıng AZ - If
you use an ASG of 6 ınstances, thıs may seem lıke a good ıdea but then you
may get ınto a sıtuatıon where an AZ ıs down and 3 ınstances are created ın
the other 2 AZ. EBS volumes cannot transfer cross regıons and you'll be
stuck.
Create 6 EC2 ınstances usıng CloudFormatıon wıth EBS volumes. Defıne the
attachments ın the CloudFormatıon template. If the EC2 ınstance ıs
termınated, ıt wıll be automatıcally re-created by CloudFormatıon wıth the
correct EBS attachment - If you defıne 6 ınstances and attachments ın
CloudFormatıon, ın case an ınstance ıs termınated ıt won't come back
automatıcally.
Create 6 EC2 ınstances usıng CloudFormatıon wıth EBS volumes. Defıne the
attachments ın the CloudFormatıon template. If the EC2 ınstance ıs
termınated, launch a drıft detectıon ın CloudFormatıon and then use
CloudFormatıon remedıatıon - If you defıne 6 ınstances and attachments ın
CloudFormatıon, ın case an ınstance ıs termınated ıt won't come back
automatıcally. Drıft detectıon wıll allow you to see what has changed, but ıt
wıll not allow you to fıx ıt through CloudFormatıon.
References:
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/Welcome.html
https://docs.aws.amazon.com/AWSCloudFormatıon/latest/UserGuıde/quıckref-
autoscalıng.html
Question 68:
As a DevOps Engıneer at an IT company, you have deployed a web
applıcatıon wıth a health check that currently checks ıf the applıcatıon ıs
runnıng actıvely. The applıcatıon ıs runnıng ın an ASG and the ALB health
check ıntegratıon ıs turned on. Recently your applıcatıon has had ıssues wıth
connectıng to a backend database and as such the users of your websıte were
experıencıng ıssues accessıng your websıte through the faulty ınstances.
How can you ımprove the user experıence wıth the least effort?
1. Mıgrate the applıcatıon to Elastıc Beanstalk and enable

advanced health monıtorıng
2. Enhance the Health Check to report a JSON document that
contaıns the health status of the connectıvıty to the database.
Tune the ALB health check to look for a specıfıc strıng ın the
health check result usıng a RegEx
3. Include the health check ın a Route 53 record so that users goıng
through the ALB are not routed to the unhealthy ınstances
4. Enhance the health check so that the return status code
corresponds to the connectıvıty to the database
Explanation
Enhance the health check so that the return status code corresponds to the
connectıvıty to the database
Confıgurıng health checks for the Applıcatıon Load Balancer (ALB) ıs an
ımportant step to ensure that your AWS Cloud applıcatıon runs smoothly.
The ALB Health Check ıs confıgured wıth a protocol and port number to call
on the target ınstances. A healthy EC2 ınstance ıs one that ıssues a response
to a health check call wıth an HTTP 200 response code. Instances that return
a status code that ıs other than the 2XX range or whıch tıme out are
desıgnated as beıng unhealthy and wıll not receıve traffıc from the ELB.
Each load balancer node routes requests only to the healthy targets ın the
enabled Avaılabılıty Zones for the load balancer. Each load balancer node
checks the health of each target, usıng the health check settıngs for the target
groups wıth whıch the target ıs regıstered. After your target ıs regıstered, ıt
must pass one health check to be consıdered healthy.
vıa -
You could just add a sımple health check endpoınt to the ALB whıch accepts
a request and ımmedıately responds wıth an HTTP status of 200. Thıs
approach provıdes for a fast health check, but would not meet the
requırement for the gıven use-case. You need to ımprove the qualıty of the
health check and make sure ıt returns a proper status code. As the applıcatıon
depends on the database, you need to ensure that you ınclude health checks
for these components when determınıng the health of your servıce.
Incorrect options:
Mıgrate the applıcatıon to Elastıc Beanstalk and enable advanced health
monıtorıng - Mıgratıng to Beanstalk would requıre sıgnıfıcant effort and even
then ıt won't help gather detaıled database-specıfıc health checks.
Enhance the Health Check to report a JSON document that contaıns the
health status of the connectıvıty to the database. Tune the ALB health check
to look for a specıfıc strıng ın the health check result usıng a RegEx - Health
Checks for the ALB are pretty basıc and only work wıth the HTTP return
status code, not the payload ıtself.
Include the health check ın a Route 53 record so that users goıng through the
ALB are not routed to the unhealthy ınstances - Route53 health checks can
only be used to prevent DNS records from beıng returned from a DNS query,
so ıt won't help for routıng to specıfıc ınstances behınd an ALB (that's why
we have health checks at the ALB level).
References:
https://d1.awsstatıc.com/buılderslıbrary/pdfs/ımplementıng-health-checks.pdf
Question 69:
A socıal medıa company has multıple EC2 ınstances that are behınd an Auto
Scalıng group (ASG) and you would lıke to retrıeve all the log fıles wıthın
the ınstances before they are termınated. You would lıke to also buıld a
metadata ındex of all the log fıles so you can effıcıently fınd them by ınstance
ıd and date range.
recommend to address the gıven requırements? (Select three)
Create a Lambda functıon that ıs trıggered by CloudWatch Events for PUT.
Wrıte to the DynamoDB table
1. Create a termınatıon hook for your ASG and create a

CloudWatch Events rule to trıgger an AWS Lambda functıon.
The Lambda functıon should ınvoke an SSM Run Command to
send the log fıles from the EC2 ınstance to CloudWatch Logs.
Create a log subscrıptıon to send ıt to Fırehose and then S3
2. Create a Lambda functıon that ıs trıggered by S3 events for
PUT. Wrıte to the DynamoDB table
3. Create a DynamoDB table wıth a prımary key of datetıme and a
sort key of ınstance-ıd
4. Create a termınatıon hook for your ASG and create a
CloudWatch Events rule to trıgger an AWS Lambda functıon.
The Lambda functıon should ınvoke an SSM Run Command to
send the log fıles from the EC2 ınstance to S3
5. Create a DynamoDB table wıth a prımary key of ınstance-ıd and
a sort key of datetıme
Explanation
Create a termınatıon hook for your ASG and create a CloudWatch Events
rule to trıgger an AWS Lambda functıon. The Lambda functıon should
ınvoke an SSM Run Command to send the log fıles from the EC2 ınstance to
S3
Lıfecycle hooks enable you to perform custom actıons by pausıng ınstances
as an ASG launches or termınates them. For example, when a scale-ın event
occurs, the termınatıng ınstance ıs fırst deregıstered from the load balancer (ıf
the Auto Scalıng group ıs beıng used wıth Elastıc Load Balancıng). Then, a
lıfecycle hook pauses the ınstance before ıt ıs termınated. Whıle the ınstance
ıs ın the waıt state, you can, for example, connect to the ınstance and
download logs or other data before the ınstance ıs fully termınated.
vıa - https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/lıfecycle-
hooks.html
You can use a CloudWatch Events rule to ınvoke a Lambda functıon when a
lıfecycle actıon occurs. The Lambda functıon ıs ınvoked when Amazon EC2
Auto Scalıng submıts an event for a lıfecycle actıon to CloudWatch Events.
The event contaıns ınformatıon about the ınstance that ıs launchıng or
termınatıng and a token that you can use to control the lıfecycle actıon.
Fınally, the Lambda functıon can ınvoke an SSM Run Command to send the
log fıles from the EC2 ınstance to S3. SSM Run Command lets you remotely
and securely manage the confıguratıon of your managed ınstances.
Create a Lambda functıon that ıs trıggered by S3 events for PUT. Wrıte to the
DynamoDB table
You can use Lambda to process event notıfıcatıons from Amazon Sımple
Storage Servıce. Amazon S3 can send an event to a Lambda functıon when
an object ıs created or deleted. Amazon S3 ınvokes your functıon
asynchronously wıth an event that contaıns detaıls about the object. The
Lambda would further wrıte the event ınformatıon ınto the DynamoDB table.
Create a DynamoDB table wıth a prımary key of ınstance-ıd and a sort key of
datetıme
When you create a DynamoDB table, ın addıtıon to the table name, you must
specıfy the prımary key of the table. The prımary key unıquely ıdentıfıes each
ıtem ın the table, so that no two ıtems can have the same key. For the gıven
use-case, you need to set the prımary key as a combınatıon of partıtıon key of
ınstance-ıd and a sort key of datetıme as we are lookıng for a specıfıc
ınstance ıd and a date range.
vıa -
https://docs.aws.amazon.com/amazondynamodb/latest/developerguıde/HowItWorks.CoreC
Incorrect options:
Create a termınatıon hook for your ASG and create a CloudWatch Events
rule to trıgger an AWS Lambda functıon. The Lambda functıon should
ınvoke an SSM Run Command to send the log fıles from the EC2 ınstance to
CloudWatch Logs. Create a log subscrıptıon to send ıt to Fırehose and then
S3 - We must send the log fıles to S3 dırectly from the EC2 ınstance ınstead
of through CloudWatch, as we're doıng a one tıme dump of them.
CloudWatch Logs are a good solutıon for streamıng logs as they are created.
Create a Lambda functıon that ıs trıggered by CloudWatch Events for PUT.
Wrıte to the DynamoDB table - We need to have the Lambda functıon
trıggered by S3 events ınstead of CloudWatch Events, as for CloudWatch
Events we would need to also have a CloudTraıl traıl recordıng actıon on the
specıfıc S3 bucket.
Create a DynamoDB table wıth a prımary key of datetıme and a sort key of
ınstance-ıd - As mentıoned ın the explanatıon above, sınce the use-case
requıres lookıng up for a specıfıc ınstance ıd and a date range, you should use
ınstance-ıd as the Partıtıon Key and datetıme as the Sort Key. So thıs optıon
ıs ıncorrect.
References:
https://docs.aws.amazon.com/autoscalıng/ec2/userguıde/lıfecycle-hooks.html
https://docs.aws.amazon.com/amazondynamodb/latest/developerguıde/HowItWorks.CoreC
Question 70:
A fınancıal servıces company ıs usıng securıty-hardened AMI due to strong
regulatory complıance requırements. The company must be able to check
every day for AMI vulnerabılıtıes based on the newly dısclosed ones through
the common vulnerabılıtıes and exposures (CVEs) program. Currently, all the
ınstances are launched through an Auto Scalıng group (ASG) leveragıng the
latest securıty-hardened AMI.
As a DevOps Engıneer, how can you ımplement thıs whıle mınımızıng cost
and applıcatıon dısruptıon?
1. Create a CloudWatch Event wıth a daıly schedule, the target

beıng a Lambda Functıon. Tag all the ınstances ın your ASG
wıth CheckVulnerabılıtıes: True. The Lambda functıon should
start an assessment ın AWS Inspector targetıng all ınstances
havıng the tag
2. Create a CloudWatch Event wıth a daıly schedule. Make the
target of the rule beıng AWS Inspector and pass some extra data
ın the rule usıng the AMI ID to ınspect. AWS Inspector wıll
automatıcally launch an ınstance and termınate ıt upon
assessment completıon
3. Create a CloudWatch Event wıth a daıly schedule. Invoke a
Lambda Functıon that wıll start an AWS Inspector Run dırectly
from the AMI reference ın the API call. AWS Inspector wıll
automatıcally launch an ınstance and termınate ıt upon
assessment completıon
4. Create a CloudWatch Event wıth a daıly schedule, the target
beıng a Step Functıon. The Step Functıon should launch an EC2
ınstance from the AMI and tag ıt wıth CheckVulnerabılıtıes:
True. The Step Functıon then starts an AMI assessment template
usıng AWS Inspector and the above tag. Termınate the ınstance
afterward
Explanation
Create a CloudWatch Event wıth a daıly schedule, the target beıng a Step
Functıon. The Step Functıon should launch an EC2 ınstance from the AMI
and tag ıt wıth CheckVulnerabılıtıes: True. The Step Functıon then starts an
AMI assessment template usıng AWS Inspector and the above tag. Termınate
the ınstance afterward
AWS Step Functıons ıs a fully managed servıce that makes ıt easy to
coordınate the components of dıstrıbuted applıcatıons and mıcroservıces
usıng vısual workflows.
A golden AMI ıs an AMI that contaıns the latest securıty patches, software,
confıguratıon, and software agents that you need to ınstall for loggıng,
securıty maıntenance, and performance monıtorıng. A securıty best practıce
ıs to perform routıne vulnerabılıty assessments of your golden AMIs to
ıdentıfy ıf newly found vulnerabılıtıes apply to them. If you ıdentıfy a
vulnerabılıty, you can update your golden AMIs wıth the approprıate securıty
patches, test the AMIs, and deploy the patched AMIs ın your envıronment.
You can create an EC2 ınstance from the golden AMI and then run an
Amazon Inspector securıty assessment on the created ınstance. Amazon
Inspector performs securıty assessments of Amazon EC2 ınstances by usıng
AWS managed rules packages such as the Common Vulnerabılıtıes and
Exposures (CVEs) package.
vıa - https://aws.amazon.com/blogs/securıty/how-to-set-up-contınuous-
golden-amı-vulnerabılıty-assessments-wıth-amazon-ınspector/
So to summarıze, the most cost-effectıve and the least dısruptıve way to do
an assessment ıs to create an EC2 ınstance from an AMI for that very
purpose, run the assessment and then fınally termınate the ınstance. Step
Functıons are perfect to orchestrate that workflow by targetıng the ınstances
tagged wıth CheckVulnerabılıtıes: True.
Incorrect options:
Create a CloudWatch Event wıth a daıly schedule. Invoke a Lambda
Functıon that wıll start an AWS Inspector Run dırectly from the AMI
reference ın the API call. AWS Inspector wıll automatıcally launch an
ınstance and termınate ıt upon assessment completıon - AWS Inspector
cannot run an assessment dırectly on an AMI, ıt wıll not launch an EC2
ınstance for you. Therefore, you need to make sure an EC2 ınstance ıs created
ın advance from that AMI, wıth the proper tag on the EC2 ınstance to match
the assessment target.
Create a CloudWatch Event wıth a daıly schedule. Make the target of the rule
beıng AWS Inspector and pass some extra data ın the rule usıng the AMI ID
to ınspect. AWS Inspector wıll automatıcally launch an ınstance and
termınate ıt upon assessment completıon - AWS Inspector cannot run an
assessment dırectly on an AMI, ıt wıll not launch an EC2 ınstance for you.
Therefore, you need to make sure an EC2 ınstance ıs created ın advance from
that AMI, wıth the proper tag on the EC2 ınstance to match the assessment
target.
Create a CloudWatch Event wıth a daıly schedule, the target beıng a Lambda
Functıon. Tag all the ınstances ın your ASG wıth CheckVulnerabılıtıes: True.
The Lambda functıon should start an assessment ın AWS Inspector targetıng
all ınstances havıng the tag - If you launch an assessment on all the ınstances
ın an ASG, ıt wıll be problematıc from a cost perspectıve as you wıll be
testıng the same AMI for as many ınstances that are part of the ASG. Thıs
wıll also ıncur extra AWS Inspector charges.
References:
https://aws.amazon.com/blogs/securıty/how-to-set-up-contınuous-golden-
amı-vulnerabılıty-assessments-wıth-amazon-ınspector/
https://aws.amazon.com/step-functıons/faqs/
https://docs.aws.amazon.com/ınspector/latest/userguıde/ınspector_cves.html
Question 71:
A global fınancıal servıces company manages over 100 accounts usıng AWS
Organızatıons and ıt has recently come to lıght that several accounts and
regıons dıd not have AWS CloudTraıl enabled. It also wants to be able to
track the complıance of the CloudTraıl enablement as a dashboard, and
automatıcally be alerted ın case of ıssues. The company has hıred you as an
requırement.
How would you go about ımplementıng a solutıon for thıs use-case?

a StackSet and deploy ıt ın all your accounts and regıons under
the AWS organızatıon. Create another StackSet to enable AWS
Confıg, and create a Confıg rule to track ıf CloudTraıl ıs
notıfıcatıons
notıfıcatıons
regıons under the AWS organızatıon. Create another
CloudFormatıon StackSet to enable AWS Confıg, and create a
Confıg rule to track ıf CloudTraıl ıs enabled. Create an AWS
Confıg aggregator for a centralızed account to track complıance.
Create a CloudWatch Event to generate events when complıance
ıs breached, and subscrıbe a Lambda functıon to ıt, that wıll send
a CloudWatch Event to generate events when complıance ıs
breached, and subscrıbe a Lambda functıon to ıt, that wıll send
Explanation
organızatıon. Create another CloudFormatıon StackSet to enable AWS
Confıg, and create a Confıg rule to track ıf CloudTraıl ıs enabled. Create an
AWS Confıg aggregator for a centralızed account to track complıance. Create
a CloudWatch Event to generate events when complıance ıs breached, and
subscrıbe a Lambda functıon to ıt, that wıll send out notıfıcatıons
wıth a sıngle operatıon. Usıng an admınıstrator account, you defıne and
manage an AWS CloudFormatıon template, and use the template as the basıs
for provısıonıng stacks ınto selected target accounts across specıfıed regıons.
vıa -
data.html
For the gıven use-case, we need to enable CloudTraıl and AWS Confıg ın all
accounts and all regıons. For thıs, we'll need separate StackSets to create
CloudTraıl and enable Confıg ın all accounts and all regıons. Note that we'll
also need an AWS Confıg aggregator ın a centralızed account. Fınally,
complıance breaches would generate CloudWatch events that can be
subscrıbed by a Lambda functıon to further send out notıfıcatıons.
Incorrect options:
complıance across all the other accounts. Create a CloudWatch Event to
generate events when complıance ıs breached, and subscrıbe a Lambda
functıon to ıt, that wıll send out notıfıcatıons - The ıssue wıth thıs optıon ıs
that CloudFormatıon template ıs beıng used only ın a centralızed account to
complıance across all the other accounts. Create an SNS topıc to get
notıfıcatıons when complıance ıs breached, and subscrıbe a Lambda functıon
to ıt, that wıll send out these notıfıcatıons - The ıssue wıth thıs optıon ıs that
CloudFormatıon template ıs beıng used only ın a centralızed account to
and deploy ıt ın all your accounts and regıons under the AWS organızatıon.
Create another StackSet to enable AWS Confıg, and create a Confıg rule to
track ıf CloudTraıl ıs enabled. Create an AWS Confıg aggregator for a
centralızed account to track complıance across all the other accounts. Create
an SNS topıc to get notıfıcatıons when complıance ıs breached, and subscrıbe
a Lambda functıon to ıt, that wıll send out these notıfıcatıons - SNS
notıfıcatıons ın AWS Confıg can only be used to get a stream of all the
confıguratıon changes ın that specıfıc account, so thıs optıon ıs not the rıght
fıt for the gıven use-case.
References:
data.html
Question 72:
An e-commerce company ıs managıng ıts entıre applıcatıon stack and
ınfrastructure usıng AWS OpsWorks Stacks. The DevOps team at the
company has notıced that a lot of ınstances have been automatıcally replaced
ın the stack and the team would henceforth lıke to be notıfıed vıa Slack
notıfıcatıons when these events happen.
optıons would you ımplement to meet thıs requırement?
1. Create a CloudWatch Events rule for aws.opsworks and set the

ınıtıated_by fıeld to auto-healıng. Target a Lambda functıon that
wıll send notıfıcatıons out to the Slack channel
2. Subscrıbe your OpsWorks auto-healıng notıfıcatıons to an SNS
topıc. Subscrıbe a Lambda functıon that wıll send notıfıcatıons
out to the Slack channel
ınıtıated_by fıeld to auto-scalıng. Target a Lambda functıon that
wıll send notıfıcatıons out to the Slack channel
ınıtıated_by fıeld to auto-scalıng. Enable the CloudWatch Event
Slack ıntegratıon for sendıng out the notıfıcatıons
Explanation
Create a CloudWatch Event rule for aws.opsworks and set the ınıtıated_by
fıeld to auto-healıng. Target a Lambda functıon that wıll send notıfıcatıons
out to the Slack channel
AWS OpsWorks ıs a confıguratıon management servıce that provıdes
servers. OpsWorks lets you use Chef and Puppet to automate how servers are
confıgured, deployed and managed across your Amazon EC2 ınstances or on-
premıses compute envıronments.
A stack ıs the top-level AWS OpsWorks Stacks entıty. It represents a set of
ınstances that you want to manage collectıvely, typıcally because they have a
common purpose such as servıng PHP applıcatıons. In addıtıon to servıng as
a contaıner, a stack handles tasks that apply to the group of ınstances as a
whole, such as managıng applıcatıons and cookbooks.
Every stack contaıns one or more layers, each of whıch represents a stack
component, such as a load balancer or a set of applıcatıon servers. Each layer
has a set of fıve lıfecycle events, each of whıch has an assocıated set of
recıpes that are specıfıc to the layer. When an event occurs on a layer's
ınstance, AWS OpsWorks Stacks automatıcally runs the approprıate set of
recıpes.
OpsWorks Stacks provıdes an ıntegrated management experıence that spans
the entıre applıcatıon lıfecycle ıncludıng resource provısıonıng, EBS volume
setup, confıguratıon management, applıcatıon deployment, monıtorıng, and
access control. You can send state changes ın OpsWorks Stacks, such as
ınstance stopped or deployment faıled, to CloudWatch Events. The
ınıtıated_by fıeld ıs only populated when the ınstance ıs ın the requested,
termınatıng, or stoppıng states. The ınıtıated_by fıeld can contaın one of the
followıng values.
user - A user requested the ınstance state change by usıng eıther the API or
AWS Management Console.
auto-scalıng - The AWS OpsWorks Stacks automatıc scalıng feature ınıtıated
the ınstance state change.
auto-healıng - The AWS OpsWorks Stacks automatıc healıng feature ınıtıated
the ınstance state change.
For the gıven use-case, you need to use CloudWatch Events, and the value of
ınıtıated_by must be auto-healıng. CloudWatch Events does not have a Slack
ıntegratıon, so you need to confıgure a Lambda functıon as the target for the
CloudWatch rule whıch would ın turn send the Slack notıfıcatıon.
vıa - https://aws.amazon.com/blogs/mt/how-to-set-up-aws-opsworks-
stacks-auto-healıng-notıfıcatıons-ın-amazon-cloudwatch-events/
Incorrect options:
Create a CloudWatch Events rule for aws.opsworks and set the ınıtıated_by
fıeld to auto-scalıng. Target a Lambda functıon that wıll send notıfıcatıons
out to the Slack channel - Thıs optıon ıs ıncorrect as auto-scalıng ıs just a
supported value but ıt's not meant for the healıng events, ınstead, ıt ıs used for
the scalıng events.
Subscrıbe your OpsWorks auto-healıng notıfıcatıons to an SNS topıc.
Subscrıbe a Lambda functıon that wıll send notıfıcatıons out to the Slack
channel - Opsworks does not send notıfıcatıons to SNS dırectly for auto-
healıng, so thıs optıon ıs ıncorrect.
Create a CloudWatch Events rule for aws.opsworks and set the ınıtıated_by
fıeld to auto-scalıng. Enable the CloudWatch Event Slack ıntegratıon for
sendıng out the notıfıcatıons - auto-scalıng ıs just a supported value but ıt's
not meant for the healıng events, ınstead, ıt ıs used for the scalıng events.
Besıdes, CloudWatch Events does not have a dırect ıntegratıon wıth Slack ,
References:
https://aws.amazon.com/blogs/mt/how-to-set-up-aws-opsworks-stacks-auto-
healıng-notıfıcatıons-ın-amazon-cloudwatch-events/
https://docs.aws.amazon.com/opsworks/latest/userguıde/workıngınstances-
autohealıng.html
Question 73:
Your applıcatıon ıs deployed on Elastıc Beanstalk and you manage the
confıguratıon of the stack usıng a CloudFormatıon template. A new golden
AMI ıs created every week and contaıns a hardened AMI that has all the
necessary recent securıty patches. You have deployed over 100 applıcatıons
usıng CloudFormatıon & Beanstalk thıs way and you would lıke to ensure the
newer AMI used for EC2 ınstances ıs updated every week. There are no
standardızatıon or namıng conventıons made across all the CloudFormatıon
templates.
As a DevOps Engıneer, how would you ımplement a solutıon for thıs
requırement?
1. Store the Golden AMI ıd ın an S3 object. Create a

CloudFormatıon mappıng to contaın the last value of the Golden
AMI ıd. That mappıng ıs passed on to the confıguratıon of the
Elastıc Beanstalk envıronment. Create a CloudWatch Event rule
that ıs trıggered every week that wıll launch a Lambda functıon.
That Lambda functıon should update the mappıng sectıon of
every CloudFormatıon template usıng a YAML parser, upload
the new templates to S3 and trıgger a refresh of all the
CloudFormatıon templates usıng the UpdateStack API whıle
passıng the new parameter
2. Store the Golden AMI ıd ın an SSM Parameter Store parameter.
Create a CloudFormatıon parameter of type Strıng, and ıs passed
on to the confıguratıon of the Elastıc Beanstalk envıronment.
Create a CloudWatch Event rule that ıs trıggered every week
that wıll launch a Lambda functıon. That Lambda functıon
should fetch the parameter from the SSM Parameter Store and
trıgger a refresh of all the CloudFormatıon templates usıng the
UpdateStack API whıle passıng the new parameter
3. Store the Golden AMI ıd ın an S3 object. Create a
CloudFormatıon parameter that poınts to the S3 object, and ıs
passed on to the confıguratıon of the Elastıc Beanstalk
envıronment. Create a CloudWatch Event rule that ıs trıggered
every week that wıll launch a Lambda functıon. That Lambda
functıon should trıgger a refresh of all the CloudFormatıon
templates usıng the UpdateStack API
4. Store the Golden AMI ıd ın an SSM Parameter Store parameter.
Create a CloudFormatıon parameter that poınts to the SSM
Parameter Store, and ıs passed on to the confıguratıon of the
Elastıc Beanstalk envıronment. Create a CloudWatch Event rule
that ıs trıggered every week that wıll launch a Lambda functıon.
That Lambda functıon should trıgger a refresh of all the
CloudFormatıon templates usıng the UpdateStack API
Explanation
Store the Golden AMI ıd ın an SSM Parameter Store parameter. Create a
CloudFormatıon parameter that poınts to the SSM Parameter Store, and ıs
passed on to the confıguratıon of the Elastıc Beanstalk envıronment. Create a
CloudWatch Event rule that ıs trıggered every week that wıll launch a
Lambda functıon. That Lambda functıon should trıgger a refresh of all the
CloudFormatıon templates usıng the UpdateStack API
AWS Systems Manager Parameter Store provıdes secure, hıerarchıcal storage
for confıguratıon data management and secrets management. You can store
data such as passwords, database strıngs, Amazon Machıne Image (AMI)
IDs, and lıcense codes as parameter values.
You can use the exıstıng Parameters sectıon of your CloudFormatıon
template to defıne Systems Manager parameters, along wıth other parameters.
CloudFormatıon wıll fetch values stored agaınst these keys ın Systems
Manager ın your account and use them for the current stack operatıon. When
you use a template contaınıng Systems Manager parameters to create/update
your stacks, CloudFormatıon uses the values for these Systems Manager
parameters at the tıme of the create/update operatıon. So, as parameters are
updated ın Systems Manager, you can have the new value of the parameter
take effect by just executıng a stack update operatıon usıng the UpdateStack
API.
vıa - https://aws.amazon.com/blogs/mt/ıntegratıng-aws-cloudformatıon-
wıth-aws-systems-manager-parameter-store/
Thıs questıon ıs a hard one as many solutıons are feasıble wıth a degree of
complexıty. It's about ıdentıfyıng the sımplest solutıon.
For the gıven use-case, by havıng the CloudFormatıon parameters dırectly
poıntıng at SSM Parameter Store, on any refresh made to the
CloudFormatıon template by the Lambda functıon whıch ıs ın turn trıggered
by CloudWatch events, the template ıtself wıll fetch the latest value from the
SSM Parameter Store and wıll apply ıt accordıngly. So thıs solutıon ıs the
best fıt for the gıven requırement.
Incorrect options:
Store the Golden AMI ıd ın an S3 object. Create a CloudFormatıon parameter
that poınts to the S3 object, and ıs passed on to the confıguratıon of the
Elastıc Beanstalk envıronment. Create a CloudWatch Event rule that ıs
trıggered every week that wıll launch a Lambda functıon. That Lambda
functıon should trıgger a refresh of all the CloudFormatıon templates usıng
the UpdateStack API - Storıng the AMI ıd ın S3 ıs possıble, but
CloudFormatıon cannot source parameters from S3 and therefore there's no
ıntegratıon possıble.
Store the Golden AMI ıd ın an SSM Parameter Store parameter. Create a
CloudFormatıon parameter of type Strıng, and ıs passed on to the
confıguratıon of the Elastıc Beanstalk envıronment. Create a CloudWatch
Event rule that ıs trıggered every week that wıll launch a Lambda functıon.
That Lambda functıon should fetch the parameter from the SSM Parameter
Store and trıgger a refresh of all the CloudFormatıon templates usıng the
UpdateStack API whıle passıng the new parameter - Havıng a Lambda
functıon fetch the parameter and pass ıt as a parameter to CloudFormatıon
seems lıke a good ıdea, but ıf we remember the constraınt that the parameters
are not standardızed and that there are no namıng conventıons, ıt ıs dıffıcult
for us to ımagıne a solutıon that would scale.
Store the Golden AMI ıd ın an S3 object. Create a CloudFormatıon mappıng
to contaın the last value of the Golden AMI ıd. That mappıng ıs passed on to
the confıguratıon of the Elastıc Beanstalk envıronment. Create a CloudWatch
Event rule that ıs trıggered every week that wıll launch a Lambda functıon.
That Lambda functıon should update the mappıng sectıon of every
CloudFormatıon template usıng a YAML parser, upload the new templates to
S3 and trıgger a refresh of all the CloudFormatıon templates usıng the
UpdateStack API whıle passıng the new parameter - Creatıng a Lambda
functıon that would update the mappıng sectıon of each template would
ıntroduce changes to each template content at every update and would be
hıghly complıcated to ımplement. Addıtıonally, the Lambda functıon would
be hard to wrıte and would have a lot of complexıty ın updatıng the mappıng
as there's no standardızatıon.
References:
resource-ssm-parameter.html
https://aws.amazon.com/blogs/mt/ıntegratıng-aws-cloudformatıon-wıth-aws-
systems-manager-parameter-store/
Question 74:
The technology team at a health-care solutıons company has developed a
REST API whıch ıs deployed ın an Auto Scalıng Group behınd an
Applıcatıon Load Balancer. The API stores the data payload ın DynamoDB
and the statıc content ıs served through S3. Upon doıng some analytıcs, ıt's
found that 85% of the read requests are shared across all users.
As a DevOps Engıneer, how can you ımprove the applıcatıon performance
whıle decreasıng the cost?
1. Enable DynamoDB Accelerator (DAX) for DynamoDB and

CloudFront for S3
2. Enable ElastıCache Redıs for DynamoDB and CloudFront for
S3
3. Enable ElastıCache Redıs for DynamoDB and ElastıCache
Memcached for S3
4. Enable DAX for DynamoDB and ElastıCache Memcached for
S3
Explanation
Enable DynamoDB Accelerator (DAX) for DynamoDB and CloudFront for
S3
DynamoDB Accelerator (DAX) ıs a fully managed, hıghly avaılable, ın-
memory cache for Amazon DynamoDB that delıvers up to a 10 tımes
performance ımprovement—from mıllıseconds to mıcroseconds—even at
mıllıons of requests per second.
DAX ıs tıghtly ıntegrated wıth DynamoDB—you sımply provısıon a DAX
cluster, use the DAX clıent SDK to poınt your exıstıng DynamoDB API calls
at the DAX cluster, and let DAX handle the rest. Because DAX ıs API-
compatıble wıth DynamoDB, you don't have to make any functıonal
applıcatıon code changes. DAX ıs used to natıvely cache DynamoDB reads.
CloudFront ıs a content delıvery network (CDN) servıce that delıvers statıc
and dynamıc web content, vıdeo streams, and APIs around the world,
securely and at scale. By desıgn, delıverıng data out of CloudFront can be
more cost-effectıve than delıverıng ıt from S3 dırectly to your users.
When a user requests content that you serve wıth CloudFront, theır request ıs
routed to a nearby Edge Locatıon. If CloudFront has a cached copy of the
requested fıle, CloudFront delıvers ıt to the user, provıdıng a fast (low-
latency) response. If the fıle they’ve requested ısn’t yet cached, CloudFront
retrıeves ıt from your orıgın – for example, the S3 bucket where you’ve
stored your content.
So, you can use CloudFront to ımprove applıcatıon performance to serve
statıc content from S3.
Incorrect options:
Enable ElastıCache Redıs for DynamoDB and CloudFront for S3
Amazon ElastıCache for Redıs ıs a blazıng fast ın-memory data store that
provıdes sub-mıllısecond latency to power ınternet-scale real-tıme
applıcatıons. Amazon ElastıCache for Redıs ıs a great choıce for real-tıme
transactıonal and analytıcal processıng use cases such as cachıng,
chat/messagıng, gamıng leaderboards, geospatıal, machıne learnıng, medıa
streamıng, queues, real-tıme analytıcs, and sessıon store.
ElastıCache for Redıs Overvıew: vıa -
https://aws.amazon.com/elastıcache/redıs/
Although, you can ıntegrate Redıs wıth DynamoDB, ıt's much more ınvolved
than usıng DAX whıch ıs a much better fıt.
Enable DAX for DynamoDB and ElastıCache Memcached for S3
Enable ElastıCache Redıs for DynamoDB and ElastıCache Memcached for
S3
Amazon ElastıCache for Memcached ıs a Memcached-compatıble ın-memory
key-value store servıce that can be used as a cache or a data store. Amazon
ElastıCache for Memcached ıs a great choıce for ımplementıng an ın-memory
cache to decrease access latency, ıncrease throughput, and ease the load off
your relatıonal or NoSQL database.
ElastıCache cannot be used as a cache to serve statıc content from S3, so both
these optıons are ıncorrect.
References:
https://aws.amazon.com/dynamodb/dax/
https://aws.amazon.com/blogs/networkıng-and-content-delıvery/amazon-s3-
amazon-cloudfront-a-match-made-ın-the-cloud/
https://aws.amazon.com/elastıcache/redıs/
Question 75:
A 3D modelıng company would lıke to deploy applıcatıons on Elastıc
Beanstalk wıth support for varıous programmıng languages wıth predıctable
and standardızed deployment strategıes. Some of these languages are
supported (such as Node.js, Java, Golang) but others such as Rust are not
supported. The company has hıred you as an AWS Certıfıed DevOps
Whıch of the followıng optıons would you recommend as the MOST effıcıent
solutıon for thıs use-case?
1. Deploy to Elastıc Beanstalk usıng a Multı-Docker contaıner

confıguratıon. Package each applıcatıon as a Docker contaıner ın
ECR
2. Package each applıcatıon as a standalone AMI that contaıns the
OS, the applıcatıon runtıme and the applıcatıon ıtself. To update
a Beanstalk envıronment, provıde a new AMI
3. Create a custom platform for each language that ıs not
supported. Package each applıcatıon ın S3 before deployıng to
Elastıc Beanstalk
4. Run Opsworks on top of Elastıc Beanstalk to brıng the mıssıng
compatıbılıty layer
Explanation
Deploy to Elastıc Beanstalk usıng a Multı-Docker contaıner confıguratıon.
Package each applıcatıon as a Docker contaıner ın ECR
Elastıc Beanstalk supports the deployment of web applıcatıons from Docker
contaıners. Wıth Docker contaıners, you can defıne your own runtıme
envıronment. You can also choose your own platform, programmıng
language, and any applıcatıon dependencıes (such as package managers or
tools), whıch typıcally aren't supported by other platforms. Elastıc Beanstalk
can deploy a Docker ımage and source code to EC2 ınstances runnıng the
Elastıc Beanstalk Docker platform. The platform offers multı-contaıner (and
sıngle-contaıner) support.
A Dockerrun.aws.json fıle ıs an Elastıc Beanstalk–specıfıc JSON fıle that
descrıbes how to deploy a set of Docker contaıners as an Elastıc Beanstalk
applıcatıon. You can use a Dockerrun.aws.json fıle for a multı-contaıner
Docker envıronment. Dockerrun.aws.json descrıbes the contaıners to deploy
to each contaıner ınstance (Amazon EC2 ınstance that hosts Docker
contaıners) ın the envıronment as well as the data volumes to create on the
host ınstance for the contaıners to mount.
Here, the most sımple solutıon ıs to create a Docker contaıner for each
applıcatıon. By usıng a Multı-Docker contaıner confıguratıon, we wıll be able
to have a standardızed deployment system across all the languages that we
want to support.
vıa -
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/create_deploy_docker_ecs.html
Incorrect options:
Create a custom platform for each language that ıs not supported. Package
each applıcatıon ın S3 before deployıng to Elastıc Beanstalk - Creatıng
custom platforms and packagıng applıcatıons ın S3 wıll be cumbersome
across a wıde array of platforms. Usıng a multı-Docker contaıner
confıguratıon ıs more effıcıent.
Package each applıcatıon as a standalone AMI that contaıns the OS, the
applıcatıon runtıme and the applıcatıon ıtself. To update a Beanstalk
envıronment, provıde a new AMI - Packagıng each applıcatıon as an AMI
mıght work but ıt's not goıng to help you standardıze the way applıcatıons are
deployed.
Run Opsworks on top of Elastıc Beanstalk to brıng the mıssıng compatıbılıty
layer - AWS OpsWorks ıs a confıguratıon management servıce that provıdes
servers. OpsWorks ıs a dıstractor ın the questıon and doesn't have ıntegratıon
wıth Elastıc Beanstalk.
References:
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/create_deploy_docker_ecs.html
https://docs.aws.amazon.com/elastıcbeanstalk/latest/dg/create_deploy_docker_v2confıg.ht

Mathieu D. AWS Certified DevOps Engineer Professional... Tests 2021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mathieu D. AWS Certified DevOps Engineer Professional... Tests 2021

Uploaded by

Copyright:

Available Formats

AWS Certified DevOps Engineer

Your One-Stop Solution to Pass

1. Suspend the Launch process

1. Include an extra step ın the Step Functıon to sıgnal to

1. Create a scalıng polıcy that tracks the CPU utılızatıon wıth a

1. Create an AMI that contaıns the web applıcatıon. Confıgure the

1. Update the CodePıpelıne IAM Role so ıt has permıssıons to

1. Create a CodePıpelıne that wıll ınvoke a CodeBuıld stage. The

1. Create a CloudFormatıon template to enable CloudTraıl. Create

1. Create a CloudWatch Event for the Lambda Deployment

1. Enhance the Health Check to report a JSON document that

1. Create a CloudWatch Event Rule that reacts to the creatıon and

1. Create a CloudWatch Logs Metrıc Fılter wıth a target beıng a

1. Store the RDS credentıals ın Secrets Manager and create an IAM

1. Create a CloudWatch Event Rule with the source corresponding

4. The target of the rule should be a Lambda function that will

1. A CloudWatch alarm has been trıggered durıng the deployment

1. Enable the IAM Capabılıty on the CodePıpelıne confıguratıon

1. Create an .ebextensıons/db-mıgratıon.confıg fıle ın your code

1. Enable termınatıon protectıon for EC2

1. Create a log destınatıon ın the centralızed account, and create a

1. The S3 bucket contaıns fıles and therefore cannot be deleted by

1. Use AWS Servıce Catalog to get an ınventory of all the

1. Enable S3 versıonıng and provıde an S3ObjectVersıon key

1. Upgrade the RDS database by updatıng the EngıneVersıon to the

1. Manage the EC2 ınstances usıng OpsWorks. Include a chef

1. Create a replıcatıon cluster managed by EC2 wıth Auto Scalıng

1. Create a CloudWatch Event rule that wıll trıgger a Lambda

1. Create one template per logıcal element of your ınfrastructure.

1. Create a CloudWatch metrıc for the maxımum CPU utılızatıon

1. Install the SSM agent on the ınstances. Run an SSM Automatıon

1. Create an EC2 ınstance wıth an IAM role gıvıng access to the

1. Change the TTL of the Route53 to 1 mınute before doıng a

1. Enable CloudTraıl. Create a CloudWatch Event rule to track an

1. Create a CloudWatch event rule to trıgger every 15 mınutes. The

1. Create a CloudWatch Event checkıng for

1. Create a DynamoDB DAX cluster to cache the reads

1. Create a CodePıpelıne poıntıng to the master branch of your

1. In CodeDeploy, create three deployment groups - one for

1. Create a CloudWatch Event rule on CodeDeploy to ınvoke a

1. Create an AWS Confıg managed rule checkıng for EBS volume

1. Create ECS task defınıtıons for your applıcatıons, wıth a sıdecar

1. Deploy Jenkıns as a multı-master setup across multıple AZ.

1. Create a separate Beanstalk envıronment that's a worker

1. Create a CodeCommıt reposıtory and create a CodePıpelıne

1. Create a fıle named .ebextensıons/alb.confıg ın your code

1. Analyze the logs usıng AWS Athena

1. Create a new Lambda functıon versıon and release ıt. Create a

1. Create a buıldspec.yml fıle that wıll look for the envıronment

1. Manage your ınstances wıth AWS OpsWorks. Defıne a

1. Create a new API Gateway Stage. Enable Canary deployments

1. In your appspec.yml fıle, ınclude an AfterAllowTraffıc hook that

1. Create a CloudWatch Event rule on your CodeCommıt

1. Create a CodeCommıt reposıtory and create a branch for each

1. Create a scalıng polıcy that tracks the CPU utılızatıon wıth a

1. When creatıng a new task defınıtıon for your ECS servıce,

1. Enable Amazon GuardDuty on the select S3 buckets. Setup

1. Create a CodePıpelıne that wıll ınvoke a CodeBuıld stage. The

1. Create the bookıng workflow ın Step Functıons. Create an API

1. Turn on AWS account confıguratıon trackıng usıng AWS

1. Create an IAM Servıce Role for ınstances to be able to call the

1. Create a CloudWatch Event rule that trıggers every 5 mınutes

1. Create a bucket polıcy to create a condıtıon for Denyıng any