Cloud Profiler is a statistical profiler that continuously gathers CPU usage and memory-allocation information from your applications. When users report issues, a good first place to check is the monitoring to check resource utilization. High CPU usage can cause dropped or ignored connections; the database engine and underlying OS are fighting for resources and do not respond to the connection in time.

References: 'Cloud Profiler Concepts' - https://cloud.google.com/profiler/docs/concepts-profiling

"Check the serial port logs of the Compute Engine instance." - Checking the serial port of the application compute engine instance will not help. As for the more critical Cloud SQL instance here, we will not have access to the underlying VM as it is a Cloud SQL instance.

"Determine whether there is an increased number of connections to the Cloud SQL instance." - The question mentions that the number of active users remained stable. If the currently active users are the same, then if the number of connections they are creating to the database has increased, checking the profiler would help find bottlenecks and resource-intensive components faster and more accurately than just the connection measure.

"Use Cloud Security Scanner to see whether your Cloud SQL is under a Distributed Denial of Service (DDoS) attack." - Assuming the degraded performance is due to a DDoS attack without any evidence to back it up means most probably time and resources being wasted using Cloud Security Scanner as it only eliminates one potential cause an not the most efficient route to the root cause.

To mitigate the impact of the incident on users, we will need to triage and get the system back to a running state as soon as possible. To do this, we can roll back the release, and after this is done, we can begin to try and review and fix the problem.

Reference:

'Triage' - https://sre.google/sre-book/effective-troubleshooting/

"Review the Stackdriver monitoring." - We have already reviewed the monitoring to identify the problem that has occurred. After establishing that there is a problem, reviewing the monitoring again is not going to mitigate the impact of the incident on users of the service.

"Upsize the virtual machines running the login services." - We are not aware of what the problem is and taking action blindly could make the problem worse.

"Deploy a new release to see whether it fixes the problem." - This does not mitigate the issues to users and could in fact, make the problem worse.

The correct answer is "Create a logs-based metric in Cloud Logging and a dashboard for that metric in Cloud Monitoring." Cloud Logging is a Google Cloud Platform service that allows you to store and analyze log data. You can create a logs-based metric in Cloud Logging, which allows you to aggregate log entries into time-series data. This time-series data can then be visualized in a dashboard in Cloud Monitoring. This will allow you to visualize how often a cache miss happens over time.

References: https://cloud.google.com/logging/docs/logs-based-metrics#counter-metric

"Link Cloud Logging as a source in Google Data Studio. Filter the logs on the cache misses." - Linking Cloud Logging as a source in Google Data Studio would allow you to view the raw log data but would not allow you to aggregate the log entries into time-series data or visualize the data in a dashboard.

"Configure Cloud Profiler to identify and visualize when the cache misses occur based on the logs." - Cloud Profiler is a Google Cloud Platform service that allows you to analyze the performance of your application and identify performance issues. It does not allow you to aggregate log entries into time-series data or visualize the data in a dashboard.

