NAVER Cloud Platform Certified Associate common mistakes
NAVER Cloud Platform Certified Associate · Understand the traps and how to avoid them.
Treating NAVER Cloud Platform's account/region model as if it were a single global account with automatic resource replication, and assuming a resource created in one region is visible or usable in another.
Candidates carry over habits from other clouds where a global console view blurs regional boundaries, so they answer questions about where a resource lives or whether it must be re-created per region without checking the platform's region-scoped design.
What to do instead
Before answering, explicitly state for each resource whether it is region-scoped or account-global, and confirm that cross-region use requires explicit configuration (replication, peering, or separate creation). Memorize the distinction between the account/organization layer and the region layer, and practice mapping a small architecture (VPC, Server, storage, database) region by region.
Choosing a compute option (Server vs. container vs. autoscaling group) based on familiarity rather than on the workload's lifecycle and scaling trigger, e.g., picking a fixed Server for a spiky web tier or an autoscaling group for a stateful singleton.
The exam phrases scenarios around operational characteristics (bursty traffic, stateless services, persistent local state) and candidates pattern-match on product names instead of reading the constraints in the scenario.
What to do instead
Build a decision table: stateless and horizontally scalable → autoscaling group behind a load balancer; containerized microservices needing orchestration → container service; stateful or single-instance workloads → standalone Server. For each practice scenario, underline the constraint words (bursty, stateful, persistent disk) before selecting.
Assuming block storage can be attached to multiple servers simultaneously or that object storage behaves like a file system with in-place edits and rename semantics.
Candidates conflate block, file, and object storage models and answer questions about concurrent access, locking, or partial updates using the wrong storage semantics.
What to do instead
Memorize the access model per storage type: block storage is attached to a single server at a time, file storage supports shared concurrent mount, object storage is accessed via API/HTTP and is not suitable for in-place partial edits. Practice classifying use cases (shared web content, database data files, backups/archives) into the correct type.
Designing a VPC layout without separating public and private subnets, or placing a managed database in a public subnet and relying on security groups alone.
Candidates focus on connectivity (does it route?) and skip the isolation question (should it route?), so they miss questions that hinge on which tier should be reachable from the internet.
What to do instead
For every architecture question, draw the internet boundary first: load balancer/public entry in a public subnet, application servers and databases in private subnets, with outbound access via NAT where needed. Then verify routing tables and security group rules separately, since both must permit traffic.
Treating IAM policy evaluation as 'any allow wins' or ignoring the interaction between Sub Account permissions, group membership, and resource-level policies when determining effective access.
Candidates remember individual features but not the evaluation order, so they misjudge scenarios where a user is in multiple groups or where a broad policy is narrowed by another layer.
What to do instead
Write out the evaluation chain explicitly for each scenario: identity (Sub Account) → group memberships → attached policies → resource-level restrictions, and determine the net effect. Practice with a two-group user who has an allow in one group and no permission in another, and with a policy that grants a broad action but is scoped to specific resources.
Confusing authentication/authorization controls (IAM, Sub Account) with detection and monitoring controls (security monitoring, audit logging), and answering 'how do we prevent this?' when the question asks 'how would we detect this?'
Both live in the Security domain and candidates group them mentally as 'security', losing the preventive-vs-detective distinction the question is testing.
What to do instead
Tag every security control you study as preventive, detective, or corrective. For each scenario, identify the verb in the question (prevent, detect, respond, audit) and choose the control class that matches it before picking a product.
Assuming monitoring metrics and billing cost data are the same view, or that a resource's cost can be attributed without a tagging/labeling strategy set up in advance.
Candidates answer cost-allocation questions by naming a monitoring dashboard, and answer alerting questions by naming a billing report, because both surfaces show per-resource numbers.
What to do instead
Separate the two: monitoring answers 'is it healthy and performing?' (metrics, alerts, dashboards), billing answers 'what did it cost and who owns it?' (usage/cost reports, budgets). For cost attribution questions, first confirm a tagging convention exists; if not, the correct answer often involves establishing one before analysis is possible.
Selecting a managed AI/data service for a task it does not perform, e.g., expecting a speech or vision API to also handle translation, or expecting a managed database service to provide an analytics warehouse.
Candidates memorize product names and marketing categories but not the input/output contract of each service, so they map a scenario to the nearest-sounding product.
What to do instead
For each AI/data service, write one line: input type, output type, and the single job it does. Then, for scenario questions, extract the input (text, audio, image, tabular) and the desired output before selecting. If the scenario needs two steps (e.g., speech-to-text then translation), answer with the pipeline, not a single service.
Planning a migration as a lift-and-shift of every workload without classifying which workloads should be re-architected, re-platformed, or retired, and without accounting for data transfer and cutover downtime.
Candidates focus on 'how do I move it' and skip 'should I move it as-is', so they miss questions about migration strategy selection and about the operational cost of the cutover window.
What to do instead
For migration scenarios, classify each workload into retain / retire / re-host / re-platform / re-architect and justify with one sentence. Separately estimate the cutover: data volume, transfer method, and acceptable downtime, and check whether a hybrid period with connectivity between on-premises and cloud is required.
Answering operational-best-practice questions with a single action (e.g., 'enable autoscaling') instead of a full loop of observe → alert → scale/remediate → verify, and omitting rollback and change-tracking steps.
Candidates treat operational questions as product-selection questions, so they name a feature but not the process around it, missing answers that require monitoring thresholds, alert routing, and post-change verification.
What to do instead
For every operational scenario, write the loop explicitly: what metric is observed, what threshold triggers action, who/what is notified or acts, how the change is rolled back, and how success is verified. Practice describing a deployment with a canary or staged rollout plus a defined rollback condition.