Microsoft Systems Administrator (Entry Level) - Comprehensive Interview Preparation Guide

Direct answer

The sequence is the same regardless of filesystem: initialize the new disk as an LVM (Logical Volume Manager) physical volume, add it to the existing volume group, extend the logical volume into the newly available space, then grow the filesystem to fill the larger volume, all of which can happen while the filesystem stays mounted. The one real difference between ext4 and XFS shows up at the very last step: resize2fs (ext4) takes the block device directly and can grow or, offline only, shrink; xfs_growfs (XFS) takes the mount point, not the device, and can only ever grow, never shrink, for the life of that filesystem.

The steps, concretely

Given an existing volume group vgdata with a logical volume lvapp mounted at /data, and a new disk /dev/sdb just attached to the host:

pvcreate /dev/sdb
vgextend vgdata /dev/sdb
lvextend -L +100G /dev/vgdata/lvapp

pvcreate writes LVM's metadata header onto the new disk, marking it as available for use. vgextend folds its capacity into the existing volume group's free space pool. lvextend -L +100G grows the logical volume by 100 gigabytes drawn from that pool (you can also use -l +100%FREE to consume all of a VG's remaining free space in one step, rather than specifying an exact size).

Growing the filesystem, ext4:

resize2fs /dev/vgdata/lvapp

Run with no size argument, resize2fs grows the filesystem to fill the entire underlying block device, and it can do this online, while /data stays mounted and in active use.

Growing the filesystem, XFS:

xfs_growfs /data

Note the argument is the mount point, /data, not the device path; XFS's growfs tool operates through the mounted filesystem itself rather than the raw device. Like resize2fs, this runs online with the filesystem mounted and serving traffic throughout.

Worked example with real numbers

Starting from a 150 GiB lvapp that is nearly full, adding a second 150 GiB disk and extending fully:

$ vgextend vgdata /dev/sdb
  Volume group "vgdata" successfully extended
$ lvextend -L +150G /dev/vgdata/lvapp
  Size of logical volume vgdata/lvapp changed from 150.00 GiB (38400 extents) to 300.00 GiB (76800 extents).
$ resize2fs /dev/vgdata/lvapp
  # filesystem now reports 300 GiB total, still mounted throughout

The logical volume doubled from 150 GiB to 300 GiB by consuming the entirety of the newly added disk's capacity, and the extent count doubling exactly in step with the size (38400 to 76800, at LVM's default 4 MiB extent size: 150 GiB / 4 MiB = 38400 extents, confirming the arithmetic) is a useful sanity check that the operation did exactly what you expected before you move on to growing the filesystem itself.

Safety considerations before touching any of this

• Take a backup or an LVM snapshot before extending anything on a volume holding data you cannot afford to lose, even though these operations are designed to be safe: a snapshot (lvcreate --snapshot -L 20G -n lvapp-snap /dev/vgdata/lvapp) gives you a rollback point in case something unrelated goes wrong mid-operation, at essentially no cost if nothing does.
• Verify you are extending the correct logical volume and using the correct new disk, with lsblk and vgs/pvs before running anything: extending the wrong LV, or accidentally initializing a disk that already holds data you meant to keep, as a fresh PV, is a genuinely destructive, hard-to-reverse mistake, and it happens most often when device names like /dev/sdb shift after a reboot on a host with multiple disks.
• Check free space in the VG first (vgs shows VFree directly) so lvextend does not fail partway through, or worse, silently succeed with a smaller size than intended because you asked for more than was actually available.

Trade-offs and pitfalls

• The ext4-versus-XFS difference here is not cosmetic: if you ever expect to need to shrink a volume (moving data to smaller, cheaper storage; reclaiming clearly overprovisioned capacity), XFS forecloses that option permanently the moment you format with it, while ext4 at least allows it offline. This is a decision to make at filesystem-creation time, not something to discover you need later.
• resize2fs targets the block device while xfs_growfs targets the mount point; running the wrong tool against the wrong kind of argument is a common enough mix-up that it is worth double-checking which filesystem you are actually working with before running either command, especially in a mixed-filesystem environment.
• None of these operations validate that the application using the volume actually benefits from more space immediately; a database or log aggregator that was already failing due to being full may need an explicit nudge (a restart, or clearing a stuck disk-full error state) even after the underlying filesystem correctly reports more room available.

Direct answer

An API gateway routing to multiple backend services sits at the one point in the architecture where every client request converges before fanning out, which makes it both the highest-leverage place to enforce security consistently and the single point whose own compromise or misconfiguration has the broadest blast radius; the five highest-priority threat vectors are authentication/authorization bypass, injection and input tampering, denial of service and abuse, misrouting and server-side request forgery (SSRF) toward internal backends, and credential/secrets exposure at the gateway layer itself.

