Operating System Fundamentals Questions

Comprehensive knowledge of operating system concepts and practical administration across Linux, Unix, and Windows platforms. Core theoretical topics include processes and threads, process creation and termination, scheduling and context switching, synchronization and deadlock conditions, system calls, kernel versus user space, interrupt handling, memory management including virtual memory, paging and swapping, and input and output semantics including file descriptors. Practical administration and tooling expectations include file systems and permission models, user and group account management, common system utilities and commands such as grep, find, ps, and top, package management, service and process management, startup and boot processes, environment variables, shell and scripting basics, system monitoring, and performance tuning. Platform specific knowledge should cover Unix and Linux topics such as signals and signal handling, kernel modules, initialization and service management systems, and command line administration, as well as Windows topics such as the registry, service management, event logs, user account control, and graphical and command line administration tools. Security and infrastructure topics include basic system hardening, common misconfigurations, and an understanding of containerization and virtualization at the operating system level. Interview questions may probe conceptual explanations, platform comparisons, troubleshooting scenarios, or hands on problem solving.

HardSystem Design

73 practiced

Design a scalable forensic acquisition and analysis architecture for a large cloud environment containing thousands of Linux and Windows VMs plus containerized workloads. Address automated evidence collection, preservation of volatile data, use of snapshots and object storage, jurisdictional/legal constraints, integrity verification, indexing for search, and triage prioritization.

Sample Answer

**Clarify requirements & constraints**- Support thousands of Linux/Windows VMs + containers across multi-region cloud providers; preserve volatile data quickly; produce court-admissible evidence; respect jurisdictional/data residency and legal holds.

**High-level architecture**- Orchestration layer (Kubernetes + serverless functions) triggers collection- Collector agents (lightweight, signed binaries) on VMs/containers for live acquisition- Cloud-provider snapshot service + volume-level snapshots- Immutable object store (WORM-enabled) for evidence blobs and metadata- Indexing/search cluster (Elasticsearch/Opensearch) for artifacts- Chain-of-custody DB (append-only ledger; use signed records, optional blockchain anchor)- Triage/CASE management UI with risk scoring

**Automated evidence collection & volatile preservation**- On detection (SIEM/EDR alert or legal hold), orchestration triggers: - Live triage script to collect volatile data first: memory dump (LiME/WinPMEM), process list, network connections, open files, ephemeral container namespaces, kernel logs. - Agent uploads encrypted, chunked artifacts to staging area; metadata signed and time-stamped. - Simultaneously trigger storage snapshot of attached volumes; snapshot copied to forensic account/region if policy allows.- For containers, capture image layers, container runtime metadata, and host namespaces; for ephemeral pods use admission-webhook to install sidecar policy for future capture.

**Snapshots & object storage**- Use provider snapshots (fast crash-consistent) for disk state; forensically mount snapshots in isolated forensic account; export to immutable object storage (S3 with Object Lock/Governance).- Tag evidence with case-id, jurisdiction, TTL, legal hold.

**Integrity verification & chain-of-custody**- Compute SHA-256 for each artifact and for snapshot exports; store hashes in signed ledger with timestamp and operator ID.- Use hardware-backed KMS for signing keys; periodically notarize ledger root hash (e.g., anchoring to public blockchain or notary service).- Maintain human-readable chain-of-custody logs accessible to auditors.

**Indexing & search**- Extract and normalize artifacts (file metadata, registry, logs, memory strings, network indicators) into an indexed schema.- Enrich with IOC feeds, user/persona mapping, and geolocation; provide full-text search and timeline reconstruction.

**Triage prioritization**- Scoring engine combines: alert severity, asset criticality (Crown jewels), jurisdictional impact, volatility score (RAM-only evidence), and business impact.- High-score: immediate live RAM + snapshot. Medium: snapshot within SLA. Low: scheduled capture.- Provide pre-built playbooks (malware, data exfiltration, insider threat).

**Jurisdictional & legal constraints**- Policy engine enforces region-level rules: if data cannot leave jurisdiction, preserve snapshot in-region and perform remote analysis in isolated forensic VPC; obtain warrants for cross-border transfers.- Legal-team integration for hold workflows; audit trails and redaction tools for privacy.

**Operational considerations & trade-offs**- Balance speed vs forensic completeness: prioritize volatile capture first; snapshots are eventual consistent for disks.- Minimize agent footprint; use ephemeral collectors where install is restricted.- Regular validation exercises, chain-of-custody drills, and retention policy reviews.

I would implement an initial pilot on a subset of high-value assets, validate end-to-end integrity and legal acceptability with counsel, then scale automation and indexing.

HardTechnical

81 practiced

A Kubernetes cluster experienced data exfiltration through ephemeral pods. As a forensic examiner, outline a plan to collect and preserve evidence across worker nodes and control plane: how to acquire etcd snapshots safely, collect API server and kubelet audit logs, capture container image layers and persistent volumes, and correlate CNI network artifacts to build an activity timeline.

