Observability practice questions

OCI Data Flow

Why it fails: Incorrect. Data Flow is a fully managed Apache Spark service for big data processing, not a log routing tool.

OCI GoldenGate

Why it fails: Incorrect. GoldenGate is designed for real-time database replication and data integration.

OCI Archive Storage lifecycle rules

Why it fails: Incorrect. Lifecycle rules manage bucket-tier transitions, not ingestion routing from OCI Logging.

OCI Logging Analytics

Why it fails: Incorrect. Logging Analytics analyzes log data.

OCI Network Firewall

Why it fails: Incorrect. Network Firewall inspects traffic flows, not global endpoint uptime.

OCI APM Synthetic Monitoring

Why it fails: While APM synthetic monitoring tests web applications, OCI Health Checks is the foundational, lightweight service specifically designed for basic public endpoint availability monitoring.

Configure a Service Connector Hub rule to push agent binaries to new instances upon creation.

Why it fails: Incorrect. Service Connector Hub moves data between services, it does not push software binaries to VMs.

Rely on default OCI Monitoring service metric collection, which automatically collects guest OS log files without agents.

Why it fails: Incorrect. Guest OS log files require an agent (like the Logging Agent) to be collected; Monitoring service only collects hypervisor and platform metrics by default.

Create an OCI Events rule for instance creation that triggers a Resource Manager stack to install the agent via SSH.

Why it fails: Incorrect. Using Resource Manager and SSH for post-provisioning installation is brittle compared to native Cloud Agent plugin configurations.

OCI Service Connector Hub pattern matching

Why it fails: Incorrect. Service Connector Hub routes data; it does not perform ML log clustering.

OCI Cloud Guard Threat Detector rules

Why it fails: Incorrect. Cloud Guard detects security misconfigurations and posture risks, but Logging Analytics provides the ML log clustering engine.

OCI APM Anomaly Detection agent

Why it fails: Incorrect. APM is for application tracing, not log message pattern clustering.

Attach IAM permission tags to shared resources to automatically split charges at the bank level.

Why it fails: Incorrect. IAM permissions do not affect financial billing logic.

Write custom OCI Monitoring metric alarms that automatically credit compartments when shared resources are used.

Why it fails: Incorrect. Monitoring alarms do not alter billing ledger calculations.

Manually split CSV invoice files in Excel after downloading monthly Cost Reports.

Why it fails: Incorrect. Manual spreadsheet manipulation is not an automated or scalable architectural solution.

OCI Service Connector Hub

Why it fails: Incorrect. Service Connector Hub moves data between services like Logging and Storage, not Monitoring alarms to Functions.

OCI API Gateway

Why it fails: Incorrect. API Gateway publishes REST APIs, it does not receive internal monitoring alarms.

OCI Events Service

Why it fails: Incorrect. While Events can trigger functions, metric alarms route through the Notifications service.

SQL*Net protocol

Why it fails: Incorrect. SQL*Net is for database connectivity, not metric ingestion.

Syslog RFC 5424

Why it fails: Incorrect. Syslog is for log forwarding, not time-series metric publishing.

IMAP email protocol

Why it fails: Incorrect. IMAP is for retrieving emails.

Rely exclusively on manual polling of the OCI Metrics Explorer console by the on-call engineer.

Why it fails: Incorrect. Manual polling is reactive and violates automated enterprise observability best practices.

Disable all IAM security policies during alarm firing to allow unrestricted troubleshooting access.

Why it fails: Incorrect. Disabling security policies violates enterprise security posture and compliance mandates.

Configure OCI Logging to stream logs to an OCI Streaming topic, which then writes to a Block Volume with hardware-enforced encryption.

Why it fails: Block Volumes do not support WORM compliance locking natively in the same way Object Storage retention rules do, and Streaming is not an archival store.

Route all logs through an OCI API Gateway, enforce a WORM storage policy via IAM JSON syntax, and query via Logging Analytics.

Why it fails: API Gateway does not store logs or provide WORM capabilities.

Use Oracle Database Vault to ingest log data into autonomous JSON databases configured with immutable tables.

Why it fails: While autonomous JSON tables support immutability, this is an over-engineered pattern when OCI Logging native Object Storage export with Compliance mode is available.

Modify the OCI Events service emission frequency to throttle metric collection to once every 15 minutes.

Why it fails: Throttling metric collection affects data fidelity and is not the correct mechanism for alarm evaluation control.

