NAVER Cloud Platform Certified Associate cheat sheet

NCP organizes resources by Region (geographic location) and Zone (isolated datacenter within a Region); a Zone failure does not affect other Zones in the same Region.

Region codes follow the pattern KR (Korea), US (US West), SG (Singapore), JP (Japan), DE (Germany); not every service is available in every Region, so check service-by-Region availability before design.

The Platform is accessed through three surfaces: the NAVER Cloud Platform console (web UI), the API (REST, signed requests), and the CLI; all three share the same IAM and Sub Account permission model.

VPC is the network boundary: resources such as Server, Load Balancer, and Database are placed in a VPC and subnet; Classic environments (pre-VPC) exist for legacy resources and are separated from VPC environments.

Architecture pattern for HA: deploy across at least two Zones, front with a Load Balancer, and keep state (DB, object storage) in managed services rather than on a single server.

Services are grouped into categories: Compute, Storage, Networking, Database, Security, Management, Application Services, AI/Data Analytics, and Hybrid/Global.

Resource naming: every resource has a name plus a system-generated ID/instance number; automation and API calls reference the ID, not the display name.

Billing is pay-as-you-go by default with separate pricing per Region and per service; a contract/discount plan can lower rates but changes the billing model, not the architecture.

Server (VM) products are chosen by vCPU/memory ratio: Standard (balanced), High Memory, High CPU, and GPU variants; the spec cannot be changed while running in all cases, so plan resize via stop/start or redeploy.

Server storage is split into boot storage (OS disk) and additional block storage; block storage is attached per server and is Zone-bound, so a volume cannot be moved across Zones without snapshot/copy.

A server's public IP is optional and can be assigned/released independently; a server without a public IP reaches the internet through a NAT Gateway placed in a public subnet.

Auto Scaling uses a Launch Configuration (server spec, image, init script, key) plus a Scaling Group (min/max/desired capacity, subnets, Load Balancer attachment) and Scaling Policies (target metric, schedule, or manual).

Scaling policy types: metric-based (e.g., CPU utilization threshold), schedule-based (cron-like), and manual adjustment; cooldown prevents rapid repeated scaling events.

Container: NCP provides Kubernetes Service (managed control plane, node pools) and Container Registry for images; node pools can be scaled and spread across Zones.

Kubernetes Service node pools use server specs from the compute catalog; the control plane is managed by NCP, and worker nodes are billed as servers.

Init scripts (user data) run at first boot and are the standard way to install agents, mount storage, and register with monitoring without manual steps.

Server image types: public images (OS-only), private images (my server snapshots), and shared images; a private image is Region-scoped and is the basis for identical scaling instances.

Object Storage is bucket-based, S3-compatible API, with storage classes (Standard, Infrequent Access, Archive) and lifecycle rules to transition or expire objects; it is Region-scoped and accessed by endpoint.

Block Storage is attached to a single server in the same Zone; File Storage (NAS) is shared across multiple servers over NFS and is used when several instances need the same filesystem.

Snapshot of block storage is incremental and stored separately; restoring a snapshot creates a new volume that can be attached to another server.

VPC consists of subnets (public/private), route tables, NAT Gateway, Internet Gateway, and ACLs; Security Groups are stateful and attached to resources, while NACLs are stateless and applied at subnet level.

Load Balancer types: Application LB (HTTP/HTTPS, L7, path/host routing), Network LB (TCP/UDP, L4, high throughput), and Network Proxy LB; health checks remove unhealthy targets from rotation.

Global DNS and CDN sit in front of origins: CDN caches content at edge locations and reduces origin load; DNS record changes propagate per TTL.

VPN Gateway and dedicated connection options connect on-premises to a VPC; VPN is IPsec over the internet, while dedicated lines provide predictable bandwidth.

VPC Peering connects two VPCs privately; it does not transitively connect a third VPC, so hub-and-spoke designs need explicit peering or a transit approach.

Security Group rules are allow-only (default deny); a common mistake is opening only the inbound port while forgetting the outbound rule for responses or package installs.

Managed relational options: Cloud DB for MySQL, Cloud DB for PostgreSQL, Cloud DB for MariaDB, Cloud DB for MSSQL, and Cloud DB for Oracle; each provisions a DB server separate from application servers.

Cloud DB for Redis is the managed in-memory cache; use it for session stores and hot data, not as the primary durable store.

High availability: DB instances support standby/HA configuration with automatic failover; the standby is in a different Zone from the primary.

Backups: automated backup retention is configurable; a restore creates a new DB instance rather than overwriting the existing one, so cutover is a DNS/app change.

Access control: DB access is restricted by ACG (Access Control Group) rules and DB user accounts; the DB endpoint is private within the VPC by default.

Read replicas (where supported) offload read traffic; replication lag means reads may be stale, so route only tolerant queries to replicas.

