Cloud, On-Premises, Protocols, and Ports

Hosting Models: On-Premises vs Cloud

A CCST Networking objective is comparing cloud and on-premises applications and describing common protocols. They belong together because users report an application symptom, not a layer, so you must locate the service and the path to it.

An on-premises service runs on infrastructure the organization owns or directly manages: a server in a network closet, a campus data center, or a private facility. Examples include a local file or print server, a directory service, an internal web app, a camera recorder, or a local DHCP server. On-prem gives direct control over hardware, maintenance windows, security policy, and physical access, but the organization owns power, cooling, backups, patching, hardware failure, and capacity.

A cloud service runs on provider-managed infrastructure reached over a network, usually the Internet: hosted email, cloud storage, Software as a Service (SaaS) business apps, virtual servers, managed databases, and collaboration platforms. Cloud cuts local hardware and eases multi-site reach, but it adds dependency on Internet access, DNS, identity providers, provider status, subscriptions, and cloud security settings. Cloud does not mean "no network"; it means the service is somewhere else and the path matters.

Most organizations mix both: a user signs in with a cloud identity, prints to an on-prem printer, opens files from a cloud drive, and resolves names through a local DNS forwarder. Troubleshooting should separate questions: Is the endpoint connected with valid IP settings? Can it reach the gateway? Does DNS resolve the service name? Is the destination local or remote? One user or everyone? Does a provider status page show an outage? Did a firewall rule, VPN, certificate, or password change?

Common Protocols and Their Well-Known Ports

Port numbers give you a vocabulary for firewall rules and captures. Memorize this table; it is heavily tested.

Telnet (port 23) is insecure and should be replaced by SSH (port 22). SFTP rides over SSH on port 22, which is different from plain FTP on 20/21.

Turning Ports Into Diagnoses

Ports do not prove an app is healthy, but they reveal expected traffic and likely failures:

• If TCP 443 is blocked, most cloud apps and modern websites fail.
• If DNS (53) fails, users say "the Internet is down" even though IP connectivity works.
• If DHCP (67/68) fails, a client may have no usable address or self-assign an APIPA address (169.254.x.x) that cannot reach the network.
• If NTP (123) fails, the device clock drifts and certificate validation and log timestamps break, producing confusing TLS errors.

Common trap: assuming "Internet is down" means a routing or ISP outage when DNS or NTP is the real fault. For CCST support, know each protocol's purpose, recognize its well-known port, then verify symptoms, check scope, compare working and non-working clients, and document the protocol or port that appears to be failing.

Secure vs Insecure Protocol Pairs

The exam frequently contrasts an older cleartext protocol with its encrypted replacement, so learn them as pairs and know why the secure one wins. HTTP (port 80) sends web traffic in the clear; HTTPS (port 443) wraps it in Transport Layer Security (TLS) so credentials and data cannot be read in transit. Telnet (port 23) carries remote command-line sessions, including the password, as plain text; SSH (port 22) encrypts the whole session and is the correct choice for managing devices. FTP (ports 20/21) transfers files without protection; SFTP runs over SSH on port 22 and is encrypted.

On the mail side, plain IMAP (143) and POP3 (110) have secure counterparts IMAPS (993) and POP3S (995).

When you see a question asking which protocol to use, the safe default is the encrypted member of the pair unless the scenario specifically requires legacy compatibility. A device still offering only Telnet is a finding to flag, not a configuration to keep.

A Scope-and-Compare Workflow for Service Faults

Because users report services, not ports, a repeatable workflow keeps you honest:

1. Confirm the basics: is the endpoint connected with a valid IP, mask, gateway, and DNS server?
2. Resolve the name: can the client resolve the service's hostname? A failed lookup with working IP connectivity is a DNS problem, not an outage.
3. Locate the service: is it on-premises (check the local server, switch, and firewall) or cloud (check Internet reachability, DNS, identity, and the provider status page)?
4. Compare clients: does the problem hit one user or everyone? One affected user points at that endpoint or its port; everyone points at a shared dependency such as DNS, DHCP, the gateway, or the provider.
5. Identify the protocol and port: name the specific protocol that should be flowing (for example HTTPS on 443 for a web app) and confirm a firewall rule, VPN, certificate, or recent password change did not block it.

Notice how often DNS, DHCP, and NTP sit underneath symptoms that look like something else. A wrong device clock from a failed NTP sync breaks TLS certificate validation and makes logs unreadable; a failed DHCP lease yields an APIPA 169.254 address that cannot route; a DNS outage makes every cloud service appear down at once. Recognizing these by their port and purpose is exactly the practical protocol knowledge the CCST exam measures.