Pass Google Professional Cloud Architect Exam in First Attempt Guaranteed!

All Google Professional Cloud Architect certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the Professional Cloud Architect Google Cloud Certified - Professional Cloud Architect practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Managing Your Resources

7. Cloud Data Storage Monitoring with Stackdriver

Let's discuss monitoring your cloud storage resources. I'm over here at the Google Cloud Platform console. I'm on the main dashboard, as you can see. If I go over here to Resources, you can see that I have an app engine spun up, a compute engine, and cloud storage. Three buckets are there, and BigQuery as well. You could also see on the monitor that I've got an API as well and am running a couple. It looks like, on top of my head, I can't see the computer engine as well, and so on and so forth. But the main goal of this module is to talk about cloud storage. But before we go to monitoring, let's take a look at cloud storage and some areas we want to look at.

The first is that if you're going to monitor a resource, it's a really good idea to identify what you want to monitor. So you see that there are three buckets here. I've got the GCP demo bucket, I've got the My Python, Hello World, and I've got the staging area for that application as well. You can see that one is regional and one is multiregional. And in the demos before with cloud storage, you saw how to create a bucket and upload files, so on and so forth. What we want to do now is essentially create and monitor a cloud storage bucket. Let's proceed over to the left and select monitoring. Now you can see Stackdriver coming up. Stackdriver is a tool that's pretty much integrated into GCP as well as AWS as well. But when you go over the specific areas, like tracing, logging, et cetera, you could see that you have a thumbtack. This is essentially what has been integrated. Now that you're monitoring, you can see that there's an oddly enough large attack. But also you've got this little, I guess you call it, icon that has an arrow, like a heart, that just basically says that's going to bring you over to another resource, another web page. And you can see that it's bringing me over to Stackdriver.

Now, if you haven't signed in before to Stackdriver, the way Stackdriver works is that you get to use it for free for 30 days. And after 30 days, it downgrades you to the basic version, essentially. Now, for demos and other basic training exercises, you don't really need to go spend a lot of money and upgrade to the premium Stackdriver. There's really no need for it. But in a production environment, you may want to—you're going to have a lot more granularity. And as we go through the demo here, you'll see that there are going to be specific areas of monitoring that you need to have the upgraded version of on the dashboard. Here you can see that it's bringing up the Google App engine response, CPU usage, and so on and so forth. You can see that there were some incidents that did occur, but nothing regarding storage. Actually, right here today, it looks like there are two incidents; it looks like the metric that was set was exceeded and has not been visible for an hour. So let's go and check it out. There's a policy violation, and I set this up on purpose just so you can see how this would work. If you want to be monitored, you could also set up email alerts. You could use a pub sub. You could also use other notification services.

A common one people like to use is pager duty. Again, whatever you choose, let's proceed to monitoring first. Let's go back to the main page. What I like to do is go over to Resources, and you can see that the resources that show up Now, before I continue on, when you log in, it's going to ask you to log in. The first time you log in, what it's going to do is literally talk back and forth between Stackdriver and Google Cloud, and it'll update the project, you know, the project that you're working on and the resources that are in that project. So it's pretty cool. It does all the work for you. You don't have to tell it to do anything. From an initial standpoint, there's no setting up, no APIs, and no agents to deal with. In most cases, there's definitely additional monitoring you do where you have to set up agents. But in this case, for cloud storage, there's really nothing to do. Let's go over to monitoring. Again. Let's go to block. Actually, not block.

Let's go to cloud storage. That's where we want to be. You can see that there are two incidents. As of right now, you could see that the bucket of health has nine buckets total. In the projects that I'm available with, you can see that the total size is one megabyte, or 441 kilobytes. If I select that bucket, you can see that it tells you the storage class is standard if there's any traffic received or not. Now, this is an app engine for a Python app. It's a Hello World app. There really is not much going on there. Let's go over to my demo. Actually, this was the one that was used in the demo. As you can see, there isn't any traffic in this case. And then if we go back here to the migration point, again, there's no traffic because there is no activity. But if we go back, for example, six weeks or a month, that chart looks like it's having some issues, but that's okay. Let's go back to cloud storage and go ahead and create what's called an alerting policy. Actually, let's go back; I want to show you one more thing. Okay, so one of the other things that I've noticed is that I'm using the network. And if you're going over the network, you're going to have issues with latency, jitter, and network drops. Sometimes these populate, sometimes they don't.

