PCDOE practice questions 171–180

1. Question 171 · 210 in bank

   Your development team has created a new version of their service's API. You need to deploy the new versions of the API with the least disruption to third-party developers and end users of third-party installed applications. What should you do?

   • AIntroduce the new version of the API. Announce deprecation of the old version of the API. Deprecate the old version of the API. Contact remaining users of the old API. Provide best effort support to users of the old API. Turn down the old version of the API.
   • BAnnounce 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.
   • CAnnounce 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.
   • DIntroduce 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.

   Show answer

   Answer: A

   Explanation

   Let's start with Eliminating, as I see a lot of you are confused here. You cannot deprecate or announce depreciation before introducing the newer version. This easily eliminates B and C options. Now between A and D, A fully follows the pattern of API deprecation. Deprecate, but have not stopped yet, trying to provide support till it is totally closed. No support after that. Go with A. Hope this helps all.

   Source: Adapted from community discussion — KyubiBlaze

   References

   • Google Cloud documentation

   Next question

2. Question 172 · 210 in bank

   You are running an application on Compute Engine and collecting logs through Stackdriver. You discover that some personally identifiable information (PII) is leaking into certain log entry fields. You want to prevent these fields from being written in new log entries as quickly as possible. What should you do?

   • AUse the filter-record-transformer Fluentd filter plugin to remove the fields from the log entries in flight.
   • BUse the fluent-plugin-record-reformer Fluentd output plugin to remove the fields from the log entries in flight.
   • CWait for the application developers to patch the application, and then verify that the log entries are no longer exposing PII.
   • DStage log entries to Cloud Storage, and then trigger a Cloud Function to remove the fields and write the entries to Stackdriver via the Stackdriver Logging API.

   Show answer

   Answer: A

   Explanation

   Seems both A and B will work. However i will go with A, since it is included in the fluentd core and does not require installing a new plugin "The filter_record_transformer filter plugin mutates/transforms incoming event streams in a versatile manner. If there is a need to add/delete/modify events, this plugin is the first filter to try. It is included in the Fluentd's core." https://docs.fluentd.org/filter/record_transformer

   Source: Adapted from community discussion — not_thanos

   References

   • Google Cloud documentation

   Next question

3. Question 173 · 210 in bank

   You support a service that recently had an outage. The outage was caused by a new release that exhausted the service memory resources. You rolled back the release successfully to mitigate the impact on users. You are now in charge of the post-mortem for the outage. You want to follow Site Reliability Engineering practices when developing the post-mortem. What should you do?

   • AFocus on developing new features rather than avoiding the outages from recurring.
   • BFocus on identifying the contributing causes of the incident rather than the individual responsible for the cause.
   • CPlan individual meetings with all the engineers involved. Determine who approved and pushed the new release to production.
   • DUse the Git history to find the related code commit. Prevent the engineer who made that commit from working on production services.

   Show answer

   Answer: B

   Explanation

   B. Focus on identifying the contributing causes of the incident rather than the individual responsible for the cause. According to Site Reliability Engineering (SRE) practices, the goal of a post-mortem is to identify the underlying causes of the incident in order to take steps to prevent it from happening again in the future. This involves looking for patterns and issues in the system rather than looking for a specific person to blame. It's important to have a focus on learning and continuous improvement, rather than assigning blame.

   Source: Adapted from community discussion — JonathanSJ

   Next question

4. Question 174 · 210 in bank

   You support a high-traffic web application and want to ensure that the home page loads in a timely manner. As a first step, you decide to implement a Service Level Indicator (SLI) to represent home page request latency with an acceptable page load time set to 100 ms. What is the Google-recommended way of calculating this SLI?

   • ABucketize the request latencies into ranges, and then compute the percentile at 100 ms.
   • BBucketize the request latencies into ranges, and then compute the median and 90th percentiles.
   • CCount the number of home page requests that load in under 100 ms, and then divide by the total number of home page requests.
   • DCount the number of home page request that load in under 100 ms, and then divide by the total number of all web application requests.

   Show answer

   Answer: C

   Explanation

   https://sre.google/workbook/implementing-slos/ In the SRE principles book, it's recommended treating the SLI as the ratio of two numbers: the number of good events divided by the total number of events. For example: Number of successful HTTP requests / total HTTP requests (success rate)

   Source: Adapted from community discussion — raf2121

   References

   • Google Cloud documentation

   Next question

5. Question 175 · 210 in bank

   Select 2

   You support a user-facing web application. When analyzing the application's error budget over the previous six months, you notice that the application has never consumed more than 5% of its error budget in any given time window. You hold a Service Level Objective (SLO) review with business stakeholders and confirm that the SLO is set appropriately. You want your application's SLO to more closely reflect its observed reliability. What steps can you take to further that goal while balancing velocity, reliability, and business needs? (Choose two.)

   • AAdd more serving capacity to all of your application's zones.
   • BHave more frequent or potentially risky application releases.
   • CTighten the SLO match the application's observed reliability.
   • DImplement and measure additional Service Level Indicators (SLIs) fro the application.
   • EAnnounce planned downtime to consume more error budget, and ensure that users are not depending on a tighter SLO.

   Show answer

   Answer: DE

   Explanation

   I would go for B+D: -A: no, there's no reason to add capacity if we are barely scratching error budget; -B: everything seems fine, so it's ok to dare with more innovative/risky releases; -C: no, stakeholders said SLO is ok; -D: adding additional SLIs (and so SLOs) might be a way to reflect observer reliability more closely; -E: put the servers down for no reason is a no-no.

   Source: Adapted from community discussion — Trony

   References

   • Google Cloud documentation

   Next question