"Configure BigQuery as a sink for Cloud Logging. Create a scheduled query to filter the cache miss logs and write them to a separate table." - Configuring BigQuery as a sink for Cloud Logging would allow you to store the log data in a separate table, but would not allow you to aggregate the log entries into time-series data or visualize the data in a dashboard.`

The correct answer is "Create a new GCP monitoring project and create a Cloud Monitoring Workspace inside it. Attach the production projects to this workspace. Grant relevant team members read access to the Cloud Monitoring Workspace."

This answer follows the principle of least privilege, as it provides relevant team members with the least amount of access required to view the metrics of the production projects. By creating a new GCP monitoring project and a Cloud Monitoring Workspace inside it, and then attaching the production projects to this workspace, it allows for the monitoring of the production environment without false alerts from development and staging projects. Furthermore, granting relevant team members read access to the Cloud Monitoring Workspace allows them to view the metrics of the production projects without the need for access to the production projects themselves. It is Google's recommendation to that 'when you want to manage metrics for multiple projects; we recommend that you create a project to be the scoping project for that metrics scope.'

Reference: https://cloud.google.com/monitoring/settings/multiple-projects

"Grant relevant team members read access to all GCP production projects. Create Cloud Monitoring workspaces inside each project." - This answer does not follow the principle of least privilege as it provides relevant team members with 'read' access to all GCP production projects. This would provide them with more access than is necessary, as they would not need access to the projects themselves to view the metrics of the production environment. Furthermore, creating Cloud Monitoring workspaces inside each project would not allow for the monitoring of the production environment without false alerts from development and staging projects.

"Grant relevant team members the Project Viewer IAM role on all GCP production projects. Create Cloud Monitoring workspaces inside each project." - This answer does not follow the principle of least privilege as it provides relevant team members with the Project Viewer IAM role on all GCP production projects. This would provide them with more access than is necessary, as they would not need access to the projects themselves to view the metrics of the production environment. Furthermore, creating Cloud Monitoring workspaces inside each project would not allow for the monitoring of the production environment without false alerts from development and staging projects.

"Choose an existing GCP production project to host the monitoring workspace. Attach the production projects to this workspace. Grant relevant team members read access to the Cloud Monitoring Workspace." - This answer does not follow the principle of least privilege as it grants relevant team members read access to the Cloud Monitoriung Workspace, which would provide them with more access than is necessary, as they would not need access to the projects themselves to view the metrics of the production environment. Furthermore, choosing an existing GCP production project to host the monitoring workspace would not allow for the monitoring of the production environment without false alerts from development and staging projects.

Before deprecating the API, the new version should be released and ready for usage. Additionally, no further support should be provided to users of the old API, it is within their remit to upgrade to the new version. Consumers who do not upgrade won't benefit from using the new version and will incur the technical debt of having to refactor their code to match the new library.

These steps correspond approximately to the service lifecycle outlined in the Site Reliability Workbook.

Reference: https://sre.google/workbook/engagement-model/ - (The Service Lifecycle)

"Announce deprecation of the old version of the API. Introduce the new version of the API. Contact remaining users on the old API. Deprecate the old version of the API. Turn down the old version of the API. Provide best effort support to users of the old API." - You cannot deprecate or announce the deprecation before introducing the newer version of the API

"Announce deprecation of the old version of the API. Contact remaining users on the old API. Introduce the new version of the API. Deprecate the old version of the API. Provide best effort support to users of the old API. Turn down the old version of the API." - You cannot deprecate or announce the deprecation before introducing the newer version of the API

"Introduce the new version of the API. Contact remaining users of the old API. Announce deprecation of the old version of the API. Deprecate the old version of the API. Turn down the old version of the API. Provide best effort support to users of the old API." - You cannot support users of the old API after it has been turned down.

We are given 3 requirements for our application running in GCP - streamline the release process, lower operational toil and keep user data secure. Given this is a GCP exam, the application is running in GCP and Google's eyes, and handling user data outside of GCP is 'insecure', we can eliminate the solutions running on-prem or on local running stations.

If it were possible to run Jenkins using Cloud Build, that would be the best, lowest operational toil solution, however, Jenkins only is able to run on GCE instances (from the available options in the question).

References: Jenkins Plugin to run on GCE - https://plugins.jenkins.io/google-compute-engine/

"Implement Jenkins on local workstations." - Handling user data on local workstations is insecure.

"Implement Jenkins on Kubernetes on-premises." - Handling user data on-prem is insecure.

"Implement Jenkins on Google Cloud Functions." - Cloud Functions is a CI/CD tool and cannot be used to run Jenkins, unfortunately. Cloud functions let you treat Google services like building blocks and is a serverless offering. It is expected that you are able to make the deduction that Jenkins cannot run using Google Cloud Functions as Jenkins is not a Google Cloud Product.

Load balancing the traffic is a best practice if we wish to improve service availability; it will enable our infrastructure to be resilient and distributes the load across multiple instances. We will be able to configure health checks at a VM level and provides the initial steps to create an auto-scaling architecture.

References:

Adding instances to a MIG - https://cloud.google.com/compute/docs/instance-groups/working-with-managed-instances#adding_instances_to_a_mig

"Change the specified SLO to match the measured SLI" - The customer sets the SLO, and the SLI is a measure, not something that can be changed

"Move the service to higher-specification compute instances with more memory" - The instance is failing due to low memory

"Set up additional service instances in other zones and use them as a failover in case the primary instance is unavailable" - This answer is worded very carefully so as not to be the same as using a managed instance group - creating this failover ability will require more than likely custom tooling for this 'primary' instance approach so would be an inefficient solution to the problem.

The correct answer is "Import the Cloud Profiler package, and configure it to relay function timing data to Cloud Monitoring for further analysis." Cloud Profiler is a Google Cloud Platform (GCP) service that can be used to collect detailed metrics such as system resource utilization both inside and outside of GCP. It is a statistical, low-overhead profiler that continuously gathers CPU usage and memory-allocation information from your production applications. It also has the advantage of being a centralized GCP service, which minimizes the work required to set up the collection system.

"Import the Cloud Debugger package, and configure the application to emit debug messages with timing information." - Cloud Debugger is a Google Cloud Platform (GCP) service that allows users to debug their applications. However, it is not designed to collect detailed metrics such as system resource utilization, so there are better choices for this task. EDIT: It is also being deprecated as of May 2023.

"Instrument the code using a timing library, and publish the metrics via a health check endpoint that is scraped by Cloud Monitoring." - Instrumenting the code using a timing library is a good way to collect detailed metrics such as system resource utilization. However, publishing the metrics via a health check endpoint scraped by Cloud Monitoring is not the most efficient way to collect the metrics. A better option would be to use a centralized GCP service such as Cloud Profiler.

"Install an Application Performance Monitoring (APM) tool in both locations, and configure an export to a central data storage location for analysis." - Installing an Application Performance Monitoring (APM) tool in both locations is a good way to collect detailed metrics such as system resource utilization. However, there are more efficient ways to collect the metrics than configuring an export to a central data storage location for analysis. A better option would be to use a centralized GCP service such as Cloud Profiler.

The Production Readiness Review (PRR) is a process that is used to assess the readiness of a service for production. The goal of the PRR is to identify any potential issues or risks that could arise during the service's operation in production. After the PRR analysis phase, the next phase is to select items in PRR to improve before handover the service to the SRE team. Therefore, the correct answer is:

"Identify recommended reliability improvements to the service to be completed before handover." - The goal of the PRR is to identify any potential issues or risks that could arise during the service's operation in production. Therefore, the next step should be to identify any recommended reliability improvements that need to be completed before the service can be handed over to the SRE team.

"Adjust the SLO targets to be achievable by the service so you can bring it into production." - Adjusting the SLO targets to be achievable by the service is not the next step in the PRR process. The first step is to identify potential issues or risks that could arise during the service's operation in production.

"Notify the development team that they will have to provide production support for the service." - Notifying the development team that they will have to provide production support for the service is not the next step in the PRR process. The first step is to identify potential issues or risks that could arise during the service's operation in production.

"Bring the service into production with no SLOs and build them when you have collected operational data." - Bringing the service into production with no SLOs is not a recommended practice for SRE teams. SLOs should be established before the service is brought into production to ensure that the service is operating as expected and meeting its goals.

The core question being asked here is how to define SLOs based on current performance. Google suggests to 'not pick a target based on current performance' and that it is 'better to start with a loose target that you tighten than to choose an overly strict target that has to be relaxed when you discover it's unattainable.

Reference:

'Don’t pick a target based on current performance' and 'Perfection can wait' - https://sre.google/sre-book/service-level-objectives/