You might have to refresh your browser; you want to use Chrome. In most cases, Mozilla works horribly, if at all. So just be aware of that. So when you're monitoring again on the Web, it's not going to always be the most responsive, which I guess is the way to look at it. You can see the number of requests. I had set up an alert, actually earlier, so it looks like it finally populated in my Python, Hello World. You could see that some network traffic had been received. For example, if I go back to myPython, I'll just show you what that bucket is actually doing. If I go to the App Engine Dashboard, you can see that there's an App Engine instance, and every couple seconds or so, it makes some sort of API request. Are you still there? Are you still there? and that's essentially an API. Hello World. That's all it is. It's just going out there. I'm going to check to see if the root directory is there. Basically, that's all it really does. It tells you the number of hours worked, the workload, and any kind of error as well. Let's go back to monitoring. Let's say I want to monitor a bucket, and there are certainly different areas that you do and set up. Let's go back to cloud storage. here, and I'm already there, actually. Now I want to go ahead and create what's called an alerting policy. And what we could do is set up conditions.

So if I add a condition, I could set a specific metric threshold on a bucket. Now, you can see that there are advanced types; there's basic health and advanced health. If you want to use the advanced health or advanced types, you have to be part of the premium service. This is where you could configure more customised alerts, health checks, etc. Let's go ahead and create a metric threshold. Let's go ahead and select "Cloud Storage," and you can see "Cloud Storage Bucket." Let's go ahead and select the bucket. Now, what we could do is select based on the basic metrics. Again, if you need more metrics or want to add custom metrics, you need to go with Premium. But in this case, let's go ahead and look at Receive Bytes. You can see that it pops up. Receive bytes; request count You can see that the request you could see based on the day this is again, based on the bucket resource threshold, could be one. Let me see here. I could change that based on the threshold. I like to do at least five or so for that. And then for how many minutes? You know, one minute. Whatever the default, you want to set it up, so go ahead and select any resource by default. And I could save the condition for the bucket. Now, I could also create a policy called "bucket test one." Let's say I could save that policy. You can see that I have policies with basic conditions.

Let's go back to bucket test one, and then let's go over to edit here. What I want to do too is let's go ahead and add a notification. You go over there and add your email. You could also add a page of duty or add text. You could also use something else, like a web hook, for example, or maybe have it send a PubSub if you so choose. Again, you could send it to the mobile app as well. These are part of the premium service; just be aware of that. And you could add multiple notifications to the documentation. For example, you could add a specific email. Like, for example, this could say this is a "bucket alert," "this buckets," "whatever has an issue," and so on and so forth. This could be a way you could disseminate those alerts and react to them appropriately. Let's go ahead and save the policy.

Now that I've done that, let's go ahead and actually close that. I'm not going to add anything in this case. Okay, let's go ahead and save the policy now. And so you can see that there are several policies when it comes to monitoring. Again, you could do many different things. You could also do uptime checks on specific resources as well. One of the things you might want to do is create groups for your buckets. Like for example, I usually recommend customers go in and create essentially a group for monitoring based on the region that they're in. Especially if you're a larger organisation based on the zone. Or perhaps it could be based on the resource type, like production, cloud, SQL, or something of that nature. You can create different dashboards as well. It's very simple to do that. You get set up for error reporting as well as logging the resources in a project logging as well. Again, very powerful capability with Stackdriver. Literally, you could teach a whole class a whole day on just a stackdriver. very powerful solution that you could use with Google Cloud and your cloud storage buckets.

8. Demo - Google Stackdriver Demo Must Know Cloud Architect

