I85PREP
⌘ K
IBM Cloud Associate SRE study materials
IBM Cloud Associate SRE study resources

IBM Cloud Associate SRE practice questions

One question at a time. Build your IBM Cloud Associate SRE understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1SRE principles and service reliability

In IBM Cloud SRE practice, which term is defined as a quantitative measure of a specific aspect of service behavior, such as the proportion of successful requests or the 99th-percentile latency?

  1. Service Level Agreement (SLA)
  2. Service Level Objective (SLO)
  3. Service Level Indicator (SLI) Correct answer.
  4. Error budget

Explanation

An SLI is the actual measured quantity, such as success ratio or latency percentile, that describes service behavior. An SLO sets a target range for that indicator, an SLA turns commitments into a contract, and the error budget is the allowed amount of unreliability.

Question 2SRE principles and service reliability

An SRE team notices engineers spend several hours each week manually rotating API keys and filing the same access-review tickets. Which SRE concept best describes this work?

  1. Toil Correct answer.
  2. Capacity buffer
  3. On-call escalation
  4. Incident command

Explanation

Toil is manual, repetitive, automatable work that scales with service growth and produces no lasting value. Key rotation and repeated access tickets fit that definition, so the team should automate them rather than treat them as incident response or capacity planning.

Question 3SRE principles and service reliability

What is the primary goal of a blameless postmortem after a production incident?

  1. Replace the service SLO with a stricter contractual SLA
  2. Assign individual fault so management can apply discipline
  3. Document systemic causes and actions that prevent recurrence Correct answer.
  4. Reduce the number of responders needed for future incidents

Explanation

A blameless postmortem focuses on how systems, processes, and safeguards allowed the incident rather than on punishing individuals. The output should be a shared timeline, contributing causes, and concrete corrective actions that reduce recurrence risk.

Question 4SRE principles and service reliability

A service has a 99.9% availability SLO over 30 days. The team has consumed 100% of its error budget with 10 days remaining. According to a typical SRE error budget policy, what should happen next?

  1. Increase the SLO to 99.99% to motivate the team
  2. Disable all monitoring to avoid alert noise until the window resets
  3. Freeze non-essential changes and focus on reliability fixes Correct answer.
  4. Continue releasing features because the SLA still permits downtime

Explanation

An error budget policy makes the consequence of exhausting the budget explicit and pre-agreed. When the budget is spent, non-essential releases should pause and engineering effort should shift to reliability until the service is back within its SLO.

Question 5SRE principles and service reliability

Which set of signals is commonly called the “four golden signals” for monitoring a user-facing service?

  1. Availability, durability, cost, and security
  2. Latency, traffic, errors, and saturation Correct answer.
  3. Throughput, queue depth, thread count, and garbage-collection pause
  4. CPU, memory, disk, and network

Explanation

The four golden signals are latency, traffic, errors, and saturation because together they describe the user-visible health and pressure on a service. Resource metrics such as CPU and memory are useful causes, but they are not the canonical golden-signal set.

Question 6SRE principles and service reliability

A team plans to release a new version of an IBM Cloud service. They route 2% of live traffic to the new version while comparing error rate and latency against the baseline. Which practice are they applying?

  1. Blue-green deployment with full cutover
  2. Canary release Correct answer.
  3. Feature flag kill switch
  4. Shadow testing with mirrored requests

Explanation

A canary release exposes a small slice of real traffic to the new version and compares its behavior with the baseline before wider rollout. This limits blast radius while providing production evidence about errors and latency.

Question 7SRE principles and service reliability

Which metric most directly indicates how quickly an operations team restores service after an incident begins?

  1. Mean time to recovery (MTTR) Correct answer.
  2. Mean time between failures (MTBF)
  3. Change failure rate
  4. Service level objective (SLO) attainment

Explanation

Mean time to recovery measures the average elapsed time from incident start to restored service, so it directly reflects restoration speed. MTBF describes how often failures occur, SLO attainment summarizes reliability over a window, and change failure rate tracks deployment quality.

