Pass Amazon AWS DevOps Engineer Professional Certification Exams in First Attempt Easily

Amazon AWS DevOps Engineer Professional Certification Practice Test Questions, Amazon AWS DevOps Engineer Professional Exam Practice Test Questions

Want to prepare by using Amazon AWS DevOps Engineer Professional certification exam practice test questions efficiently. 100% actual Amazon AWS DevOps Engineer Professional practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. Amazon AWS DevOps Engineer Professional exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with Amazon AWS DevOps Engineer Professional certification practice test questions and answers with Exam-Labs VCE files.

SDLC Automation (Domain 1)

7. CodeCommit - Triggers & Notifications

So let me go ahead and quickly remove this Junior Developer from my account. This way, I can do anything I want in there. So I'll go to Stefan, go to groups, and I will remove the junior devs from my account. Here we go. I'm not in this group anymore. And we're back into code commits. Okay, so next thing we want to do is look at code commit triggers and notifications, because as a DevOps, you need to be able to automate a lot of things. And so automation is one of the centrepieces of the exam. And so notifications and triggers are definitely at the centre of all these automations. So let's go to Settings, and here we have a couple of settings for notification, triggers, and tags. So let's explore notifications. And here we can set up notifications so that the users will receive emails about repository events. So let's set up a notification and see what happens because they're crucial. So here we can configure a notification and say, "Do you want to send a notification to an SMS topic"? And for this, you have to create one. So I'll scale back commit notifications and click on Create. So we have our SMS topic that has been created, and the notifications will go directly into the SNS topic. Then it will create what's called a Cloud Watch event rule. And so the Cloud Watch event role will be in the middle of all your automations for the DevOps exam and for your DevOps role on AWS. So you need to remember that creating a notification here on this could-commit repository will create a Cloud Watch event rule. And we'll have a look at that event rule in a second. Now, what type of events do we want that rule to catch? Maybe we want to look at pull request update events, pull request comment events, and commit comment events. Okay. Click on "Save." And here we go. Now we have set up a notification, it has a target SNS topic, it has an associated Cloud Watchevent rule, and it is catching all these little events. We could also add subscribers to these. So we could add an email subscriber, for example, [email protected], to receive notifications of these events. And obviously, we need to confirm the subscription if we want to go on. So, before we move on to triggers, I'd like to take a deep dive into SNS and cloud watch events because they're extremely important to understand. So if we go to SNS, we have one topic in here; that's the topic that we just created. And if you look at the subscription, the one that just got added from the code commitUI actually added the subscription directly into the SNS topic for [email protected], pending confirmation. Okay, so we're pretty clear about what SNS does, and then from there, we could obviously add a lot more subscriptions on any kind of protocol we wanted, whether it was HTTPS, email, JSON, SQS lambda, SMS, or platform application endpoints. So lots of different options here for integrations and automations. So cool. Now we are pretty set with this. Now let's go into Cloud Watch, and we'll go to Cloud Watch events, and we'll go to Rules. And here we see that we have a rule that has been created directly by clicking commit, and the description of the rule is here. An Amazon Cloud Watch event rule has been created by Alice Good. Commit. So we'll click on this rule, and here we can see the type of event pattern that this role responds to. So it says the source is code commit, the resources are my webpage, my web page repo, and the detailed types of events that it catches are code commit, pull request, change, comment on pull request, and comment on commit, and the targets of such events are the SNS topic, but we could extend this. So here we've just set up these very quick notifications through this UI. However, we could create a rule directly from Cloud Watch events and specify that this rule is for code commit. So let's find a code commit and make a lot more integration possible. So we have repository state change, commit comment, pull request comment, and pull request state change. Alternatively, we can have any API via cloud trails. We'll see this in greater detail later on, but for now, we have the option to catch all events or just one of these four. So if you remember the rule from before, let's have a look at this rule. The rule from before was catching a pull request change, commenting on a pull request, and commenting on a commit. So let's go back here. These are the three right here, but we have a fourth one called code commit, repository state change, and this is a fourth one that's not in here. And if we scroll down, we have sample events that have been given to us by Cloud Watch events. So here we can see what type of repository state change can happen, and one of them can be a reference created. So, for example, when the tag is created, or here we have a reference that has been updated, or here we have a reference that has been deleted, and so on. so we can get a lot more information about what happened in quick commits. Event commits will be in here, and we can catch those here. The really cool thing about Cloud Watch event roles is that we can have targets. And this could be an SMS topic like the one we have created before, but it could also be a lambda function if you create one, a Kinesis stream, or a sqsq. As a result, you can begin to create some really nice integration. Later on, we'll see that we can also have a codebuild project if we want to send a trigger from any change in code commit directly into code build. It's great to know that the cloud provides us with a lot of options for dealing with these integrations and DevOps automation. So that's what I want to show you here. Remember that here we have created one rule directly from the UI encode commit, and then we have triggers. And so it's really confusing, but notifications and triggers are sort of similar, but not exactly the same. So let's create a trigger and see what it is. So I'll call it my first code commit trigger. And what is the type of event we want to respond to, where we can respond to push to an existing branch, create a branch or tag, or delete a branch or tag? And so these were also covered by CloudWatch events, but they are different, and the documentation is very tricky about it. So we'll catch all repository events, and we can specify which branch we want to catch these events on, as well as the target service (SMS or Lambda), and here we go and click on create trigger. So here we can create up to ten triggers. Now you don't have to remember the difference between notification and triggers, although if you go to the documentation and scroll down to this part called "Difference," let me show you. Notice that these are different. So it says repository notifications are different from repository triggers. And although you can configure a trigger to use SNS to send emails, you can also have other types of events. And so it says that triggers do not use Cloud Watch events rules to evaluate repository events. So as such, their scope is wider. So if you want the full power of CloudWatch, you would need to use a CloudWatch event rule for these notifications. But the bottom line is, I don't want to confuse you with those, okay? There are notifications and triggers, and they all respond to new pull requests, deleted new commits, new branches, deleted requests, deleted tags, and so on. All that you need to remember going into the DevOps exam is that anything that happens in your code commit repository can trigger something, for example an SMS notification or a lambda function, and so on. And so, as such, we can start building a lot of good automations around all these things that happen in our code commit. And this will be the source of all the automation for our CI/CD pipelines. So that's what I want to remember out of this. Not the exact difference between notifications and triggers, because the exam will not ask you this, but more around the fact that code commit is enabled for automation. Alright, so that's it for this lecture. I hope you liked it, and I will see you in the next lecture.