Apply a smoothing function like 'Moving Average' directly within the OCI Notifications topic subscription settings.

Why it fails: Smoothing functions are applied in the Alarm query expression (e.g., using MQL functions like 'mean()'), and Notification subscriptions do not process metric smoothing.

Set the Repetition Interval to 15 minutes.

Why it fails: Repetition Interval controls how often notifications are re-sent for an already firing alarm, not the condition to trigger.

An alarm in OCI Monitoring can only be in one of two states: Active or Inactive.

Why it fails: Incorrect. OCI alarms have states including OK, FIRING, and SUSPENDED.

MQL does not support mathematical functions or aggregations; all calculations must be performed prior to ingestion.

Why it fails: Incorrect. MQL supports numerous functions like .mean(), .rate(), .sum(), and percentiles.

OCI Streaming Service Cost Estimator

Why it fails: The OCI Pricing Calculator is used for estimations, but the Streaming Service does not feature a dedicated cost estimator tool.

OCI Logging Analytics Cost Module

Why it fails: There is no dedicated 'Logging Analytics Cost Module'; cost features are handled by Cost Analysis and Usage Reports.

The CpuUtilization metric in the oci_computeagent namespace for each backend instance

Why it fails: CpuUtilization is emitted by the Compute Instance Monitoring plugin and describes host CPU consumption. High CPU may correlate with errors, but it does not measure HTTP response codes and cannot distinguish a 5xx from normal traffic. Alarming on it would produce false positives and miss error spikes caused by non-CPU issues such as database timeouts.

The LoadBalancerBackendSetHealth metric emitted by the oci_lbaas namespace

Why it fails: This metric reports the health-check status of backend servers (such as OK, WARNING, or CRITICAL) as determined by the load balancer's configured health-check policy. It reflects whether backends pass health probes, not the count or rate of HTTP 5xx responses returned to clients. It would not capture elevated 5xx error rates when backends still pass health checks.

The UnhealthyBackendCount metric in the oci_healthchecks namespace

Why it fails: The oci_healthchecks namespace pertains to OCI Health Checks, a separate DNS-based traffic management service that probes endpoints from global vantage points. It is not tied to the Flexible Load Balancer's backend set and does not count HTTP 5xx responses. Using it here monitors the wrong service and will not capture load balancer-observed errors.

Increase the alarm severity from WARNING to CRITICAL for every alarm so notifications are prioritized

Why it fails: Severity controls how notifications are labeled and routed, not whether an alarm fires or resolves. Raising severity does not stop a metric that oscillates around a threshold from repeatedly entering the firing state. It may even amplify noise by escalating every flap to a critical page, worsening the original complaint rather than resolving it.

Remove the metric's dimensions from the alarm query so all resources are evaluated as one aggregate

Why it fails: Dropping dimensions aggregates many resources into a single time series, which can mask a problem on one host and delay detection. It does not address flapping or non-resolving alarms, and it destroys per-resource visibility that teams rely on for triage. This is a query-shaping decision, not a mechanism for controlling alarm state transitions.

Enable the alarm's repeat notification interval so reminders are sent at fixed intervals while the alarm remains firing

Why it fails: Repeat notification controls how often reminders are sent while an alarm stays in the firing state. It does not reduce the number of distinct firing transitions caused by oscillation and does nothing to help alarms that fail to resolve. In fact, a short repeat interval increases notification volume, which is the opposite of what the teams requested.

Create one alarm per compartment but reuse the same topic, because alarms cannot query metrics outside their own compartment

Why it fails: The premise is false: a Monitoring alarm's metric query is not restricted to the compartment where the alarm is created. Alarms can query metrics across compartments in the tenancy. Building multiple alarms around this misconception adds redundant resources and defeats the goal of a single simple configuration for all three databases.

Create one alarm per database in each compartment and subscribe the on-call group to three separate topics

Why it fails: Creating three alarms and three topics multiplies configuration and maintenance, and it is unnecessary because alarms are tenancy-scoped resources that can query metrics across compartments. This approach also risks inconsistent thresholds and subscriptions drifting over time. It works technically but is not the simplest correct design for a single notification path.

Create an alarm in each compartment and use a Service Connector Hub connector to merge their outputs into one topic

Why it fails: Service Connector Hub moves data between services such as Logging and Object Storage; it does not merge alarm notifications into a topic. Alarms already publish to Notifications topics directly. Adding a connector introduces an unnecessary component and would not consolidate the three alarms into the single notification path the team wants.

