Compute practice questions

Worked examples for Compute

1. Question 1

   A team has built a hardened, fully patched custom image in their primary OCI region and now needs to launch instances from that exact image in a second region to stand up a disaster-recovery environment. What must they do to make the image usable in the second region?

   1. A. Nothing — custom images are tenancy-wide global resources, so the image is already selectable when launching an instance in any subscribed region.

      Treats a custom image like a global resource (such as a compartment or IAM policy). Custom images are scoped to the region in which they were created and are not automatically present in other regions.

   2. B. Copy the custom image to the destination region (or export it to Object Storage and import it there), then launch instances from the copy in that region.Correct answer

      Correct. Because a custom image is a regional resource, making it available elsewhere requires an explicit copy to the target region, or an export-to-Object-Storage and import cycle, which produces a separate image resource in the destination region.

   3. C. Detach the source instance's boot volume and attach it to a new instance in the second region, then capture the image there.

      Ignores the scope of storage resources. Boot and block volumes live in a specific availability domain and cannot be attached to an instance in another availability domain, let alone another region.

   4. D. Move the image into a compartment that the disaster-recovery region uses, since compartment membership determines which region a resource is served from.

      Confuses compartments with regions. Compartments are global logical containers for access control and organization; moving a resource between them changes governance, not the region the resource physically resides in.

   Explanation

   A custom image is a region-scoped resource: it captures the boot volume contents of an instance — operating system, installed software, and configuration — within the region where it was created. Getting that same golden image into another region therefore requires an explicit region copy, or an export to Object Storage followed by an import that creates a new image resource in the destination. Assuming automatic global availability, trying to move the underlying boot volume (which is bound to a single availability domain), or reassigning the image to a different compartment all misread how image and storage scoping works.

2. Question 2

   A regulated line-of-business application is being migrated to OCI. Compliance requires that the physical servers running the application never host workloads belonging to any other tenant. The team still wants to run several small, independently sized instances that can be created, stopped, and deleted as demand changes, rather than one large server per component. Which compute option best satisfies both requirements?

   1. A. Launch each component as a standard virtual machine instance on OCI's shared compute infrastructure.

      Treats hypervisor-level isolation as equivalent to physical single tenancy. Standard VM instances run on hosts that may also run other tenants' VMs, so the requirement that no other tenant share the physical server is not met.

   2. B. Provision a dedicated virtual machine host and launch the application's VM instances onto that host.Correct answer

      A dedicated VM host is a physical server dedicated to a single customer's VM instances, so the hardware is single-tenant while the workload still runs as flexible, individually managed VMs — exactly the isolation-plus-agility combination described (OCI Compute overview, dedicated virtual machine hosts).

   3. C. Launch one bare metal instance for each application component.

      Bare metal does give single-tenant physical hardware, but it dedicates an entire physical server per component, forfeiting the ability to run several small, independently sized VMs and over-provisioning every component.

   4. D. Create a capacity reservation for the required shapes and launch standard VM instances into it.

      Confuses a capacity guarantee with tenancy isolation. A capacity reservation ensures capacity is available when you launch, but reserved instances still run on shared, multi-tenant hardware.

   Explanation

   A dedicated virtual machine host is a physical server reserved for one customer's VM instances, which delivers single-tenant hardware without giving up the flexibility of running many small, separately managed VMs. Standard VM instances run on shared hosts and therefore cannot satisfy a no-shared-hardware compliance rule. Bare metal does isolate the hardware, but a whole physical server per component is gross over-provisioning and loses VM lifecycle agility. A capacity reservation addresses whether capacity will be available at launch time, not who else runs on the underlying hardware.

3. Question 3

   A retail company runs a stateless web front end that scales out sharply during promotions and scales back in afterwards. Each node needs only a modest amount of CPU and memory, there is no requirement that nodes avoid sharing physical hardware with other tenants, and the team wants to avoid paying for resources that sit idle. Which compute option best fits this front-end tier?

   1. A. Launch virtual machine instances that use a flexible shape, sizing OCPUs and memory to each node's actual requirementCorrect answer

      Correct. VMs are the standard choice for elastic, shared-tenancy workloads, and a flexible shape lets you choose OCPU count and memory independently so the node matches the workload instead of a preset bundle — the right-sizing lever for avoiding idle capacity.

   2. B. Launch one bare metal instance per front-end node so each node has an entire physical server to itself

      Reflects the misconception that bare metal is the default choice for performance-sensitive tiers. A bare metal instance is an entire physical server sized far beyond a modest web node, so it over-provisions every node and is slow and costly to add and remove during scaling events.

   3. C. Provision a dedicated virtual machine host and run all front-end nodes on it so they never share hardware with other tenants

      Confuses single-tenant isolation with cost efficiency. A dedicated VM host is the answer to a licensing or compliance requirement for non-shared hardware; the stem states no such requirement exists, and you pay for the whole host whether or not the VMs on it are busy.

   4. D. Create a capacity reservation for the front-end shape and rely on it to serve traffic between promotions

      Treats a capacity reservation as a substitute for running instances. A reservation only holds capacity so instances can be launched later; it runs no workload, and unused reserved capacity is still billed, which is the opposite of avoiding idle spend.

   Explanation

   Virtual machines are the general-purpose compute form in OCI for workloads that scale elastically and do not require dedicated physical hardware, and flexible shapes let OCPU and memory be selected independently so an instance is sized to the workload rather than to a preset bundle. Bare metal dedicates a whole physical server to one instance and grossly over-provisions a small web node; a dedicated VM host answers an isolation requirement that this workload does not have and bills for the entire host; a capacity reservation guarantees future launch capacity but runs nothing and bills unused capacity.

