JNCIA-Cloud cheat sheet

Service models: IaaS supplies virtualized compute, storage, and network; PaaS supplies a managed runtime and middleware; SaaS supplies the finished application. Control shifts to the provider as you move IaaS to SaaS.

Deployment models: public (multi-tenant, provider-owned), private (single-organization), hybrid (workloads split across both with connectivity between), and community (shared by organizations with common requirements).

NIST essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. A model missing measured service is not full cloud by this definition.

Shared responsibility splits by service model: the provider secures physical facilities, hypervisor, and, for PaaS/SaaS, the runtime and application layers; the customer always owns data classification, identity governance, and access policy.

Virtualization types: Type 1 hypervisor runs directly on hardware (ESXi, KVM); Type 2 runs on a host OS. Containers share the host kernel and isolate at the process level, so they are lighter but less isolated than VMs.

Elasticity vs scalability: elasticity is automatic, demand-driven scaling in and out; scalability is the capacity to grow. Vertical scaling resizes an instance; horizontal scaling adds instances.

Availability design: redundancy within a zone, replication across zones, and geographic replication across regions. Higher availability tiers cost more and add latency between copies.

Consumption economics: CapEx converts to OpEx, cost tracks usage, and reserved or committed-use pricing trades flexibility for discount. Egress bandwidth and idle resources are common hidden cost drivers.

Lifecycle stages: provision, configure, operate, monitor, and decommission. Tagging at provision time enables cost allocation, automation targeting, and policy enforcement later.

CIDR: /24 = 256 addresses, /25 = 128, /26 = 64, /27 = 32, /28 = 16. Usable hosts = 2^(32-prefix) - 2 for a traditional subnet; cloud providers often reserve additional addresses per subnet.

VPC/VNet is an isolated virtual network scoped to a region. Subnets are scoped to a single availability zone; a subnet cannot span zones.

Public subnet routes to an internet gateway; private subnet routes outbound through a NAT gateway and has no inbound path from the internet.

Security groups are stateful, instance-level allow rules; network ACLs are stateless, subnet-level rules evaluated in order with an explicit deny. Return traffic must be allowed separately in an ACL.

Route tables select the next hop by longest prefix match. Local VPC routes typically take precedence over propagated or peering routes for the same prefix.

VPC peering is non-transitive: A peered to B and B peered to C does not connect A to C. A transit gateway or hub-and-spoke design provides transitive routing.

VPN over the internet is encrypted but variable in latency and bandwidth; dedicated interconnect is private, predictable, and higher cost. Many designs use VPN as failover for interconnect.

DNS resolution: public zones answer internet queries; private hosted zones answer only from associated VPCs. Split-horizon DNS returns different answers internally and externally.

Load balancing: L4 balances on IP and port without inspecting payload; L7 balances on HTTP host, path, or header and supports TLS termination and content routing.

Identity is the primary control plane: authenticate with MFA, authorize with least-privilege roles, and prefer temporary credentials from role assumption over long-lived access keys.

IAM policy evaluation: an explicit deny overrides any allow; access requires an allow from an identity policy, a resource policy, or a permissions boundary, within the account and organization guardrails.

Encryption: at rest uses provider-managed or customer-managed keys; in transit uses TLS. Customer-managed keys enable rotation control and key-policy separation of duties.

Key management separation: the key administrator should not be the data user. Envelope encryption wraps data keys with a master key so rotation does not re-encrypt bulk data.

Network defense in depth: security groups, subnet ACLs, WAF for HTTP payload inspection, DDoS scrubbing at the edge, and private endpoints to avoid public exposure.

Logging and detection: control-plane audit logs (API calls), data-plane flow logs, and application logs feed a SIEM. Alerting on privilege escalation and root or break-glass use is baseline.

Secrets management: store credentials in a managed secret store with rotation; never embed them in code, images, or environment files committed to version control.

Compliance frameworks (SOC 2, ISO 27001, PCI DSS, HIPAA) shape control selection; the provider's certification covers the provider's layer, and the customer must evidence its own controls.

Threat model cloud-specific risks: misconfigured public storage, overly permissive roles, exposed management interfaces, and credential leakage are more common than hypervisor compromise.

Infrastructure as Code declares desired state in versioned templates; the tool computes a diff and applies it. Idempotency means re-running the same template yields no change.

Declarative vs imperative: declarative describes the end state and lets the tool decide steps; imperative lists commands. Declarative templates are preferred for repeatability.

Plan/preview before apply: review the change set to catch destructive operations such as resource replacement, then apply through a controlled pipeline.

State management: remote state with locking prevents concurrent applies from corrupting the record of deployed resources; state should be treated as sensitive because it may contain secrets.

Configuration management (Ansible, Chef, Puppet) converges the inside of a server; provisioning tools (Terraform, CloudFormation) create the infrastructure. Most estates use both.

CI/CD pipeline stages: source commit, build, unit test, policy and security scan, deploy to staging, integration test, promote to production, with automated rollback on failure.

Autoscaling policies use target tracking, step, or scheduled rules; health checks remove unhealthy instances, and cooldown or warm-up periods prevent flapping.

Event-driven automation triggers on state change (object created, alarm fired, tag changed) and invokes a function or workflow, removing manual runbook steps.

Orchestration vs automation: automation executes a single task reliably; orchestration coordinates multiple automated tasks across services and enforces order and dependencies.