IT Foundations: A Practical Guide to Hardware, Networks, Operating Systems, and Databases

Computer architecture describes how processors, memory, storage, and input/output devices cooperate. A processor fetches instructions, decodes them, and performs operations using registers and execution units. Caches retain copies of data and instructions to reduce expensive accesses to main memory. RAM holds active program state but ordinarily loses its contents without power; SSDs provide persistent storage. Performance therefore depends on the workload: a calculation may be limited by processor execution, while a reporting task may spend most of its time waiting for storage or network responses.

Binary representation gives these components a common way to encode information. The unsigned eight-bit value 00101101 equals 32 + 8 + 4 + 1, or decimal 45. Eight bits permit 256 distinct patterns, representing 0 through 255 when interpreted as unsigned integers. Under eight-bit two’s-complement interpretation, 11111111 instead means −1; as unsigned data, it means 255. Meaning comes from the encoding and context, not the pattern alone. Text requires an encoding such as UTF-8, and fractional numbers often use floating-point formats that cannot represent every decimal fraction exactly. These distinctions explain overflow, corrupted text, and surprising rounding results.

Operating systems mediate access to hardware and provide abstractions that applications can use. A process is a running program with resources such as an address space and open files; its threads are units of execution scheduled onto processor cores. Virtual memory maps process-visible addresses to physical memory and supports isolation between processes. Some memory pages may be moved to secondary storage under pressure, although not all memory is pageable. Excessive paging can make a machine unresponsive even when processor utilization is modest. Filesystems organize persistent data and metadata, while permissions control which identities may read, modify, or execute objects.

Suppose a Linux application cannot write its log. Start by identifying the account running the process, then inspect the destination with ls -ld and check free space using df -h. Check inode availability with df -i if the filesystem uses a finite inode pool. Parent directories require traversal permission, and the filesystem may be mounted read-only. Linux mode 640 grants the owner read/write access, the group read access, and others no access; ACLs or mandatory access controls may impose additional rules. Do not respond by granting everyone full permissions. On Windows, use equivalent evidence from service identities, NTFS permissions, Event Viewer, and storage inspection.

The OSI model separates networking into seven conceptual layers: physical, data link, network, transport, session, presentation, and application. Real TCP/IP implementations do not map perfectly onto that teaching model, but the separation helps locate faults. Ethernet and Wi-Fi handle local-link communication; IP addresses support routing between networks; TCP supplies an ordered byte stream with retransmission and flow control. UDP sends datagrams without providing those guarantees itself. Protocols built above UDP can add reliability: QUIC, used by HTTP/3, is an important example. Ports distinguish transport endpoints, while application protocols define how communicating programs interpret messages.

Consider a workstation at 192.168.10.34/24 accessing a service at 192.168.20.80. With the conventional mask 255.255.255.0, the workstation recognizes that the destination is outside its local subnet and normally sends traffic through a configured router. For an IPv4 Ethernet next hop, ARP discovers the corresponding link-layer address. If the user supplied a hostname, DNS usually resolves it before the connection is established, unless a usable cached result already exists. For HTTPS over TCP, connection establishment precedes a TLS handshake that negotiates encryption and normally authenticates the server. Test these stages separately: inspect addressing and routes, query DNS, then check the service port. A failed ping alone does not prove the service is unavailable.

Relational database systems store data in tables governed by a schema. Primary keys identify rows, and foreign keys constrain relationships between tables. Imagine customers(customer_id, name) and orders(order_id, customer_id, total). Keeping the customer name in the customers table avoids repeating it in every order and reduces update inconsistencies. This illustrates normalization: organizing data according to dependencies rather than duplicating facts indiscriminately. Appropriate data types and constraints matter too. An order total usually belongs in an exact decimal type rather than a binary floating-point type, while a NOT NULL constraint can prevent missing values where they would violate business rules.

To total orders by customer, use SELECT c.customer_id, c.name, SUM(o.total) AS total_spend FROM customers c JOIN orders o ON o.customer_id = c.customer_id GROUP BY c.customer_id, c.name;. This inner join excludes customers without orders; a LEFT JOIN with COALESCE can include them with zero totals. An index on orders.customer_id may help relevant joins and filters, but indexes consume storage and add write overhead, so inspect execution plans rather than assuming improvement. Transactions group changes into a controlled unit: a transfer should not debit one account without crediting the other. Isolation behavior varies by database and isolation level, so concurrent access needs explicit consideration. Applications should bind query parameters instead of concatenating untrusted input into SQL.

Cybersecurity basics begin with confidentiality, integrity, and availability. Confidentiality limits unauthorized disclosure; integrity protects against unauthorized or accidental alteration; availability keeps services usable. Authentication establishes an identity, while authorization determines what that identity may do. Apply least privilege to human users and service accounts, and separate routine work from administrative access. Multifactor authentication makes stolen passwords less useful, but it does not remove the need for secure sessions and careful authorization. Reduce exposure through patching, disabling unnecessary services, and restricting network access. Encryption in transit protects communication, while encryption at rest addresses different risks and requires sound key management.

For a small web application, a practical baseline is to allow public access only to required application endpoints, keep the database inaccessible from the public internet, and give the application a narrowly scoped database account. Store secrets outside source code and restrict access to them. Record meaningful authentication and administrative events without logging passwords or sensitive tokens. Maintain backups under access controls that production compromise cannot easily defeat, and test restoration. Recovery point objective describes acceptable data loss measured in time; recovery time objective describes the target time to restore service. These requirements determine backup frequency and recovery design. Successful backup jobs alone are not proof that usable recovery is possible.

Systems administration combines configuration, automation, monitoring, and change control. Command-line tools expose system state directly and can be composed into repeatable workflows. On Linux, ps helps inspect processes, ss helps inspect sockets, and journalctl reads systemd journal records where available. On Windows, PowerShell provides structured objects through commands such as Get-Process and Get-Service. Learn what a command reads or modifies before running it with elevated privileges. Prefer narrow, read-only inspection during initial investigation, and record relevant timestamps so that events from different systems can be correlated.

Automation should reduce variation without amplifying mistakes. Before changing a service configuration, capture the current state, review the proposed difference, validate syntax where supported, and establish a rollback procedure. Test in a disposable environment before applying the change more widely. Good configuration automation aims for idempotence: repeated execution converges on the intended state rather than repeatedly adding entries or restarting services unnecessarily. Monitoring then verifies whether that state delivers useful service. Processor load and memory consumption are supporting signals; request success rate and response time are closer to user experience. Keep scripts and configuration templates under version control, but exclude credentials and other secrets.

Effective IT troubleshooting starts with scope and evidence. Ask what failed, who is affected, when it began, and what changed. Separate an observed symptom from an assumed cause: “the portal times out” is evidence, while “the database is down” is a hypothesis. Compare a failing client with a working one and follow the request path through name resolution, connectivity, encryption, application processing, and storage. Change one variable at a time when practical. Preserve diagnostic evidence before restarting components, because a restart can erase the state needed to explain an intermittent problem.

Suppose users report that a portal returns HTTP 502. A gateway or proxy is responding, but that does not prove the backend application is healthy. Inspect gateway logs for upstream connection errors, identify the configured backend address, and check whether the application is listening on the expected interface and port. Review service status and recent deployment logs. If a configuration change introduced the wrong port, validate the correction and use the deployment process to apply it safely. Confirm recovery with an actual user operation, not merely a green process indicator. A useful foundations lab recreates this scenario in isolated virtual machines or containers and records symptoms, tests, findings, and prevention steps.