Let's go ahead and talk about Stackdriver and how we're going to monitor an app engine instance. We'll also look into debugging and logging in this demo. And I'm going to keep it under 20 minutes to give you a good idea of the features and functionalities and give you a little bit more than what you really need to know for the architect exam, but certainly not enough of what you would need to know for the data engineer exam. But let's get started. And before we get started, we're looking at an app engine console. So I'm over here in a specific dashboard, and I have an instance that I started up around 1030 this morning.

So if you go back, you can see that I just went ahead and started this application. It is a Hello, World! application. Again, HTTP web applications I go here; the URL is here, and if you look up here, it says Hello World. So we're on the dashboard again. Now that we're back, I want to point out two or three things before we go over to Stackdriver. So we're over here, and you can see that the current load is set up. It's monitoring the route, and index.dot.html tells you the number of requests and average latency. You can see it's five or six Ms, which is pretty good. Now I could go over here to error reporting, and it'll go ahead and bring up any errors that I want to populate again; I didn't configure anything yet. We're going to go ahead and do that.

So you can see that there's nothing there. Let's go back. And you could also go over to view traces as well. And we're going to go over to Traces and take a look at that as well. Okay, so just to make sure we're on the same page, we have an app engine instance. We're going to go ahead and look at monitoring. In that instance, we're going to go look at errors. We're going to go take a look at how to use Stackdriver. So what we want to do is go over here to monitoring, and you can see that that's under Stackdriver. And so, oddly enough, these are the features that we just talked about, right? So Stackdriver is broken down into each of these features, or modules. And that's very important to know for the exams because the capabilities of each of these are, of course, very different, and you would want to use them for very different use cases. Monitoring is again going to give you an idea of whether something is up or not. Are there errors being reported, et cetera? In debugging tracing, for example, you're going to use those for different use cases. We're going to talk about those as well. Logging error reporting So let's go to monitoring first.

And if you notice, you can see that I have this external link icon. I click on Monitoring, and now it'll go ahead and bring us over to the Stackdriver website. Now, the first time you log in to monitoring, it's going to ask you to give the right credentials for what you want to monitor. And so, as we spoke about earlier in the module before this one around Stack Driver Overview, you know that StackDriver has the capability to have what's called "monitored projects." And so, to basically create a monitored project, also known as a hosting project, Basically, a hosting project is going to consist of the account that you would use to monitor specific projects or projects. So again, let's say if you want to monitor a bunch of GA instances, let's say you want to monitor your HR application over here, create a separate group for that, and I'll go through what a group is.

So basically, a group is over here. Create a group for whatever purposes you have, for monitoring purposes. And then let's say I want to create another group for, say, the email app you're modifying or testing. And again, that's just one way to sort of be able to segment monitoring and keep it manageable as well. For the exam, you want to know that with Stackdriver, it's tied to projects, so just be aware of that. So now I'm in monitoring, and as you can see if I go to Overview under Resources, you can actually monitor infrastructure or GCP. So what the heck is the difference? So you go over here and monitor instances overhere, or they've got it set up to where it's App Engine, Pub, Sub, or SQL. So these are basically the main applications. Then over here would be your storage and infrastructure-related issues, security groups, for example, as well.

Now, as far as this specific application goes, let me know why that's hanging there. OK, hold on, there it is. So if I go over here in the dashboard, if I scroll down, you could see that I've got a couple basically dashboard views here. And so you go over here and create a dashboard. And since I already have a dashboard configured, if I go to the dashboard, you can see that I created one called GA instances. So I go over here, and you can see that there are two things that have been set up to be monitored. And again, I just set this up. So it's not really populating yet, but this just started to do so. You can see that it's just basically showing that this instance is up every five minutes, or actually, I think every five minutes is what I set it up for. So again, it's going to eventually populate. But if I go back to the monitoring overview and go over to events, I could go view events. So you can see here that it tells me it's an instance.