Sample Answer

**Situation & goal** As the forensic examiner I must collect and preserve volatile and persistent cluster evidence across control plane and worker nodes without contaminating sources, then correlate artifacts (etcd, audit logs, images, PVs, CNI/network) into a verified activity timeline suitable for analysis or legal use.

**Immediate preservation (chain-of-custody)** - Isolate network access to the cluster (read-only where possible); document who, when, and commands used. - Take immutable copies: compute SHA256 for every file/artifact collected and log collection metadata (host, path, user, timestamp, collection tool/version). - Work from read-only mounts or remote exports; avoid restarting kube components.

**Control plane — etcd snapshot (safe acquisition)** - Use etcdctl with the cluster's TLS client certs from the control plane user, running on a control-plane host or from an isolated forensic workstation with read-only access:

bash

export ETCDCTL_API=3
  etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
          --cert=/etc/kubernetes/pki/etcd/peer.crt \
          --key=/etc/kubernetes/pki/etcd/peer.key \
          snapshot save /forensic/etcd-snap.db

- Verify snapshot integrity via etcdctl snapshot status and compute hash; never modify running etcd data directory. - If etcd is managed (cloud), request provider's snapshot/export or use API to perform read-only export.

**Collect API server and audit logs** - Collect kube-apiserver logs (/var/log/pods or systemd journal) and the audit log files defined by --audit-log-path and audit-policy. Preserve audit-policy file and server flags. - For hosted control planes, request cloud provider audit exports or use supported APIs. - Record timestamps and timezone consistency; compute hashes.

**Worker nodes — kubelet, container runtime, images, ephemeral pods** - Gather kubelet logs (/var/log/kubelet.log or journalctl -u kubelet). - Collect container runtime metadata: containerd/CRI-O state (/var/lib/containerd, /var/lib/containers), crictl inspect for container IDs, image digests, and layers:

bash

crictl ps -a
  crictl inspect <container-id> > /forensic/<id>.json
  # export image layers (containerd)
  ctr -n k8s.io images export /forensic/image.tar <image@sha256:...>

- Capture filesystem layers and writable layer using read-only copy or export image tar; compute hashes.

**Persistent Volumes (PVs) and CSI** - Identify PV backing store (hostPath, NFS, iSCSI, cloud disk). For block volumes, snapshot at the storage layer (LVM, cloud snapshot API) to avoid mounting writes. For file shares, mount read-only or use rsync --read-only to copy. - Collect PV metadata: PV/PVC YAML, StorageClass, CSI driver logs.

**CNI and network artifacts** - Collect CNI plugin state files (/etc/cni/net.d, /var/lib/cni) and plugin logs (Calico, Flannel, Cilium). - On worker nodes capture: iptables/ipsets, conntrack entries, netstat, ss, and eBPF maps if available. Use tcpdump/pcap capture for live flows (if still active):

bash

tcpdump -i any -s 0 -w /forensic/node-eth0.pcap 'host <suspicious-ip>'

- Export Calico/Flannel flow logs, BPF logs, and kube-proxy rules. Collect node-level host NIC and bridge configs.

**Correlation & timeline building** - Normalize timestamps to UTC; use file metadata and application-level timestamps. - Key correlation pivots: pod UID, container ID, image digest, etcd object keys, API server audit requestUIDs, source IPs, and network flow 5-tuples. - Steps: - Parse audit logs for Pod create/exec/attach/execve events and record requestUID, user, source IP. - Match requestUID → etcd object changes (etcd snapshot) to find created/deleted resources. - Use container runtime metadata to map container IDs → image layers → filesystem changes. - Map network flows (pcap/conntrack) to pod IPs and source IPs from audit logs. - Produce timeline entries: timestamp, actor (user/service account/IP), action (kubectl exec, pod create), resource (pod UID, image), evidence pointer (file path, hash).

**Tools & formats** - Use etcdctl, crictl/ctr, kubectl (--raw for etcd keys if needed), tcpdump, tshark, yara, sleuthkit, Plaso/Timesketch for timeline, and immutable archive formats (ZIP/TAR with detached hash record). Export JSON artifacts where possible.

**Legal/operational notes** - Avoid modifying production state; coordinate with infra/incident response for agreed windows. Obtain authorizations. Preserve logs before rotating. Keep reproducible, scriptable collection commands and signatures.

Result: verified, hashed artifacts from etcd, audit logs, runtimes, PVs, and network captures with a correlated timeline linking API actions to container and network behavior suitable for forensic analysis and reporting.

EasyTechnical

74 practiced

For a workstation forensic intake on Windows, enumerate the primary artifact locations you would collect during initial triage (for example: registry hives, Event Logs, $MFT, Prefetch, user profiles, browser data). For each artifact explain briefly what types of evidence it commonly contains and why it matters to investigations.

