Pass Your Amazon AWS Certified SysOps Administrator - Associate Certification Easy!

Prepare with top-notch Amazon AWS Certified SysOps Administrator - Associate certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All Amazon AWS Certified SysOps Administrator - Associate certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Managing EC2 at Scale - Systems Manager (SSM) & Opswork

4. AWS Tags & SSM Resource Groups

So in AWS, you may know that we can use tags. And tags are basically key-value pairs of text that can be attached to many different database resource kinds. The most commonly used is EC-2, obviously, but they can be attached to many different services. So you have free naming conventions. You can name whatever you want for the tags, but common tags are going to be name, environment, team, or whatever you want. and they're used for many different things. They're used for resource grouping, automation, and cost allocation, and we'll see how Systems Manager uses them as a recommendation, a real-world recommendation, in general. It's better to have too many tags and too few tags as much as you can on your instances, and then you'll see what you do with it later on. Now for Resource Groups on Amazon SystemsManager, we're able to create, view, and manage groups of resources using these tags. And so we can create logical groups of resources in SSM, and we can create groups such as applications or different layers of an application task, or maybe production versus development environments. We'll have you play with this, and this is something you can do from within SSM. The reason you would do this is to get an overview of all these resources that share the common tag. By the way, the resource groups are regional services, so you need to create different resource groups if you're operating in different regions. and resource groups. Work with EC. Two S, three DynamoDB, Lambda, etc. So let's go ahead and play with it. So I'm in my C-two instances, and what I'm going to do is just tag them. So the first one I will add a name to is "my Dev Server," and the environment is going to be "Dev." The team is going to be in finance. Three tags I have added: Now for the second one, I can add another tag, and I will say the name is going to be my production server. The environment this time is going to be promotional, and the team is going to be finance. So this is my finance application, but now it's in production. Okay? So we have my dev server and my production server. And you can see the name tag here. Get propagated to the easy-to-remember instancename in this table. And then finally, for this one, we'll create another development server. So name my other dev server, and the environment is going to be dev, and then the team is going to be operations. Okay, so here we go. We have three easy two-instances, and they've been tagged. Two of them have the same environment, named Dev. Now, if you click on Resource Groups at the very top, you can see there are different things. You have the option of creating a new group, using Tag Editor, or using classic groups. Actually, classic groups don't work anymore. So we'll just go and use the new options. The Tag Editor is a way for you to tag resources within your environment. So you can search for any region. You can search for the kind of resource tag that you want, such as images and EBS volumes or whatever, and then you can just tag them. So it's pretty nice. But for us, we'll be using the resource groups, so we'll just create a group. Now, when you go to resource groups, you basically land in the SSM UI. And so here on the left-hand side, we can just click on Find Resources or Save Resource Groups. So we'll click on Create Resource Group, and now we have to select the group type. It could be either tag-based or cloud formation stack-based. It's easy. When you create a cloud formation stack, all the groups and the elements will be tagged the same way. So that's a very good shortcut. But for us, because we create things manually and tag things manually, we'll use the tag-based method. Now, for the grouping criteria, you can add multiple criteria. So as you can see, all these things can appear in our grouping. So we can have EC, two instances, the DynamoDB table, all of this, elastic Beanstalk, load balancers, lambda functions, and anything else that can be tagged. Basically, we're looking into simple examples. So here we go. And we say, okay, I want the tag key environment, and I want the tag value to be dev. So I'd like to retrieve all of my developer instances. So I click on View Resource Group, and here in Group Resources we get the results. We have two simple examples of environment development in here. And so, that's pretty awesome. Here we can name this group, I can say my circumstances, and we don't need to provide a good description. And we could also tag the group itself. So here's just a simple query, but using this we're able to group resources. If we wanted to, we could have used S, three buckets, etc. Alongside these things: Okay, create this group. And now my dev instances have been successfully created in the current region. So, for me, this is a regional service, not an EU one. We could do another one, obviously. So this is a safe group. There are my development instances where we could create another one in the same way. So we could create an easy-to-instance environment again. And here we'll say "prod" and view resource groups. Here's an example of a product. So I'll say my PROD instances, and then finally, we could also create another type of group, maybe just the ones that belong to the Finance team Finance.So we'll say, "Okay, I want my easy instance, and the team is going to be finance." I'll view the resources, and now we have two resources, one in development and one in production; I'll call it Team Finance. Create Group. So here we go. We have three resource groups, and the reason why we have these resource groups created in here is to be able to apply OS patching commands to all these things at the same time. So making use of resource groups and tags is critical to making systems manager work. So get tagging, create resource groups, and once you're there, I will see you in the next lecture so we can have a play with them.