6. Question 176 · 210 in bank

   Select 2

   You support a service with a well-defined Service Level Objective (SLO). Over the previous 6 months, your service has consistently met its SLO and customer satisfaction has been consistently high. Most of your service's operations tasks are automated and few repetitive tasks occur frequently. You want to optimize the balance between reliability and deployment velocity while following site reliability engineering best practices. What should you do? (Choose two.)

   • AMake the service's SLO more strict.
   • BIncrease the service's deployment velocity and/or risk.
   • CShift engineering time to other services that need more reliability.
   • DGet the product team to prioritize reliability work over new features.
   • EChange the implementation of your Service Level Indicators (SLIs) to increase coverage.

   Show answer

   Answer: BC

   Explanation

   BC https://sre.google/workbook/implementing-slos/#slo-decision-matrix A: wrong – SLO is already well-defined, customer satisfaction is high. E: wrong – change SLI means how SLO, which is already well-defined. CD are valid, but the best option is C because current product is already quite reliable.

   Source: Adapted from community discussion — NXD

   Next question

7. Question 177 · 210 in bank

   Your company follows Site Reliability Engineering principles. You are writing a postmortem for an incident, triggered by a software change that severely affected users. You want to prevent severe incident from happening in the future. What should you do?

   • AIdentify engineers responsible for the incident and escalate to the senior management.
   • BEnsure that test cases that catch errors of this type are run successfully before new software releases.
   • CFollow up with the employees who reviewed the changes and prescribe practices they should follow in the future.
   • DDesign a policy that will require on-call teams to immediately call engineers and management to discuss a plan of action if an incident occurs.

   Show answer

   Answer: B

   Next question

8. Question 178 · 210 in bank

   Select 2

   Your organization uses a change advisory board (CAB) to approve all changes to an existing service. You want to revise this process to eliminate any negative impact on the software delivery performance. What should you do? (Choose two.)

   • AReplace the CAB with a senior manager to ensure continuous oversight from development to deployment.
   • BLet developers merge their own changes, but ensure that the team's deployment platform can roll back changes if any issues are discovered.
   • CMove to a peer-review based process for individual changes that is enforced at code check-in time and supported by automated tests.
   • DBatch changes into larger but less frequent software releases.
   • EEnsure that the team's development platform enables developers to get fast feedback on the impact of their changes.

   Show answer

   Answer: CE

   Explanation

   Answer should be C and E To revise the change approval process and eliminate any negative impact on software delivery performance, you should consider the following approaches: C. Move to a peer-review based process for individual changes that is enforced at code check-in time and supported by automated tests: Implementing a peer-review process ensures that changes are reviewed by team members, which can catch issues early in the development process. Automated tests can provide additional confidence in the quality of changes. This approach encourages collaboration and reduces the need for a formal CAB. E. Ensure that the team's development platform enables developers to get fast feedback on the impact of their changes: Fast feedback mechanisms, such as automated testing and continuous integration pipelines, allow developers to quickly identify and address issues with their changes. This reduces the need for a formal approval board like CAB and promotes a culture of ownership and responsibility among developers.

   Source: Adapted from community discussion — ManishKS

   References

   • Google Cloud documentation

   Next question

9. Question 179 · 210 in bank

   Your organization has a containerized web application that runs on-premises. As part of the migration plan to Google Cloud, you need to select a deployment strategy and platform that meets the following acceptance criteria: 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?

   • ADeploy 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.
   • BDeploy 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.
   • CDeploy 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.
   • DDeploy 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.

   Show answer

   Answer: D

   Explanation

   Option D allows for continuous testing of multiple versions of microservices, meets the traffic splitting requirements, and provides the necessary flexibility for controlling traffic based on user-agent headers, making it the most suitable choice based on the specified acceptance criteria.

   Source: Adapted from community discussion — ManishKS

   Next question

10. Question 180 · 210 in bank

    Your team is running microservices in Google Kubernetes Engine (GKE). You want to detect consumption of an error budget to protect customers and define release policies. What should you do?

    • ACreate SLIs from metrics. Enable Alert Policies if the services do not pass.
    • BUse the metrics from Anthos Service Mesh to measure the health of the microservices.
    • CCreate a SLO. Create an Alert Policy on select_slo_burn_rate.
    • DCreate a SLO and configure uptime checks for your services. Enable Alert Policies if the services do not pass.

    Show answer

    Answer: C

    Explanation

    The best answer is C. Create a SLO. Create an Alert Policy on select_slo_burn_rate. Here's why: SLOs (Service Level Objectives): SLOs are crucial for defining the acceptable performance levels of your microservices. They help you set clear targets for things like latency, availability, and error rates. Error Budget: An error budget is a defined amount of "acceptable" errors or performance degradation within a given time period. It allows for some flexibility while still ensuring overall service health. Alerting on Burn Rate: The select_slo_burn_rate metric in Cloud Monitoring allows you to track how quickly your error budget is being consumed. By creating an alert policy based on this metric, you can be notified when the burn rate exceeds a predefined threshold, indicating a potential risk of exceeding your error budget.

    Source: Adapted from community discussion — thewalker

    References

    • Google Cloud documentation

    Next question

Keyboard:J Kmove between questionsA–Dselect an answerRshow or hide the answer← →change page

PCDOE practice, question 171. 210 questions available.