NHN Cloud Associate common mistakes
NHN Cloud Associate · Understand the traps and how to avoid them.
Treating NHN Cloud instance flavors as if they were interchangeable with AWS EC2 instance types, and picking a flavor by vCPU count alone while ignoring the memory-to-vCPU ratio and whether the flavor is a general-purpose or dedicated type.
Candidates arrive from AWS or Azure prep material where the naming conventions look familiar, so they pattern-match '2 vCPU' to a familiar instance size without checking the NHN Cloud flavor families, their memory ratios, and which families support features such as dedicated host placement or GPU. The exam deliberately offers two plausible flavors where only one matches the stated workload profile.
What to do instead
Build a one-page flavor table before exam day: family name, vCPU-to-memory ratio, intended workload (web, batch, in-memory DB, GPU), and whether it is a general or dedicated type. On each question, extract the workload signal first (memory-hungry, CPU-bound, latency-sensitive), then eliminate flavors whose ratio contradicts it before comparing price or disk.
Assuming a stopped instance stops billing, and choosing 'stop' as the cost-optimization answer when the question asks how to eliminate compute charges for an instance that must be kept for later reuse.
Public cloud habits from other providers carry over, but NHN Cloud's billing model for instances depends on whether the instance is terminated versus stopped and on whether the attached block storage and public IP persist. Candidates answer from habit rather than from the stated billing rule, and the distractor 'stop the instance' reads as obviously correct.
What to do instead
Memorize the rule as a three-part statement: what happens to the instance, what happens to attached block storage, and what happens to the public IP or floating IP, for each of stop, terminate, and delete. When a question says 'must be reusable later', the correct answer is the one preserving the storage, and the cost saving comes from releasing the compute and the public IP, not from the stop action alone.
Configuring an autoscale or instance template group but forgetting that the scaling policy needs a health check or load balancer association, so the group scales out and the new instances never receive traffic.
Candidates focus on the trigger metric (CPU threshold) and treat the load balancer as a separate topic, because exam domains are listed separately. In reality the autoscale group's value depends on the new instance being registered with the load balancer and passing its health check, and the question's symptom ('instances launched but users see errors') points at that gap.
What to do instead
Whenever you see autoscaling in a question, draw the chain: instance template, autoscale group, load balancer member registration, health check. If any link is missing in the scenario, that is the fault. Also check that the health check port and path match what the application actually serves, since a mismatch produces the same symptom.
Choosing a Kubernetes cluster answer that ignores the difference between the control plane managed by NHN Cloud and the node pool the candidate must size, then blaming node failure when the real issue is a missing node pool or an undersized one.
Candidates conflate 'managed Kubernetes' with 'fully managed', expecting the provider to supply worker capacity. NHN Cloud Kubernetes Service manages the control plane but the worker node pool is the candidate's responsibility, including instance flavor, node count, and autoscaling of the node pool itself.
What to do instead
Separate the two layers explicitly in notes: control plane (managed, no node sizing) versus node pool (candidate-sized, has its own autoscaler). For any 'pods pending' scenario, check node pool capacity and the pod's resource requests before checking the control plane, and remember that cluster autoscaling requires the node pool autoscaler to be enabled, not just the horizontal pod autoscaler.
Treating a container registry image pull failure as a network problem and opening security group rules, when the actual cause is a missing image pull secret or a repository permission the node's service account does not have.
Candidates associate 'ImagePullBackOff' with connectivity because that is the most visible infrastructure layer, and NHN Cloud's registry requires authentication that is configured separately from the cluster's network. The question usually states that the network path is open, which should redirect attention to credentials.
What to do instead
For any image pull failure, check in order: does the image reference and tag exist in the registry, is an image pull secret attached to the pod's service account or spec, and does that secret's credential have read access to that repository. Only after those three pass should you examine network rules.
Designing a VPC with overlapping subnet CIDR ranges between the VPC and an on-premises network, then discovering that the VPC peering or hybrid connection cannot route traffic.
Candidates allocate private ranges casually (/16 here, /16 there) because each subnet looks fine in isolation, and the exam scenario later adds an on-premises connection. Overlapping address space is a silent design error that surfaces only when peering or a VPN is introduced, and peering in NHN Cloud does not support transitive routing or overlapping ranges.
What to do instead
Before answering any network design question, write down the address plan: VPC CIDR, each subnet CIDR, on-premises CIDR, and any peered VPC CIDR. Reject any option where ranges overlap. Also remember that peering is non-transitive, so a hub-and-spoke design needs either a transit approach or explicit peering per spoke.
Placing a load balancer in a single subnet or availability zone and then answering that the architecture is highly available because a load balancer exists.
Candidates equate the presence of a load balancer with redundancy, but the load balancer's own resilience depends on which subnets and zones it spans, and on whether backend members exist in more than one zone. The exam tests whether the candidate inspects the load balancer's placement rather than its existence.
What to do instead
For every high-availability question, check three things independently: the load balancer spans multiple zones or subnets, the backend members are distributed across those zones, and the health check is configured so a failed member is removed. If any of the three is single-zone, the design is not highly available regardless of how many instances exist.
Choosing a block storage type by capacity alone and ignoring the performance characteristics, so a database volume is provisioned on a storage type whose IOPS or throughput cannot sustain the workload.
Candidates treat storage as a size decision because that is how the pricing page is organized, and the exam question supplies an IOPS or latency requirement that should drive the type choice. The capacity number is the loudest detail in the question and drowns out the performance requirement.
What to do instead
Read storage questions twice: first for capacity, second for performance. Note whether the scenario mentions IOPS, throughput, or latency, and map that to the storage type designed for it. Also check whether the volume must be attachable to multiple instances, since that constraint eliminates some types outright.
Assuming object storage is a drop-in replacement for a POSIX filesystem and answering that an application can mount an object storage bucket as a shared directory for concurrent writes.
Candidates blur the line between object storage, block storage, and shared file storage because all three are 'storage'. Object storage is accessed over HTTP with an object-level API and does not provide file locking or in-place modification semantics, so applications expecting a mounted filesystem behave incorrectly.
What to do instead
Maintain a three-row comparison: block storage (attached to one instance, filesystem on top), shared file storage (mounted by many instances, POSIX semantics, for shared concurrent access), object storage (HTTP API, immutable-style objects, for static assets, backups, logs). Match the application's access pattern to the row, not to the price.
Answering database questions by selecting the largest or most feature-rich database service instead of matching the service to the access pattern, and ignoring read replica versus backup versus high-availability distinctions.
Candidates memorize service names without their operational contracts, so 'read replica' and 'standby for failover' collapse into one idea, and a question about offloading read traffic gets answered with a failover standby that serves no reads. Similarly, a relational requirement gets answered with a key-value store because it sounds scalable.
What to do instead
For each database service, record four properties: data model, whether it is relational, how it scales reads (replica), how it survives failure (standby or multi-zone), and how it recovers data (backup and point-in-time restore). Answer by matching the question's stated need to exactly one of those four properties, and reject options that solve a different one.