For example, you see the icons; I could filter them, but let's go ahead and go over here to responses by code. So if I go over there, let's say, okay, let's do a couple of things. Let's go to uptime checks first. So let's go to this one here first. And you can see that I've got an uptime check. And what this does is that it measures the latency, like, literally, every second or so between the data centers. And I made it so that it would fail basically because the uptime is not reasonable, nor is the latency time for that matter; you could see that a 4 or 4 error was received in 310 ms. And that's okay; I'm going from the US. To Brazil. That should be expected. Virginia is 53 ms. And so you could see that it was failing. And I want to do that because you can see that it's red. So that tells you that there's an alert to look at. So if I go over here, you can see that it failed. I go over here, and it tells me the resource, the default. So the default of the application we just looked at, the Hello Worldapp check, is actually every five minutes.

And so it checks the latency, and basically the timeout is 10 seconds. So again, that's basically the configuration I did as a test. Then I go over here to alerts. I could go click on alerts, and did I not click on that? Go to Policy Overview. You can see that there are no policies there. So I could go add a policy. No need to do that right now; I just want to show you. But let's go back to the monitoring. I just want to point out one thing before we go into debug tracing and logging. So you can see that the instance itself is being monitored for 4 hours, and you can also see that I just configured one for 200 hours as well. So again, I could go over here and click on that, and I could drill down and change the view. pretty powerful capability. And then if I go here for an hour, you can see that it also will change the view of this window as well. I could go over here to the alerting policy, and you can see I could create a new policy if I want. I could go add a condition; I could create different types of conditions, like a metric threshold or an uptime check. I could go ahead and create a health check as well, but that is for premium as well as advanced types.

So if I create a metric threshold, let's say for my app engine, let's say I just want to monitor app engine versions, I go over there, apply it to a single or to a group. I just created a group, so I'll just apply it to the group. And of course there's nothing near there yet because I haven't fully kicked anything off for this specific error. But if I go over here, let's say I want to monitor idle instances. Again, I'm paying for the service if it's sitting idle. You know, these things do cost money. So let's just make sure I turn it off. So I go ahead and monitor every minute. Let's say I do ten minutes, and again, I can go ahead and save, and I got to set a value of, let's say, if it exceeds one instance, for example, I could just save the condition. Okay? So I've got that set up under that. Now this is sort of the cool part, especially if you're a developer or a programmer. So you want to go over to like debug trace and logging. I'm just going to go ahead and go to Trace for the time being. And you can see I'm under this project because, again, if you have multiple projects like I do, it's very easy to get confused if you're not paying attention. So I'm going to go ahead and leave it as is. So you can see that it brings me back to GCP, the Trace window. And again, I could go click on that specific resource, and you can see that it populates the index, dot HTML, the log file, and so on and so forth. I can go ahead and look at the areas as well, and you can see that that's for Ms.

So that's not bad. So I go back to Overview. Actually, the trace was first. This is actually sort of cool because what you're looking at is essentially a window that is showing you sort of like a pictorial graph of the behaviour of those specific HTTP methods that are occurring. So, for example, you could see that most of the time it's pretty stable, but you could also see that at specific times there seems to be some latency jumping. So again, this is a good way for you as a developer, a program, a tester, or whatever to sort of look into why your application is behaving the way it is. So why are you getting latency at specific times of the day? And you go ahead and actually drill down and figure out how to create custom reports, custom graphs, or whatever you want to do. Go over here to analyse the results. You go ahead and create a specific URL. So if I want to test the default home page, I could, or if I want to go to a specific page, I could too. What's really cool is, let's say I just go here to the root. I'm just going to go that route, and then I could also select our PCs as well. And let's say I want to do HTTP. I'm going to select all statuses. Let's say I don't want to see everything; I just want to see the 404. That's a common error, right? So why is that page not available? Then I'm going to say page not available, and then I could go with default service or all services. So right now, I'm set to use the default service.

You can see that it defaults to that version. I could select the time, the start, and the end. And what's really neat is that you can create what's called a baseline. So let's say I already had a baseline setup for the trace to actually evaluate against. Well, again, being able to do that could be the difference between you solving a performance issue in a minute or in an hour or two. So this is great if you can compare what it should be or what you started with with what you have now. So you go submit, and again, I don't have enough traces. You do need to have a minimum amount, and in this case it's $100. So once you get over 100 traces setup, you can then run these reports. So again, that's just a cool tool. In this case, I didn't set that up, but you go ahead and take a look. You can also create reports as well. So let's go back to, let's say, logging now. And for the architect exam, my recommendation is to go through each of the little menu items so that you have a good idea of what they can do.