4. Question 4

   A web tier runs behind a load balancer on an autoscaled instance pool. The architect wants new instances created by scale-out events to start serving traffic without any manual step. What is the correct design?

   1. A. Write automation that watches for new instances and calls the Load Balancing API to add each one to the backend set.

      Rebuilds a capability the platform already provides. Custom registration automation is unnecessary once the pool itself is attached to the backend set, and it adds a failure point.

   2. B. Enable autoscaling, which provisions and manages its own dedicated load balancer for the pool.

      Assumes autoscaling creates networking resources. Autoscaling only changes the pool's instance count; the load balancer is a separate resource the architect creates and attaches.

   3. C. Reference the load balancer's backend set in the instance configuration so every launched instance registers itself.

      Puts a fleet-level relationship in the per-instance template. The load balancer is attached to the instance pool, not declared inside the instance configuration.

   4. D. Attach the instance pool to the load balancer's backend set, so instances the pool launches are added automatically and removed when the pool scales in.Correct answer

      Correct. A load balancer attachment on the instance pool keeps backend set membership in sync with pool membership as autoscaling adds and removes instances.

   Explanation

   An instance pool can be attached to a load balancer backend set, and that attachment makes backend membership follow pool membership: instances the pool launches — including those added by an autoscaling scale-out — are registered automatically, and instances removed by scale-in are taken out. Hand-rolled registration automation is redundant, autoscaling never creates a load balancer of its own, and the attachment lives on the pool rather than in the instance configuration template.

5. Question 5

   A public-facing storefront runs on an instance pool. Traffic is bursty and unpredictable — a social media mention can triple load within minutes, at any hour of any day. Which elasticity design best fits this workload?

   1. A. Schedule-based autoscaling with a cron schedule that raises and lowers the pool size every hour around the clock.

      Applies schedule-based scaling to unpredictable demand. Schedules fire at fixed clock times and are blind to actual load, so an unforeseen burst between schedule points gets no extra capacity.

   2. B. Keep the pool at a fixed size and have on-call staff update the pool size manually when they are paged.

      Treats manual intervention as elasticity. Human response time is far slower than a minutes-long burst, and the design provides no automatic scale-in afterwards.

   3. C. Metric-based autoscaling on the pool's average CPU utilization, with a minimum and maximum instance count.Correct answer

      Correct. Metric-based autoscaling adds instances when the pool's performance metric crosses a threshold and removes them when load falls, which is exactly the reactive behavior unpredictable demand requires.

   4. D. Replace the pool members with a much larger shape so a single instance can absorb any burst.

      Confuses over-provisioning (vertical sizing) with elasticity. Capacity is paid for continuously, is capped by the largest shape, and still does not adjust to demand.

   Explanation

   Metric-based autoscaling is the mechanism for load-driven, unpredictable demand: it watches a performance metric such as CPU utilization across the pool and adds or removes instances when thresholds are crossed, bounded by a configured minimum and maximum. Schedule-based scaling fires only at known clock times and cannot see an unforeseen burst; manual resizing is far too slow for a minutes-long spike; and moving to a larger shape is static over-provisioning rather than elasticity.