Question 8SRE principles and service reliability

An SRE team wants alerts that fire when users are actually experiencing pain, not when a single backend node has high CPU. Which alerting approach best follows SRE principles?

  1. Alert on cause-based metrics such as CPU and memory before symptoms appear
  2. Alert only when a host stops sending metrics for five minutes
  3. Alert on multi-window burn rates of the service’s SLO error budget Correct answer.
  4. Alert on every infrastructure threshold crossing to catch all anomalies

Explanation

SRE alerting favors symptoms that reflect user impact, and error-budget burn rate is a direct symptom of reliability loss. Multi-window burn-rate alerts catch both fast and slow consumption while reducing noise from individual infrastructure causes.

Question 9SRE principles and service reliability

Before running a chaos experiment against a production service, what should the team define first?

  1. A new SLA that promises zero impact during the experiment
  2. A rollback plan that restores the last database backup
  3. A communication plan that notifies only the executive sponsor
  4. A steady-state hypothesis and a limited blast radius with abort conditions Correct answer.

Explanation

Chaos engineering starts with a measurable steady-state hypothesis, a controlled blast radius, and pre-agreed abort conditions so the experiment can be stopped safely. These controls turn a disruption into a valid experiment rather than an uncontrolled outage.

Question 10SRE principles and service reliability

An application currently runs three instances across three availability zones. To achieve N+1 redundancy for zone failure while maintaining full capacity, what should the team provision?

  1. Three instances, because each zone already has one
  2. Four instances spread so one zone loss leaves three running Correct answer.
  3. Two instances in one zone and one in each of the other zones
  4. Six instances, because N+1 always means doubling capacity

Explanation

N+1 redundancy means provisioning one additional unit beyond the capacity needed to serve normal demand, so a single zone loss does not reduce serving capacity. Four instances distributed across zones can lose one zone and still leave three instances running.

Question 11SRE principles and service reliability

In an SRE engagement, which statement best describes the relationship between a service level objective (SLO) and a service level agreement (SLA)?

  1. An SLO and an SLA are identical because both are legal commitments.
  2. An SLO is an internal target usually stricter than the external SLA. Correct answer.
  3. An SLA defines the monitoring query, while an SLO defines refunds.
  4. An SLA is an internal target always stricter than the published SLO.

Explanation

An SLO is an internal reliability target derived from user expectations, while an SLA is an external contract with business or legal consequences. Teams commonly set the SLO stricter than the SLA so normal operation stays within the contracted commitment.

Question 12SRE principles and service reliability

An on-call engineer receives an alert at 02:00. Which artifact should provide the exact diagnostic and mitigation steps for that alert?

  1. The alert-specific operational runbook Correct answer.
  2. The team's blameless postmortem archive
  3. The service's architecture decision record
  4. The quarterly business review deck

Explanation

An operational runbook is the documented procedure for diagnosing and mitigating a specific alert or known failure mode. It should be kept current and linked directly from the alert so the on-call engineer can act quickly under pressure.

Question 13SRE principles and service reliability

During a major customer-facing outage, which responsibility belongs to the incident commander?

  1. Approving the permanent code fix after the incident closes
  2. Writing the customer-facing marketing email
  3. Debugging the deepest application stack trace personally
  4. Coordinating roles, priorities, and communications Correct answer.

Explanation

The incident commander coordinates response roles, sets priorities, and manages communication rather than personally debugging every technical detail. This separation lets technical responders focus on diagnosis and mitigation while one person maintains shared situational awareness.

Question 14SRE principles and service reliability

An SRE team wants alerts that catch both fast, severe SLO violations and slow, sustained budget burn without flooding on-call. Which alerting approach fits best?

  1. Multiwindow, multi-burn-rate alerts on the SLO error budget Correct answer.
  2. Daily reports of request latency sent by email
  3. A single static threshold on CPU utilization for every host
  4. One alert per individual 5xx response observed in the logs

Explanation