8. CodeCommit - & AWS Lambda

So here, let's look at the integration between code commit and lambda through a cool example. So it's in the documentation. It's called "create an AWS code commit trigger for a lambda function." And the lambda function doesn't do much, but it's still good to see how this integration works. And the reason we're following the documentation so much is that the exam, the DevOps exam, will ask you a lot of questions. And everything comes from the documentation. So this is why I'm always very attentive to the documentation, because I want you to be as true as possible to the exam. So let's go ahead and create a lambda function. So I'll go to AWS Lambda and we'll create a function from scratch function.And this will be a Lambda code commit. And the runtime will be Python two seven. And we'll go ahead and create that function for the role. We'll create a new role with basic Lambda permissions. and click on the create function. Okay, now let's scroll down and we'll see that we have to configure the triggers. And the triggers will come from code commits. So let's dive into lambda. Once this function has been created, here we go. And the trigger for it is going to be a code commit. So excellent. And the repository name will be my Web page. The trigger name will be a name for the notification. So what is my lambda trigger, and what events do we want to have? All events. And what branch? All branches. And if you want to add some custom data, we'll put it here. But for now, we're fine. Click on "Add." And here we go. Code commits will now be triggering our lambda function. And then our Lambda function has a basic execution role. So it's able to write logs to Cloud Watch logs. Okay, now let's go and maybe add some code to this function. So let me refresh this page right here. And I will click on, yes, the lambda function. And here we go. We can edit the code inline. Let's go back to our documentation. And in here, I'm going to copy the code for Python. Here we go. Copied. And here it is pasted. And what does it do? It takes both of those, which is the AWS Python client library. and we could commit. And it says, okay, you are going to retrieve the git clone URL from the events passed onto the lambda handler and just print those into the log just so we can see it. So it really does nothing. It just prints the Git clone URL. But it's a cool way of seeing what's happening. When we do push a commit into codecommit and then the lambda function gets triggered, this lambda function could do a lot more. It could, for example, check in the commit history if there are any credentials being committed. It could check if the commit is compliant with whatever security measures we have or whatever naming convention we have, and so on. And then they return a notification to the Slack channel if something went wrong. So you can do anything you want here. The idea is that the lambda function is being triggered by a change in code commit, and so you could check anything you wanted. As a result of that, we'll save this function, and we could test it. So if we can test, we can create a new test event and you can choose the type of event template you want. So we'll choose a code commit repository, and I'll call it my sample cut commit, and this is the kind of event that will happen in our code commits. Okay, excellent. We'll click on "create," and I will test our function with this, and the function is executing but it failed because, well, access is denied exception.We're not authorised to do this get repository on this resource, and that's okay. It's because it's just a sample test event, and really, we can't access this dummy repository. So we are fine here. Okay, so excellent. Now let's go ahead and actually test this function with our code commit repository. So back in the code, I'll go to indexHTML and edit our file and scroll down. Congratulations. V five. Excellent. And it's [email protected]. And click on "commit changes." And now this commit has been done into master, so our lambda function should have been triggered, and as such, because we have printed the references and the clone URL into the log, it should have been going into cloud watch logs. So we're going to Cloud Watch, we're going to CloudWatch logs, and here we have our log group for our lambda function, and here is the execution of it. And yes, we can see that it says the reference is master, and we're still getting some error-denied exceptions, and honestly, I don't want to deal with those right now. But the idea is that yes, our lambda function is working, and it's probably missing some IAM permissions to do what it needs to do. Okay? But the idea is that it reacts to changes in our code commit repository, and as a result, we've built an automation, and we could build many more. If we go to the settings of our code commit and then to triggers, we should see that yes, my lambda trigger is also in here, and we can see that the target service is lambda this time. So that's it. just a quick example. Honestly, they won't have to deal with the hassle of dealing with Ian's permissions, but you get the idea. We can integrate Lambda with code commit, and that's a takeaway you should have going into the exam. Alright, that's it. I will see you at the next lecture.

