NIFCLOUD Certified Associate common mistakes
NIFCLOUD Certified Associate · Understand the traps and how to avoid them.
Treating NIFCLOUD's menu structure like another hyperscaler's and answering service-placement questions by habit (for example assuming object storage lives under a 'compute' section or that load balancing sits under storage), instead of recalling which category each service is grouped into.
Candidates come from AWS/Azure/GCP backgrounds and map familiar service names onto NIFCLOUD without checking the actual service taxonomy; the exam's fundamentals domain asks where a service belongs and what it is for, and habit-based mapping produces confident wrong answers.
What to do instead
Build a one-page service map from the official service list, grouping every service under its published category (compute, storage, networking, security/identity, operations). For each service write one line: what problem it solves and one adjacent service it is often confused with. Review this map before attempting fundamentals questions, and when a question names a service, first place it in the map rather than reasoning from another cloud's naming.
Assuming a virtual server can be resized or have its disk/network configuration changed freely after creation, and answering compute questions as if CPU, memory, and attached storage were all hot-adjustable.
General cloud experience teaches that instances are elastic; candidates then pick 'change the plan in place' options for scenarios where the correct answer is to build a new server from an image or snapshot and cut over, or where the disk must be handled separately from the server plan.
What to do instead
Study the virtual server specification model explicitly: which parameters are fixed at creation (plan/type, OS image, disk sizing choices at provisioning), which can be changed by stopping and reconfiguring, and which require recreating the server. Practise the migration pattern 'snapshot the disk, create a new server from the image/disk, attach the private network, switch traffic, retire the old server' as the default answer for plan changes when in doubt.
Confusing block storage with object storage in scenario questions - for example proposing object storage as the boot volume for a virtual server, or proposing an attached disk as the target for large unstructured file archives accessed over HTTP.
The words 'disk', 'volume', 'bucket', and 'storage' overlap across providers, and candidates answer from the storage name rather than from the access pattern (block device mounted by an OS versus HTTP API objects versus long-term archive).
What to do instead
Classify every storage scenario by three questions: is it mounted by an operating system (block), is it accessed by an application over an API with keys (object), or is it retained long-term with rare retrieval (archive)? Memorise the mount/attach semantics of block storage, the bucket-and-key semantics of object storage, and the retrieval-latency and durability trade-offs of archive. Answer the access-pattern question first, then name the service.
Designing a private network layout without accounting for how subnets, IP address ranges, and routing relate to each other - for example placing two subnets in overlapping CIDR ranges, or expecting servers in different subnets to reach each other without any routing consideration.
Candidates treat 'create a private network' as a single checkbox and skip CIDR planning; the networking domain tests whether you can reason about address space, segmentation, and how a server's NIC is bound to a subnet.
What to do instead
Before answering, sketch the address plan: private network CIDR, subnet CIDRs carved from it with no overlap, which servers sit in which subnet, and what must route between them. Learn which traffic stays inside the private network versus what needs a gateway or VPN. For any connectivity question, write down source address, destination address, and the path between them; the wrong option usually breaks at one of those three points.
Choosing a load balancer protocol/listener type that does not match the workload - for example selecting an HTTP-oriented listener for a non-HTTP TCP service, or expecting TLS termination behaviour that the chosen listener type does not provide.
Load balancing questions are usually phrased as availability scenarios, so candidates focus on 'add a balancer' and ignore the protocol layer; listener type determines what the balancer can inspect and how health checks and certificates work.
What to do instead
For each load balancing question, identify the backend protocol first (HTTP/HTTPS versus raw TCP), then the required features (TLS termination, host/path routing, source-IP preservation), then the health-check method. Memorise which features belong to which listener family and note that health checks must match what the backend actually serves. If a scenario needs layer-7 behaviour, a layer-4 listener is the trap answer.
Treating identity and permissions as a single global admin switch - granting broad account-level privileges to a script or teammate because 'it needs to create servers', rather than scoping a role or policy to the specific actions required.
In lab and tutorial material everything is done as the account owner, so candidates never see the granular permission model; exam questions about least privilege then get answered with the most convenient broad option.
What to do instead
Learn the identity model in layers: the account/tenant, the users and groups within it, the API keys/credentials those users hold, and the permission scope attached to them. Practise writing the minimal action list for two concrete jobs (a monitoring agent that only reads metrics; a deployment user that creates and deletes servers in one private network) and choose the option that matches that list. Reject any answer that grants permissions broader than the stated job.
Ignoring the distinction between control-plane actions and data-plane effects when answering monitoring questions - for example assuming that because a server shows 'running' in the control panel, the application inside it is healthy and the question's failure is impossible.
Candidates equate resource status with service health; the operations domain tests whether you know which signals (resource state, metric thresholds, agent-based checks, log output) tell you what, and when each is blind.
What to do instead
Build a signal table: resource lifecycle state tells you the virtual machine exists and is powered; resource metrics tell you CPU, disk, and network pressure; in-guest monitoring or logs tell you the application is serving. For every monitoring scenario, ask 'which of these signals would actually change if the described fault occurred?' and pick the answer that observes the right layer. Remember that a running server with a full disk or a crashed process still reports as running.
Answering billing questions by assuming a pay-as-you-go hourly model with no fixed components - for example expecting a stopped or unused resource to cost nothing, or ignoring that some plans and attached resources bill independently of usage.
Candidates generalise from other clouds' per-second billing and forget that a virtual server plan, an attached disk, a public IP, and a load balancer may each be billed on their own basis, and that stopping a server does not necessarily release everything it holds.
What to do instead
Learn the billing units per resource type: what is charged per hour of existence versus per unit of consumption (storage capacity, data transfer, request counts), and which resources persist and continue to bill after a server is stopped (disks, addresses, balancers). For each billing question, list every resource in the scenario and its billing basis before comparing options; the correct answer usually accounts for a resource the distractors silently drop.
Assuming that placing resources in a private network makes them reachable only internally, and forgetting that a public address or gateway is a separate, explicitly attached thing - leading to wrong answers about how a server is exposed to the internet or how an on-premises site connects in.
The private/public boundary is described in several places (network creation, address assignment, VPN, firewall), and candidates collapse it into one step; questions about exposure and hybrid connectivity then get answered with the wrong component.
What to do instead
Draw the exposure path for a server: private NIC and subnet, then any public address assignment, then any firewall or packet-filter rules, then the route to the internet or to an on-premises network over VPN. For each connectivity question, identify which link in that chain the scenario changes, and choose the component that operates at that link. If the question mentions an on-premises router or a customer gateway, the answer involves the VPN side, not a public address.
Skipping the 'which service is this, really' step on scenario questions and jumping straight to a configuration detail, so a question about choosing between archive and object storage or between a managed database and a self-managed server on a disk gets answered at the wrong level of abstraction.
Scenario questions are long and candidates latch onto the first familiar keyword (a size, a protocol, a frequency) and answer a detail question that was never asked; the exam deliberately mixes service-selection and configuration depth.
What to do instead
Use a two-pass method: on the first pass, restate the scenario in one sentence naming the required capability and the constraint (access pattern, retention, protocol, latency, cost). On the second pass, eliminate options that solve a different capability before comparing the survivors on configuration detail. If two options differ only in detail but one targets the wrong service category, the category mismatch is the intended discriminator.