Multiwindow, multi-burn-rate alerting compares error-budget consumption over short and long windows to catch both sudden severe violations and slower sustained burn. It ties alert urgency to user-impacting SLO risk and reduces noisy alerts from individual symptoms.

Question 15SRE principles and service reliability

A client service calls an IBM Cloud API that is briefly overloaded. Which retry strategy best avoids making the overload worse?

  1. Retry each request a fixed 100 times with no delay
  2. Use exponential backoff with jitter and a retry cap Correct answer.
  3. Retry immediately in a tight loop until the call succeeds
  4. Disable timeouts so retries never abandon an in-flight request

Explanation

Exponential backoff with randomized jitter spreads retries over time and prevents many clients from retrying in lockstep, while a retry cap bounds total load. This reduces the chance of a retry storm that deepens the overload.

Question 16SRE principles and service reliability

A service uses a circuit breaker around a failing downstream dependency. What does the open state accomplish?

  1. It increases the timeout for each request to improve success chance.
  2. It permanently removes the dependency from the architecture.
  3. It fails fast instead of waiting on calls likely to time out. Correct answer.
  4. It forwards every request to the dependency to confirm recovery.

Explanation

When a circuit breaker opens, it stops sending requests to a dependency that is likely to fail and returns an error or fallback quickly. This protects callers from exhausting threads and connections while the dependency recovers.

Question 17SRE principles and service reliability

A service is near its SLO limit and traffic exceeds capacity. Which action best protects the SLO for the most important users?

  1. Shed low-priority traffic and degrade noncritical features Correct answer.
  2. Disable health checks so more capacity stays available for work
  3. Retry all failed requests immediately at the edge
  4. Increase every request timeout so slow requests can finish

Explanation

Load shedding and graceful degradation preserve capacity for critical user journeys when demand exceeds supply. Dropping or simplifying low-priority work is preferable to letting all requests slow down and violate the SLO.

Question 18SRE principles and service reliability

Before a predicted traffic peak, which activity best shows whether the service has enough headroom to meet its SLO?

  1. Run a peak load test with a safety margin Correct answer.
  2. Shorten the SLO measurement window to one hour
  3. Review the last postmortem's action-item list
  4. Add more dashboards for every microservice

Explanation

A load test at expected peak plus a safety margin measures whether the service can sustain the load while meeting its SLO. It reveals saturation points and dependencies that may fail before production traffic arrives.

Question 19SRE principles and service reliability

A request must pass through three independent components, each with 99.95% availability and no redundancy or retry. What is the approximate composite availability?

  1. 99.50%
  2. 98.50%
  3. 99.95%
  4. 99.85% Correct answer.

Explanation

For independent serial components, composite availability is the product of each component's availability: 0.9995 multiplied by itself three times is approximately 0.9985, or 99.85%. The result is lower than any single component because every dependency must succeed.

Question 20SRE principles and service reliability

A service runs application instances in three availability zones, but its managed database has a single primary in one zone and no cross-zone failover. Which reliability conclusion is most accurate?

  1. Zone redundancy of the application tier eliminates the need for database backups.
  2. The database primary remains a single point of failure for writes. Correct answer.
  3. The service is fully zone-redundant because the application tier spans three zones.
  4. The service automatically meets a 99.99% SLO because three zones are used.

Explanation

Spreading application instances across zones improves resilience for the compute tier, but a single-zone database primary still creates a single point of failure for writes. True zone resilience requires the data tier to have a failover or replication strategy as well.

Question 21SRE principles and service reliability

A user request traverses an IBM Cloud Kubernetes Service cluster and several microservices, and latency has increased. Which observability capability lets an SRE see the time spent in each service along that single request path?

  1. Distributed tracing with span timing Correct answer.
  2. Host-level CPU utilization dashboards
  3. Aggregated application logs with severity levels
  4. Synthetic transaction checks from one region

Explanation

Distributed tracing propagates a trace context across service calls and records span timing, so an SRE can attribute latency to a specific hop. Logs may show errors but not end-to-end timing, synthetic checks show availability from outside, and CPU dashboards show resource use rather than per-request latency.