Parameter/option groups configure engine settings; changing a parameter may require a restart, so schedule changes in a maintenance window.

Data migration into managed DB commonly uses a dump/restore or a replication-based migration; large datasets need a maintenance window and a rollback plan.

Object Storage and Cloud DB are different durability models: Object Storage for files/blobs, Cloud DB for transactional relational data; do not use a DB as a file store.

IAM (main account) is the root identity; Sub Account creates additional identities under the main account with their own login and permissions.

Access is granted by policy: a Sub Account is assigned one or more policies (managed or custom) that allow specific actions on specific resources; default is deny.

Least privilege rule: grant the narrowest policy that supports the job; use custom policies rather than administrator policies for operational staff.

Sub Account supports grouping (folders/groups) so policies can be assigned to a group instead of per user; group membership inherits permissions.

MFA can be enforced for Sub Accounts; API access uses access keys (access key ID + secret key) that must be rotated and never embedded in code.

Security monitoring services include Security Monitoring, Web Security Check, and vulnerability/analysis tooling; alerts are configured per rule and routed to notification channels.

ACG (Access Control Group) is the VPC-era firewall for resources; rules are allow-based and evaluated for inbound and outbound separately.

Certificate Manager and SSL certificates secure HTTPS on Load Balancers; certificate expiry is an operational risk that needs monitoring.

Audit: activity logs record who did what and when; retain logs according to policy and centralize them outside the account being audited.

Cloud Insight / Monitoring collects metrics (CPU, memory, disk, network) from servers via an agent; without the agent, only hypervisor-level metrics are visible.

Alarm rules trigger on metric thresholds and can send notifications (email, SMS, webhook) or invoke auto-scaling actions; an alarm without a notification channel is silent.

Cloud Log Analytics centralizes logs; agents or service integrations ship logs, and retention is a billing and compliance decision.

Billing: charges are per service and per Region; the My Page / billing dashboard shows current usage, and a budget alert warns before overrun.

Cost drivers to check first: running servers (24/7), unattached block storage, snapshots, public IPs, NAT Gateway data processing, and outbound data transfer.

Resource Manager / tagging: apply consistent tags (environment, owner, cost center) so cost and inventory reports can be filtered.

Maintenance and patching: managed services announce maintenance windows; servers require OS patching via your own process or automation.

Change safety: use separate environments (dev/stage/prod) with separate Sub Accounts and VPCs, so a mistake in dev cannot touch prod.

Status/monitoring: service health notices and event history help distinguish a platform incident from an application bug.

AI services are consumed as APIs: CLOVA Speech (STT/TTS), CLOVA OCR, CLOVA Face Recognition, and Papago Translation are called with an API key from the application, not embedded in client code.

CLOVA Studio provides generative AI model access and prompts via API/console; usage is metered, so token/request volume is a cost factor.

Data analytics: Data Forest / Hadoop-based analytics and Cloud Data Box for data exploration; Object Storage is the common landing zone for raw data.

Application services include API Gateway (routing, auth, rate limiting), Cloud Functions (serverless), and Message Queue / pub-sub style services for decoupling.

API Gateway is the standard place to terminate auth, apply rate limits, and version APIs in front of backend services.

Search/Recommendation and Vision services are managed APIs; the design decision is managed API vs. self-hosted model, driven by latency, data residency, and cost.

AI API keys are credentials: store them in a secret manager or environment configuration, rotate them, and restrict them per application.

For data pipelines, separate ingestion (Object Storage), processing (analytics/compute), and serving (DB/cache) layers so each can scale independently.

Migration order: inventory and dependency mapping first, then network (VPC/subnets/VPN), then data, then application cutover, then decommission.

Hybrid connectivity options: IPsec VPN Gateway for quick/low-cost links, dedicated connection for steady high bandwidth; design for failover between them where needed.

Data transfer into NCP: Object Storage supports bulk upload tools and transfer acceleration-style options; very large datasets need a staged transfer plan and checksum verification.

Cutover pattern: run source and target in parallel, replicate data, test, then switch DNS with a low TTL; keep the old environment for rollback until validation passes.

Operational baseline: infrastructure as code or documented runbooks, centralized logging, alarms on every critical metric, and tested backups with restore drills.

Security baseline: MFA on Sub Accounts, least-privilege policies, no long-lived keys in code, Security Group/NACL review, and periodic access recertification.

Cost baseline: right-size server specs from monitoring data, use Auto Scaling for variable load, apply lifecycle rules to Object Storage, and delete unattached volumes/snapshots.

Resilience baseline: multi-Zone deployment, health-checked Load Balancer, managed DB with standby, and a documented RTO/RPO per workload.

Post-migration validation: compare performance and error rates against the source, confirm backup/restore works, and update on-call runbooks and ownership records.