Compute: Virtual Servers, Images, and Networking Basics
What this domain covers
Compute questions test virtual-server sizing, image lifecycle, and basic network attachment. A NIFCLOUD virtual server is defined by a flavor (CPU/memory), an image (OS template), and one or more NICs attached to private networks. Bare metal is for workloads needing direct hardware; virtual servers are the default.
Core rules
- Images are templates. A standard image gives a clean OS; a custom image captures a configured server for repeatable deployment. Treat images as immutable build artifacts and version them.
- A NIC connects a server to a private LAN subnet and receives a private IP. Public reachability is provided by a global IP, load balancer, or NAT gateway, depending on design. Do not assume every server needs a public IP.
- Boot volumes and attached block volumes have different lifecycles. Deleting a server does not automatically mean you want to delete its data volume; check the deletion option.
- Resizing usually requires a stop/start and may be constrained by the image and zone. Plan maintenance windows.
- Use startup scripts or user data for bootstrap, not for secrets.
- Security groups and firewall rules filter traffic at the network edge; guest OS firewalls are a second layer.
Worked example
Deploy a stateless web tier from a custom image. Create two servers in different zones, each with one NIC on the same private LAN and no global IP. Put a load balancer in front; allow outbound updates through a NAT gateway. Reasoning: stateless servers can be replaced from the image; private-only NICs reduce exposure; the load balancer owns the public endpoint.
Traps
Storing session state on the boot disk; assuming a custom image includes attached block data; opening SSH or RDP to 0.0.0.0/0; forgetting that a stopped server may still incur storage or IP charges; and building from a golden image that was never patched.