Compute: Instances, Shapes, Images, Autoscaling, and Instance Configuration
What this domain tests
Compute questions test shape selection against a workload profile, image and boot-volume lifecycle, and how instance configurations, pools, and autoscaling interact. Autoscaling behaviour questions are common because they combine several resources.
Core rules
- Flexible shapes let you choose OCPU count and memory independently within a supported range; fixed shapes use preset sizes. Arm A1 shapes require Arm-compatible images.
- Burstable shapes suit workloads with low average CPU and accumulate credits for occasional bursts.
- Custom images are captured from an instance (or imported from Object Storage), are regional, and can be copied to another region. Platform images are maintained by Oracle.
- Instance configurations are immutable templates holding shape, image, metadata, tags, and block volume definitions. To change one, clone it with edits and update the pool.
- Instance pools launch identical instances from a configuration across ADs and fault domains.
- Autoscaling rules are metric-based (for example CPU utilization) or schedule-based, with minimum and maximum pool size and a cooldown.
Worked example
A web tier must scale on load. Build an instance configuration from a flexible shape with 1–4 OCPUs, behind a load balancer, then a pool with minimum 2 and maximum 8 spread over three ADs. Add a scale-out rule at 70% CPU and a scale-in rule at 30%, both with a 300-second cooldown so the tier does not flap. Scale-out adds instances one step at a time; existing instances are not rebalanced.
Traps
Trying to edit an instance configuration in place (it cannot be edited); expecting autoscaling to move running instances between ADs; horizontally scaling a stateful app with no shared session or storage; forgetting service limits and compartment quotas cap the pool size regardless of the autoscaling maximum.