Because debugging and tracing are so different, if you're not a programmer, for example, you may not really, really understand the total differences. So if you play around with it, oh yeah, I know. Trace is for this, and debug is for that. And again, on the exam, you can expect two questions or so just on Stackdriver. Now, very quickly, you go over here and look at the log files. You can see that it's listing the 200 HTTP outputs that I have set up. And so if I click there, you can see that it can hide that or vice versa. I have the ability to get pretty granular. I could only look at critical if I wanted nothing to show up; I could jump to a certain date. So again, if you run this overtime, it's a very powerful tool. You create special metrics that you want to monitor. If you so choose to export, that is well. If I go create an export, you could see that I could send it to BigQuery cloud storage, pub sub for the data engineers. You definitely want to know that. And again, you create what's called a sync. So basically, again, a sync is basically an output, or, in this case, like, let's say, cloud storage, a place that you're going to dump the water in. Think of that as a sink.

So basically, it's an output. And I go here—let's say cloud storage. I would then select a bucket, and I have to create a name so I can call this, like, "test." Looks like I already created one test before testing two, let's say. And no, I violated; I already knew I violated the term; as far as the naming goes, I need to look at my keyboard. Hold on. Okay, so call it testing; it's very simple. Now exporting that to cloud storage under this cloud storage sync will take a few minutes in some cases, depending on the size. But again, it didn't take that long because, why, it just really started this a couple of hours ago. So go over here to resource usage. You could see that for this project, I am already using 1.81 gigabytes just for it, and then the projected monthly usage would be 3.39. So again, that's logging. So that's about all I had for a Stackdriver overview. As far as the demo, just two other things that, if you are curious on the exam, again, you want to know that for logs, like if you want to log AWS, you need to have a connector to do that. Again, go to the documentation and find out how you want to set up your AWS account. For example, to be able to do that With that said, that's the end of the story.

Containers

1. Containers

Welcome back. Let's go ahead and talk about containers now on the exam. Again, we've seen this chart more than a few times, and again, it should be pointed out to you that this is an important chart to know for the exam because, again, you're going to be required to place the right compute solution essentially with the right configurations and right answers in the test, right exam answers essentially. Now, Container Engine is again fairly simplistic to know at a high level. It's not particularly difficult. There isn't a lot of what I call "bells and whistles" that you have to remember or know for the test. Now, generally, Container Engine is going to be used as infrastructure as a service or platform as a service, more commonly platform as a service, in a lot of cases.

But again, it could be used for infrastructure as well. Now, Google uses the Kubernete’s container solution, and we'll go through that. And I know I didn't say that totally correctly, but that was my betrayal of Kubernetes, however you say that. But again, you don't need to know all the specific details. And again, if you're going to run a container workload, you want to use the Container Engine. So what exactly is a container? Now, a container is generally going to be used to manage an application, so you're not managing virtual machines; you're just managing the application. And so this is a managed service, of course. And so this is great for developers that need to develop an application and not have to worry about managing a virtual machine.

For example, in a container, you're just managing the application and any dependencies. Now, as far as containers go, generally, another couple of things that you want to know is that you can relocate these very efficiently. So they're portable, and you isolate them. So isolation in the sense that you don't have to worry about intermingling and having any kind of vendor issues with the operating system or anything like that, repeatability as well as performance, it's usually a lot quicker to deploy these. So the goal is that, again, the containers bundle the application code and dependencies into a single unit, therefore abstracting the application from the infrastructure. So again, manage applications, not machines. So let's take this in test format. Again, looking at the case study, if you have a case study question that's asking you based on what the customer is doing, would you recommend going with Container Engine or would you recommend any other solutions? And those solutions will likely be one of these on the exam, and you'll have to know that it's Container Engine. So, it's very simple, and I won't spend a lot of time on it.