Question 22SRE principles and service reliability

During a Sev 1 incident, the on-call SRE has followed the runbook but cannot restore service within the documented resolution window. According to standard incident response practice, what should the SRE do next?

  1. Escalate through the defined escalation policy to involve additional responders Correct answer.
  2. Close the incident and open a problem ticket for next week
  3. Wait for the alert to auto-resolve before notifying anyone
  4. Restart every production node simultaneously to force recovery

Explanation

An escalation policy defines when and whom to engage, bringing in subject-matter experts, additional teams, or management when the on-call responder cannot restore service within the target window. Waiting wastes recovery time, broad restarts increase blast radius, and closing an active incident hides ongoing customer impact.

Question 23SRE principles and service reliability

An SRE team is preparing to deploy a new version of an IBM Cloud service. Which safeguard most directly reduces the time to restore service if the change causes a regression?

  1. Tested rollback procedure for the prior version Correct answer.
  2. Disabling all health checks throughout the deployment window
  3. A significantly longer application request timeout for all callers
  4. A weekly status email sent to all stakeholders

Explanation

A tested rollback procedure restores a known-good version quickly, directly reducing mean time to restore service when a deployment regression occurs. Longer timeouts can worsen failure behavior, status emails do not restore service, and disabling health checks can route traffic to unhealthy instances.

Question 24SRE principles and service reliability

A front-end service calls three downstream IBM Cloud services. It sets a 2-second timeout on its own request, but it does not send a deadline to the downstream calls. Under load, the front end times out and retries, while the downstream services continue processing the abandoned requests. What is the most effective remediation?

  1. Disable retries at the front end and keep downstream timeouts unlimited
  2. Propagate a request deadline and cancel downstream work when it expires Correct answer.
  3. Move all downstream calls to a single availability zone to reduce latency
  4. Increase the front-end timeout to 30 seconds so downstream calls can finish

Explanation

Deadline propagation ensures downstream services stop work that can no longer be used, conserving capacity and preventing retry amplification. Simply increasing the timeout delays failure, disabling retries without cancellation still leaves abandoned work, and using a single availability zone reduces resilience rather than fixing the deadline problem.

Question 25SRE principles and service reliability

A recommendation service that depends on a catalog API is failing, but the product page can still function without recommendations. Which design best supports graceful degradation during the catalog API outage?

  1. Hide recommendations with a feature flag and serve the core page Correct answer.
  2. Increase the maximum connection pool size to the catalog API
  3. Retry the catalog API indefinitely until the dependency recovers
  4. Return an HTTP 500 error for the entire product page to every user

Explanation

A feature flag or fallback lets the service disable optional recommendations and keep the critical product page available. Infinite retries amplify pressure on the failing catalog API, a full-page 500 error makes the outage worse for users, and a larger connection pool does not help when the dependency is failing.

Question 26SRE principles and service reliability

An SRE team receives hundreds of alerts during a regional network issue, most of which are downstream symptoms of the same failure. Which alerting practice best reduces noise without hiding the primary problem?

  1. Send every alert immediately to the on-call pager
  2. Route all alerts to a shared email inbox only
  3. Group related alerts and inhibit downstream symptom alerts Correct answer.
  4. Raise every alert threshold until alerts stop firing

Explanation

Alert grouping and inhibition consolidate related symptoms and suppress alerts caused by a known upstream failure, so responders see the primary signal instead of hundreds of duplicates. Sending every alert creates fatigue, raising thresholds can hide real problems, and email-only routing delays response.

Question 27SRE principles and service reliability

An IBM Cloud service has grown steadily over the last six months. The SRE team wants to decide when to add capacity so that the service keeps meeting its SLO during the next quarter. Which approach is most appropriate?

  1. Set capacity to the average utilization of the last 24 hours
  2. Estimate capacity from the single busiest day last year
  3. Add capacity only after the SLO has already been breached
  4. Forecast demand from growth trends against tested capacity headroom Correct answer.

Explanation

