Senior Systems Administrator Interview Preparation Guide - FAANG Standards

Approach

/proc/meminfo is a Linux virtual file (generated by the kernel on read, not stored on disk) with one Key: value kB pair per line; parse it into a dictionary keyed by field name rather than by fixed line position, since the kernel does not guarantee field order is stable across kernel versions, then derive used memory and percent used from the four fields the question names, treating any missing field as an explicit None rather than crashing or silently defaulting to zero.

Implementation (Python)

def parse_meminfo(text):
    """Parse /proc/meminfo text into a dict with derived used-memory fields.

    Handles missing fields (returns None for anything not present) and
    does not assume any particular line order, since /proc/meminfo's
    field order is not a guaranteed kernel ABI.
    """
    wanted = {"MemTotal", "MemFree", "Buffers", "Cached", "SwapTotal", "SwapFree"}
    values = {}
    for line in text.splitlines():
        if ":" not in line:
            continue
        key, _, rest = line.partition(":")
        key = key.strip()
        if key not in wanted:
            continue
        # Values look like "   16345600 kB"; keep the number, kB is the base unit.
        parts = rest.strip().split()
        if not parts:
            continue
        try:
            values[key] = int(parts[0])
        except ValueError:
            continue

    result = {k: values.get(k) for k in wanted}

    mem_total = result["MemTotal"]
    mem_free = result["MemFree"]
    buffers = result["Buffers"]
    cached = result["Cached"]

    if None in (mem_total, mem_free, buffers, cached):
        result["used_kb"] = None
        result["percent_used"] = None
    else:
        used = mem_total - mem_free - buffers - cached
        result["used_kb"] = used
        result["percent_used"] = round((used / mem_total) * 100, 2) if mem_total else None

    return result

Output

Ran against a normal sample (all six fields present, in a different order than the code checks them in) and a partial sample (SwapTotal/SwapFree lines entirely absent, which some kernels omit when swap is disabled):

{
  "Cached": 4271208,
  "MemFree": 6531220,
  "SwapFree": 2097148,
  "SwapTotal": 2097148,
  "Buffers": 412872,
  "MemTotal": 16336984,
  "used_kb": 5121684,
  "percent_used": 31.35
}
{
  "Cached": 4271208,
  "MemFree": 6531220,
  "SwapFree": null,
  "SwapTotal": null,
  "Buffers": 412872,
  "MemTotal": 16336984,
  "used_kb": 5121684,
  "percent_used": 31.35
}

Hand-checked: 16336984 - 6531220 - 412872 - 4271208 = 5121684, and 5121684 / 16336984 * 100 = 31.354..., which rounds to 31.35, matching the printed output; the partial-sample case correctly still computes used_kb/percent_used (they only depend on the four non-swap fields) while reporting SwapTotal/SwapFree as null since those lines were genuinely absent from the input.

Key points

Order-independence: the parser reads every line and keys results by field name (key.strip() from before the colon), so it does not matter whether MemTotal is line 1 or line 12, unlike a parser that assumes a fixed line index. Missing fields: each wanted field defaults to None via values.get(key) rather than 0, which matters because a missing SwapTotal (swap disabled) is a meaningfully different fact than SwapTotal: 0 (swap enabled with zero configured, unusual but different), and silently treating "absent" as "zero" would hide that distinction from anyone consuming the JSON. Derived fields only compute when all four required inputs are present; the arithmetic itself (MemTotal - MemFree - Buffers - Cached) uses the exact formula the question specifies, and both derived fields fall back to None together rather than partially computing on incomplete data.

Trade-offs and pitfalls

This definition of "used" memory is the classic (and slightly pessimistic) one that treats Buffers and Cached as fully reclaimable, which is close to true but not exact on modern kernels (some cached memory is not trivially reclaimable, and there is a more accurate MemAvailable field the kernel exposes directly for this purpose since Linux 3.14). For a production monitoring script, prefer reading MemAvailable directly over recomputing this classic formula, since the kernel's own estimate accounts for reclaim nuances this simple subtraction does not; the formula in this answer follows the question's explicit specification. All units here stay in kB (the native unit /proc/meminfo reports) throughout, converting to MB or GB and mixing units partway through the calculation is a common source of off-by-1024x bugs in scripts like this.

Direct answer

The Print Spooler (the spoolsv.exe service, which accepts print jobs, queues them and passes them to printers) is a long-running Windows service that loads printer driver code inside its own process, so a faulty driver can take the whole service down. Treat it as a controlled experiment with one variable. Line up the crash timeline against the driver change, find which queues use the new driver, switch one test queue back to the previous driver and see whether the crashes stop. Once the cause is confirmed, move every queue back to the last known good driver, restart the Spooler service, remove the bad driver, and put a gate in front of future driver changes so a new driver proves itself somewhere harmless first.

Confirm the driver is the cause (ordered checks)

1. Timeline. Write down when the driver update was applied and when the first crash happened. If crashes started before the update, stop: the driver is not the cause. Crash records live in the Application event log; the entry that records the crash names the faulting module. A vendor driver DLL (dynamic-link library, a code module loaded by a program) as the faulting module, rather than a Windows component, is strong evidence. Pull the records with:

Get-WinEvent -LogName Application -MaxEvents 500 |
    Where-Object { $_.LevelDisplayName -eq 'Error' -and $_.Message -match 'spool' } |
    Select-Object TimeCreated, Id, Message -First 10

A crash is logged as an Application Error event with ID 1000. The text below is illustrative (the module name and numbers are made up), but the field names are the standard ones:

Log Name:      Application
Source:        Application Error
Event ID:      1000
Level:         Error
Faulting application name: spoolsv.exe, version: 10.0.20348.1, time stamp: 0x6531a2c4
Faulting module name: CONTOSOPCL6.DLL, version: 9.2.0.0, time stamp: 0x66f0b1d2
Exception code: 0xc0000005
Faulting application path: C:\Windows\System32\spoolsv.exe
Faulting module path: C:\Windows\System32\spool\DRIVERS\x64\3\CONTOSOPCL6.DLL

How to read it: the faulting application is the process that died (here the Spooler, so the crash is in the print service). The faulting module is the specific code inside that process that was running when it died, and its path under spool\DRIVERS shows it is a printer driver, not Windows itself. The exception code 0xc0000005 is an access violation, a program touching memory it does not own, which is a typical symptom of a buggy driver. If the faulting module were a Windows file such as ntdll.dll, the evidence would point away from the driver. In the command's output the Message column holds this same text, cut to the width of the window.

2. Scope. List which queues use the suspect driver: Get-Printer | Where-Object DriverName -eq 'Contoso Universal PCL6 v9.2' | Select-Object Name, DriverName. A queue is a named printer on the server, and each queue uses one driver. Illustrative output:

Name         DriverName
----         ----------
Floor2-Color Contoso Universal PCL6 v9.2
Floor3-Mono  Contoso Universal PCL6 v9.2

Queues using another driver version do not appear, so those are your control group. Crashes that follow the driver, and only its queues, point to it. If every queue crashes the service regardless of driver, look elsewhere: a port monitor (the component that sends a job's data to the printer's network or local port), a print processor (the component that converts a job into the form the driver expects) or a recent Windows update.
3. Reproduce on demand. Send a test job to one queue that uses the suspect driver and watch whether the Spooler service stops or restarts. A crash you can trigger is far more convincing than a correlation.
4. A/B test. Move that one test queue to the previous driver with Set-Printer -Name <queue> -DriverName <previous driver> and send the same job. If the crash disappears with only the driver changed, you have a causal result, not just a coincidence.
5. Corroborate. Check the vendor's release notes and known issues for the version, and, if possible, reproduce on a lab clone of the print server before touching production further.

Restore printing quickly