5. SSM Documents & SSM Run Command

Okay, let's talk about SSM documents. So SSM documents can be either written in Jason's or Yemen's language, and you can define parameters and actions, and then all of a sudden the document does something for you. There are many documents that exist already in AWS, and I will show you this in a second. And so without further ado, here is what a document should look like. And so this looks like this. This is a YAML document, and it contains a schema version, a description, some parameters, some steps where you can run a shell script, etc., etc. There's a slight difference if you use a different service. But the idea is that the document describes what the actions should be. Now, your document can beapplied to many different things. It can be applied to State Manager, it can be applied to Patch Manager, it can be applied to automation, it can be applied to run commands, and on top of it, it can reference the parameter store. So overall, documents are a common denominator in SSM, and if you start using SSM at scale, it will be good for you to know how to write your own documents. So let's have a look at what AWS has for us. So if we go to Systems Manager and then, in the bottom left, we go to Documents, Here we can see all the documents available to us. And so you can see, there are pages and pages of documents. And the document types can be an automation, it can bea command, or it can be different things as well. And so all these are created by Amazon. So all these documents are created by Amazon. The platform types can be Windows or Linux, or just Windows, or just Linux. And then each document has a version. So you can take in any document, for example, apply a patch baseline, and you can view details such as the parameters that are available to you and the content of the documents. So this is a big document created by AWS, et cetera, et cetera. So this is just to show you that there are a lot of documents. Very shortly we're going to create our own documents. So stand by. OK, so we have these documents, and what do we do with them? For this part, I want to teach you about the run command. Because the run command can be asked at the exam, and the idea is, okay, we want to execute a command on all our easy two instances. How do we do this? For this, we're going to execute a document or just run a command, right? And this command can be run across all these instances. And we can use resource groups; we can use tags; we can use whatever we want. There is a possibility that you have rate control or error control, and it's tightly integrated with Am, Cloud Trail, S, Three, Cloud Watch, all these things. You don't need to SSH to run a command, which is quite cool, and we get the results right in the console. So let's have a play with this. So here are my documents. And so what I want to do is install an Apache server on all my instances right here. But I want to do it all at once. Okay, so what I'm going to do first is allow my security group. I'm going to allow an HTTP role. This way, I can show you that there is currently no website running. So let's go back to our instances. We go to the dev instance, open the public IP, and you can see here that the site can be reached; it can refuse to connect. So there is no server running on this instance or any of the instances right now. Okay, now we go to Documents and we're going to create a new document. Now when you create a document, you should give it a name. I'll call it "install and configure Apache." You can give it a better name if you want to. You can choose a document type. It can be a common document, policy document, or automation document, and it can be used with different services. For us, we'll use a run command, so we'll use a command document. The format can be either JSON or YAML. For me, I'll choose YAML because I think it's a little bit more readable, at least for me. Okay, so now we need to fill some stuff in. I don't want to bore you with the details. So we're just going to use a document that I've created right here, and I'll show you what it does. This is a simple YAML template to install Apache. So there is one parameter, and this is a string, and it's a welcome message. And by default, the welcome message is what it will do. But we can set the message to whatever we want. Then for the main steps of what the run command will do, it will do a run shell script action, name the configuration of Apache, and it will run all these commands. It will execute sudo yam update pseudo yam, Httpd installation, systemctl commands to start the Httpd service, and finally message from hostname into the index HTML. So that's a very simple one. It's just a bunch of commands we run one by one, but it demonstrates the use of parameters right here. Okay, we'll create the document, and now the document has been created. We can locate a document by searching for "owned by me." And now for the fun part: learning how to install and configure Apache. If we click on the documents, we get more details. It is for the Linux platform. As you can see, we can have different versions of these documents, and we can look at the parameters, the permissions, the content, etc., etc. Okay, now for the fun stuff. Let's go to runcommand, and we're going to run that command. We'll click on "run a command," and here we have to choose a document that we're going to run, so again I'll choose "owner owned by me." OK, here's my Apache installation and configuration. Now we have to use the comment parameters, so I'll custom hello world" as my welcome message because we've just customised the parameter, and here we can select instances either by specifying a tag (for example, "environment dev"); there would be a way of doing it so we can do environment dev and all the instances that have a dev environment will be good; or we can just manually select instances (in my case, I'll just select all the instances quicker, OK). Other parameters are that we can specify a timeout, so how long are we waiting for the command to wait and for timeouts before we just say it's over? It didn't work, so 600 can be signed, but you can increase or decrease this based on the command you run. Obviously, rate control tells us how many instances at a time we can execute the actions on the targets, and so right now we're saying okay. We have a concurrency of one target, which basically means that we can only run the command on one target at a time; if you have 50 targets, that means 50 targets at a time; or you can use a percentage error threshold of When do we want to stop the task? If there is one error, then we stop, but you can set the threshold if you expect some commands to fail, and the outputs can be written to an S bucket, so we can either enable range three buckets or we can choose a bucket for the text box right now I'll just disable it because you need the easy to instance right to s3, which we don't have, but we could also send the entire output to Cloud Watch and the log group main could be a custom run command, and we can have notifications, which work very well. We'll click on "run" and here we go, the command has been started now as you can see we have three targets as a target and zero completed zero errors. We'll refresh it and as you can see the last one is in progress while the other two are pending. So we'll refresh and one has completed so now it's going to go on the second one. This is because we've set up a one instancing. The logs are right here, and the custom run command lets us see all the outputs of our instances. So if I take a random instance, for example, this one, we can see that all the outputs of my commands are right here into Cloud Watch, which is kind of cool. and we can see, for example, that HTTPD was installed and was complete. OK? So, if we go back to our Systems Manager and refresh, we can see that the overall status is success, with three targets completed, three targets missed, and zero errors. If you click on any of these instances, you can see the output of the commands as well right here, which is super neat. OK, so this is very good, but what about the outcome of it? Well, if we go to our server, take this IP, open a new browser, and go to it, we get a custom "Hello World" from our instance, and we can do it the same from this instance as well, for example. And the third one should work as well. As a result, we were able to run a command from Systems Manager to install Apache on three servers and nothing happened. That's kind of cool. So remember, all of this came about because we used a document, we created a document, and then finally we used the run command, etc. And finally, you can also view the custom document history if you want to. So that was helpful. I hope you understand what Recommend does, and I will see you in the next lecture.