Use Logging Analytics custom parsers on generated invoice PDFs stored in Object Storage.

Why it fails: Parsing invoice PDFs yields retrospective, aggregated figures without resource-level tag attribution or real-time anomaly detection. It is tempting because invoices are the authoritative billing record, and Logging Analytics parsing would suit auditing discrepancies between invoiced amounts and expected charges.

Use native OCI Tag Defaults and OCI Monitoring alarms on the 'Billing' metric namespace.

Why it fails: Tag Defaults only apply tags at resource creation and Monitoring alarms on the Billing namespace lack the historical trend and anomaly detection required. It is tempting because both are native OCI cost tools, and Tag Defaults would suit enforcing consistent tagging across newly provisioned resources.

Deploy OCI APM Java agents to every compute node and query the JVM memory usage to estimate spend.

Why it fails: APM Java agents capture application performance telemetry such as JVM memory, not resource metadata tags or billing data, so no cost attribution is possible. It is tempting because APM provides deep observability, and it would be the correct choice for diagnosing Java application latency or memory leaks.

Events Service

Why it fails: Events Service publishes and routes state-change notifications from OCI resources; it has no metric ingestion or query API. It tempts when monitoring is confused with event-driven automation, but it would be correct for reacting to resource lifecycle changes, not for storing custom application metrics.

OCI Logging Analytics

Why it fails: Logging Analytics ingests and queries log data, not numeric custom metrics. It tempts because it handles large volumes of operational telemetry and supports querying, but it would be correct for log correlation and analysis; metric ingestion and querying require the Monitoring API.

Application Performance Monitoring (APM)

Why it fails: APM traces application performance and synthesises metrics from instrumented applications, but the OCI Monitoring API is what ingests and queries custom metrics. It tempts because APM surfaces application telemetry, yet it would be correct for distributed tracing and transaction diagnostics rather than metric ingestion.

OCI Audit Service

Why it fails: OCI Audit Service records API activity for compliance and security auditing; it does not aggregate arbitrary resource logs or provide SQL-like query and dashboard capabilities. It is tempting because it is a logging service, and would be correct for investigating who performed which API call within a tenancy.

OCI Health Checks

Why it fails: OCI Health Checks monitors endpoint availability and latency from vantage points; it neither ingests log data nor supports SQL-like querying or dashboards. It is tempting because it produces monitoring metrics, and would be correct for detecting reachability failures of public endpoints rather than analysing collected logs.

OCI Object Storage

Why it fails: OCI Object Storage stores and retrieves unstructured objects; it offers no query engine or visualisation layer over log data. It is tempting because logs can be archived there cheaply, and would be correct as a durable destination for exported logs rather than the analysis platform itself.

OCI Network Visualizer

Why it fails: Network Visualizer maps VCN topology, security rules and reachability; it shows no per-request path across microservices. It tempts because it visualises connectivity, and it is correct when diagnosing network-level reachability or misconfigured security lists between subnets.

OCI Logging Analytics with out-of-the-box system parsers

Why it fails: Logging Analytics parses and indexes log records; it cannot stitch a request's spans across service boundaries into one trace. It tempts because it aggregates telemetry centrally, and it is correct when correlating log events for root-cause analysis rather than distributed tracing.

OCI Monitoring service anomaly detection

Why it fails: Monitoring anomaly detection flags deviations in aggregated metrics such as latency, but it cannot follow an individual request across service boundaries. It tempts because it surfaces latency spikes, and it is correct when alerting on abnormal resource or service metrics rather than tracing.

Set the alarm evaluation window to 30 minutes and enable metric smoothing.

Why it fails: Evaluation windows and metric smoothing change how the threshold is computed, not how often notifications repeat; the alarm still fires on each breach. It tempts because smoothing reduces noise, but the repeat interval is controlled by the alarm's notification frequency setting.

Create an OCI Events rule with a batch window of 30 minutes.

Why it fails: Events rules react to state changes in resources, not to metric threshold breaches, so they cannot throttle repeated alarm notifications. It tempts because batching reduces volume, but OCI Monitoring alarms handle metric thresholds, and the repeat interval belongs in the alarm configuration.

Configure a notification suppression window in the Notifications service topic settings.

Why it fails: Notification topics have no suppression window setting; suppression is configured on the alarm itself. It tempts because the Notifications service does deliver alarm messages, but the repeat interval controlling how often a firing alarm re-notifies is an alarm-level parameter.