SNB Project — Cheatsheet

Infrastructure design, cloud, storage, web services and automation — 2025–2026

CAMPUS Parameters

An infrastructure choice is only solid when it doesn't just work technically, but also demonstrably fits the organization. Test every scenario against CAMPUS.

Letter	Parameter	Central question
C	Cost	What are the purchase, license, management, energy and migration costs?
A	Availability	What downtime is acceptable and what redundancy is needed?
M	Manageability	How easily can it be managed, monitored, patched and recovered?
P	Performance	Are capacity, latency, throughput and response time sufficient?
U	User-friendliness	Is the solution usable and understandable for the target audience?
S	Security	Are data, identities and services adequately protected?

Parameters can conflict. Redundancy increases availability and possibly performance, but also cost and management complexity. The best choice is therefore not "the technical maximum," but the best-justified balance according to agreed priorities.

Decision matrix

Criterion	Weight	Scenario A	Scenario B
Cost	20%	score × 0.20	score × 0.20
Availability	25%	score × 0.25	score × 0.25
Manageability	15%	score × 0.15	score × 0.15
Performance	15%	score × 0.15	score × 0.15
User-friendliness	10%	score × 0.10	score × 0.10
Security	15%	score × 0.15	score × 0.15

Justify concretely

"This is more secure" is not a full justification. Name the threat, the control, the residual risk, the cost and the impact on management and users.

From Requirement to Infrastructure

business need
      ↓
functional and non-functional requirements
      ↓
dependencies and constraints
      ↓
scenarios + CAMPUS trade-off
      ↓
design and implementation
      ↓
technical and functional tests
      ↓
monitoring, documentation and adjustment

IT infrastructure consists of hardware, software/services and users. Start from what the service needs to do, not from a product name.

Gathering requirements

number and locations of users and devices;
expected concurrent load and growth;
required storage, retention and backup;
network bandwidth and maximum acceptable latency;
availability targets, RPO and RTO;
legislation, classification and security requirements;
integrations with existing identity, DNS, DHCP and cloud;
available knowledge, time, budget and support contracts.

The ideal network is a utopia

Infrastructure keeps changing due to new applications, migrations, growth and new risks. Record assumptions and design so that controlled change stays possible.

Combining and Sizing Services

For each service, research its function, operation, dependencies, communication patterns and resource profile.

Service	Typical emphasis
DHCP	short spikes on CPU and network interface
DNS	memory for cache and fast disk for zones/logs
NAT	CPU, RAM and network throughput
VPN	CPU for cryptography and network throughput
File server	disk capacity, IOPS, network and cache
Web server	CPU/RAM, connections and back-end dependencies

Complementary workloads can fit on the same host, but consolidation also increases blast radius and resource contention. Separate services when security boundaries, maintenance windows, availability or independent scaling require it.

Monitoring follows implementation. Measure actual usage to recognize over- and under-sizing; a vendor minimum is not a capacity plan.

DNS as a Design Example

For DNS, choices need to be made about platform, namespace, zone types, updates, redundancy, placement and the relationship with AD/DHCP, among other things.

Zone type	Property
Primary	writable source zone
Secondary	read-only copy via zone transfer
AD-integrated	multimaster storage and replication via AD
Caching-only	no own zones; caches external answers

Key records: SOA, NS, A, AAAA, PTR, CNAME, MX and SRV.

Design rules

Use a domain name you actually control; an unregistered fictitious internal name complicates cloud integration.
AD cannot function without DNS; clients must use the correct internal resolver.
Place redundant resolvers close to users and important sites.
Publish only necessary records externally, for example with split DNS.
Place a public secondary in the DMZ, not the internal writable primary.
Restrict zone transfers and dynamic updates; use secure updates where possible.
DNSSEC proves authenticity/integrity of DNS data, but does not encrypt queries.

DHCP hands out the DNS server and suffix to clients and can perform dynamic updates on their behalf. Check ownership and update policy to limit stale records and poisoning risk.

Cloud and Azure Basics