6. Question 6

   An architect is preparing a fleet so that metric-based autoscaling on CPU utilization will work. Which TWO conditions must be satisfied?

   1. A. The instances must be created and managed by an instance pool that is based on an instance configuration.Correct answer

      Correct. Autoscaling operates on an instance pool, and the pool launches its members from an instance configuration template, so both must exist before a scaling policy can be attached.

   2. B. A load balancer must be attached to the instance pool before autoscaling can be enabled.

      Confuses a common companion design with a prerequisite. Attaching a load balancer is optional and useful for distributing traffic; autoscaling does not depend on it.

   3. C. Compute instance monitoring must be enabled on the pool's instances so that CPU and memory metrics are emitted to the Monitoring service.Correct answer

      Correct. Metric-based autoscaling evaluates metrics collected from the instances, so the monitoring capability must be enabled or no metric data exists for the policy to act on.

   4. D. A Monitoring alarm must be created for the CPU metric and linked to the autoscaling configuration.

      Confuses alarms with autoscaling policies. The autoscaling configuration defines its own metric and thresholds; no separate alarm resource is wired into it.

   5. E. Every instance in the pool must use a bare metal shape.

      Invents a shape restriction. Instance pools and autoscaling are not limited to bare metal; VM shapes are the common case for elastic fleets.

   Explanation

   Metric-based autoscaling needs two things in place: a scaling target and metric data. The target is an instance pool built from an instance configuration, since autoscaling adjusts pool membership rather than individual instances. The data comes from compute instance monitoring, which must be enabled so utilization metrics reach the Monitoring service. A load balancer attachment is an optional traffic-distribution choice, a separate alarm resource is not part of the autoscaling wiring, and no particular shape family is required.

7. Question 7

   A compliance policy requires that a stateless compute tier receive OS security patches every month, that any bad patch be reversible within minutes, and that no change touch instances in more than one fault domain at a time. The tier currently runs instances spread across the fault domains of one availability domain. Which OS-update strategy best satisfies all three requirements?

   1. A. Run in-place package updates on every instance simultaneously during a maintenance window so all instances stay identical.

      Violates the blast-radius rule by changing every fault domain at once, and in-place package updates are slow and unreliable to unwind, so a bad patch cannot be reversed in minutes.

   2. B. Apply the patches to the existing custom image in place so that instances already launched from it pick up the changes on their next reboot.

      Assumes images are mutable and propagate backwards to running instances. An image is an immutable point-in-time template; editing it is not possible, and instances never re-read their source image after launch.

   3. C. Build a new custom image containing the month's patches, then roll it out one fault domain at a time by replacing instances with ones launched from the new image, retaining the previous image for rollback.Correct answer

      Correct. A golden-image rolling replacement patches by launching from a new immutable image, confines each wave to one fault domain so the other fault domains keep serving, and makes rollback a matter of relaunching from the retained prior image.

   4. D. Take boot volume backups each month and restore them onto the instances, since restoring a managed backup brings the OS to the current patch level.

      Mistakes backup and restore for a patching mechanism. A backup captures whatever state existed at capture time, so restoring one reproduces the old patch level rather than advancing it.

   Explanation

   For a stateless tier, the immutable golden-image approach — bake the patched custom image, then replace instances from it — satisfies all three constraints at once: patching happens at image build time, rollback is just relaunching from the previous image that is still retained, and the rollout can be sequenced fault domain by fault domain so remaining fault domains continue serving. Patching every instance in place simultaneously breaks the one-fault-domain-at-a-time rule and is hard to unwind, images cannot be edited in place nor re-read by already-running instances, and restoring a boot volume backup returns the OS to its captured state instead of applying new patches.

8. Question 8

   An architect already spreads an application tier across all fault domains of a single availability domain. Leadership now asks what additional class of failure would be covered by also placing instances in a second availability domain of the same region. Which answer is correct?

   1. A. Failure of an individual physical host or rack that the instances run on.

      This class of failure is already covered by fault domain distribution within the AD; naming it as the new benefit shows the fault-domain boundary has been misattributed to availability domains.

   2. B. Loss of an entire availability domain, since availability domains are isolated from one another and do not share power, cooling, or the internal availability domain network.Correct answer

      Correct. Availability domains are isolated data centers within a region with independent power, cooling, and internal networking, so they are unlikely to fail simultaneously — spreading across them is what survives an AD-scoped outage.

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

      Overstates the AD boundary. Availability domains sit inside one region, so surviving a regional event requires resources in a second region — a cross-region design, not a cross-AD one.

   4. D. A defect in the custom image that every instance in the tier was launched from.

      Confuses a placement control with an image-content problem. A bad image produces identically broken instances no matter where they are placed; the remedy is image testing and staged rollout, not additional availability domains.

   Explanation

   Fault domains and availability domains sit at different levels of the isolation hierarchy: fault domains separate hardware within one AD, while availability domains are isolated data centers within a region that do not share power, cooling, or the internal AD network. Adding a second availability domain therefore buys protection against the loss of a whole AD, which fault domain spreading cannot provide. Host- or rack-level failure is already handled by the existing fault domain layout, surviving a regional disaster requires a second region because all ADs of a region are in that same region, and a faulty image fails identically in every domain because placement does not change what software the instance boots.