9. CodeBuild – Overview

So now let's get into code building. You should already know what could build, but here is a quick recap for you before we go. Handson could Build is a fully managed build service, and it's an alternative to other build tools such as Jenkins. We will see Jenkins later on. in this section. It has continuous scaling. So you don't manage any servers, and you don't provision them. There's just a build queue, and internally it will create darker containers, and you will pay for the usage it takes to complete the builds. So it's really good. As I said, it leverages Docker under the hood. So that means that every build is reproducible, and it's ephemeral. There is also the possibility of extending capabilities by leveraging your own Docker images. So if you needed to pack in some dependencies or some specific software for your company, you could provide your own Docker images, build them, and be done with it. Finally, it's secure. There is integration with KMS for encryption of build artefacts, IM for build permissions, VPC for network security, and Cloud Rail for API call logging. So how does it look in practice? Well, maybe we're going to get the source code from GitHub, and we could commit a good pipeline or storage. And then the build instructions are going to be defined. a file called a "Built Spec" YAML file. And we'll take a deep dive into that file in this section. And then maybe the logs of the bill itself can be sent to Cloud Watch logs or Amazon S rate.All the code-built bills can be monitored using CloudWatch metrics, and you get the statistics from them. And finally, we'll use Cloud Events to detect any failed bills and trigger notifications. You will see this in this lecture as well. Finally, Cloud Watch alarms to notify us if there are too many failures. and Cloud Watch events. And the laptop can again be used as glue. And we'll see this when we build some really cool automations in our DevOps mindset. Finally, Could Build can use triggers to send notifications to SNS. So we have a lot to cover. Let's get started with code building.

10. CodeBuild - First Build