Structured elaboration

1. Authentication and authorization bypass. A client reaches a backend service without a valid identity, or with a valid identity but insufficient authorization for the specific route requested, either because the gateway's own authentication check is misconfigured (a route accidentally excluded from the authentication requirement) or because a backend service incorrectly trusts that the gateway has already fully validated authorization for that specific request when it has only validated authentication. Countermeasures: enforce authentication centrally at the gateway for every route by default (an explicit opt-out for a genuinely public route, not an opt-in requirement that a new route could silently miss), validate JSON Web Tokens (JWTs) fully (signature, issuer, audience, expiration) rather than only checking for presence, and have each backend service independently re-validate authorization for its own specific resources rather than fully trusting the gateway's authentication as a substitute for its own authorization logic.

2. Injection and input tampering. A malicious or malformed request body, header, or query parameter passes through the gateway unvalidated and reaches a backend service that trusts it, since the gateway's routing function does not inherently include content validation unless explicitly configured to. Countermeasures: a web application firewall (WAF) integrated with the gateway inspecting request content against known injection patterns, and, more fundamentally, schema validation at the gateway for each route's expected request shape, rejecting anything that does not conform before it ever reaches a backend.

3. Denial of service and abuse. A single client, or a distributed set of clients, overwhelms either the gateway itself or a specific backend service through excessive request volume; because the gateway is the single point every request passes through, an under-provisioned or unprotected gateway is a single point of failure for every backend service behind it simultaneously, a materially worse outcome than one backend service alone being overwhelmed. Countermeasures: rate limiting and per-client quotas enforced at the gateway, and gateway capacity provisioned and tested against realistic peak load, not just typical traffic.

4. Misrouting and server-side request forgery toward internal backends. A gateway misconfiguration (a route mapping error, or a routing rule that fails to validate the destination correctly) sends a request to an unintended internal backend, potentially one never meant to be reachable through the gateway's public-facing routes at all; separately, if the gateway itself performs any server-side fetch based on request content (less common, but present in some gateway designs with dynamic backend resolution), that fetch logic is itself a potential SSRF vector against internal infrastructure. Countermeasures: an explicit, reviewed allow-list of valid backend destinations per route, never a dynamically-resolved or wildcard destination, and network-level segmentation ensuring the gateway itself can only reach the specific backend services its routing configuration legitimately targets, not the organization's full internal network.

5. Credential and secrets exposure at the gateway layer. The gateway itself typically holds credentials needed to authenticate to backend services on the client's behalf (an internal service-to-service credential, an API key for a downstream integration); a compromise of the gateway itself, or a logging misconfiguration that captures these credentials in request/response logs, exposes every backend service the gateway integrates with at once, not just one. Countermeasures: the gateway's own credentials for backend authentication should be short-lived and narrowly scoped per backend, not one broad, long-lived credential reused across every downstream integration, and logging configuration should explicitly exclude credential-bearing headers and fields from captured log output.

Worked example

An API gateway routes to three backend services: a public product-catalog service, an authenticated order-processing service, and an internal-only inventory-management service never meant to be reachable from outside the organization. A misconfiguration (vector 4) accidentally exposes a route to the inventory-management service through the gateway's public-facing configuration; combined with an authentication gap (vector 1, the newly-exposed route was not added to the gateway's default-authenticated route set), an unauthenticated external caller can reach the internal inventory service directly. The gateway's rate limiting (vector 3) does not prevent this, since the request volume from a single, patient attacker probing for exactly this kind of exposed route stays well under any reasonable rate threshold. The gap is closed by two independent fixes: correcting the routing configuration to remove the internal service from the public-facing route set (closing vector 4 directly), and separately confirming every route, including ones assumed to already be adequately protected, is included in the gateway's default-authenticated set rather than relying on each route being individually, correctly configured (closing vector 1 as a systemic fix, not just for this one route).

Trade-offs and pitfalls

• The worked example's compromise required two separate gaps (a routing misconfiguration and an authentication gap) to actually manifest, and fixing only one of the two would have left the other quietly present, waiting for the next routing mistake to expose it again; treating these five vectors as independent items on a checklist, rather than recognizing how they compound in a real incident, understates the actual risk of any one gap on its own.
• Rate limiting is necessary but, as the worked example shows, does not catch every abuse pattern, specifically a patient, low-volume reconnaissance attempt looking for a misconfigured route rather than attempting to overwhelm capacity; a design that treats rate limiting as covering "abuse" broadly, rather than specifically volumetric abuse, has a gap for exactly this slower, more deliberate attack pattern.
• Requiring each backend service to independently re-validate authorization, rather than fully trusting the gateway's own authentication check, adds real development overhead across every backend team, and it is precisely what limits the worked example's blast radius if the gateway-level authentication gap had gone undetected longer; a backend service that blindly trusted "the gateway already checked this" would have had no independent check to catch what the gateway itself missed.
• The gateway's own credential-management practice (vector 5) is easy to under-prioritize relative to the more visible, request-facing vectors, since a credential-exposure incident is less immediately visible than a misrouted request; but a compromise here has the broadest blast radius of any of the five vectors, since it affects every backend integration simultaneously, not one route at a time, which is why it belongs on this list at the same priority tier as the more obviously request-facing threats.