Model	Management boundary
IaaS	customer manages OS, apps and data; provider the physical layer
PaaS	customer manages application/data; provider the platform and OS
SaaS	provider delivers the full application; customer manages usage/data/configuration

Deployment	Meaning
Public cloud	shared provider infrastructure
Private cloud	cloud model for a single organization
Hybrid cloud	on-premises and cloud resources integrated

Cloud benefits include elasticity, scalability, global availability and consumption-based pricing. Against that stand dependency on connectivity/provider, governance, cost monitoring and the shared responsibility model.

Azure hierarchy

Microsoft Entra tenant
└── Management groups
    └── Subscriptions
        └── Resource groups
            └── Resources

Regions contain datacenters; availability zones are physically separate locations within a region.
Resource groups are logical lifecycle/management containers; a resource sits in exactly one resource group.
Azure RBAC determines who may perform which actions at which scope.
Tags help with ownership, environment and cost reporting.
Azure Policy checks or enforces configuration rules.

AZ-900 labs

Understand why you're creating a resource and how it's billed. Remove lab resources after use, and don't rely on temporary save-retention as documentation.

Microsoft 365 and Entra ID

Microsoft Entra ID is the central cloud identity provider for Microsoft 365. It handles authentication and supports authorization, auditing and single sign-on.

Portal/component	Use
Microsoft 365 admin center	tenant overview, users, groups, licenses and service health
Entra admin center	identity, authentication, roles and Conditional Access
Intune admin center	endpoints, apps and compliance
Security/Purview portals	security, compliance and information protection

Users and groups

Static groups get members added manually.
Dynamic groups use membership rules based on attributes.
Microsoft 365 groups support collaboration and underlie much of Teams functionality.
Use consistent prefixes and names that show purpose, audience and owner.
Preferably assign licenses via group-based licensing.

Roles

Apply least privilege: limit Global Administrators and assign specific admin roles. With Privileged Identity Management, a role can be activated temporarily, under conditions, with logging.

Groups are not OUs

Dynamic groups can logically collect users/devices, but they don't replace all functions of on-premises OUs, such as hierarchical GPO processing.

Hybrid Identity

Synchronization links on-premises AD objects to Entra objects. A stable source anchor (mS-DS-ConsistencyGuid locally, ImmutableId in Entra) prevents the same individual from being seen as a new cloud object.

Authentication method	Operation
Password Hash Synchronization	a derived password hash is synced to Entra; the cloud authenticates
Pass-through Authentication	agents validate the password against on-premises AD
Federation	an external identity provider handles authentication

PHS is simple and keeps working if the on-premises connection drops. PTA keeps validation local but requires available agents and infrastructure.

Enable the AD Recycle Bin and define recovery procedures before rolling out synchronization broadly. Otherwise, deletions and faulty changes can flow through to the cloud.

Intune and Device Management

Intune is cloud-based endpoint and app management. It works together with Entra ID, Conditional Access, Microsoft Defender and Autopilot.

Entra device states

Status	Typical scenario
Entra registered	personal/BYOD device
Entra joined	organization device, cloud-first
Hybrid Entra joined	locally AD-joined and also registered in Entra

Core objects

Enrollment links a device to management.
Configuration profiles set settings.
Compliance policies assess state, e.g. encryption, OS version and PIN.
Conditional Access uses signals such as user, device compliance, location and risk.
App deployment installs required/available apps.
Autopilot automates out-of-box provisioning.

device enrolled → configuration/applications → compliance evaluation
                                          ↓
                         Conditional Access allows or blocks

Compliance doesn't auto-remediate

A compliance policy determines whether a device meets requirements. Use configuration/remediation to actually enforce or fix the desired setting.

Work with test groups and phased rollout. Check assignment, check-in, conflicts, per-setting status and local event logs before changing a policy.

TrueNAS and ZFS

TrueNAS is a storage OS with OpenZFS and supports file storage such as SMB/NFS and block storage via iSCSI.

disks → vdev(s) → ZFS pool → dataset or zvol → share/target

