Getting Started with OCI practice questions

Worked examples for Getting Started with OCI

1. Question 1

   Which statement about connectivity and latency between availability domains in the same OCI region is correct?

   1. A. Availability domains in a region are not connected to each other, so traffic between them must traverse the public internet

      Assumes ADs are network-isolated from each other. They are isolated in terms of shared physical infrastructure, not disconnected — they are interconnected within the region.

   2. B. Availability domains share a single physical power and cooling plant, which is what keeps latency between them low

      Contradicts AD isolation. Availability domains specifically do not share power or cooling infrastructure; their low latency comes from the region's interconnect, not shared facilities.

   3. C. Traffic between availability domains has the same latency characteristics as traffic between two separate regions

      Equates intra-region and inter-region distance. ADs sit within one geographic area, so inter-AD latency is far lower than latency between distant regions.

   4. D. Availability domains in a region are connected by a low-latency, high-bandwidth network, which makes multi-AD architectures practicalCorrect answer

      Availability domains within a region are interconnected by a high-bandwidth, low-latency network, which is what allows a single application to span ADs for high availability.

   Explanation

   Availability domains within a region are connected to each other by a low-latency, high-bandwidth network, which is precisely what makes it practical to build a fault-tolerant application that spans multiple availability domains. They are not disconnected islands requiring internet transit, and because they sit within one geographic area their mutual latency is much lower than that between separate regions. Their isolation comes from not sharing power, cooling, or internal networking infrastructure — sharing a power plant would defeat the very isolation that makes multi-AD design worthwhile.

2. Question 2

   A platform team must stand up an identical set of networking and compute resources in three OCI regions. Their requirements are: the environment definition lives in a Git repository, every proposed change is reviewed as a plan before it is applied, and Oracle — not an engineer's laptop or a bucket the team has to secure and back up itself — holds the Terraform state for each environment. Which OCI interface best satisfies all of these requirements?

   1. A. Provision each region's resources through the OCI Console, using the create-resource wizards and exporting a summary of the results for the change record.

      Treats the Console — a browser GUI for interactive, one-off administration and exploration — as an infrastructure-as-code tool. It produces no version-controlled definition, no reviewable plan, and no state, so replicating the build across three regions is manual and drift-prone.

   2. B. Write a shell script of OCI CLI commands and run it from Cloud Shell once per region, storing the script in Git.

      Confuses scripting with declarative infrastructure as code. CLI commands are imperative and are stored in Git, but there is no desired-state model, no managed state file, and no plan/apply review step — the team would have to hand-code idempotency and drift detection themselves.

   3. C. Build an application that calls the OCI REST API directly through a language SDK, invoking the create operations for each resource in each region.

      Conflates programmatic access with infrastructure as code. SDK and REST calls are the right tool for embedding OCI operations in an application, but the team would have to implement desired-state reconciliation, plan preview, and state tracking from scratch rather than getting them from a managed Terraform service.

   4. D. Define the environment as a Terraform configuration and deploy it with OCI Resource Manager stacks, running plan and then apply jobs per region.Correct answer

      Resource Manager is OCI's managed Terraform service: the configuration is a versionable Terraform definition, plan jobs show proposed changes before an apply job executes them, and Resource Manager stores and manages the state file for each stack so the team does not have to.

   Explanation

   The requirement set — a declarative definition under source control, a reviewable preview of changes, and Oracle-managed Terraform state — describes managed infrastructure as code, which in OCI is Resource Manager running Terraform stacks with plan and apply jobs. The browser Console is built for interactive administration and produces no reusable definition or state. A CLI script is imperative automation: repeatable to run, but with no desired-state model, no plan step, and no managed state. Direct SDK or REST calls give programmatic control of individual operations but leave reconciliation, previews, and state entirely to the developer. The set of ways to reach OCI — Console, CLI, SDKs, REST API — is described in Oracle's SDKs and CLI documentation, and choosing among them is a matter of matching the interface to the task.

3. Question 3

   A developer is signed in to the OCI Console on a locked-down corporate laptop where they cannot install software. They need to run a few OCI CLI commands against resources in their tenancy. Which statement about OCI Cloud Shell correctly describes how it helps?

   1. A. Cloud Shell is a browser-based terminal accessible from the Console that comes with the OCI CLI preinstalled and preauthenticated as the signed-in userCorrect answer

      Correct: Cloud Shell provides a Linux shell in the browser with the CLI and other tools already installed, and it uses the credentials of the Console user who launched it, so no local install or key setup is needed.

   2. B. Cloud Shell requires the OCI CLI to be installed on the local machine first; it only provides a remote display of that local installation

      The common misconception that Cloud Shell is a front end for a local CLI install. Cloud Shell runs entirely in OCI with its own preinstalled tooling; the whole point is that nothing is installed locally.

   3. C. Cloud Shell is a graphical desktop environment that replaces the Console for creating resources by point-and-click

      Confuses Cloud Shell with the Console. Cloud Shell is a command-line terminal, not a graphical resource-creation interface.

   4. D. Cloud Shell can only run Terraform stacks and cannot execute OCI CLI commands

      Confuses Cloud Shell with Resource Manager. Cloud Shell is a general-purpose shell whose primary preinstalled tool set includes the OCI CLI; running Terraform stacks as managed jobs is Resource Manager's role.

   Explanation

   Cloud Shell is a Linux terminal embedded in the OCI Console: the OCI CLI and other developer tools are already installed in it, and the session inherits the credentials of the signed-in Console user, so a user who cannot install software locally can still run CLI commands immediately. It is not a viewer for a locally installed CLI, since it executes in OCI rather than on the laptop. It is a text terminal rather than a graphical console, and it is a general-purpose shell rather than a Terraform-only environment — managed Terraform execution is what Resource Manager provides.