6. SSM Inventory & Patches

So you can use Systems Manager to patch all of your EC2 instances and see how far they've progressed. It's really awesome. At the exam, they will ask you a lot of questions, such as "We need to patch all our EC2 instances, right?" Now how do we do this? The answer is using systems managers. Now there are tonnes of ways of doing it. Now number one is using inventory. Inventory will list the software and instances that we will encounter. Inventory plus a run command will allow us to patch software. Patch Manager plus a maintenance window will allow us to patch the OS. Patch Manager will also give us compliance insights, and State Manager can also help us ensure that all the instances are in a consistent state. Now, the exam doesn't expect you to know all these things, but the idea for you to receive is that there are different ways to use Systems Manager to either patch software, patch the OS or the software of an instance, or ensure that all the instances look the same. So this is the idea. Now let's go into the hands on. I'm in my Systems Manager, and the first thing I'm going to do is go to inventory. Inventory will give us an idea of what software is running on our instance. Currently everything is disabled, so we clicked here to enable inventory on all our instances, and now this is done. We can view the detail of that request, and here it says okay; we just ran basically a gather software inventory command, and the current status is spending. So what we have to do is to wait until it's done. As you can see, the schedule expression rate is 30 minutes. So every 30 minutes, my instances will report to SSM to tell them what software is running onto them. Okay, let's refresh a bit. So now we can see that the status is success, and if you look at instances, they've all been applied under the hood. State Manager was used, and so with StateManager we'll get some information for inventory. Let's go back to inventory. And here we go. Now in inventory we're able to see basicallywhat our instances are and so the topOS version is Amazon Linux Two. We have three instances of Amazon Linux. It also gives us inventory coverage by type so we can get some network information, etc., etc. The top five applications are going to be GeoIP, Pyramid, ACL, Amazon, Linux, Extra, etc., etc. And at the bottom, we are able to click on any instance, for example, my devserver, and view some inventory information. And now, from the inventory information, the pretty cool thing is that we can look at all the software that has been installed on our machine, and this is awesome for compliance purposes and to see what version is running on all your inventory, not just one machine. So if we look for a name, for example, "httpd," it is equal to "httpd." We can see that HTTPD was installed, and the version is 2434. That may be some information we're interested in. And it was installed on Tuesday, the 27th of November. So I really like it because it gives you a good overview of all that's happening for your instances. But that's just for inventory. We also need to look at patches. So if you go to Patch Manager, you're able to configure patching for your OS. So let's click on "configure patching." And now we can select which instances to patch. And we can either do this using instance tags or selecting a patch group. And we have to create a patch group, and we currently don't have any patch groups, or we can select instances manually, so click on all of them. And here we can set the patching schedule. So we can say either we select an existing maintenance window or we create a new maintenance window, and we say when we want things to happen, but I won't do it. Or we can skip scheduling and patching instances. Right now, the patching operation can be scanned and installed to get an idea of all the things that can be updated right now. Or just scan to get an idea of the missing patches for us to review. I'll just run a scan alone. Now we are ready to configure patching. And here we go. The patching will use the Run command to patch our instances, which is pretty cool. Now, if you go to the Run command and look at the command history, we can see that the Run patch baseline has succeeded in this command, basically succeeded, and runs successfully on three targets. So this is just a quick overview, but the idea is that you can use the Patch Manager to automatically apply patches and configure patches to different instances based on their tags, based on what you want, and based on the window you choose. And the idea is that, using SSM, you have much better confidence that your whole infrastructure is correctly patched. Lastly, the outcome of this scan went into compliance. So here we can look at the compliance of all our machines. And so we can see that the patch right here has three compliant resources. So if we click on that, we can see that these three managed instances have been compliant. And the last time we executed the scan was at this time. So that was five minutes ago. So that's the idea of how things work. This is how you can patch and manage patches in Amazon SSM. I hope you enjoyed it. I hope you have a better idea of how it works. Remember, at the exam, it's going to be very high level.It was going to say we need top-level instances. How do we do it? answer is using Systems Manager, and that's it. But I wanted to go a little bit beyond and show you exactly what I did. Okay, that's good. I will see you at the next lecture.