Object	Use
Pool	storage capacity built from vdevs
Dataset	filesystem-like, own quota/snapshots/properties
zvol	block device, e.g. for iSCSI
Snapshot	point-in-time state via copy-on-write

ZFS provides checksums, snapshots, compression and self-healing with redundant data. A pool's redundancy depends on the vdev layout; losing one entire vdev can lose the whole pool.

RAID/ZFS is not a backup

Redundancy protects against certain disk failures, not against deletion, ransomware, fire or errors written to all copies.

For a lab: give TrueNAS a management interface/IP, add separate data disks, create a suitable pool and dataset/zvol, configure permissions, and only then publish the service.

ESXi Virtual Storage

An ESXi datastore is a logical storage location for VM files, templates, ISOs and snapshots.

Type	Property
Local storage	simple, but not shared between hosts
NFS datastore	file-level NAS protocol over IP
iSCSI/FC datastore	block storage; ESXi typically creates VMFS

Shared storage supports scenarios such as migration, high availability and centralized management, but introduces a dependency on network and storage platform.

Logically or physically separate management and storage traffic, provide redundant paths/switches where availability requires it, use a matching MTU only end-to-end, and measure latency/IOPS/throughput.

NFS Storage

With NFS, TrueNAS exports a dataset; ESXi mounts it as an NFS datastore.

Steps

Create the pool and dataset in TrueNAS.
Configure dataset permissions and allowed networks/hosts.
Create the NFS share and start the NFS service.
Create a VMkernel interface on ESXi that can reach the storage.
Add the datastore with the server IP and export path.
Test create/read/write and recovery after a reboot.

showmount -e <truenas-ip>

Root mapping

Overly broad maproot/root access increases the impact of a compromised client. Restrict exports to the necessary ESXi hosts or the storage VLAN.

iSCSI Storage

iSCSI carries SCSI block commands over TCP/IP. The storage side is the target; the client/ESXi host is the initiator.

portal/IP + target/IQN + extent/zvol + association + access policy

An IQN typically has the format:

iqn.yyyy-mm.reversed-domain:unique-name

TrueNAS → ESXi

Create a zvol or file extent.
Configure the portal and allowed initiators/networks.
Create a target with a unique IQN.
Link the target to the extent.
Start the iSCSI service.
Enable the ESXi software iSCSI adapter and add the discovery portal.
Rescan storage and create a VMFS datastore on the discovered LUN.

CHAP adds authentication but is not full encryption. Isolate iSCSI in a storage VLAN and use redundant paths/multipathing per the design.

One LUN, one coordinated cluster filesystem

Don't let multiple independent hosts write to the same block volume without a shared cluster filesystem or coordination mechanism; ordinary filesystems will get corrupted.

Shared Hosting with IIS

IIS can distinguish multiple websites on one server via bindings.

binding = protocol + IP address + port + hostname

For HTTPS, the certificate and hostname/SNI belong to the binding.

Basic workflow

Install the Web Server (IIS) role and required role services.
Create a separate content directory per site.
Create a separate application pool where isolation is needed.
Configure a binding with a unique host header.
Create a DNS record pointing to the server IP.
Set NTFS permissions for the administrator and the app pool identity.
Test locally and from a client using the hostname.

Install-WindowsFeature Web-Server -IncludeManagementTools
Get-Website
Get-WebBinding

Don't use broad write permissions on the web root. Give the worker process identity only what the application needs. Separate the public website and an internal intranet with DNS, network/firewall, authentication and bindings — not just a "secret" URL.

Diagnostics

Error	Check
wrong site appears	host header, DNS and binding conflict
403	authentication/authorization, default document, NTFS
404	path, file, URL rewrite
500/502/503	application, handler, application pool and logs

NGINX and Redundant Web Hosting

On Debian/Ubuntu, configurations typically live in /etc/nginx, with sites in sites-available and symlinks in sites-enabled.