4. Question 4

   An architect is documenting how OCI's physical and logical isolation boundaries relate to each other. Which TWO statements are accurate?

   1. A. A realm is an isolated collection of regions, and resources and identities are not shared or replicated between realms.Correct answer

      Correct per the documented realm definition: a realm groups regions under one isolation boundary (for example commercial versus government realms), a tenancy exists in exactly one realm, and there is no cross-realm sharing or replication of resources or accounts.

   2. B. Availability domains within the same region are isolated from each other with independent power and cooling, and are unlikely to fail at the same time.Correct answer

      Correct per the documented availability domain definition: availability domains are one or more data centers within a region, isolated from each other and fault tolerant, with their own power, cooling, and internal network, so a failure in one is unlikely to affect another.

   3. C. Every OCI region contains at least three availability domains, which is why three fault domains exist in each region.

      Represents the misconception that all regions are multi-AD and that fault domain count derives from availability domain count. Some regions contain only a single availability domain, and fault domains are a grouping of hardware inside each availability domain, defined per availability domain rather than derived from the region's availability domain count.

   4. D. A fault domain is a logical grouping of hardware that spans the availability domains of a region, so one fault domain covers several data centers.

      Represents the misconception that a fault domain is a region-wide construct. A fault domain exists entirely within a single availability domain; it groups hardware inside that one data-center boundary and never spans availability domains.

   5. E. A tenancy's home region can be changed to any region in any realm on demand, because realms are simply a billing grouping of regions.

      Mischaracterizes a realm as a billing construct. A realm is an isolation boundary containing regions, a tenancy lives in a single realm, and its home region is where identity resources are mastered — it is not a freely reassignable billing attribute spanning realms.

   Explanation

   OCI nests its isolation boundaries as realm → region → availability domain → fault domain, and each level has a distinct, documented meaning. A realm is an isolated collection of regions with no sharing of resources or identities across realms, and a tenancy exists in exactly one realm. Within a region, availability domains are isolated data centers with independent power, cooling, and internal networking, making simultaneous failure unlikely, while fault domains sit strictly inside a single availability domain and group hardware there — they never span availability domains or regions. Claims that every region has at least three availability domains, or that a home region can be moved across realms because realms are a billing grouping, contradict the documented model: some regions are single-availability-domain, and realm membership is an isolation boundary rather than a billing label.

5. Question 5

   Which statement best describes the relationship between the OCI REST API and the other OCI access methods such as the Console, the CLI, and the SDKs?

   1. A. The REST API is the underlying interface to OCI services; the Console, CLI, and SDKs are clients that ultimately issue REST API callsCorrect answer

      Correct: OCI services expose REST APIs, and the Console, CLI, and SDKs are all client layers over those same APIs, which is why they offer broadly equivalent capability.

   2. B. The REST API is a separate, limited interface that exposes only monitoring and reporting operations, while resource creation is available only through the Console

      Misconception that the API is read-only or secondary. The REST API supports the full range of service operations, including creating and deleting resources.

   3. C. The REST API can only be invoked from inside Cloud Shell, because requests must originate within an OCI region

      Confuses where a client runs with what the API accepts. OCI REST endpoints are reachable over the public internet from any properly authenticated client, not just from Cloud Shell.

   4. D. The REST API replaces the SDKs; an SDK is only a documentation package and cannot perform service operations

      Misunderstands what an SDK is. SDKs are functional client libraries that call the REST API on the developer's behalf, handling signing and serialization — they are not mere documentation.

   Explanation

   OCI services are fundamentally exposed through REST APIs, and the Console, CLI, and SDKs are all clients built on top of those APIs — each one ultimately sends signed HTTP requests to the same service endpoints, which is why their capabilities largely overlap. The API is not restricted to monitoring, since it covers create, read, update, and delete operations across services. Nor is it callable only from within OCI: any authenticated client that can sign requests may call it. And SDKs are working client libraries rather than documentation bundles, since their whole purpose is to invoke the API for the developer.