7. SSM Secure Shell

So one of the coolest features that I like about SSM is the session manager. It's not in the exam yet, but I really want to show it to you because I think it's amazing. So Session Manager allows you to start a secure shell on your VM but does not use SSHAccess or Bastion Host; it uses the SSM agent. That's awesome. And currently it only works for EC2, but soon the premise will be supported. And the idea is that if you enable it, it will be logging all the actions you take through these secure shells to S3 and Cloud Watch logs if you enable it.For this, we need to have IAM permissions on the East Two instance, such as access to SSM, access to S3, access to Cloud Watch, etc. The awesome thing is that when you do use "Start session" on Session Manager, Cloud Trail can intercept these events, so you can have audits to see who is doing SSH sessions into your entire infrastructure using Cloud Trail. So the advantages against SSH are awesome. Number one is that you don't need to open Port 22 at all, which is a huge plus for security. Number two is that you don't need to Best in Host," which is a huge plus for operational constraints. Number three is that for auditing, all the commands can be logged to SB and Cloud Watch, which is super cool. Finally, the access to Secure Shell is done through the IAM policies for users, not SSH keys, which is also awesome for security and audits. So enough saying awesome. Let's go and play with it. I'm in Systems Manager, and I'm going to go ahead to Session Manager. In Session Manager now, we're going to go to Preferences, and this is where we can set up Three Bucket Storage and a Cloud Watch log stream. So before that, I'll go to Cloud Watch logs, and I'm going to create a log group. And that log group is going to be called SSM Secure Shells. And this is where all the logs of my secure shell are going to be. Now, in Systems Manager, I edit my preferences, I send the Cloud Watch logs, and I annotately encrypt log data because for now we don't have access to KMS, and we're going to choose a log group from the list, and that log group is going to be SSM Secure Shells. Click on "Save." And now anytime we launch a session on our EC2 instance, the Cloud Wash Logs stream will be enabled, and we'll go to SSM Secure Shell. If we go to the ECQ console, we can see that our security group right now does not have access to port 22; it's only port 80. But using Session Manager, we'll be able to start an SSH session, or secure shell. So let's click on "Start Session." Here, we can choose any server we like. For example, go to my other dev server and click on Start Session. And here we go. We have started a session. It has an ID root and an idea. And we're on this one. And here we go. We have access to a Shell session. If we do, who am I? Then we can see we are SSM users. So when we do start these sessions, we become an SSM user. But I can do pseudo-SU and get access to Sudo. I can also look at the content in my WW directory. For example, we can see it's a custom Hello World, and we're able to change it if we wanted to. But for now, that's enough. I've just done a few commands, and I'm going to terminate my session. I say yes, I'm going to terminate my session, and my session is done. In session history, we're able to see all the sessions that we have created. and in preferences again. We can add the preferences in Cloud Watch. Now, in SSM-secure shells, you need to wait a little bit sometimes, but you may see some log streams based on whether the instance sent the logs to SSM. and that can take a little bit of time. So I have just waited a few minutes, but now my log stream is appearing. And I'll be very honest with you, the log is kind of ugly. There are some weird formatting issues. As a result, SSM is probably not quite ready to log into Cloud Watch. Maybe they're addressing this, but we can see that. We can say: who am I? And it says "SSM user." Then we did Sudo Su, and then we did a CAT of this file, and we see the outcome of this file. So custom hello, weld from IP, blah blah blah, and then we set exits, and the script was done. So the idea is that now all the things we do on the secure shell are going to be logged into Cloud Watch. But what I want to show you here is that using the Systems Manager will both let you start sessions on any of our servers and start running commands, all without SSH. and I think that is a really awesome feature. So I hope you like that, and I will see you in the next lecture.