Capacity planning uses historical growth trends and compares forecast demand with tested headroom to add capacity before saturation threatens the SLO. Reacting after a breach violates the SLO, one peak day ignores seasonality and growth, and a 24-hour average does not reflect quarterly demand trends.

Question 28SRE principles and service reliability

A load balancer sends traffic to an application instance that has failed but is still registered because the load balancer only uses passive health checks. Which configuration change most directly prevents traffic from reaching the failed instance?

  1. Add more application instances behind the same load balancer
  2. Increase the load balancer's connection timeout
  3. Configure active health checks with automatic endpoint deregistration Correct answer.
  4. Enable sticky sessions for all client requests

Explanation

Active health checks probe each instance and automatically deregister unhealthy endpoints, so the load balancer stops sending traffic to failed instances. Longer timeouts, more instances, or sticky sessions do not remove the failed endpoint and can prolong customer impact.

Question 29SRE principles and service reliability

Service A has an availability SLO of 99.95% and depends synchronously on Service B, which has an availability SLO of 99.5% and no fallback. What is the most accurate conclusion about Service A's ability to meet its SLO?

  1. Service A's SLO is automatically raised by Service B's lower SLO
  2. Service A cannot meet 99.95% unless Service B improves or a fallback is added Correct answer.
  3. Service A can meet its SLO because its own code has no defects
  4. Service A can ignore Service B because SLOs apply only to front-end services

Explanation

A synchronous dependency without a fallback caps the caller's achievable availability at or below the dependency's availability. Service A's own code quality cannot remove that dependency, SLOs apply to every service rather than only front ends, and a lower dependency SLO cannot raise the caller's SLO.

Question 30SRE principles and service reliability

A retail service has very low traffic most of the month and a large, predictable peak during a three-day sale. The SRE team wants an SLO that reflects user experience during both periods without being dominated by low-traffic hours. Which SLO window design is most appropriate?

  1. Use a time-based SLI that treats every minute of the month as equally important
  2. Use a request-based SLI on a rolling window so real traffic drives it Correct answer.
  3. Use a daily SLO that resets each midnight and ignores the sale period
  4. Use a fixed monthly SLO measured only during the three-day sale peak

Explanation

A request-based SLI weights measurement by actual user requests, so the sale peak and normal periods both contribute according to real impact instead of low-traffic minutes dominating the score. A rolling window keeps the SLO current, while time-based equal-minute scoring, sale-only measurement, or daily resets would misrepresent user experience across the month.

Question 31Monitoring, observability, and alerting

In IBM Cloud Monitoring, what is the primary role of the lightweight agent installed on a host or Kubernetes node?

  1. It collects host and container metrics and streams them to the monitoring backend. Correct answer.
  2. It aggregates application logs and forwards them to IBM Cloud Log Analysis.
  3. It evaluates alert thresholds locally on the node and sends notifications directly without involving the backend service.
  4. It stores metric time series locally to provide long-term retention on the node.

Explanation

The monitoring agent is a collector: it samples host and container metrics on the node and streams them to the IBM Cloud Monitoring backend, where they are stored, queried, and evaluated. It is not a log shipper, it does not provide long-term local retention, and alert evaluation happens in the service rather than on the node.

Question 32Monitoring, observability, and alerting

Which IBM Cloud service records account-level and control-plane API activity so an SRE team can investigate who deleted a resource or changed an IAM policy?

  1. IBM Cloud Log Analysis
  2. IBM Cloud Monitoring
  3. IBM Cloud Activity Tracker Correct answer.
  4. IBM Cloud Metrics Routing

Explanation

Activity Tracker ingests account-level and control-plane API events, such as instance creation, IAM policy changes, and key deletion, and preserves them for audit and compliance investigations. It is event-oriented and is not a store of host performance metrics, which is what Monitoring provides.

Question 33Monitoring, observability, and alerting

The four golden signals used to describe the health of a user-facing service are latency, traffic, errors, and which fourth signal?

  1. Ingest throughput
  2. Retention window
  3. Saturation Correct answer.
  4. Label cardinality

