NAVER Cloud Platform Fundamentals and Architecture
Domain 1 - Fundamentals and Architecture
This domain tests whether you understand how NAVER Cloud Platform is assembled: account hierarchy, the region/zone model, the VPC-centric network design, and how console, API, CLI and SDKs expose the same resources. Questions are usually scenario wrappers - choose a region layout, an account model, or a resource dependency order.
Core rules
- A main account owns all resources and billing; sub accounts are created in IAM and receive permissions only through attached policies. Nothing is allowed by default.
- A region is a physical location (Korea, Singapore, Japan, and others); a zone is an isolated facility inside a region. Multi-zone placement is the standard answer for high availability, but not every product is zone-scoped - confirm availability before designing.
- A VPC is the network boundary. Subnets are public or private; private subnets reach the internet only through a NAT Gateway, and only public subnets attach to an Internet Gateway.
- Access control is enforced by ACG (Access Control Group) rules attached to server network interfaces, not by the subnet alone.
- Every console action has an API equivalent; automation through API/CLI is expected for repeatable builds.
Worked example
A team needs a web tier that survives the loss of one zone. Reasoning: place at least two servers in different zones of the same region behind a Load Balancer, and let the health check remove the failed zone. If the chosen database product is single-zone in that region, document the residual risk instead of claiming HA is achieved.
Traps
- Assuming a service exists in every region or zone.
- Designing with the main account access key because sub-account policy setup is slow.
- Putting private-subnet servers behind an Internet Gateway and calling it a NAT.