8. What if I lose my EC2 SSH key?

So a common question that comes up in the exam is, "What if I lost my SH key for EC 2?" And there are different kinds of answers based on whether or not your EC2 is EBS-backed, instanced, or instanced or backed.So the traditional method is that if your instances are EBS-backed, then the first thing you can do is stop the instance. and then you detach the root volume from it. Then you attach that root volume to a new E2 instance as a data volume, and you can SSH into that new E2 instance. And then you have access to a data volume. Because you have access to that data volume, you can modify the SSH Authorized Keyfob. And this is basically where all the SSH public keys are. And here in that file, you just add a new line, and you add your new key that you have access to today. and you add your new public key there. Okay? Once you're done, you move the volume back to the stop instance because you've now been able to modify that volume, add in your key, and then you can move it back to the stop instance, and you can start the instance again, and you can SSH into it again because you have modified that SSH authorised key file again. So that's easy, but that's fairly manual. Now, there's a new method using SSM, and if the instance again is only EBS-backed, not instance-or-bag-backed or only EBS-backed, then you can run this automation called AWS Support Reset Access. And that will basically create something called ECQ Risky and do some lovely things on your Windows or Linux machines to basically restore your admin and SSH privileges. And then finally, if your instance easy to instanceis Instant Store backed, you cannot stop it. Because if you stop it, you lose all the data on it. So in that case, AWS says you cannot recover our SSH key, and you cannot do anything. And AWS recommends you terminate your instance and create a new one with a new SSH key that you have access to. But here's a tip. It's nowhere on the Internet. It's not in the documentation. It's my tip. You can use Session Manager to access and get a shell through SSM. And then from that shell, you can edit that file—the same SSH authorizekey file—directly, and you can give yourself access back to that instance store. So it is something that's alittle known that works really well. It also works if your instances of EBS are packed. But I don't think the exam will ask you to use Session Manager at the exam just yet. So for now, if you have an instance storeback to EC2, just know that you cannot stop the instance, and so you cannot recover the SSH key using these methods outlined above. Okay? So I think this is a great example of how Systems Manager can help you do some admin tasks and automation and recover these two instances. So if you're on the left-hand side of automation and you click on "execute automation," you have to choose the documents. So we'll choose "document name prefix equal," and then you type "AWS support." I'm sorry, you can't really see that. So the document name prefix equals AWS support." And then you have here wehave AWS support reset access. So let's click on it. And this gives us access to the documents. And so this document says it will use the EC2-rescue tool on the specified EC2-instance to re-enable password encryption by the EC2 console for Windows or generate and add a new SSH key pair for Linux. And so this is great. And this is the kind of thing we want to use the parameters for. This is going to be the instanceID we want to recover that's required. And then the size of the EC2-rescue instance type that we want to create to basically perform that automation. Then there's the unexpected ID and the assumed role, because the automation basically assumes a few permissions to execute the documents. And that's it, really. And then you'll just execute that automation, and you'll basically do simple automation, and you just place all the parameters in there, and then you click on "Execute," and you have recovered your EC2 instance, even if you lost an SH key. So that's it. I hope you liked it, and I will see you in the next lecture.

ExamCollection provides the complete prep materials in vce files format which include Amazon AWS Certified SysOps Administrator - Associate certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to Amazon AWS Certified SysOps Administrator - Associate certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.