6. Question 6

   A company runs a stateless web tier on several compute instances inside a single availability domain of an OCI region. The architects distribute those instances across multiple fault domains. What failure scenario does this fault domain placement primarily protect the application from?

   1. A. Corruption or accidental deletion of application data stored on the instances

      Conflates infrastructure redundancy with data protection. Fault domains isolate hardware failure domains; they do not create copies of data, so logical corruption or deletion propagates regardless of placement.

   2. B. Loss of the entire availability domain due to a power or cooling outage in that data center

      Misconception that fault domains span availability domains. All fault domains of a deployment live inside one availability domain, so losing the whole AD takes every fault domain in it with it; surviving an AD loss requires deploying to another AD.

   3. C. A region-wide disaster such as a large-scale natural event affecting the geographic area

      Confuses fault-domain-level hardware isolation with disaster recovery. Protection against a region-wide event requires replication or failover to a second region, not additional fault domains in one AD.

   4. D. Failure of, or planned maintenance on, a set of hardware within that one availability domainCorrect answer

      A fault domain is a grouping of hardware and infrastructure inside an availability domain. Distributing instances across fault domains means a hardware failure or infrastructure maintenance event affects only the resources in one fault domain, leaving the rest running.

   Explanation

   A fault domain is a grouping of hardware and infrastructure within a single availability domain, and resources placed in different fault domains do not share a single point of hardware failure or of infrastructure maintenance. Because every fault domain of a deployment sits inside the same availability domain, this placement does nothing for the loss of the entire AD or for a region-wide disaster — those require another availability domain or another region respectively. Nor is a fault domain a data-protection mechanism: it isolates infrastructure failure, not logical corruption or deletion, which needs backups. Source: Oracle Cloud Infrastructure documentation, "Regions and Availability Domains".

7. Question 7

   A new cloud administrator with no scripting experience needs to explore OCI, view existing resources, and create a single test compute instance by following guided steps. Which OCI interface best fits this need?

   1. A. The OCI REST API

      Ignores the audience. Calling the REST API directly requires constructing and signing HTTP requests, which is the least approachable option for a non-scripting user doing a one-off task.

   2. B. An OCI SDK for Python

      Assumes programming is needed for simple exploration. SDKs target developers embedding OCI operations in code; they add a programming prerequisite this user does not have.

   3. C. The OCI ConsoleCorrect answer

      Correct: the Console is the browser-based graphical interface, with guided creation workflows and resource views, making it the natural entry point for interactive, one-off administration.

   4. D. OCI Resource Manager

      Over-applies infrastructure as code. Resource Manager requires authoring Terraform configuration, which is unnecessary overhead for a single exploratory instance.

   Explanation

   The Console is OCI's browser-based graphical interface, offering navigation, resource listings, and guided creation workflows, which makes it the appropriate choice for interactive exploration and one-off administrative tasks by someone who does not script. Calling the REST API directly means hand-building signed HTTP requests, and using an SDK means writing program code, so both impose skills the task does not require. Resource Manager expects Terraform configuration to be authored and managed as a stack, which is valuable for repeatable environments but disproportionate for creating one test instance.

8. Question 8

   A company runs a stateless web tier on compute instances in an OCI region that contains only a single availability domain. The architecture team wants the tier to survive (1) the failure of a single rack or a hardware maintenance event inside that data center, and (2) a prolonged outage that makes the entire region unreachable. Which deployment approach correctly addresses BOTH requirements?

   1. A. Deploy all instances in a single fault domain for lower latency, and take scheduled backups of the boot volumes to satisfy both the hardware-failure and the regional-outage requirement.

      Conflates backups with high availability. A single fault domain leaves every instance exposed to the same rack/maintenance event, and backups stored without a running capacity target elsewhere restore data but do not keep the tier available during either failure.

   2. B. Distribute the instances across multiple fault domains in the availability domain, and rely on the fault domains to provide the cross-region resilience because fault domains are replicated to the region's peer.

      Represents the misconception that a fault domain spans or is mirrored across regions. A fault domain is only a logical grouping of hardware inside one availability domain; it has no existence or replica outside that availability domain, so it cannot address a regional outage.

   3. C. Distribute the instances across multiple fault domains in the availability domain, and replicate the workload into a second region with failover between the regions.Correct answer

      Fault domains group hardware within a single availability domain, so spreading instances across them isolates the tier from a rack-level hardware failure or from maintenance that affects one fault domain at a time; region-level unreachability is outside any single region's blast radius, so surviving it requires a second region. This is the documented pairing of intra-region high availability with cross-region disaster recovery.

   4. D. Request that additional availability domains be added to the region, since spreading instances across availability domains inside one region protects against a full regional outage.

      Claims that a single region's availability domains give regional resilience. Availability domains are isolated data centers within the same region and do provide intra-region isolation, but they share the region's geography; an event that takes the whole region offline affects them all. The number of availability domains in a region is also a property of the region, not something a tenancy chooses.

   Explanation

   OCI's physical hierarchy is region → availability domain → fault domain, and each level bounds a different blast radius. Fault domains group hardware within one availability domain so that a hardware failure or Oracle maintenance action affects only one fault domain at a time, which is the correct control for a rack-level or maintenance event inside a data center. Availability domains are isolated data centers within a region and do not protect against the loss of the entire region, and a fault domain has no cross-region existence, so neither can satisfy the regional-outage requirement — that requires replication and failover to a second region. Scheduled backups preserve data but by themselves do not keep a tier serving traffic through either failure.