Explanation

The four golden signals are latency, traffic, errors, and saturation. Saturation measures how close a constrained resource such as CPU, memory, or a queue is to its limit, which makes it an early indicator that a service is approaching degradation.

Question 34Monitoring, observability, and alerting

A team wants an IBM Cloud Monitoring alert that fires only when p99 latency of a single Kubernetes namespace exceeds 500 ms for five minutes. Which alert configuration element restricts the metric to that namespace?

  1. A dashboard template shared with the namespace owners for review.
  2. A scope that filters the metric query on the kubernetes.namespace.name label. Correct answer.
  3. A notification channel bound to the namespace owners' email address.
  4. A retention policy on the monitoring instance shortened to five minutes.

Explanation

Alert scope in IBM Cloud Monitoring is a metric query with filters and optional grouping, so filtering on kubernetes.namespace.name restricts evaluation to series from that namespace. Notification channels, retention settings, and dashboards do not constrain which series an alert evaluates.

Question 35Monitoring, observability, and alerting

An SRE deploys a LogDNA agent as a DaemonSet to ship application logs from a Kubernetes cluster into IBM Cloud Log Analysis. Which credential should the agent configuration use to authenticate ingestion?

  1. An IAM API key granted the Viewer role at the account level.
  2. The Log Analysis ingestion key issued for the target instance. Correct answer.
  3. The IBM Cloud Monitoring access key for the same resource group.
  4. A service ID's HMAC credentials generated for object storage access.

Explanation

Log agents authenticate to IBM Cloud Log Analysis with an ingestion key tied to the target instance, which authorizes writes into that instance's log stream. IAM API keys govern the management API and do not grant ingestion, and monitoring credentials are unrelated to log ingestion.

Question 36Monitoring, observability, and alerting

A team needs to compute the 95th percentile of request latency for each five-minute window. Which metric type should the instrumentation record?

  1. A counter incremented once per completed request.
  2. A histogram of latency observations. Correct answer.
  3. A gauge that stores the latency of the most recent request only.
  4. A boolean flag marking each request as slow or not slow.

Explanation

A histogram records observations into buckets, so the backend can compute percentiles such as p95 per window. A counter only totals events, a gauge keeps a single last value, and a boolean flag discards the magnitude needed for percentile estimation.

Question 37Monitoring, observability, and alerting

Microservices on IBM Cloud Kubernetes Service must appear as a single trace in the observability backend. Which mechanism lets a downstream service attach its span to the trace started by the calling service?

  1. Writing each span to a local file inside the pod for later collection by the node.
  2. Propagating the trace context headers, such as traceparent, on outbound requests. Correct answer.
  3. Sampling one hundred percent of requests at the ingress gateway only.
  4. Emitting a new random trace ID in every service and relying on timestamp proximity to correlate spans afterwards.

Explanation

Trace context propagation carries the trace ID and parent span ID in headers such as traceparent, letting each downstream service attach its span to the same trace. Random IDs, local files, and sampling at a single tier do not preserve parent-child relationships across services.

Question 38Monitoring, observability, and alerting

A service has a 99.9% availability SLO over 30 days. Which alerting approach best detects fast error-budget consumption while limiting false pages?

  1. Page on a multi-window burn rate, where a short window confirms a long-window burn. Correct answer.
  2. Page when the 30-day error budget is fully exhausted.
  3. Page as soon as the error-rate metric records any value greater than zero, regardless of the SLO budget.
  4. Page whenever a single request fails.

Explanation

Burn rate compares the observed error rate with the rate the SLO allows, so a high burn rate signals fast budget consumption. Multi-window conditions, such as a one-hour burn confirmed by a five-minute window, page quickly on real incidents while requiring sustained evidence, which suppresses transient blips.

Question 39Monitoring, observability, and alerting