Okay, so we have our code in version control, and now we want to move on to the next step of CI CD, which is to build and test our code. And for this, we'll use the code build service. So we'll click on Getting Started, and I'll keep the code commit in my first tab. So here in code building, I can go ahead and build and test my code with elastic scaling. The idea with code build is that it will launch Docker containers for us, provision them, and then shut them down after we're done building and/or testing our code. And the really cool thing about it is that it's serverless. We just need to say how we want our code to be built and tested, and we'll do that for you. And we'll only pay for the time of the build that we use. So that's very handy, obviously. So let's get started and launch our code build. So we'll create a project, and the project will be my web app codebuild. Excellent. We can have a description, and we can also build Bash if you want it to, but we just won't configure it right now. So what do we want to build in the first place? Well, we have our code right here, and our code is just an index of an HTML file. So, just a web file. And we want to eventually deploy it onto a web server. And we want to test whether or not that index HTML file has the word congratulations in it. Because if it doesn't have it, well, we think it's a bug. And so that's going to be our test. Obviously. A more complex app could be built in a more complex way and tested in more complex ways. So for this, we'll go back to code build and say we will test whether or not our indexHTML file has the word "congratulations" in it. Okay, next we could specify tags, but we won't. And so we need to specify where the source of our code is coming from. And in this case, we could specify code commit, and we will specify code commit, but we could have chosen no source at all, GitHub bit bucket, or GitHub enterprise. So we'll use code commit and choose a repository on my webpage. And here, as you can see, we have to specify a reference type. and that's very important. Either it's going to be a branch or a git tag or a commit ID. So commit ID is a specific version that we want to test. So do I want to test my first commit, my v-2, v-3, v-4, v five?Or do I want to test a tag? A tag is when you're saying, "Okay, this is version one of my repository, and you've redone it, or version two, and you're done." And the branch is how to test ongoing code. So we'll test the master. Okay. We could specify a commit ID to test as well, but for now we'll just say Master and we will fetch Master. and the latest commit to Master is the one we did, which is this one, which is edited index HTML, and that was done a few minutes ago. We could specify some additional configuration if we're using git sub modules, but this is more advanced and not needed for the exam, so for now what you need to remember is that we select our source provider to be code commit, but we could have had other source providers, and then we say encode commit. What do we want to fetch and test? We could have said commit ID, git tag, or branch, and which was master and which was branch. So, as we can see from this GetGo, if we wanted to test multiple branches, we'd have to create multiple code build projects, so here we'll test on Master and I'll say my web app could build Master, so we know it's Master okay. I'll scroll down, and now we choose the environments, so we can either use the images that are managed by code build, and they're really good, or we could specify our own custom Docker image if we needed to have some specific software installed on our image to perform our build in our test. For now, we'll use a managed image by code build, and for the operating system we'll choose Amazon Linux 2, and for the runtimes we'll choose standard, and the image will choose this one, and we'll always use the latest image for this runtime version okay.Now that we're ready, we have to create a service role. A service role is what will allow Could Build to do what it needs to do, so for this, we'll create a service role automatically called Could Build. My web app could build a service role, and in there I'm able to specify some additional configurations such as the timeout, so how long I want my bill to go for until it comes out and fails, so 1 hour, but it could be between five minutes and eight hours, so what we want to see here from a DevOps perspective is that we are able to run some very long builds and very long tests as such. Build is a great candidate for running performance testing. for running functional testing. Integration testing and so on, whereas lambda, when asked if it is better than Could Build for running tests well, Lambda has a timeout of 15 minutes, so you can't do much in lambda, so code bill is much better suited because it can go between five minutes and eight hours for a timeout, so I'll choose one hour as the default, then there's a queue timeout, so Create a queue concept so that every time you want to build or test something, it goes into a queue, and Could Build will queue this up and do it one by one. Or in parallel, obviously. And then finally, if you want to have a VPC in which to execute your code-built projects, and this is only if you're reusing resources within your VPC for whatever reason, But for now we're not using any VPCs, so we will not set up anything. Now you can say how performant you want your Docker containers in the code build, and by this, you specify how much memory and how many vCPUs or virtual CPUs you want to have. Obviously, the more performant it is, the more you'll have to pay. We'll keep three gigabytes of memory and two vCPUs. We can also set up some environment variables for this container, but for now we won't do it. Now there is the most important section, which is built spec, and we'll have a deep dive on built spec in this course. So for now we'll say okay, we'll use a build spec file, and it turns out that we have already created a build spec YML file in our code commit repository. So that's perfect. If the file had a different file name or it was not in the root of a repository, then we could set up a different name here. Then for artifacts, what artefacts do we want to push at the end? For now we'll select no artifacts, but we'll talk about artefacts in depth in the future lecture. Then, where do we want to send the logs generated during code build? Well, we want to send them into Cloud Watch, and we could set up a group name or a streamname if you wanted to, or S Three, and we could set up a bucket and a path prefix. The reason we want to send the logs to CloudWatch and to S3 is that we do not want to lose the logs after the Docker container is gone because if things fail or work, we still want to be able to do some debugging. So I'll click on "Create Build Projects," and it's just been created. So we could obviously edit the configuration and return to all of the configuration we just did. But this is fine. What we want to do now is start a build. So we'll click on "Start New Build" and choose the same time as before, and we cannot change the source. But we could set a different branch, gettitle commit ID if you wanted to, and we could also set some environment variables to override. For now, I'll just click on "Start build," and now the build has started, which means that a Docker container will be started by code build, and it will take all the code from this code commit repository and test it according to the specification in the build spec YML. Now in the next lecture we'll see exactly what this file does. So for now, let's not bring this too much into our build. We must wait for the construction to begin and complete. So let's wait a few seconds. And here we can see that some logging has already started. So we have a few commands being run at the moment. And we have the option to view the entire log in Cloud Watch. So if I click on Cloud Watch, here we have the entire log of what happened. So we could review it if you wanted to. Let's go back to a good build. And now we can see that the build has been successful and it succeeded.So that means that all the code we have right here in this code commit repository is compliant and passes the testsuite that we have in the build spec YAML file. So this is a very one on one of could build. But we'll go deeper in the next lecture and see all the options we have. But for now, we've created a build project, then we've run our first build, and it was successful, which is very reassuring. So one really cool thing to see is that the duration was 32 seconds, and this is how much we've been billed for this build. So 32 seconds have elapsed. This is how much this build will cost us. And the best part is that it has been elastic. The Docker container is now gone, and I'm not paying for it anymore. For a good build, all resources are created in an elastic, serverless manner. And that makes it extremely flexible and great for building and testing engines within AWS. And the DevOps exam will ask you questions around choosing the best way to test your code. Is it from EC Two? Is it from a code build? Is it from Jenkins? And we'll see what Jenkins says in this section, obviously. However, the idea is that with code build, everything is serverless and everything is simply used correctly. And when it's gone, it's gone, and we don't pay for it anymore. Alright, that's it for this lecture. I will see you at the next lecture.

