Observability, Management and Governance practice questions

Worked examples for Observability, Management and Governance

1. Question 1

   A new tenancy has just been provisioned and an administrator creates several VCNs and compute instances before any observability configuration is done. Regarding the Audit service at that moment, which statement is accurate?

   1. A. Audit records nothing until an administrator enables auditing individually for each service the tenancy uses

      The 'Audit must be manually enabled per service' misconception. Audit is tenancy-wide and always on for supported API calls; per-service opt-in would leave dangerous gaps in the compliance trail exactly when they matter most.

   2. B. Audit logging is automatically enabled for the tenancy, so those API calls are already being recorded without any setupCorrect answer

      Correct. The Audit service records calls to OCI public API endpoints for the tenancy automatically; there is no enablement step, which is what makes it a dependable compliance baseline from the moment a tenancy exists.

   3. C. Audit records nothing until an Events rule is created to forward resource-state changes into the audit trail

      Inverts the relationship between the two services. Events does not populate Audit; the two are independent, with Audit recording API calls automatically and Events emitting on resource-state changes to trigger actions.

   4. D. Audit records nothing until a Service Connector Hub connector is created with the audit logs as its source

      Confuses reading with recording. A connector can read audit data and move it elsewhere, but the audit records must already exist for a connector to consume them; the connector is not what causes them to be captured.

   Explanation

   The Audit service automatically records REST API calls made against tenancy resources with no configuration step, which is why it can serve as an always-available compliance and forensic baseline. Per-service enablement is not required, and no Events rule feeds the trail — Events is the separate, active mechanism that reacts to resource-state changes by triggering actions. Service Connector Hub can consume audit data as a connector source, but it only moves records that the Audit service has already captured.

2. Question 2

   An architect wants every newly launched compute instance in a compartment to page the on-call team by email and SMS, and to also post to an internal HTTPS endpoint. What is the standard OCI design for this event-driven flow?

   1. A. Create a Service Connector Hub connector with Events as the source and each recipient's email address as a target.

      Misconception that Service Connector Hub is the delivery mechanism for human alerts. Service Connector Hub routes telemetry data between OCI services; individual email and SMS recipients are subscriptions on a Notifications topic.

   2. B. Create an Events rule matching the instance launch event whose action publishes to a Notifications topic, then add email, SMS, and HTTPS subscriptions to that topic.Correct answer

      Correct. An Events rule matches the resource-state change and delivers to an action target; the Notifications topic provides the publish/subscribe fan-out so one event reaches many subscription protocols.

   3. C. Create an Events rule that lists the recipients' email addresses and the HTTPS endpoint directly in the rule's action, with no topic involved.

      Misconception that Events can email a user directly. An Events rule's action targets a service — Notifications, Functions, or Streaming — and the subscriber list lives on the Notifications topic, not in the rule.

   4. D. Create an Events rule whose action invokes a Function that opens SMTP and HTTPS connections to each recipient itself.

      Uses a Function where a simple notification suffices. Custom code is warranted for logic the platform does not provide; multi-protocol fan-out to subscribers is exactly what a Notifications topic already does, so this adds code to maintain for no capability gain.

   Explanation

   The canonical event-driven flow is rule → action target: an Events rule matches a resource-state change and delivers it to Notifications, Functions, or Streaming. Notifications supplies the publish/subscribe fan-out, so one published message reaches every subscription — email, SMS, HTTPS, and others — without the rule knowing the recipients. Listing recipients inside the rule assumes Events can address individuals directly, writing a Function to do the delivery duplicates functionality the platform already provides, and Service Connector Hub is a telemetry-routing service rather than an alert-delivery mechanism for people.

