NAVER Cloud Platform Certified Professional common mistakes
NAVER Cloud Platform Certified Professional · Understand the traps and how to avoid them.
When sizing a Server or Kubernetes node pool, you pick the smallest spec that fits current CPU/memory and ignore whether the workload needs a GPU, local NVMe, or a specific CPU generation, then fail items asking which instance family is valid for that workload.
Candidates memorize generic 'small/medium/large' thinking from other clouds and assume any spec can run any image. NAVER Cloud Platform exposes distinct server families (standard, high-memory, GPU, bare metal) and Kubernetes node pools inherit those constraints, so a spec chosen only on vCPU count is often invalid for the stated workload.
What to do instead
Build a one-page mapping of server families to workload signatures (general web, memory-heavy DB, GPU inference/training, bare metal for licensing) and rehearse the rule that node pool spec must be compatible with the pod's resource requests plus any device plugin requirement. When a question states a workload trait, first eliminate families that lack that trait before comparing sizes.
You treat a VPC subnet as spanning multiple availability zones, or assume you can move a resource between subnets/zones after creation without redeploying.
Experience with regional subnets in other clouds leads candidates to answer that a single subnet covers all zones. On NAVER Cloud Platform a subnet is bound to one zone, and many resource placements (Server instances, load balancer targets, database nodes) are fixed at creation.
What to do instead
Draw the VPC as zone columns with subnets inside each zone, and annotate which resources are zone-pinned versus regional. For any question about high availability, verify that the design places nodes in at least two zone-specific subnets before accepting it. For change questions, default to 'recreate in the target subnet' unless the service explicitly supports in-place movement.
You conflate IAM sub-accounts, groups, and roles, and answer access questions by granting permissions directly to a user instead of through the intended principal model, or you miss that some services use their own service roles.
The terminology overlaps with other platforms but the binding model differs. Candidates remember 'policies attach to users' and overlook group-based inheritance and role assumption for service-to-service access, so least-privilege questions get answered with the broadest option.
What to do instead
Memorize the principal hierarchy (main account, sub-account, group, role) and the rule that permissions flow through policy statements bound to those principals. Practice rewriting a broad permission into the narrowest policy that still satisfies the stated task, and check whether the actor is a human, a service, or an automated pipeline before choosing the principal type.
You select a load balancer type (application vs network) based on habit rather than on the stated protocol, TLS termination need, and target type, and you misstate which health check settings apply.
Load balancer choice feels interchangeable, so candidates skip the discriminating details: L4 versus L7 inspection, whether the listener terminates TLS, and whether targets are instances or IPs. Exam items plant one detail that only one type satisfies.
What to do instead
Create a decision table with rows for protocol, TLS termination, path/host routing, and target type, and fill in which load balancer type supports each. Before answering, extract those four facts from the stem and let them eliminate options; then confirm the health check protocol matches what the backend actually serves.
You assume Object Storage behaves like a block volume or a POSIX filesystem, or you pick the wrong storage class for the access pattern described (frequent random reads, archive, static web serving).
All storage looks like 'a place for files' until the question asks about latency, mounting, or lifecycle. Candidates default to block storage for anything persistent and forget that Object Storage is accessed over HTTP and is not mountable as a disk.
What to do instead
Classify each storage service by access method (block device, network file, HTTP object), durability/availability scope, and lifecycle support. For each practice scenario, write one sentence on why the chosen storage matches the access pattern, and reject any option that requires mounting where the stem implies HTTP access or vice versa.
You design a database deployment as a single node and call it highly available, or you ignore read replica lag and failover behavior when the question asks about RPO/RTO.
Candidates equate 'managed database' with 'automatically HA'. Managed does not mean multi-zone by default; the HA property comes from the specific configuration (standby/replica placement across zones) and the failover mechanism.
What to do instead
For every database question, explicitly state where the primary and any standby/replica live (which zone) and what happens on failure. Learn the difference between synchronous standby (low RPO) and asynchronous read replica (possible lag), and match the option to the RPO the stem implies rather than to the word 'managed'.
You answer monitoring questions by naming a dashboard instead of the metric, threshold, and action, and you skip how alarms route to notification channels or trigger automation.
Monitoring is studied passively ('there is a monitoring service'), so candidates recognize the product name but cannot connect metric to alarm rule to action. Items test the chain, not the brand.
What to do instead
Practice writing full alarm specifications: resource, metric, statistic/period, threshold, evaluation count, notification channel, and automated action. Memorize which metrics are available per resource type (compute, database, load balancer) and how an alarm can trigger a scaling or runbook action, then answer by completing the chain rather than picking the service name.
You treat CDN and DNS as independent add-ons and fail to trace the request path (client to DNS resolution to CDN edge to origin) or to reason about cache key, TTL, and origin protection.
Candidates learn CDN as 'faster static files' and DNS as 'name to IP', so multi-step questions about cache misses, invalidation, or origin exposure have no mental model to run. The exam expects you to follow the path and identify where a setting takes effect.
What to do instead
Rehearse a single request-path diagram and annotate where each control acts: DNS record type and TTL at resolution, CDN cache key and TTL at the edge, origin shielding and access control at the origin. For each scenario, ask 'where in this path does the described behavior happen?' and eliminate options that place a control at the wrong hop.
You assume migration is a lift-and-shift copy and ignore dependency discovery, network path (VPN vs dedicated connection), and cutover validation, so you pick an option that moves data without addressing connectivity or rollback.
Migration questions read like storage questions, so candidates focus on the transfer mechanism and forget the surrounding requirements: private connectivity, DNS cutover, data consistency during transfer, and a rollback plan.
What to do instead
Structure every migration answer as four checkpoints: inventory/dependency, connectivity (is private line or VPN required?), transfer method and consistency, and cutover with rollback. If an option solves the transfer but not connectivity or rollback, it is incomplete; prefer the option that covers all four or explicitly state the missing piece.
You optimize cost by downsizing specs alone and miss commitment/reserved options, idle-resource cleanup, storage lifecycle, and the trade-off between cost and availability in the stated SLA.
Cost questions feel like arithmetic, so candidates pick the cheapest line item without checking whether it violates the availability or performance requirement stated earlier in the stem. They also overlook that some discounts require a commitment term.
What to do instead
Answer cost questions in two passes: first eliminate options that break the stated SLA or performance need, then compare remaining options on total cost including commitment term, data transfer, and storage lifecycle. Practice identifying idle or orphaned resources (unattached volumes, unused public IPs) as a separate, safe saving category.