An on-call rotation is overwhelmed by pages that fire for CPU spikes that never affect users. Which change best reduces alert noise while keeping detection of real user impact?

  1. Disable all paging and rely on weekly dashboard reviews during the next business day.
  2. Route every infrastructure metric to the paging channel so nothing is missed, accepting the extra pages as coverage.
  3. Lower the CPU threshold further so the team is warned before users notice anything at all.
  4. Page on user-facing symptoms with sustained for-durations; file cause signals as tickets. Correct answer.

Explanation

Symptom-based alerting pages on what users actually experience, such as elevated error rate or latency, and uses sustained for-durations to filter transient blips. Cause-based signals like CPU remain useful for diagnosis, but paging on them directly produces noise when the spike has no user impact.

Question 40Monitoring, observability, and alerting

An engineer adds the user ID and the full request URL as labels on an HTTP request counter exported to IBM Cloud Monitoring. What is the most likely operational consequence?

  1. Loss of the metric because user IDs are not permitted as label values.
  2. Automatic aggregation of the counter into a single series at ingestion time.
  3. A sharp rise in time series cardinality, increasing storage cost and slowing queries. Correct answer.
  4. Improved compression and faster queries because repeated label values collapse into fewer stored series automatically.

Explanation

Each unique combination of label values creates a separate time series, so user ID and full URL can multiply series into the millions. That inflates storage and ingestion cost and slows queries and dashboards, which is why high-cardinality identifiers are kept out of metric labels.

Question 41Monitoring, observability, and alerting

A compliance team must keep IBM Cloud Activity Tracker audit events for seven years and query them later with an external SIEM. Which IBM Cloud capability should the SRE configure?

  1. Increase the dashboard time range in IBM Cloud Monitoring
  2. Route events to an IBM Cloud Object Storage bucket Correct answer.
  3. Enable an exclusion rule in IBM Cloud Logs
  4. Create a threshold alert in IBM Cloud Monitoring

Explanation

Activity Tracker is the audit source, but long-term retention is achieved by routing events to durable storage such as IBM Cloud Object Storage. Event routing can also forward selected events to other targets for near-real-time analysis. An exclusion rule, dashboard range, or metric alert does not extend audit retention.

Question 42Monitoring, observability, and alerting

An IBM Cloud Monitoring alert must open a PagerDuty incident for the on-call engineer when a production latency threshold is breached. Which configuration item connects the alert policy to PagerDuty?

  1. A log exclusion rule
  2. A notification channel Correct answer.
  3. A metric label
  4. A dashboard template

Explanation

Alert policies in IBM Cloud Monitoring send notifications through configured notification channels. A PagerDuty channel carries the alert payload to PagerDuty, which then creates the incident according to its routing rules. Dashboards, labels, and log exclusion rules do not deliver alerts to on-call tooling.

Question 43Monitoring, observability, and alerting

An SRE runs the same IBM Cloud Logs query every morning to isolate errors from the checkout namespace. Which IBM Cloud Logs feature should be used to store the query and filters for reuse by the team?

  1. An alert definition
  2. An exclusion rule
  3. A parsing template
  4. A saved view Correct answer.

Explanation

A saved view in IBM Cloud Logs preserves a search query and its filters so team members can reopen the same log selection without rebuilding it. Alert definitions evaluate conditions and notify; they do not serve as reusable query shortcuts. Exclusion rules and parsing templates change ingestion or field extraction, not saved search criteria.

Question 44Monitoring, observability, and alerting

An IBM Cloud Monitoring alert on node CPU utilization pages the on-call engineer during brief one-minute spikes that do not affect users. The team still wants to catch sustained CPU saturation. Which alert setting should they adjust?

  1. The notification channel severity mapping
  2. The log retention period
  3. The condition evaluation window Correct answer.
  4. The dashboard refresh interval

Explanation

An evaluation window requires the threshold condition to persist for a defined period before the alert changes state. Lengthening that window suppresses short spikes while still firing when CPU remains saturated. Notification mapping, dashboard refresh, and log retention do not change how long a metric condition must hold.

Question 45Monitoring, observability, and alerting