3. Question 3

   During an incident review, an architect must decide which OCI service is responsible for each of two distinct needs: (1) reliably re-creating the failed environment's infrastructure exactly as defined, and (2) being notified when CPU utilization on the replacement instances crosses a threshold. How should these responsibilities be assigned?

   1. A. Monitoring re-creates the infrastructure from its collected metric history, and Resource Manager raises the CPU threshold notification through stack jobs.

      Inverts both roles. Metric history is time-series telemetry and carries no capability to provision resources, and stack jobs are Terraform operations, not alarm evaluations.

   2. B. Resource Manager handles both, because a stack's Terraform state doubles as the metric store used to evaluate threshold conditions.

      Misunderstands Terraform state. State records the resources a stack manages and their attributes — it is not a time-series metric store and nothing evaluates alarm conditions against it.

   3. C. Monitoring handles both, since configuring an alarm on an instance metric also registers the instance's definition for automatic rebuild if it fails.

      Assumes observability implies provisioning. Creating an alarm on a metric has no effect on resource lifecycle; nothing about an alarm definition stores or rebuilds infrastructure.

   4. D. Resource Manager re-creates the infrastructure by applying the stack's Terraform configuration, and Monitoring evaluates an alarm on the CPU metric emitted by the instances to trigger the notification.Correct answer

      Correct. Resource Manager provisions declaratively by applying a stack's Terraform configuration, while Monitoring ingests metrics emitted by resources and evaluates alarms against them to notify when a condition is met — the standard division of provisioning versus observability.

   Explanation

   These are two different services with two different jobs. Resource Manager provisions infrastructure by running Terraform against a stack's configuration, which is what makes re-creating a defined environment repeatable. Monitoring queries the metrics that OCI resources emit and evaluates alarms against them, which is what produces a notification when CPU utilization crosses a threshold. Terraform state describes managed resources, not time series, and an alarm definition confers no ability to rebuild infrastructure.

4. Question 4

   In OCI Logging, which THREE categories of logs can be collected and stored? (Choose three.)

   1. A. Audit logs, which record API activity against resources in the tenancyCorrect answer

      Correct. Audit logs capture the record of API calls made against tenancy resources and are one of the log categories surfaced through Logging.

   2. B. Service logs, emitted by supported OCI services such as load balancers and object storage bucketsCorrect answer

      Correct. Service logs are emitted by supported OCI services once enabled on the resource, and are stored in a log within a log group.

   3. C. Custom logs, containing application or infrastructure diagnostic events published by the customerCorrect answer

      Correct. Custom logs carry customer-authored diagnostic events, typically shipped from compute instances by an agent or published directly.

   4. D. Metric logs, which store the numeric time-series values that Alarms evaluate

      Invented category conflating Monitoring with Logging. Numeric time series live in Monitoring as metrics; there is no 'metric log' category in Logging.

   Explanation

   OCI Logging organizes log data into three categories — audit logs for tenancy API activity, service logs emitted by supported OCI services, and custom logs published by the customer's own applications or agents — all stored in logs that belong to log groups. Numeric telemetry is a separate concern owned by Monitoring, which stores metrics rather than log records, so a category that describes time-series values does not belong in Logging.

5. Question 5

   A governance policy requires that any newly launched compute instance missing a mandatory cost-center tag be automatically stopped and its owner informed. Which architecture best satisfies this requirement?

   1. A. Create an Events rule for the instance-launch event whose action invokes a function that checks the tags, stops non-compliant instances, and publishes to a Notifications topicCorrect answer

      Correct. This uses each service in its documented role: Events detects the resource-state change and delivers the event payload, Functions runs the custom conditional logic and remediation the payload cannot express on its own, and Notifications fans the outcome out to subscribers.

   2. B. Configure the Audit service to inspect each recorded LaunchInstance call and stop instances whose tags fail validation

      The 'Audit can trigger a response' misconception. Audit is a passive recording service: it captures API calls for later query and compliance review but has no rule engine, no evaluation logic, and no ability to act on what it records.

   3. C. Create an Events rule for the instance-launch event whose only action is a Notifications topic with an email subscription describing the policy

      Under-designs the flow. A Notifications topic can inform people but cannot evaluate tag conditions or stop an instance; the requirement includes automated remediation, which needs executable code.

   4. D. Create a Monitoring alarm on an instance-count metric whose action stops instances when untagged instances appear

      Confuses metric-threshold alarming with event-driven remediation. Alarms evaluate numeric time series against a threshold and publish to a topic; they cannot inspect resource metadata such as tags nor perform lifecycle operations.

   Explanation

   Event-driven governance composes three roles: Events matches the resource-state change and delivers the event payload, Functions supplies the custom conditional logic and any remediation API calls, and Notifications fans the outcome out to human subscribers. A notification-only rule cannot evaluate tags or stop a resource, so it fails the automated-remediation half of the requirement. The Audit service records API activity but cannot act on it, and a Monitoring alarm evaluates numeric metric thresholds rather than inspecting resource metadata or invoking lifecycle operations.