11. CodeBuild - buildspec.yml Deep Dive

So now we need to understand exactly how build works, and for this, let's get back to our build projects. And as we know, it was running a build, and for this, it was looking at a file called a build specification YAML. So this file is extremely important, and this is a really simple version of build spec YAML that I have here. And then we'll have a look at the build specification reference document for good builds. So let's have a look here. We specify an aversion, and this is just a version for couldbuild to understand how to interpret this file. Then there are phases, which are what will happen during our code-built stages, such as phases, which are what they should do step-by-step to test and build everything. So we have an install section right here that is installing a runtime, and here we are saying, "Okay, we want node JS 10 on our image, and it's already installed as a version zero two." And then we can run a set of commands sayingokay, what could we install as well on this dockerimage at runtime in case we needed something. For example, if we needed an external package or web get or curl or whatever, we could specify commands here to install what we would need it.Then in the pre-build command, we would do any type of setup we would need, for example, with conflict files, etc. And we can also specify a list of comments, so we can specify many comments in our pre-bill section. The build section is what we actually want to do to build and/or test our application. As a result, we can configure a variety of commands here. As you can see, this is the YAML format, so we can set up many commands by using the hyphen like this. And here I set up three commands, two echos just to have some log appear, and then agrep here, which says if the world congratulations is in index HTML, then you should return successfully. Finally, in the post-build command, what do we want to do? Maybe if we have created an artefact right here, maybe if you've compiled our application, maybe in the post-build we want to push it somewhere else as an artefact so we can use it in different stages of our pipeline. So this is obviously a very simple built spec YAML. I could have removed most of the sections that have just echoes in them because they're just log statements. But I want to show you the structure as is. So if we go back to the code build now and we go to our build run, we can see that we have different phases. And these were all the phases that happened in our code build. They were submitted to the queue, so we can see how long they were in the queue before provisioning. So how long did it take for that Docker container to arrive? That was 17 seconds. Then download the source, which is how long it took to download the source from the code commit repository, and then we went into the hooks. So install the prebuilt build and postbuild, which are the sections that we defined right here. And then upload artefacts finalising and completed. So everything worked, and everything worked fine. What if we just changed something? So let's have could build fail for us? So we'll go into the index HTML and I'll edit this file, and instead of having congratulations, I'll have error v. five. Okay, so I'll say [email protected]. And so here. because we have introduced an error into our code. into the master branch. If we go back to "we could build" and to our "build project" here and now, we say "start building," and we start to build again from the branch master. Then it will pull all the new versions of this code, including this new index HTML file that has RV five in it instead of congratulations. And so, based on the instructions that were set in our build spec YAML file, this line right grep congratulations YML," "congrats to index HTML," should fail and should make our entire build fail. So yes, here the build status is failed, and we can go into the first details and see that the build here failed and there was an error while executing the command, the grip. So it's the one I told you was perfect. It's because we have purposely introduced some error, and so we were able to build our project, test it, and see that yes, indeed, there was an error, and as such, the build itself is a failure. If you go to the build history, then we cansee there's some succeeded build and some failed build. Okay, back in our project now, so we understand how code build works and how this buildspec YAML file is used, but let's go into the reference to understand all the possibilities for this buildspec YAML. So if we scroll down, we see here under build spec syntax everything that needs to be there. So it's version 20, and we can have a user run as a specific Linux username. Most of these things are optional, so if we don't specify them, then they're not taken into account. We're also able to set up environment variables and parameters from the parameter store. We can even have a git credential helper if we're using some private git repository. The phases are the most important. We have the install phase, and for each of these phases, we can run it as a different Linux username. So we can run it as, for example, EC2-two user, root, or whatever; we can specify the runtime version. So here is what type of runtime I want to have on my image. And here's NodeJS 10. We could have Python and other things. Then the commands we want to run, so we canrun multiple commands, that's why you have multiple hyphens. And now we have it finally blocked. So what is this finally blocking? It's saying, "Okay, run these commands, and whether or not they fail or succeed, then finally run these comments." So it could be some clean-up that we do for whatever reason. As a result, we can set these up for each and every phase. So for pre-build, we can run it as a different Linux username, have several commands, and have a family block again to run some commands no matter what happens if these pass or fail. So pre build build and post build. So that's four different phases that we can specify in our build spec, YAML, and then finally we have artifacts. So what are "artifacts"?Artifacts are a bunch of files that you have to specify, and you can give them names and so on, but this will be what is kept after our build is done. So, for example, say we build an application and it generates some files called Jars. They're for Java. Then these files, if we leave them on the Docker container, could build when it shuts down, destroying the container, and everything we build will be lost. So the idea here is that if we specify an artefact and we specify some files to be part of that artifact, then they will be uploaded, for example, to Tos 3, and we can retrieve them later and use them in the next phases of our deployment. For CI CD, we'll have a look into artefacts in a later lecture. Finally, if we wanted to cache some files—for example, some build dependencies or whatever—we could specify a cache, and this will allow us to speed up our code build deployment. So what you need to remember out of this entire buildspike YAML file is the fact that we can specify different phases for install, pre-build build, and post build.We're able to specify some environment variables and some parameters from the parameters store, and we have this final block in case a comment goes wrong. We can still run some comments afterwards to clean things up. In the very bottom of this documentation, we have an example of what it should look like. So there's a build specification example where, for example, here we specify a Java home environment variable, parameter store, which contains a login from parameter store. So this is how, for example, we would specify a private secret in a code build. So here we said the secret is external and you should fetch it directly from the parameter store, which is coming in very handy. Finally, this type of installation—prebuild build, post build—with some blocks displayed here into what would occur regardless. And finally, some artefacts and cache. So have a look at this file. Make sure you understand exactly how this example works. And if you don't, then you need to understand why you don't understand them and go back to this documentation and try to understand what you're missing in terms of information. But overall, I think that by now we should understand exactly everything that is in this file. That's it for this very boring lecture on what goes into a built-spec file. But you need to understand it going into the exam. Alright, that's it. I will see you at the next lecture.

So when looking for preparing, you need Amazon AWS DevOps Engineer Professional certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, Amazon AWS DevOps Engineer Professional exam practice test questions in VCE format are updated and checked by experts so that you can download Amazon AWS DevOps Engineer Professional certification exam practice test questions and answers files in VCE format.