A platform team wants application teams to see only IBM Cloud Monitoring metrics for their own Kubernetes namespaces, while the SRE team sees all namespaces. Which IBM Cloud Monitoring construct enforces this separation?

  1. Notification channels
  2. Log exclusion rules
  3. Dashboard annotations
  4. Teams configured with scopes Correct answer.

Explanation

IBM Cloud Monitoring uses teams and scopes to control which metrics and resources a group of users can view. A scope can filter by labels such as Kubernetes namespace, so each application team sees only its own data while SREs retain a broader scope. Notification channels, annotations, and log exclusion rules do not restrict metric visibility.

Question 46Monitoring, observability, and alerting

A team sends millions of verbose debug log lines into IBM Cloud Logs each day, but those lines are never searched. Which IBM Cloud Logs control stops the debug lines from consuming plan volume?

  1. An exclusion rule Correct answer.
  2. A parsing template
  3. A dashboard board
  4. A saved view

Explanation

An exclusion rule in IBM Cloud Logs drops matching log lines before they are indexed, so they do not count against ingestion volume. Saved views, parsing templates, and boards operate on logs that have already been ingested or on display layout. Exclusion is the correct control when the content is known to be unnecessary.

Question 47Monitoring, observability, and alerting

Security requires that IBM Cloud Activity Tracker events for IAM policy changes be streamed to an external SIEM in near real time, while the events remain visible in Activity Tracker. Which configuration meets this requirement?

  1. Use Activity Tracker Event Routing to Event Streams Correct answer.
  2. Create an IBM Cloud Monitoring metric alert on IAM latency
  3. Apply an IBM Cloud Logs exclusion rule to IAM events
  4. Archive all events only to IBM Cloud Object Storage

Explanation

Activity Tracker Event Routing can forward selected audit events to targets such as IBM Cloud Event Streams for near-real-time consumption by a SIEM. Routing does not remove the events from Activity Tracker, so the original audit view remains available. A metric alert, log exclusion, or cold archive alone does not provide the required streaming path.

Question 48Monitoring, observability, and alerting

Application logs arrive in IBM Cloud Logs as JSON lines, but searches only match the whole raw line. Which IBM Cloud Logs feature should the SRE configure so that fields such as request_id and status can be searched and alerted on individually?

  1. An exclusion rule
  2. A notification channel
  3. A saved view
  4. A parsing template Correct answer.

Explanation

A parsing template tells IBM Cloud Logs how to extract structured fields from each log line, after which those fields become searchable and usable in alerts. A saved view only stores a query, an exclusion rule drops lines, and a notification channel delivers alerts. Field extraction must happen before field-level search works.

Question 49Monitoring, observability, and alerting

A p99 latency alert uses a fixed 500 ms threshold. Traffic is diurnal, and the alert pages every afternoon even when latency is normal for that hour. Which alerting approach best reduces noise while preserving detection of abnormal latency?

  1. Use a time-of-day baseline for latency Correct answer.
  2. Alert on average latency instead of p99
  3. Raise the threshold to the highest afternoon value
  4. Disable the alert during business hours

Explanation

A time-of-day baseline learns the normal diurnal pattern and alerts when latency deviates from what is expected for that hour. Raising the threshold to the peak or disabling the alert hides real regressions, and average latency masks tail pain. The goal is to detect abnormal behavior relative to normal traffic, not to suppress whole time windows.

Question 50Monitoring, observability, and alerting

An IBM Cloud Monitoring alert fires for a service, and the SRE needs to jump from the alert to the matching IBM Cloud Logs entries for the same request. Which practice makes that correlation possible?

  1. Route all logs to cold archive and query them only after an incident closes
  2. Include a shared request or trace identifier in metrics and logs Correct answer.
  3. Store logs and metrics in separate retention plans with different expiration dates
  4. Create a dashboard for each service and refresh it every minute

Explanation

Correlation requires a common identifier that exists in both the alerting metric context and the log records. If the request or trace ID is captured as a searchable log field and exposed in the metric or alert metadata, the SRE can pivot directly to the relevant log lines. Retention differences, dashboards, and cold archives do not create that link.