6. Question 6

   Which TWO statements accurately describe the OCI Audit service as a governance control? (Choose two.)

   1. A. Audit automatically records REST API calls made against OCI resources in a tenancy, without per-service enablement by an administrator.Correct answer

      Correct. Audit is on by default across the tenancy and captures API activity as it happens, which is what makes it usable as a compliance trail.

   2. B. An audit log entry identifies the principal that made the request along with timing and request detail, supporting after-the-fact attribution.Correct answer

      Correct. Capturing who called, when, and with what request/response detail is precisely the forensic value of an API-activity trail.

   3. C. Audit evaluates configured thresholds on captured API activity and fires an alarm when a threshold is breached.

      Confuses Audit with Monitoring. Threshold evaluation and alarm firing belong to the Monitoring service, which works on metrics; Audit performs no evaluation.

   4. D. Audit rules can be configured with an action target so that a matching API call directly invokes a Function.

      Misconception that Audit is a trigger mechanism. Audit has no rules or action targets; automated response to activity is designed with the Events service.

   5. E. Audit must be explicitly enabled for each service in a compartment before that service's API calls are recorded.

      Misconception that Audit is opt-in per service. It records API activity across the tenancy without per-service enablement, which is why it can be relied on for compliance.

   Explanation

   The Audit service is a passive, always-on record of API activity across the tenancy: it captures calls as they are made and records the calling principal together with timing and request detail, which is what supports after-the-fact attribution during a compliance investigation. It does not evaluate anything and has no action targets — threshold evaluation and alarm firing belong to the Monitoring service, which operates on metrics, and automated response to a change is designed with an Events rule. The claim that Audit is opt-in per service also misreads it: its value as a compliance control depends on it not requiring an administrator to turn it on.

7. Question 7

   What is the primary purpose of a log group in OCI Logging?

   1. A. It converts log records into numeric metrics so that Alarms can evaluate them.

      Confuses a log group with metric extraction. A log group is an organizational and access-control container; turning log data into a metric is a separate capability, not what a log group does.

   2. B. It is the subscription endpoint that receives alarm messages when a threshold is breached.

      Confuses a log group with a Notifications topic. Alarm messages are published to a Notifications topic with subscriptions; a log group has no role in alarm delivery.

   3. C. It defines the retention period for metric data points stored by the Monitoring service.

      Confuses Logging containers with Monitoring retention. Metric retention is a property of the Monitoring service and is not configured through a log group.

   4. D. It is a logical container for logs within a compartment, used to organize logs and apply IAM policy to them as a unit.Correct answer

      Correct. A log group is a logical container for one or more logs inside a compartment; it is the unit that organizes logs and to which access policies are applied.

   Explanation

   In OCI Logging, a log group is a logical container that holds logs within a compartment, giving you a single object on which to organize related logs and attach IAM policy. It is purely an organizational and authorization boundary for log data. Alarm delivery is handled by Notifications topics, and metric storage and retention belong to Monitoring — neither is governed by a log group.

8. Question 8

   A compliance team must answer the question "which user deleted this block volume last Tuesday, and from what IP address?" long after the fact. Separately, the platform team wants a Function to run automatically the moment any future block volume is deleted. Which OCI service fills each need?

   1. A. The Audit service provides the retrospective record of the API call and its principal; the Events service triggers the Function on future delete state changes.Correct answer

      Correct. Audit automatically records REST API calls (principal, source IP, timestamp, request/response) as a passive, queryable trail for compliance and forensics, while Events emits an event on a resource-state change and routes it to an action such as a Function.

   2. B. The Audit service satisfies both needs: audit log entries can be configured to invoke a Function when a matching API call is recorded.

      Misconception that Audit can trigger an automated response. Audit only records API activity; it has no rule engine and no action targets. Automation on resource-state change is the Events service's job.

   3. C. The Events service satisfies both needs: an Events rule stores a searchable history of every API call and can also invoke a Function.

      Misconception that Events is a historical activity log. Events fire forward in time on resource-state changes and are not retained as a queryable record of past API calls; retrospective attribution comes from Audit.

   4. D. Service Connector Hub provides the retrospective record of the API call, and the Notifications service triggers the Function on delete state changes.

      Confuses roles: Service Connector Hub moves telemetry between services rather than being the system of record for API activity, and Notifications fans out messages to subscribers — it is an Events action target, not the rule engine that detects the state change.

   Explanation

   The Audit service is the API-activity trail: it automatically records REST API calls against OCI resources, including the calling principal, source IP, and timestamp, so it answers retrospective "who did what" compliance questions. The Events service is the active automation layer: a rule matches a resource-state change such as a volume delete and routes it to an action target like Functions, Notifications, or Streaming. Treating Audit as a trigger, or Events as a historical log, inverts their roles, and Service Connector Hub and Notifications are routing and fan-out layers rather than the record-of-truth or the rule engine.