Now, I'll be very honest, though, because again, if they specify containers, then you know it's Container Engine. If they specify application specifically or again, if you want to scale specific workloads, then again, you know, AppEngine probably might be the better choice. But again, if they specify a cluster container approach, then, you know, it would be a container engine, some things about containers. Now you'll have the notes and everything else for you to download. a couple of things. I don't want to be too repetitive here. I just want to point out a few things that I think are helpful for you to know for the I think Google maintains Kubernetes. Again, it's a clustered approach. We'll go through how that's laid out. It does autoscale, and you can also use Stackdriver to monitor the container engine as well. So, again, being able to manage applications and not virtual machines is a good thing. Now, this is the link for Cornetes, if you want to find out more about what it is. And there are different containers out there. You've got Docker, for example. But then there's Kubernetes. And that's what Google uses—the GKE version of it. Now, basically, the node is going to run a Docker runtime, and then it will have what's called the Kubelet agent. And so this agent here is again going to be a very small instance of the agent. And again, it's going to schedule those containers. And then again, it's going to run Kubernetes days, essentially. Then over here, you've got your master endpoints.

And so an endpoint is basically an entryway, or "doorway," as they call it, to the cluster. So it's an access point, which is sort of the way I would refer to this. Now, as far as Cup is concerned, just to clarify a few things, this is again an open-source project. It's a framework. It's very common to see that in a lot of environments. Now, again, it does have some unique features, but it also has some not-so-unique features as well. But one of the things that I think is important to understand is that Kubernetes does have what's called an endpoint. Now, an endpoint, again, is a doorway to the cluster. So that's significant. So keep that in the back of your mind. There is an API server. You can schedule, create pods, et cetera. And when the container engine deploys, essentially what's called a "pod" Now a pod is essentially GKE. Remember, it's Google Kubernetes engines. It's an abstraction layer that represents the application.

So you have your containers here, and then you have a volume over here. The volumes are over here in storage. And the pod basically contains references to all that. It has a namespace. It has access to storage. And again, it does have a single IP address as well. So that's considered a pod. So think of the pod as more of a placeholder is the way I like to explain it. They like to call it an abstraction. Sometimes I find abstraction or anything to do with virtualization interesting. Some folks that don't totally understand virtualization still get confused over how some of this may work. So the way I like to call it is more of, again, not so much an abstraction, but more of a placeholder in the sense that everything is referenced appropriately. Now, GKE, again, just a quick reminder, is used to manage applications, not machines. You definitely want to understand the abstractions for the applications. And again, abstractions being how the pods are basically referencing, use a single IP and a single namespace with access to that storage. So as far as nodes and node pools go, basically, a node pool is an instance group in the Kubernetes cluster. So basically, all the virtual machines in the pool are the same.

The pools can contain different VMs, and the pools can be in different zones. So basically, you have flexibility in terms of how these can be laid out. It is a no-no to wear pool. And again, GKE replicates the pools along with all the clusters. Now that it is possible you could exceed quotas, pay attention to how you deploy these. And lastly, a Federated Cluster—basically, a Federated Cluster—has a really good purpose. And on the test, there'll be a question sort of inferring that maybe having a federated cluster could be the right decision. So you need to understand what "federation" is in the first place. So if you think of federation from an IAM perspective, that just means what? You know, folks from different clouds and different organisations will use a singular ActiveDirectory or LDAP service, for example. So basically, it could be "open up," "SAML," or any other protocol that is out there. But the goal of a federated cluster in many cases is to be able to take that cluster and move it to another region. So, for example, if you want to move a cluster from the Americas to Europe, you'd need to, of course, use federated clusters.

So there are benefits to that. Again, a lot of it just has to do with what you're willing to pay for because, again, doing this has a cost. So if you're developing an application and rolling it out to test it and validate it, again, there's a cost to doing that. You need to figure out if it makes sense. Okay, that's about all that I had to say about Kubernetes containers for the test. Again, containers have a large water area. To Kubernet-contain containers effectively, it really takes a whole day to do it effectively. But with that said, this is what you want to know for the test. Let's go ahead and continue on. Take a quick look at the container engine demo that I'll do.