Direct answer

For about 100 remote users I would build a Remote Desktop Services (RDS) deployment with five parts: session hosts (the servers where users' desktops and apps actually run), a Remote Desktop Connection Broker (tracks who is on which host and reconnects them), Remote Desktop Gateway (tunnels RDP over HTTPS port 443, so RDP itself is never exposed), Remote Desktop Web Access (the web page that lists apps and desktops) and a Remote Desktop Licensing server (issues the client access licenses, or CALs). Every infrastructure role is duplicated on a second machine, the broker's state lives in a shared SQL database (SQL Server or Azure SQL Database, a database service the two brokers both read), and the two gateway/web servers sit behind a load balancer (a device or service that spreads incoming connections across several servers and stops sending them to one that stops responding). Licensing is per-user RDS CALs, one per person, installed on a license server. Internet exposure is limited to the gateway and Web Access servers behind one load balancer on TCP 443 (plus UDP 3391 for the gateway's UDP transport), with a trusted certificate and multifactor authentication on the gateway sign-in.

Components and how each stays up

Microsoft's high-availability guidance is to duplicate each infrastructure role service on a second machine. That is eight servers plus the database (4 session hosts + 2 broker and licensing + 2 gateway and web access), which is the footprint to defend: a smaller one has a single point of failure at some layer. The session hosts, the broker, the gateway and the license server are what a working remote session needs; Web Access is the page where users pick their apps and desktops.

Sizing the session hosts (worked arithmetic)

Capacity is a measured number, not a formula. I run a pilot with the real applications and find how many concurrent users one session host carries at an acceptable response time; assume the pilot shows 35. Worst case all 100 users are connected at once:

• Hosts to carry the load: ceil(100 / 35) = 3.
• One extra host so one can fail or be patched: 3 + 1 = 4 hosts.
• With one host down, 3 hosts carry 100 users: 100 / 3 = 33.3 users each, which is under 35, so the design holds during a failure.

If the pilot measures 50 instead, the answer changes to ceil(100 / 50) = 2, plus 1 = 3 hosts. The measured per-host number is what flips the host count.

Licensing

• Each user and each device that connects to a session host running Windows Server needs an RDS CAL, issued by a Remote Desktop Licensing server.
• How many to buy: 100 users means 100 per-user CALs, not 200 because there are two license servers. Microsoft's roles guidance has both license servers associated with every RD server so issuing continues if one is down; how the purchased license codes are installed across the pair is a licensing-agreement question to settle with your Microsoft reseller before the build.
• Per-user vs per-device: remote workers use their own devices from home, so I would buy per-user CALs (100). Per-user CALs are tied to a user in Active Directory, cannot be tracked in a workgroup, and can be over-allocated, which would breach the licensing terms, so I track usage in Remote Desktop Licensing Manager. Per-device CALs fit shared devices used by several shifts.
• Version rule: the RDS CAL must be the same version as, or newer than, the session host's Windows Server version (a Windows Server 2022 CAL cannot be used on a 2025 session host), and the license server must run the same or a newer Windows Server version than the CALs it holds.
• Grace period: there is a 120 day grace period during which no license server is needed. After it ends, clients must hold a valid CAL to sign in, so the license server is built and activated first, not last.

Protecting access from the internet

1. Expose only the gateway tier, never RDP (3389) or the broker. RD Gateway and RD Web Access run on the same two servers behind the same load balancer, so TCP 443 (and UDP 3391 for the gateway) reaches both, while the brokers, session hosts and SQL database stay unreachable from the internet. Place the gateway servers in a perimeter network (a separate network zone between the internet and the internal network, sometimes called a DMZ), with TCP 443 inbound to the load balancer and rules allowing the gateway to reach the internal brokers and hosts.
2. A trusted TLS certificate on the gateway and web access servers, and a public DNS name that matches it.
3. Authorization policies: RD Gateway requires a Connection Authorization Policy (RD CAP, who may connect) and a Resource Authorization Policy (RD RAP, which internal machines they may reach). By default both are rules stored on the gateway; the CAPs can instead be held on a central Network Policy Server, while RAPs are always evaluated on the gateway itself. Scope users to a named security group and the RAP to the session hosts only.
4. Multifactor authentication: with the RD CAPs held on a central Network Policy Server (NPS, the Windows Server role that answers RADIUS authentication requests), the Microsoft Entra multifactor authentication NPS extension, installed on that NPS server and not on the gateway, adds a second factor to the gateway sign-in. The gateway sign-in supports phone call and Approve/Deny push in the Authenticator app, not SMS or typed codes, so plan enrollment accordingly. This is a layer added on top of a working gateway.
5. Operations: patch the gateway first, alert on repeated sign-in failures, and give both Web Access servers identical validation and decryption machine keys, as Microsoft's farm procedure requires. Those keys are the secrets IIS uses to sign and decrypt the tokens Web Access issues to a browser; with identical keys, a sign-in started on one Web Access server is accepted by the other when the load balancer switches the user over.

Trade-offs and pitfalls

• Recommendation: this on-premises RDS design if the applications must stay on your servers. Choose Azure Virtual Desktop instead if there is no appetite for running broker, gateway and database infrastructure, or if the team is not already staffed to patch it.
• Windows Internal Database (WID, a lightweight database engine built into Windows) is used by roles that include the Connection Broker, but a highly available broker needs a shared database server (SQL Server or Azure SQL Database). Microsoft also lists WID as being removed from Windows in a future release and advises SQL Server for these roles, so use SQL from the start.
• Co-locating roles saves servers but ties failure domains together. I accept brokers plus licensing on one pair at 100 users; I would separate them at larger scale.
• User data on the session hosts disappears with a failed host. Keep profiles and files on a highly available file share, not on the host's local disk.

Direct answer

Default to password hash synchronization (PHS) plus Seamless single sign-on (SSO), which signs in domain-joined PCs without a password prompt. It has the least infrastructure, keeps working when on-premises servers are down, and still applies your on-premises password complexity and history rules at change time. Choose pass-through authentication (PTA, where an on-premises agent checks the password against a domain controller) only if you must enforce on-premises lockout, disabled, expired and sign-in-hours state at every single sign-in. Choose federation with Active Directory Federation Services (AD FS) only for needs Microsoft Entra ID cannot meet natively, such as third-party multifactor authentication (MFA) or sign-in with a sAMAccountName. Enable PHS even if you choose PTA or federation, as the fallback.

What each method does at sign-in

A few terms first. A tenant is your organization's own dedicated instance of Microsoft Entra ID. Microsoft Entra Connect is the on-premises software that copies users from AD to the tenant. Federation means the tenant hands the password check to a separate on-premises sign-in service (AD FS), which vouches for the user afterwards.

• Password hash sync (PHS): Connect copies a processed form of each password hash to the cloud, and the cloud itself checks the password. Nothing on-premises is involved at sign-in.
• Pass-through authentication (PTA): the cloud passes the typed password to an on-premises agent, which asks a domain controller whether it is right and returns yes or no.
• Federation (AD FS): the cloud redirects the user to the on-premises AD FS farm, which checks the password and issues a signed token back to the cloud.
  For choosing a method, what matters is where the password is checked, what happens when on-premises is down, and how quickly a disabled account is refused; the intervals and agent counts in the table are operating details that follow from that choice.

The options compared

Behaviour detail

• Sign-in with PHS. A user changing a password on-premises signs in with it after the next sync, normally minutes. Existing cloud sessions are unaffected. Bulk account disables should be followed by an immediate sync cycle.
• Seamless SSO creates an AZUREADSSO computer account in each forest. Microsoft recommends rolling its Kerberos decryption key (the secret that lets Entra decrypt the Kerberos tickets browsers present) at least every 30 days with Update-AzureADSSOForest, once per forest only, because Microsoft documents that running it more than once per forest stops the feature until users' Kerberos tickets expire and are reissued by AD. It works only with PHS or PTA.
• Password expiry. If synced users must follow cloud password-expiry rules, enable the CloudPasswordPolicyForPasswordSyncedUsersEnabled feature before enabling PHS; accounts that must never expire (service accounts) then need DisablePasswordExpiration set explicitly.

High availability of the sync engine

Microsoft Entra Connect Sync can only be active-passive. A second server in staging mode (a standby copy kept current but not allowed to write to the cloud) imports and synchronizes but does not export, and does not run password sync or password writeback until you disable staging. If it has been in staging for long, password sync needs a catch-up period after it goes active, and newly changed passwords do not work in the cloud until the backlog clears. Staged rollout, mentioned in the pitfalls, is a different feature: it moves chosen user groups to cloud authentication gradually. Check state on either server:

Import-Module ADSync
Get-ADSyncScheduler | Select-Object StagingModeEnabled

Microsoft Entra Connect cloud sync is the lighter alternative, because it does not depend on a single sync server and can provide higher availability. For PTA, install three agents (the first with Connect plus two more) so one can be down for maintenance while another fails.

Writeback

Password writeback (which keeps the on-premises password current after a cloud change) sends a password changed or reset in the cloud (self-service password reset or an administrator in the Entra admin center) back to AD DS. It works with PHS, PTA and federation, enforces your on-premises history, complexity, age and filters, uses only outbound port 443, and cannot reset passwords for protected-group members. Only one active Connect server can use writeback at a time, and it is not reliable with staged rollout enabled for a security group.

Worked example

At 09:00 HR disables a leaver's AD account. Under PTA the leaver's next sign-in is refused, because the agent checks the live account state. Under PHS the disabled state can lag up to 30 minutes, so the leaver may still sign in until about 09:30 unless you force a sync cycle after the change. If that window is unacceptable for a high-risk population, that is the case for PTA, with PHS still enabled as the fallback.

Trade-offs and pitfalls

• Switching methods needs planning; staged rollout lets you move users gradually.
• PTA keeps password validation on-premises but adds an on-premises dependency; PHS is the opposite.
• Federation is the most capable and the most fragile.

Direct answer. Bring online everything that doesn't strictly need the down dependency, and put a firm, visible hold on anything that does, rather than letting it silently degrade or silently retry. Decide what "handling a transaction" means without the dependency in a way that never risks a customer being charged, billed, or committed twice: hold, don't guess. And tell customers proactively, in plain language, before they have to ask.

1. Decide what comes online, using criticality, not convenience

This decision should trace back to the business impact analysis, the process that ranks business functions by how much an hour or a day of downtime actually costs, so it isn't made ad hoc mid-incident. Functions that don't touch the down dependency come online first. Functions that touch it only on a non-essential path (browsing, viewing account history) come online in a read-only or informational mode. Functions where the dependency is essential to the transaction itself (authorizing a new charge) stay explicitly gated, not silently attempted.

The authority to declare "we're operating in a degraded state" and to approve which functions run that way should be defined in the continuity plan ahead of time, not improvised in the room. That's usually someone senior enough to own the customer and regulatory risk of the decision, not just whoever is closest to the outage.

2. Handle the affected transactions without guessing

Accept the transaction, record the customer's intent, and hold it in a clearly marked pending state rather than attempting it against a dependency that isn't there, or silently retrying it in the background where the customer can't see what happened. Be honest about the state: "received and pending" is very different from letting a customer believe it went through, and that distinction is also what stops a customer from trying again themselves out of uncertainty.

When the dependency comes back, process the backlog in order and reconcile before declaring the incident closed: confirm, transaction by transaction, that what your system believes happened matches what the dependency's own records show, and follow up individually on anything that doesn't match rather than assuming the queue drained cleanly.

3. Communicate the degraded state to customers

Say something before they have to ask. A visible status message in the product itself, not only on a status page nobody checks mid-transaction, that names what's affected, sets expectations (their action is saved but pending, not lost), and gives a realistic timeframe, even a wide one, beats silence. Update it as the situation changes, and if any pending items need a customer to take action, reach out directly instead of leaving them to notice on their own. Keep the message consistent across channels so a customer who checks two of them doesn't get two different stories on top of the outage itself.

4. Protect service levels for what's still running

The functions still online need their own expectations reset for the duration. It's reasonable to temporarily relax targets for anything adjacent to the affected dependency (background jobs that would also normally touch it) so they don't cause a second incident by retrying aggressively against something that's down. That should be a deliberate, communicated decision, not something that just happens because nobody planned for it.

Worked example

A checkout flow depends on a third-party payment processor down for two hours, well past what anyone expected. Browsing, cart building, and order history don't touch the processor, so they stay fully online. Checkout is gated: a customer can complete every step through "place order," and the order is recorded as pending payment with the cart and the chosen payment method captured, but no charge is attempted. The product tells them directly: order saved, payment processing is delayed, confirmation will follow once it's back, expected within the hour. No background retry loop fires against the processor. When it recovers, pending orders are processed in the order placed, and each is reconciled against the processor's own transaction record before being marked complete, so a customer is never charged twice even if an earlier attempt is later discovered to have partially gone through.

Trade-offs & pitfalls. The tempting shortcut is to keep retrying the transaction in the background hoping the dependency returns soon; that's exactly how a customer ends up double-charged if the retry succeeds silently after they've already tried again themselves out of frustration. Hold and communicate, don't guess and retry. Silence is worse than an honest "we don't know exactly when," because customers who get no information assume the worst or attempt workarounds that make reconciliation harder afterward. And bringing too much online too fast, without a clear degraded-mode decision from someone with the authority to own that risk, is how a team ends up shipping a feature that looks live but isn't actually safe to depend on.

Direct answer

Separate the two things reboots are doing in the plan: applying fixes, and restarting the machine. Reduce how often a machine must restart (live kernel patching, Windows hotpatching where supported, replacing instead of patching, rolling updates over redundant nodes), and be honest with the business that the rest cannot be eliminated, so give them a number for the remaining exposure and ask for the smallest guaranteed window that bounds it. Never promise "patched with no downtime and no risk".

Step 1: Sort the estate by how it can be updated without downtime

Each row below is a method for a different kind of host, so they are not alternatives for one machine; an estate usually uses several. (Hardening baselines, meaning agreed secure settings, come in Step 2. The word "baseline" in the hotpatch row means something else: a full cumulative update that does require a restart.)

The hotpatch facts: the hotpatch baseline refreshes every three months, with hotpatch releases for the following two months, so a planned year is four baselines (restart needed) and eight hotpatch months. An unplanned baseline can replace a hotpatch month if a fix cannot be hotpatched.

Checking one host. After a live patch or hotpatch, confirm it landed on the host itself, because "the console says compliant" is a second-hand view.

• Linux live patch: uname -r still prints the old kernel version (a live patch does not change it), so check the live-patch interface instead. The kernel keeps one directory per loaded patch under /sys/kernel/livepatch/, and cat /sys/kernel/livepatch/<patch-name>/enabled reads 1 while that patch is active (patch names depend on the vendor's package; I could not run this here because a container has no live-patched kernel).
• Windows hotpatch: list installed updates with Get-HotFix, which lists the updates Component Based Servicing installed (columns Source, Description, HotFixID, InstalledBy, InstalledOn), and look for the month's KB number: (Get-HotFix | Sort-Object -Property InstalledOn)[-1] shows the most recent one, and Get-HotFix -Id KB5099999 (an illustrative number) returns nothing if that update is absent. For Azure VMs, the VM's Updates page in the Azure portal also shows the hotpatch status.

Step 2: Hardening without downtime

Hardening changes are mostly configuration, not binaries. Roll them out as rolling, per-node changes behind the same redundancy, with the change applied to one node, verified, then repeated. Settings that need a service restart (not a host restart) are handled by draining that node. Build the settings into the golden image so new instances arrive hardened, rather than modifying running hosts.

Step 3: What to tell the business about the remaining risk

State it as a measurable exposure window, an owner, and a decision.

Worked example (illustrative numbers, stated as assumptions): suppose after the techniques above 40 of 500 hosts can only be restarted in a single scheduled window per quarter. The longest a fix can wait for such a host is the gap between windows, about 91 days (365 divided by 4, rounded to the nearest day). Live patching or hotpatch narrows that for kernel and Windows security fixes, but not to zero.

Recommendation: ask for the smallest fixed window that bounds exposure, for example two hours monthly for the 40 hosts, rather than none; each shorter gap proportionally shortens worst-case exposure (monthly gives about 30 days, a third of the quarterly gap).

Trade-offs and pitfalls

• Live patching is a mitigation, not a replacement for reboots: a kernel can be live-patched for months and still drift from the tested baseline.
• Replace-instead-of-patch moves risk into the image pipeline; the pipeline must be patched and tested too.
• Do not hide the residual risk in a spreadsheet. If an incident occurs on an accepted host, the signed acceptance is what shows the business chose the exposure knowingly.
• What would change the recommendation: if the 40 hosts include internet-facing ones, the compensating controls alone are not enough and the second node becomes the priority.

Direct answer

The ICMP messages you'll see most often during ping/traceroute each map to a specific, distinct network condition: Destination Unreachable (with several sub-codes for host, network, or port), TTL/Time Exceeded, Fragmentation Needed, and Redirect, and reading which specific one you got (not just "it failed") tells you what to check next.

Structured elaboration

1. Destination Unreachable, host unreachable: a router along the path has no route to the specific destination HOST; check routing tables at the router that generated this message.
2. Destination Unreachable, network unreachable: a router has no route to the destination NETWORK at all, a broader failure than "host unreachable," usually indicating a missing or withdrawn route rather than just an ARP/reachability issue for one specific host.
3. Destination Unreachable, port unreachable: the destination host IS reachable, but nothing is listening on the specific port being probed; this is actually the NORMAL, expected response that classic UDP-based traceroute relies on to detect it has reached the final destination (since it deliberately probes an unlikely-to-be-open port).
4. TTL Exceeded (Time Exceeded): as covered by traceroute's core mechanism, a router decremented TTL to zero and discarded the packet; seeing this from an intermediate hop is normal and expected during traceroute, but seeing it unexpectedly during regular traffic (not traceroute) can indicate a routing loop or an unusually long path exceeding a low starting TTL.
5. Fragmentation Needed (with the "don't fragment" bit set): a router needs to fragment the packet to forward it but is prohibited from doing so, and reports the MTU of the constrained link in its reply, which is exactly the message Path MTU Discovery depends on to let the sender adjust; its absence (being filtered somewhere) is the classic PMTUD black-hole failure mode.
6. Redirect: a router is telling the sender that a better next hop exists for this destination than the one currently being used, typically because the sender's default gateway assumption is suboptimal for that specific destination; on modern networks, redirects are frequently disabled or ignored for security reasons (they can be spoofed to redirect traffic maliciously), so seeing them, or specifically NOT seeing them where you might expect one, both carry diagnostic meaning depending on context.

Worked example

A traceroute to a destination shows normal TTL-Exceeded replies through several hops, then a "Destination Unreachable, network unreachable" from an intermediate router instead of ever reaching the destination. This specific sub-code tells you the FAILURE is at the ROUTING layer at that specific router (it has no path to the destination network at all), distinct from what you'd see if the destination itself were simply not responding (which would produce silence or timeouts, not an explicit unreachable message) or if only a specific port were closed (which would be "port unreachable," implying the network path and host are both fine).

Trade-offs & pitfalls

Treating all "Destination Unreachable" messages as equivalent is a common mistake; the sub-code (host, network, port, and several others) carries real diagnostic information about WHERE and WHAT kind of failure occurred, and conflating them (for example, treating a normal "port unreachable" completion of a UDP traceroute as an error) leads to misreading perfectly healthy tool output as a failure.

Direct answer

A local account lives in the Security Account Manager (SAM), a small account database stored on one specific Windows machine, and is only ever authenticated by that machine; a domain account lives once in Active Directory and is authenticated by a domain controller (a server that holds the directory and validates logons), so the same identity works across every machine joined to that domain. Every other difference, where the profile lives, how password and lockout policy is applied, whether single sign-on (SSO, logging in once and being trusted by other resources without re-entering credentials) works, and when you'd deliberately choose one over the other, follows from that one structural fact.

Structured elaboration

Why domain accounts get real single sign-on and local accounts don't. When you log into a domain-joined machine with a domain account, the domain controller issues a ticket (Kerberos's ticket-granting mechanism) that the machine can present on your behalf to other domain resources. A local account has no domain controller vouching for it; it is only ever known to the one machine that created it, so there is nothing for a second resource to trust without being handed the same raw credential again.

Common scenarios where a local account is the right choice over a domain account:

• A standalone machine that will never join the domain at all: an isolated workshop kiosk, or a host deliberately segmented off the domain's trust boundary for security reasons (a DMZ system).
• Break-glass emergency access: keeping a local administrator account specifically so a technician can still log in and diagnose the machine when the network path to a domain controller is unavailable, since local authentication has no dependency on reaching the domain at all.
• A machine-scoped service or application account: something intentionally confined to exactly one machine, since it structurally cannot be used to authenticate anywhere else, which shrinks the blast radius if that one credential is compromised.
• Initial setup and imaging, before the machine has even joined the domain yet.

Worked example

Two concrete situations make the distinction tangible. First: a branch office loses its wide-area network link to the data center overnight. A technician arriving on-site the next morning cannot authenticate a domain account on the affected workstation, because there is no reachable domain controller to validate it, but the local Administrator account (a break-glass account kept for exactly this case) still authenticates instantly, since the SAM database it checks against lives on that same machine. Second: a new hire, jsmith, already has a domain account used daily on their assigned desktop. On their first day working from a shared lab machine, logging in with the exact same domain account still creates a brand-new, empty C:\Users\jsmith profile on that lab machine (no desktop shortcuts, no saved settings) even though it is unambiguously the same identity, because without roaming profiles or Folder Redirection configured, the profile is per-machine while only the underlying account is domain-wide.

Trade-offs and pitfalls

The most common mistake is assuming the domain's password and lockout policy automatically covers the built-in local Administrator account on a domain-joined machine; it does not, since that account is still governed by local policy on that machine, which is exactly why Microsoft's LAPS (Local Administrator Password Solution) exists, to randomize and centrally manage that one account's password per machine rather than leaving it to drift. A second, genuinely dangerous pitfall is administrators duplicating the same local account name and password across many machines as an informal substitute for single sign-on convenience: this creates a real lateral-movement risk, because compromising the password hash on one machine effectively compromises the identical local account on every other machine sharing it, which is the exact mechanism pass-the-hash attacks rely on. A third pitfall is treating a fresh, empty local profile on a new machine as a sign that "the account didn't work," when it is simply expected behavior for a domain account without roaming configured. Finally, keeping any accounts local at all trades away the domain's centralized policy enforcement and access-review visibility in exchange for machine-level autonomy and resilience when the network is unavailable, so local accounts should be deliberately minimized to the specific cases above and tracked, since they fall outside routine domain-wide access reviews by construction.

Direct answer
Selective Acknowledgment (SACK) lets a receiver tell the sender exactly which non-contiguous blocks of data it has ALREADY received, so after a loss the sender only has to retransmit the specific missing segment(s), not everything that came after it.

Structured elaboration
Without SACK, TCP uses cumulative acknowledgment: an ACK only confirms "I have received everything up through this byte, contiguously." If segment 3 of a 10-segment flight is lost but segments 4 through 10 all arrive fine, the receiver can only ACK up through the end of segment 2, it has no way to tell the sender "I actually already have 4 through 10, I'm just missing 3." A sender using only cumulative ACKs, upon detecting the loss, may end up retransmitting segments 3 through 10 (everything the receiver hasn't cumulatively acknowledged), even though 4 through 10 were never actually lost.

With SACK enabled (negotiated via a permitted option in the handshake, then carried on subsequent ACKs), the receiver's ACK can include SACK blocks, explicit ranges of sequence numbers it holds that are NOT contiguous with the main acknowledged run, in the example above, a SACK block spanning segments 4 through 10. Now the sender knows precisely that only segment 3 needs retransmitting.

Worked example
Say a sender has segments with sequence ranges [1000-1500), [1500-2000), [2000-2500), ... up to [4500-5000), and segment [2000-2500) is lost in transit while everything else arrives. Without SACK: the receiver's ACKs stay pinned at ack=2000 (the last contiguous byte received) even as segments up through 5000 keep arriving; the sender, upon detecting the loss (via duplicate ACKs all saying ack=2000), knows only that SOMETHING after 2000 needs resending and, in older/naive implementations, could resend everything from 2000 onward. With SACK: the same duplicate ACKs at ack=2000 now also carry a SACK block like sack=2500-5000, telling the sender explicitly that only the single segment [2000-2500) is actually missing, so it retransmits exactly that one segment and nothing else.

Trade-offs & pitfalls
SACK is most valuable on connections with a large amount of data in flight (a large window relative to segment size) and where losses are isolated rather than in a solid burst, since that's exactly the scenario where "retransmit everything after the gap" wastes the most bandwidth compared to "retransmit only the gap." On a connection with a tiny window, or where an entire flight is lost at once (nothing left to selectively acknowledge), SACK provides little advantage.

What the FHS is and why it exists

The Filesystem Hierarchy Standard (FHS) is a specification maintained by the Linux Foundation that defines where categories of files belong on a Linux system: configuration here, variable runtime data there, user binaries somewhere else. Distributions (Debian, Red Hat Enterprise Linux, and most others) largely follow it. The payoff is portability of operational knowledge: an engineer who knows the FHS can find a service's config, logs, and data on an unfamiliar box without exploring first, and packaging tools and automation (Ansible, systemd unit files, backup scripts) can rely on paths existing in predictable places; systemd here is the init system and service manager most current Linux distributions use to start and supervise services.

The directories, what lives there, and a placement example

Worked example: where a new internal tool's files land

Say the team ships an internal metrics agent as a .deb package. Its systemd unit file (defining how it starts) goes in /etc/systemd/system/, its own tunables go in /etc/metrics-agent/config.yml, its binary is installed by the package manager to /usr/bin/metrics-agent, and its running output (rotated logs, a small on-disk queue of unsent metrics) lives under /var/log/metrics-agent/ and /var/lib/metrics-agent/. If instead the vendor shipped it as a self-extracting tarball outside the distro's package manager, the whole tree would go under /opt/metrics-agent/ so it never collides with anything dpkg/rpm thinks it owns.

Trade-offs and pitfalls

• /usr historically held a stricter separation from / (so / could mount before other filesystems were available at early boot), but most modern distributions merge /bin, /sbin, and /lib into /usr via symlinks (the "usr-merge"). The FHS still describes the logical roles even where physical layout has consolidated.
• Putting large or fast-growing data (a database, container images) directly under /var without giving it its own filesystem is a common outage cause: /var filling up can starve logging and package operations for the whole host, so production hosts typically give /var, and sometimes /var/log specifically, a dedicated partition or volume.
• Third-party software that ignores /opt and scatters files into /usr/local or /usr can conflict with the package manager during upgrades; /usr/local is the FHS-sanctioned spot for locally-built software that isn't managed by the distro's packages, which is a subtly different bucket from /opt's vendor-installed trees.