MediumTechnical

76 practiced

You suspect persistence via cron on a Linux server. Describe a structured approach to locate and analyze possible cron-based persistence across the system: which files and directories to inspect, commands to run, artifacts to collect for preservation, and anti-forensic cron techniques you should be aware of.

Sample Answer

**Approach / Framework**1. Triage live system (preserve volatile state), then collect forensic artifacts for offline analysis.2. Inspect cron configuration, user crontabs, system jobs, and common hiding places. Note timestamps, ownership, and hashes.

**Commands to run (live, read-only where possible)**

bash

# record system info
uname -a; date; who -a; ps aux; netstat -tunapl

# list system cron dirs
ls -la /etc/cron* /var/spool/cron /var/spool/cron/crontabs
# per-user crontabs
crontab -l -u root
for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u $u 2>/dev/null; done

# systemd timers
systemctl list-timers --all

# examine at jobs
ls -la /var/spool/atjobs /var/spool/at
atq; atrm

**Files & locations to collect**- /etc/crontab- /etc/cron.d/*, /etc/cron.daily|hourly|weekly|monthly/*- /var/spool/cron/* and /var/spool/cron/crontabs/*- /var/log/cron, /var/log/syslog, /var/log/messages (rotate files)- /etc/inetd.conf, systemd timers (/etc/systemd/system/*.timer)- user shell histories (~/.bash_history), .ssh, PATH-wrapping scripts- collect hashes and timestamps (sha256sum), preserve with read-only image or file copy

**Artifacts to preserve**- File copies with metadata (use cp -a or rsync -a), fls/icat if imaging- Memory image (if possible) to capture in-memory cron jobs/command strings- Auditd logs, process accounting (acct), and shell history files

**Anti-forensic techniques to watch for**- Jobs installed via ephemeral processes or direct in-memory scheduling (deleted crontab entries)- Cron entries invoking scripts from writable locations or via symlink chains- Timestamp manipulation (touch), log tampering/truncation, log clearing- Jobs hidden in PATH wrappers or via LD_PRELOAD/cron env modifications- Use of Alternate Schedulers (systemd timers, at) to avoid cron

**Analysis notes**- Correlate cron timestamps with syslog/audit records and process trees.- Recover deleted crontabs from filesystem slack or journal if ext4/other supports.- Document chain-of-custody, commands run, and justification for live collection.

MediumTechnical

70 practiced

You have artifacts from a compromised Windows server and a Linux jump host. Describe a methodical approach to create a cross-platform timeline of attacker activity: what artifacts you would normalize, tools you would use to build the timeline, how to handle conflicting timestamps, and how to validate the timeline for legal defensibility.

Sample Answer

**Approach overview**- Create a single normalized timeline from preserved artifacts, correlate by UTC, document provenance and methods for legal defensibility.

**Artifacts to normalize**- Windows: EVTX (Security, System, Microsoft-Windows-Sysmon), MFT ($MFT entries), USN journal, Prefetch, ShimCache/AppCompat, Registry keys (SAM, SYSTEM for boot time, SOFTWARE run keys), Shellbags, LNK, prefetch, Winlogon, Scheduled Tasks.- Linux/jump host: /var/log/auth.log, syslog, bash/zsh history, auditd logs, systemd-journal, crontab, SSH logs, inode change times, /var/log/secure.- Network: firewall logs, proxy, IDS alerts, PCAPs with timestamps.

**Tools**- Collection: FTK Imager, dd, dc3dd (for imaging), hashes (SHA256).- Normalization & timeline building: log2timeline/Plaso to parse EVTX, MFT, shell history, systemd/journal; psort to filter; Timesketch for collaborative analysis and visualization.- Supporting: Rekall/Volatility for memory artifacts, SleuthKit for filesystem metadata, EvtxECmd/EvtxParser, Registry Explorer, audit2timeline scripts.

**Handling conflicting timestamps**- Convert all timestamps to UTC; record original timezones.- Identify reliable anchors: Windows SYSTEM boot time (from registry) and EventRecordIDs to order events; journalctl monotonic boot IDs on Linux.- Account for clock skew: compute drift via NTP/Windows Time events, correlate network device logs/PCAPs as external reference.- Prefer source-of-truth where applicable (e.g., EVTX time-created vs file system MAC times). When conflicts persist, annotate uncertainty and present alternative orders.

**Validation & legal defensibility**- Maintain chain-of-custody and write-blocked imaging; log every action and tool/version used.- Produce reproducible scripts, include hashes of evidence and derived timeline files.- Use auditable tools (Plaso/Timesketch) and export human-readable reports with raw-event references (event IDs, offsets).- Peer review and preservation of original artifacts; where interpretation affects conclusions, provide confidence levels and explain assumptions.- Retain both parsed timeline and raw event pointers so examiners/court can verify source evidence.

Unlock Full Question Bank

Get access to hundreds of Operating System Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.