The previous driver package must still be available: either still installed (check with Get-PrinterDriver) or in your saved driver packages (installable with Add-PrinterDriver -Name <driver> -InfPath <path to the INF file> (an INF file is the driver's setup information file); Microsoft documents -InfPath as the path of the INF file in the driver store, so make sure the saved package has been added to the driver store first). Then:

$bad  = 'Contoso Universal PCL6 v9.2'       # driver installed by the change that preceded the crashes
$good = 'Contoso Universal PCL6 v9.1'       # previous package, kept in the driver store

# Which queues use the suspect driver?
Get-Printer | Where-Object DriverName -eq $bad | Select-Object Name, DriverName

# Move them back one by one, restart the spooler, then remove the bad driver.
Get-Printer | Where-Object DriverName -eq $bad | ForEach-Object { Set-Printer -Name $_.Name -DriverName $good }
Restart-Service -Name Spooler
Remove-PrinterDriver -Name $bad -RemoveFromDriverStore

Run this on the print server in an elevated session (these cmdlets need administrator credentials). The script was parse-checked and its cmdlets and parameters checked against Microsoft Learn; the PrintManagement cmdlets exist only on Windows, so it was not executed. Notes:

• The Set-Printer loop is the fast path because it restores service as soon as each queue changes. Remove the driver last so no queue ever points at a driver that is missing. -RemoveFromDriverStore also removes it from the driver store (the protected area where Windows keeps staged driver packages), so it cannot be picked again by mistake.
• If users cannot wait for the rollback, redirect them to a spare print server or queue while you work, and say so in the status message.
• Check the result with a test page from a client, then watch the Application log for repeat crashes through a full working day.

Keep it from happening again

A crash loop is also a good moment to ask whether the server needs that vendor driver at all. If a simpler driver prints the same documents, retiring the vendor driver removes the failure for good.

Pitfalls

• Do not remove the driver first: if you uninstall before moving the queues, you create a second outage.
• Changing the driver and restarting the service together hides which fixed it. In the A/B test change only the driver.
• Rolling back one queue is not proof for the others if they use a different driver version; repeat the check per driver.

Direct answer

Don't treat 1TB/day as one blob: split it by log class, keep security logs at full fidelity for a long time because you can't predict when you'll need them, and be aggressive about compressing, shrinking the searchable ("hot") window, and sampling everything else. The cost reduction mostly comes from moving bytes out of expensive, instantly-searchable storage into cheap archival storage sooner, not from deleting data outright.

Structured elaboration

Three levers do almost all the work, and they compose:

1. Compression. Switching from raw text to a compressed columnar format (a column-oriented file format, meaning it stores each field together across rows rather than row-by-row, e.g. Parquet with Snappy or gzip) typically shrinks log data several-fold, because timestamps, service names, and log levels repeat constantly and compress well. This is free fidelity: every original field is still there, just packed tighter.
2. Tiered storage. Keep a short "hot" window (fully indexed, fast to search) and move everything older into a cold/archive storage class that costs an order of magnitude less per gigabyte but takes longer to retrieve (minutes to hours instead of seconds). The hot window should match how far back people actually search during a live incident, not how far back you need to retain data.
3. Sampling and selective indexing for low-value classes. Debug logs are the biggest volume and the least likely to matter weeks later; keep errors/exceptions at full fidelity but sample routine debug chatter (e.g. 5-10%) once it's past the first few days. Index only the fields you actually query on, not every field in every log line.

Security logs get none of the shrinking: the whole point of the policy is that you don't know today which security event will matter in six weeks, so fidelity there is non-negotiable, and only the storage tier (hot vs. cold) changes over time, not the completeness of the data.

Worked example (concrete policy by class)

I modeled the cost impact with an illustrative unit-cost model (hot storage = 1 unit per GB-month, cold/archive = 0.1 units per GB-month, a directionally realistic 10x ratio between instantly-queryable and archival object storage, not a specific vendor's price list) against a 1,000 GB/day baseline split 10% security / 40% access / 50% debug, with today's baseline being everything flat, uncompressed, and hot for 90 days:

HOT_UNIT, COLD_UNIT, COMPRESSION = 1.0, 0.1, 3.0
classes = {
    "security": dict(daily_gb=100, hot_days=30, cold_days=335, sample=1.00),
    "access":   dict(daily_gb=400, hot_days=30, cold_days=60,  sample=0.10),
    "debug":    dict(daily_gb=500, hot_days=7,  cold_days=23,  sample=0.05),
}
baseline_days = 90

def new_cost(c):
    compressed = c["daily_gb"] / COMPRESSION
    return compressed * c["hot_days"] * HOT_UNIT + compressed * c["sample"] * c["cold_days"] * COLD_UNIT

def baseline_cost(c):
    return c["daily_gb"] * baseline_days * HOT_UNIT

for name, c in classes.items():
    b, n = baseline_cost(c), new_cost(c)
    print(f"{name:<10} baseline={b:>7.0f}  new={n:>7.0f}  reduction={((b-n)/b*100):5.1f}%")

Output:

security   baseline=   9000  new=   2117  reduction= 76.5%
access     baseline=  36000  new=   4080  reduction= 88.7%
debug      baseline=  45000  new=   1186  reduction= 97.4%

Combined, that's a 91.8% reduction in the cost model (90,000 to 7,383 units), comfortably past the 60% target even for the untouched-fidelity security class, because moving bytes to a 10x-cheaper tier does most of the work by itself. If 90%+ feels too aggressive for a real environment (e.g. you actually need more than 30 days of hot access-log search), you have headroom to extend the hot windows and still land above 60%; the model makes that trade-off a single parameter change rather than a re-architecture.

Multi-tenant extension

If this is a multi-tenant product rather than a single environment, the same three-tier structure still applies, but retention windows and isolation now vary per customer SLA tier instead of per log class alone: a Gold-tier customer's logs might warrant a dedicated index (not just a shared index with a tenant_id filter) and a dedicated encryption key so their data can be cryptographically deleted or exported independently, while a Bronze-tier customer's logs live in a shared, field-isolated index with a shared key. That per-tenant key strategy is also what makes an emergency eDiscovery (electronic discovery, producing data for litigation or a regulator) export tractable: you can export and later destroy one tenant's key without touching anyone else's data.

Trade-offs & pitfalls

• Cold storage is cheap per gigabyte but not free to use: rehydrating archived data for an investigation takes time and sometimes direct retrieval cost, so "we kept everything" is only true in a useful sense if you also budget for and rehearse rehydration.
• Sampling debug logs means some incidents literally have less evidence than others by design; make sure whoever owns incident response knows sampling exists and isn't surprised mid-investigation that 95% of a trace is missing.
• A retention policy that isn't automated (relying on someone to manually delete or tier data) tends to silently regress back toward "keep everything hot forever" within a few months; the lifecycle transitions need to be enforced by the storage system itself, not by a runbook.

Direct answer
When a client keeps retransmitting its SYN and never sends the final ACK (while the server's SYN-ACK is only retransmitted once before the connection times out), the most likely causes are that the client's connect timeout hasn't fired yet, that something between the two hosts is dropping the ACK specifically (an asymmetric path or a stateful device confused about direction), or that the client-side application itself never actually attempted the ACK due to a bug. A different failure shape, the server sends SYN-ACK and the client immediately sends RST, points to a different family of causes entirely: the client rejecting the connection outright.

Structured elaboration
For the "client retransmits SYN, no final ACK" pattern, work through causes in order of likelihood:

1. Asymmetric routing dropping only the return-to-forward-direction ACK path. If the SYN-ACK reaches the client (we know it does, since the client keeps retransmitting new SYNs rather than giving up, meaning it IS getting a response of some kind) but the client's ACK can't get back to the server along some other path, a stateful firewall or NAT device on that asymmetric path may be dropping the ACK because it doesn't recognize the connection's state in that direction.
2. A middlebox is rewriting or dropping specific TCP options in the SYN-ACK that the client's stack doesn't handle gracefully, causing it to silently discard the SYN-ACK and retry instead of ACKing it.
3. Client-side firewall or security policy is specifically blocking outbound ACKs to that destination while permitting the outbound SYNs, an unusual but real misconfiguration.
4. MTU (Maximum Transmission Unit)-related silent packet loss on the SYN-ACK's return path if it happens to be an unusually large segment (rare for a SYN-ACK specifically, since it typically carries little payload, but worth ruling out if other symptoms point that way).

For the different shape (SYN-ACK followed by an IMMEDIATE client RST): this usually means the client-side application decided, upon establishing the connection, that it doesn't actually want it, for example an application-level timeout that already expired while the handshake was in flight, a client-side connection pool that raced two connection attempts and is aborting the loser, or a security tool on the client actively resetting connections that don't match an expected certificate or policy.

Worked example
To distinguish these hypotheses in practice, compare timestamps and evidence on BOTH ends: if the server's capture shows the SYN-ACK leaving on time but the client's capture never shows it arriving, the problem is in the path (asymmetric routing, a device eating it). If the client's capture shows the SYN-ACK arriving cleanly but no ACK is ever generated by the client's own stack, the bug is on the client host itself (application logic, local firewall) rather than the network path.

Trade-offs & pitfalls
A common mistake is assuming a stuck handshake is always a network problem; a client-side timeout race (the application gives up right as the handshake completes) produces an outwardly identical-looking symptom to a network drop and is only distinguishable by comparing what each side's own capture actually shows, not by reasoning about the network path alone.

Direct answer

A good handoff transfers three things: current state (what's broken or at risk right now), context (what's already been tried and what's scheduled), and ownership (who is accountable for what next), and it has to be verifiable rather than a status dump, meaning the incoming engineer confirms they can actually act (they have access, they can reproduce the symptom, they understand the next step) before the outgoing engineer is done.

Structured elaboration

Handoff checklist, in order:

1. Status snapshot: current owner and contact, "all green" or a one-line count of active incidents/unstable services.
2. Active incidents: for each, severity, start time, impact, current owner, and a link to the ticket, not a re-explanation from scratch.
3. Recent alert history: what's fired in the last several hours, and specifically any alert that's been flapping, since that's exactly what an incoming responder will misdiagnose as new if nobody flags it.
4. Ongoing mitigations and runbook links: what's been tried, what's blocked, and the specific next action, with a link to the runbook rather than a paraphrase of it.
5. Scheduled changes: upcoming deploys, migrations, or maintenance windows during the next shift, with rollback plans linked.
6. Degraded-but-not-incident services: anything running hot or close to a threshold that isn't paging yet.
7. Access and tooling: pager rotation, incident channel, dashboards, runbook repo, and an explicit note if the incoming engineer is missing access to any of them.
8. Explicit confirmation, not implied: "Can you access the dashboards I linked? Can you reproduce the symptom in incident #123? Do you agree you own the DB migration follow-up?" Each gets an actual yes, not a thumbs-up emoji on a wall of text.

Making it lightweight (chatops mechanics). For day-to-day handoffs without an active incident, a short structured chat message beats a long document nobody reads: header (shift window, owner, escalation contact), one-line status, action items with owners, upcoming risks, and links. Anything in that message that turns out to matter beyond the shift boundary (a workaround that becomes permanent, a gotcha that will recur) gets tagged for follow-up and folded into the actual runbook within a day or two, so the team's durable documentation doesn't quietly live and die in chat history.

Automating the tedious part. The status snapshot, active-incident list, and recent-alert-history sections don't need to be typed by hand: a handoff template can be pre-populated from the monitoring and paging systems (current alert state, open incident IDs, last-deploy timestamp) so the outgoing engineer is editing and confirming pre-filled facts rather than writing a report from a blank page. That reduces both the time cost of handoff and the chance that something gets left out because the outgoing engineer forgot it existed.

Worked example

Friday, 6pm, end of a shift. One active Sev2 incident (checkout latency degraded for a subset of EU traffic, mitigation in progress: a feature flag was flipped to route around a slow dependency, error rate has dropped but root cause isn't fixed), and a database migration scheduled for 2am that night. The outgoing engineer posts:

Handoff | Fri 18:00-Sat 02:00 UTC
Owner: @outgoing -> @incoming | Escalation: @oncall-lead
Status: Degraded (checkout latency, EU) -> incident #482, mitigated not resolved
Action items:
 - Watch checkout error rate; if it climbs above 2% again, re-check the feature flag is still on
 - DB migration at 02:00 UTC (runbook: <link>, rollback: <link>) - I'll be asleep, this is yours
Risks: migration touches the same table implicated in incident #482; if latency spikes right after, check the migration first
Links: <dashboard> <incident #482> <migration runbook>

The incoming engineer confirms: dashboard access works, they can see incident #482's current state, and they explicitly acknowledge owning the migration watch. That confirmation, not the message itself, is what makes the handoff complete.

Trade-offs and pitfalls

• Pitfall: a "read the ticket" handoff with no verification step lets the incoming responder discover gaps at 3am instead of at 6pm when the person with context is still reachable.
• Pitfall: too much ceremony (a mandatory 45-minute call every single handoff) burns out the outgoing engineer and makes people avoid going on-call at all; reserve synchronous overlap for when there's an active Sev1/Sev2, not as the default for a quiet shift.
• Trade-off: synchronous handoff transfers tacit knowledge best but costs both people's time; async structured notes are cheaper but only as good as their template and discipline. The right default is async-by-default, with synchronous overlap triggered automatically whenever an incident is still open at shift boundary.

Direct answer. Use the bash builtin getopts in a while loop with an option string such as ':ho:r:'. A letter followed by a colon takes a value, which arrives in $OPTARG. After the loop, shift $((OPTIND - 1)) removes the parsed options so the positional argument is $1. The leading colon puts getopts in silent mode so you print the error messages yourself. Check that the required options and the positional exist, and on any problem print a message and usage to stderr and exit non-zero (2 by convention for a usage error). -h prints usage to stdout and exits 0.

Script

A few pieces of shell syntax appear in it. ${0##*/} takes $0 (the path the script was started with) and strips everything up to the last /, leaving just the file name. cat <<EOF ... EOF is a here-document: it feeds the lines between the markers to cat as input, a convenient way to print several lines of text. [[ $retries =~ ^[0-9]+$ ]] tests a value against a regular expression (here: one or more digits and nothing else). (( $# == 1 )) is an arithmetic test, and $# is the number of positional arguments, meaning the words left after the options. exit 2 stops the script with status 2.

This script takes -o OUTDIR and -r RETRIES, each with a value, and exactly one URL.

#!/usr/bin/env bash
# usage: fetch.sh -o OUTDIR -r RETRIES [-h] URL
set -euo pipefail

prog=${0##*/}
usage() {
  cat <<EOF
Usage: $prog -o OUTDIR -r RETRIES URL
  -o OUTDIR   directory to save into (required)
  -r RETRIES  number of retries, a non-negative integer (required)
  -h          show this help and exit 0
EOF
}
die() { echo "$prog: $*" >&2; usage >&2; exit 2; }   # 2 = usage error

outdir='' retries=''
while getopts ':ho:r:' opt; do        # leading ':' = we report errors ourselves
  case $opt in
    h) usage; exit 0 ;;
    o) outdir=$OPTARG ;;
    r) retries=$OPTARG ;;
    :) die "option -$OPTARG needs a value" ;;
    \?) die "unknown option -$OPTARG" ;;
  esac
done
shift $((OPTIND - 1))                 # drop the parsed options, leave positionals

[[ -n $outdir ]]  || die "missing required option -o"
[[ -n $retries ]] || die "missing required option -r"
[[ $retries =~ ^[0-9]+$ ]] || die "-r must be a non-negative integer, got '$retries'"
(( $# == 1 )) || die "expected exactly one URL, got $#"
url=$1

echo "url=$url outdir=$outdir retries=$retries"

How it works

• Option string ':ho:r:'. The leading : selects silent error handling. h takes no value, o: and r: do.
• Silent-mode cases. A missing value arrives as opt=: with the option letter in $OPTARG. An unrecognised option arrives as opt=?. The ? is a glob character so it is escaped (\?) in the case.
• OPTIND. It holds the index of the next argument to process. shift $((OPTIND - 1)) leaves only the positionals.
• Validation after parsing. Required options are checked afterwards, because getopts has no notion of "required". -r is validated with a regular expression so -r x is rejected with a clear message.
• Exit codes. Help is exit 0 and goes to stdout, so fetch.sh -h | less works. Errors go to stderr and exit 2.
• Quoting. Every expansion in the script is quoted, so a value containing spaces survives inside the script. The caller must quote it too, because the shell splits the command line into words before the script starts (see the transcript below).

Running it

Each block shows the command as typed, the first line it printed, and its exit status (the full usage text follows the first line on errors). The second command quotes the two values that contain spaces, and the third shows the same command without those quotes:

$ fetch.sh -o /data -r 3 https://example.com/a
  url=https://example.com/a outdir=/data retries=3
  exit=0
$ fetch.sh -r 3 -o '/my data' 'https://example.com/a b'
  url=https://example.com/a b outdir=/my data retries=3
  exit=0
$ fetch.sh -r 3 -o /my data https://example.com/a b
  fetch.sh: expected exactly one URL, got 3
  exit=2
$ fetch.sh -h
  Usage: fetch.sh -o OUTDIR -r RETRIES URL
  exit=0
$ fetch.sh -o /data https://example.com/a
  fetch.sh: missing required option -r
  exit=2
$ fetch.sh -o /data -r
  fetch.sh: option -r needs a value
  exit=2
$ fetch.sh -o /data -r x https://example.com/a
  fetch.sh: -r must be a non-negative integer, got 'x'
  exit=2
$ fetch.sh -x -o /data -r 3 https://example.com/a
  fetch.sh: unknown option -x
  exit=2
$ fetch.sh -o /data -r 3
  fetch.sh: expected exactly one URL, got 0
  exit=2
$ fetch.sh -o /data -r 3 -- -weird-url
  url=-weird-url outdir=/data retries=3
  exit=0
$ fetch.sh https://example.com/a -o /data -r 3
  fetch.sh: missing required option -o
  exit=2

Reading the quoting pair: with quotes, the shell hands the script one word for /my data and one for the URL, so getopts sees -o '/my data' and a single positional. Without quotes the shell splits on spaces first, so /my becomes the value of -o and data, the URL and b are three positionals, which the (( $# == 1 )) check rejects with exit 2.

Trade-offs and pitfalls

• getopts stops at the first non-option argument. Options placed after the URL, as in the last case, are not parsed (here -o was reported missing). Use -- to pass an argument that begins with a dash, as shown with -weird-url.
• It supports only single-letter options. Long options (--output) need a hand-written while/case loop over $1 with shift, or the external GNU getopt (not available on every system, and its use needs care).
• Without the leading colon, getopts prints its own message in its own format and you lose control of the wording.
• Count the positionals after the shift. Use (( $# == 1 )) rather than testing $1 alone, so extra arguments are an error too.
• Keep usage in a function so the help text and the error path print the same thing.
• Under set -u, initialise the variables the options fill in (here outdir=''), otherwise a missing option fails with unbound variable instead of your own message.

Direct answer

Backpressure is a flow-control pattern where a slower downstream component signals upstream callers to slow down or stop, instead of the upstream just continuing to send work that piles up. It matters because unchecked traffic into a struggling dependency exhausts memory, connection pools, or threads on the way there, turning one slow dependency into a full outage for everything queued behind it.

Techniques

Worked example: token bucket under a spike

Take a downstream dependency that can sustainably handle 100 requests per second. A rate limiter is configured as a token bucket with capacity C = 100 and refill rate r = 100 tokens per second:

Now a spike arrives: 150 requests per second sustained for 3 seconds (450 requests total), starting with a full bucket:

Totals across the 3-second spike:

The downstream dependency sees exactly its sustainable rate of 100 requests per second throughout the spike, never more, because the bucket structurally cannot admit faster than it refills. The 150 shed requests get a 429 with a Retry-After header rather than being queued indefinitely or silently dropped, so well-behaved clients know to back off and retry rather than hammering the endpoint again immediately.

Trade-offs & pitfalls

Backpressure protects the downstream dependency but pushes the cost of that protection somewhere: either onto the caller (which now sees rejections and must handle retries) or onto memory (if you queue instead of reject, you delay the problem rather than solving it, and an unbounded queue just moves the resource exhaustion from the downstream service to the queue itself). Priority-based shedding requires the system to actually know which requests are high-value at the point of decision, which is often harder than it sounds, an anonymous or low-tier request during a spike might still be a paying customer's checkout attempt if request metadata isn't wired through correctly. The most common mistake is applying backpressure only at one layer (say, the API gateway) while an internal service-to-service call further downstream has no equivalent protection, so the spike still reaches and overwhelms whatever sits behind that unprotected hop.

Direct answer

I do not rank 300 patches by CVSS score (the Common Vulnerability Scoring System, a 0 to 10 measure of how severe a flaw is in the abstract). I rank them by how likely they are to hurt us this month: first evidence the flaw is being exploited, then whether the vulnerable thing is reachable by an attacker, then how much the host matters, then what already protects it, and last the cost and risk of the patch itself. That gives four tiers. The top tiers fill the capacity; everything else is deferred on purpose, with an owner and a date, and the ranking is re-run weekly because exploitation news changes it.

Signals

A CVE (Common Vulnerabilities and Exposures) identifier is just the public name of one flaw; one patch commonly fixes many CVEs, so I rank patches by the worst CVE they contain.

Tier rules

The numeric cut-off for "high EPSS" is a team decision that should be written down and revisited; one defensible way is to set it from how many patches you can absorb in a cycle rather than from a magic number.

Worked example with the numbers shown

Month backlog: 300 patches across Windows and Linux. Triage with the rules above gives:

Capacity this month, from the team's test and reboot-window budget: 60 patches. Illustrative derivation: the test lab can validate 15 patches a week, and the month has 4 weeks, so 15 x 4 = 60 patches can be tested. There are 4 reboot windows a month and each can absorb 25 patches, so 4 x 25 = 100 can be rebooted. Capacity is the smaller of the two limits, which is 60, set by testing. P0 and P1 together are 12 + 41 = 53, which fills 53 of the 60 slots. The remaining 7 go to the top of P2, chosen by asset value (domain controllers and identity servers first). Deferred: 97 - 7 = 90 P2 patches plus 150 P3 patches = 240, and 60 + 240 = 300. Each deferred patch has a recorded reason, an owner and a review date, and the 240 are re-scored every week. If a P2 CVE lands on the KEV list on the 12th, it is re-tiered that day instead of waiting for the next cycle: P0 if it sits on an internet-facing or critical host, otherwise P1 under the rules above (known exploited on internal hosts).

Two illustrative patches show how the signals combine. Patch A fixes a remote code execution flaw in a web server component. It is on the KEV list (exploited now) and the component is installed on an internet-facing host, so it meets both halves of the P0 rule (known exploited, and present on an internet-facing host), and CVSS and EPSS are not needed to decide. Patch B fixes a privilege escalation flaw in a desktop library. It has a CVSS score of 8.8 (high), is not on the KEV list, has a low EPSS probability (say 0.02, a 2 percent chance of exploitation in the next 30 days), and is installed only on internal, non-critical hosts, behind a segment boundary with no route from the internet. No P0 or P1 rule matches, because it is not known exploited and it is not on an internet-facing or critical host. The P2 rule does (high CVSS on internal, non-critical hosts), so it is P2, and the segmentation (a compensating control) places it behind other P2 patches for the leftover slots, which are chosen by asset value; otherwise it waits for the next cycle.

Notice that capacity is the number of patches the team can safely test and reboot, not the number the tools can install. Grouping patches that need the same reboot, for example a kernel and its libraries together on Linux or the monthly cumulative update on Windows, raises effective capacity without raising risk.

Mixed Windows and Linux

Do not keep two ranked lists. Put both into one backlog with the same tier rules, then split by operating system only at scheduling time because the mechanics differ: Windows patches arrive in a monthly cumulative bundle, so you choose rings and timing, whereas Linux fixes arrive per package and can be selected individually, so you can pull a single critical package forward. Third-party applications on either platform go into the same ranking.

Pitfalls

• Sorting by CVSS alone sends the team after unexploited "critical" flaws while an exploited "medium" stays open.
• Ranking by CVE count per patch rewards bundles, not risk.
• Treating deferred items as accepted: deferral without an owner and date is how a backlog becomes permanent.
• Trusting scanner severity for a flaw in a component that is installed but never loaded; check reachability before spending an emergency slot.
• Using EPSS as an on/off switch. It is a probability, so a low score reduces priority but does not make a KEV-listed flaw safe.

Direct answer

Both paths, the Active Directory Users and Computers (ADUC) graphical console and PowerShell, do the same four things in the same order: create the account directly inside the Contractors organizational unit (OU) rather than somewhere else and moving it later, set a temporary password with the "user must change password at next logon" flag so the administrator's password is never the contractor's real working credential, enable the account, and finally add it to the existing security group that already carries the needed file-share access, rather than attaching permissions to the individual account.

Structured elaboration

Why create the account directly in the Contractors OU, rather than create it elsewhere and move it. An account's OU location determines which Group Policy Objects (GPOs) apply to it. If the account is briefly created in a default location and moved afterward, it inherits whatever policy applies there first, even if only for a few minutes, which for a contractor OU commonly carries stricter baselines (tighter logon-hour restrictions, contractor-specific security settings) than the default. Setting the location at creation time avoids that gap entirely.

Why the password flag matters. "User must change password at next logon" forces the contractor to set their own password on first sign-in, so the temporary value the administrator typed never becomes the account's actual long-term credential, limiting the window in which two people know the same password to essentially zero.

Why group membership, not a direct permission grant. Adding the account to the security group that already has the file-share access (rather than granting the contractor's individual account a permission entry on the share) keeps access removal simple at offboarding: removing group membership, or disabling the account outright, is enough, instead of hunting down a one-off access control entry tied to a single person on a shared resource somewhere.

Why the order matters. Doing group membership last, after the account is created, correctly placed, and has its real password policy configured, avoids a brief window where an account already has file-share access but is still sitting on a default or predictable password.

Worked example

ADUC steps:

1. Open Active Directory Users and Computers (dsa.msc).
2. Expand the domain, right-click the "Contractors" OU, choose New, then User.
3. Enter the first name, last name, and user logon name (the sAMAccountName), for example j.contractor.
4. Click Next, enter the initial temporary password, check "User must change password at next logon," leave "Account is disabled" unchecked so the account is active, click Next, then Finish.
5. Confirm the account now appears under the Contractors OU (it will, since it was created there directly).
6. Locate the existing security group that grants the required file-share access, for example "FileShare-ProjectX-ReadOnly," open its Properties, go to the Members tab, click Add, type the contractor's account name, and click OK.

Equivalent PowerShell (ActiveDirectory module):

$SecurePassword = ConvertTo-SecureString "TempP@ssw0rd!23" -AsPlainText -Force

New-ADUser -Name "J. Contractor" `
    -SamAccountName "j.contractor" `
    -UserPrincipalName "j.contractor@corp.example.com" `
    -Path "OU=Contractors,DC=corp,DC=example,DC=com" `
    -AccountPassword $SecurePassword `
    -ChangePasswordAtLogon $true `
    -Enabled $true

Add-ADGroupMember -Identity "FileShare-ProjectX-ReadOnly" -Members "j.contractor"

-Path sets the organizational unit (as a distinguished name) at the moment of creation, which is what avoids the brief-wrong-policy window described above. -AccountPassword takes a SecureString, which is why the plaintext value is first passed through ConvertTo-SecureString; the plaintext literal shown here is only for walkthrough clarity, and in a real rollout the value would be a randomly generated password delivered out of band, never typed into a script. -ChangePasswordAtLogon $true is the exact scripted equivalent of the ADUC checkbox. -Enabled $true is easy to forget: New-ADUser creates the account in a disabled state unless this switch is explicitly set, which otherwise leaves a silently unusable account and a confused first-day helpdesk ticket. Add-ADGroupMember is run last, after the account already has its real password policy and is enabled, so it is never in a state where it holds file-share access without also having its password properly configured.

Trade-offs and pitfalls

The most direct pitfall in the script above is illustrative only: hard-coding a plaintext password, even a temporary one, into a script or ticket is bad practice in a real rollout; the password should be generated randomly and handed to the contractor through an out-of-band channel (verbally, a sealed one-time link, a password manager share), never stored in a script file, ticketing system, or chat log in plaintext. A second common mistake is omitting -Enabled $true and assuming the account works once created, since New-ADUser defaults to a disabled account without it. A third is creating the account somewhere other than the Contractors OU and moving it afterward with Move-ADObject; this works, but it is an extra step that reintroduces the brief-wrong-policy window the direct-creation approach avoids for free. A fourth, easy to overlook because it's not explicit in this walkthrough's steps, is assuming the target group's own permissions on the file share are already correctly scoped to exactly "read-only on this project" before adding the contractor to it; adding someone to a group only grants what that group's own access control entry actually says, so the group's effective permissions are worth a quick check the first time this workflow is used against it, rather than assuming its name matches its actual grant. Finally, a contractor account with no expiration date relies entirely on someone remembering to disable it at contract end; setting -AccountExpirationDate at creation time is a natural hardening step beyond the letter of this question that turns offboarding into something that happens automatically rather than something that depends on a person not forgetting.

Clarify constraints (assumptions)

• Mission-critical app with mixed VMs + databases; steady-state writes ~50 MB/min, peak bursts higher. RPO ≤15m, RTO ≤30m. Must span Azure and on‑prem.

High-level architecture

• Primary: on‑prem datacenter (or Azure) ; Secondary: Azure region.
• Use Azure Site Recovery (ASR) to replicate VMs to Azure for compute/OS/app state.
• Databases: native DB replication (see below).
• Storage: Azure Blob / Files + on‑prem NAS with Azure File Sync for file data.
• Orchestrated failover via ASR recovery plans + Azure Automation runbooks triggered by DNS failover.

Database replication approach

• For SQL Server: use Always On Availability Groups when latency allows (synchronous on LAN); across WAN use asynchronous AG or transactional replication with log shipping cadence ≤5–10 minutes to meet RPO 15m.
• For PostgreSQL/MySQL: use logical replication or async streaming replication with WAL shipping; tune wal_sender/wal_receiver and checkpoint settings.
• Ensure secondary is readable for reporting; maintain regular log backups and tail-log capture to minimize data loss.
• Use application-level idempotency and queueing for critical writes.

Storage replication

• Block/VM disks: ASR replicates VM disks to Azure incrementally.
• File shares: Azure File Sync caches on‑prem; snapshot schedule + geo-redundant storage (GRS) for blob durability.
• Object storage: write to Azure Blob with RA-GRS if primary is Azure; if primary is on‑prem, use AzCopy/Blobfuse + scheduled incremental sync and write-through for critical files.

DNS failover & health checks

• Use Azure Traffic Manager or external DNS supporting active/passive with low TTL (30–60s) and priority/weighted failover.
• Health probes at multiple levels:
  • L4: TCP port probe to load balancer
  • L7: HTTP(S) readiness endpoint returning 200 and checking DB connectivity and queue length
  • Custom heartbeat service reporting last processed sequence id
• Automate failover: health probe fails → runbook triggers ASR failover → update DNS (via API) → verify health checks before routing traffic.

Handling in‑flight transactions

• Use durable queues (Kafka/RabbitMQ/Service Bus) with persistent storage; replicate queue metadata/state or drain to secondary.
• On failover, replay uncommitted transactions from WAL/log-shipping tail and queued messages.
• Implement idempotent operations and client retry with exponential backoff; include transaction identifiers to dedupe.

Network bandwidth needs

• Estimate using change-rate formula:
  • required_bandwidth ≈ (avg_change_rate_bytes_per_minute / 60) * safety_factor
• Example: 50 MB/min → ≈ 0.67 MB/s ≈ 5.4 Mbps. With peaks and overhead use 50–100 Mbps dedicated link for comfort and log shipping; enable compression and WAN acceleration.
• For initial seeding or large failover, need burst capacity (multi-Gbps or ship seed).

Cost & trade-offs

• Synchronous cross‑site replication (zero RPO) is costly and latency-sensitive — not feasible cross‑WAN.
• Asynchronous log-shipping + frequent checkpoints meets RPO15 at moderate cost.
• ASR + Azure VMs incur compute and storage standby costs; cold standby reduces cost but increases RTO.
• Active/passive in Azure + read-only replicas reduces RTO but increases ongoing costs.
• Use automation to test failover regularly (DR run costs) — include runbook and engineers’ time.

Operational recommendations

• Regular DR drills, failover/failback playbooks, monitoring, and SLA-runbook owners.
• Test in-flight transaction replay and application idempotency.
• Monitor replication lag, network utilization, and storage snapshot health.