2. GCP Container Engine Demo

Welcome back. Let's go ahead and talk briefly about the container engine. Now on the exam, like I stated earlier, there isn't really too much on Container Engine, but there are a few things I just want to point out to make sure that you're aware of and do understand in the console as well. So remember from the previous lesson on Container Engine that Google Cloud Platform uses the Kubernetes framework for their containers.

And I never say Kubernetes correctly, so laugh, have fun, whatever. Forgive me; I just don't get that word. Whoever thought of it was definitely creative. All right, now as far as Container Engine, I'm over here logged in. I created one container. Now, creating a container is not very hard to do. It's very simple. And on this exam, you don't need to know how to do that or anything. So that's not so much of a concern. The concern is that you understand the flexibility of Google Container Engine, which is really sort of what you may want to know for the test. So let me show you a few things. So if you go over to Container, you select the container. You can see that this is named Cluster One, and you can see the details over here. And what it does is it sets up what's called a node pool. So this container is actually in a node pool. So basically, these are separate instance groups in the cluster.

Now you have the ability to change some areas of this, and that's pretty cool. You can also go to Select Permissions. Now let's say, for example, you're developing a new application and you want to be able to basically open it up to the public. Now again, you can do that. But again, you want to make sure that you set the permissions correctly based on whatever the applications are that you're using with Container Engine. So, for example, if you are using CloudSQL for your application and you're opening it up to the public, just remember that you're also exposing that application to the public as well. So be careful with how you assign permissions. Now you could also again open up the services to "Cloud Data Store," "Cloud Platform," "Big Data Table," "Big Table Administration," et cetera. These are essentially service accounts here. So again, just pay attention to permissions. That's sort of the one thing I want to point out. Another thing to point out is that you could also have persistent volumes. Now again, remember, a persistent volume is going to be available past a reboot. So again, there's a cost to that. You go ahead and do that as well. Now workloads.

Now again, I've deployed essentially one cluster. Now I don't have any workloads deployed. So again, I'd have to now remember that in Container Engine, when you deploy workloads, the workloads run inside the Container cluster. Again, make sure you think of that and are prepared to know that I go over to system workloads, and you can see that these are again running per say. These are basically defaults. I'm not actually running any of my workloads in there. This is just the default that is set and that has been started, i.e., discovery and load balancing. And again, I could go over here and show objects. You can see that we've got basically these resources here running. You can see that it tells you the service type, and the endpoints tell you that it's all in cluster one. Go over here to configuration, and again, it will show me the objects. Now you have what's called a secret. Now this is essentially, basically, as they say, a password. I like to call it almost sort of like a token in the sense that you have this sliver of information and you need that sliver of information to complete the transaction. That's what a secret is. And so the container engine uses secrets. Just remember that. So again, secrets from the beta test There is a question about secrets and knowing what those were with Container Engine.

And again, if you don't work with Container Engine, then you may not have known that because it's not something you would know. It's not something very common; usually you have passwords or tokens, but secret, that would be a different word. and then storage over here.

So again, not much to know about Container Engine; on the test, you'll see a question on it, and it will be more focused. Not so much on how to set it up or anything, but what are the capabilities around identity management? Remember what secrets are. Again, remember that a workload is what actually runs in the cluster, and so on and so forth. Again, there isn't too much more that you need to know. But one of the things too, if you haven't played around with Container Engine, you can go ahead and do the quick start tour and follow this through. This will set up a small application for you, and you go ahead and go through and set up a cluster, and then you go ahead and create what's called the guestbook tutorial. So feel free to play around with that. But again, I pretty much covered everything that I can think of that you would even see on the test with Container Engine. With that said, let's carry on to the next lesson.

Google Professional Cloud Architect practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass Professional Cloud Architect Google Cloud Certified - Professional Cloud Architect certification exam dumps & practice test questions and answers are to help students.