server {
    listen 80;
    server_name firstname.whatsnap.be;
    root /var/www/whatsnap;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo apt update
sudo apt install nginx
sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx

Use reload after a successful nginx -t so active connections are disrupted as little as possible.

Redundancy

Two web servers only become a redundant service with:

a mechanism that distributes traffic/performs failover;
consistent content and configuration;
health checks that test the actual site;
redundant DNS/network/back-end dependencies;
monitoring and a tested failover procedure.

Options include a load balancer/reverse proxy, a floating virtual IP, or DNS-based distribution. DNS round robin by itself doesn't detect a failed server, and clients can cache records.

Docker

image = immutable template/layers
container = running instance of an image
registry = storage/distribution of images
volume = persistent data outside the container layer
network = communication between containers/external

docker pull ubuntu
docker image ls
docker run --name ubuntu-container1 -it ubuntu bash
docker ps -a
docker container diff ubuntu-container1
docker exec -it ubuntu-container1 bash
docker logs ubuntu-container1
docker stop ubuntu-container1
docker rm ubuntu-container1

docker commit can save a modified container as an image, but is hard to reproduce. Use a Dockerfile for controlled builds.

FROM ubuntu:24.04
RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*
CMD ["bash"]

docker build -t my-ubuntu:1.0 .
docker tag my-ubuntu:1.0 registry.example/my-ubuntu:1.0

Good practices

use small, trusted, pinned base images;
run as non-root where possible;
don't put secrets in the image, Dockerfile or an environment dump;
write persistent data to volumes;
publish only necessary ports;
scan images and rebuild regularly with patches.

Ansible

Ansible is agentless configuration management and provisioning. Linux/BSD is usually managed via SSH and Python; Windows via WinRM; network devices via SSH/APIs.

Term	Meaning
Control node	runs Ansible
Managed node	managed system
Inventory	hosts and groups
Module	performs one kind of task
Play	hosts + vars + tasks/roles
Playbook	one or more plays in YAML
Role	reusable structure of tasks, handlers, vars, files and templates

SSH and inventory

ssh-keygen -t ed25519 -f ~/.ssh/ansible -C ansible
ssh-copy-id -i ~/.ssh/ansible.pub admin@server1
sudo apt update && sudo apt install ansible

[webservers]
server1 ansible_host=192.168.10.21
server2 ansible_host=192.168.10.22

[webservers:vars]
ansible_user=admin
ansible_ssh_private_key_file=~/.ssh/ansible

ansible all -i inventory.ini -m ping
ansible webservers -i inventory.ini -m setup

Playbook

---
- name: Configure web servers
  hosts: webservers
  become: true
  tasks:
    - name: Install NGINX
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Publish configuration
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/nginx/sites-available/site.conf
        mode: "0644"
      notify: Reload NGINX

  handlers:
    - name: Reload NGINX
      ansible.builtin.service:
        name: nginx
        state: reloaded

ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml

Ansible is declarative: describe the desired state. Modules are as idempotent as possible, so re-running produces no unwanted side effects. A shell task is often less idempotent than a purpose-built module.

Secrets

Store passwords and tokens with Ansible Vault or a secret manager. Don't commit readable secrets into inventory, playbooks or Git.

Project Approach and Checklist

Design document

scope, stakeholders and assumptions;
functional and non-functional requirements;
logical/physical diagram, address plan and naming;
alternatives and CAMPUS justification;
dependencies and failure domains;
security, backup, monitoring and management plan;
test plan with acceptance criteria;
rollback and recovery procedure.

Implementation order

network + time + naming
        ↓
identity and DNS/DHCP
        ↓
storage and virtualization
        ↓
servers, web services and endpoints
        ↓
automation
        ↓
security, monitoring, backup and tests

Minimum final tests

Domain	Test
DNS	forward, reverse, internal/external name and redundancy
Identity	normal login, MFA/CA, least privilege and recovery
Storage	read/write, permissions, performance and path/server failure
Web	correct site per hostname, HTTPS, permissions and failover
Docker	restart, volume persistence and restricted ports
Ansible	first run changes something, second run ideally reports `changed=0`
Operations	alert, backup and restore demonstrably tested

Evidence over screenshots

For each requirement, record which test was run, what result was expected and what actually happened. A configuration screen alone doesn't prove the whole service works.