Pro-DevOps-3

The principles of site reliability engineering are adhered to by your company. You are writing a postmortem for an incident, triggered by a software change that severely affected users. You're trying to prevent a serious incident from happening in the future. What are you supposed to do?

• Identify engineers responsible for the incident and escalate to the senior management.

• Ensure that test cases that catch errors of this type are run successfully before new software releases.

• Follow up with the employees who reviewed the changes and prescribe practices they should follow in the future.

• Design a policy that will require on-call teams to immediately call engineers and management to discuss a plan of action if an incident

  occurs.

To approve all changes to the current service, your organisation is using a Change Advisory Board:CAB. In order to avoid any adverse impact on the performance of software delivery, you are going to review this process. What are you supposed to do? Choose two

• Replace the CAB with a senior manager to ensure continuous oversight from development to deployment.

• Let developers merge their own changes, but ensure that the team's deployment platform can roll back changes if any issues are

  discovered.

• Move to a peer-review based process for individual changes that is enforced at code check-in time and supported by automated tests.

• Batch changes into larger but less frequent software releases.

• Ensure that the team's development platform enables developers to get fast feedback on the impact of their changes.

A containerised web application is running on premises for your organization. You must select this option as part of your Google Cloud migration plan. A deployment strategy and a platform meeting the criteria of acceptance set out below:

1. The platform must be able to direct traffic from Android devices to an Android-specific microservice.

2. The platform must allow for arbitrary percentage-based traffic splitting

3. The deployment strategy must allow for continuous testing of multiple versions of any microservice.

What should you do?

• . Deploy the canary release of the application to Cloud Run. Use traffic splitting to direct 10% of user traffic to the canary release based on

  the revision tag.

• Deploy the canary release of the application to App Engine. Use traffic splitting to direct a subset of user traffic to the new version based on

  the IP address.

• Deploy the canary release of the application to Compute Engine. Use Anthos Service Mesh with Compute Engine to direct 10% of user traffic

  to the canary release by configuring the virtual service.

• Deploy the canary release to Google Kubernetes Engine with Anthos Service Mesh. Use traffic splitting to direct 10% of user traffic to the

  new version based on the user-agent header configured in the virtual service.

Your team is running microservices in Google Kubernetes Engine (GKE). To protect customers and to set release policy, you want to know how much error budget is being used. What are you supposed to be doing?

• Create SLIs from metrics. Enable Alert Policies if the services do not pass.

• Use the metrics from Anthos Service Mesh to measure the health of the microservices.

• Create a SLO. Create an Alert Policy on select_slo_burn_rate.

• Create a SLO and configure uptime checks for your services. Enable Alert Policies if the services do not pass.

For their Google Cloud project, your organization would like to collect system logs that can be applied for the creation of dashboards in cloud operation. To collect system logs, you must set up all existing and upcoming instances of the Compute Engine service so that Ops Agent will always be updated. What are you supposed to do?

• Use the gcloud CLI to install the Ops Agent on each VM listed in the Cloud Asset Inventory,

• Select all VMs with an Agent status of Not detected on the Cloud Operations VMs dashboard. Then select Install agents

• Use the gcloud CLI to create an Agent Policy.

• Install the Ops Agent on the Compute Engine image by using a startup script

A hierarchy of Google Cloud resources for production, testing, and development exists in your company. In order to accelerate the identification and resolution of security issues, your cyber security team needs to review Google Cloud's Security posture. You need to centralize the logs generated by Google Cloud services from all projects only inside your production folder to allow for alerting and near-real time analysis. What are you supposed to do?

• Enable the Workflows API and route all the logs to Cloud Logging.

• Create a central Cloud Monitoring workspace and attach all related projects

• Create an aggregated log sink associated with the production folder that uses a Pub/Sub topic as the destination.

• Create an aggregated log sink associated with the production folder that uses a Cloud Logging bucket as the destination.

You're configuring a Google Cloud application's front end tier. The frontend tier is hosted in nginx and deployed using a

managed instance group with an Envoy-based external HTTP(S) load balancer in front. Only users based in the United Kingdom are served by the application, which is fully deployed in the Europe West2 region. The most cost effective network tier and load balancing configuration must be selected. What's it that you should be using?

• Premium Tier with a global load balancer

• Premium Tier with a regional load balancer

• Standard Tier with a global load balancer

• Standard Tier with a regional load balancer

You recently deployed your application in Google Kubernetes Engine (GKE) and now need to release a new version of the application. If there are problems with the new version, you must be able to instantly revert to the previous version of the application. What model of deployment do you need to employ?

• Perform a rolling deployment, and test your new application after the deployment is complete.

• Perform A/B testing, and test your application periodically after the deployment is complete.

• Perform a canary deployment, and test your new application periodically after the new version is deployed.

• Perform a blue/green deployment, and test your new application after the deployment is complete.

For your organization, you are building and deploying a microservice on Cloud Run. Many applications are using your service internally. You are

deploying a new release, and you need to test the new version extensively in the staging and production environments. The impact of users and developers must be minimized. What are you supposed to be doing?

• Deploy the new version of the service to the staging environment. Split the traffic, and allow 1% of traffic through to the latest version. Test

  the latest version. If the test passes, gradually roll out the latest version to the staging and production environments.

• Deploy the new version of the service to the staging environment. Split the traffic, and allow 50% of traffic through to the latest version. Test

  the latest version. If the test passes, send all traffic to the latest version. Repeat for the production environment.

• Deploy the new version of the service to the staging environment with a new-release tag without serving traffic. Test the new-release

  version. If the test passes, gradually roll out this tagged version. Repeat for the production environment.

• Deploy a new environment with the green tag to use as the staging environment. Deploy the new version of the service to the green

  environment and test the new version. If the tests pass, send all traffic to the green environment and delete the existing staging environment.

  Repeat for the production environment.

You're working for a global organisation, and you are running a service with an availability goal of 99 % using limited technical resources. You've noticed that the service is available 99.5% of the time during this calendar month. In order to be able to respond to changes in the business and new features, you need to make sure that your service is up to date with those availability targets. You also need to reduce technical debt while minimizing operational costs. You want to follow Google-recommended practices. What should you

do?

• Add N+1 redundancy to your service by adding additional compute resources to the service.

• Identify, measure, and eliminate toil by automating repetitive tasks.

• Define an error budget for your service level availability and minimize the remaining error budget.

• Allocate available engineers to the feature backlog while you ensure that the service remains within the availability target.