Study guide
Cloud, On-Premises, Protocols, and Ports
CCST Networking Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Orientation, Official Sources, and Exam Strategy
Official Exam Profile and Source Hierarchy Registration, Delivery, Attempts, and Results Using the Six Official Topic Areas Building a Practical Study Plan Exam Strategy Without Unsupported Shortcuts Ethical Preparation and Path Forward
2 Network Standards, Models, and Common Protocols
Network Building Blocks OSI and TCP/IP Models Frames, Packets, Segments, and Data Flow Network Types and Scope Cloud, On-Premises, Protocols, and Ports Bandwidth, Throughput, Latency, and Jitter
3 Chapter 3: IPv4, IPv6 Addressing, and Subnet Formats
3.1 Public, Private, and Local Addressing 3.2 IPv4 Dotted Decimal and Binary Basics 3.3 Subnet Masks, CIDR, and Prefix Lengths 3.4 Subnet Logic, Host Ranges, and Gateways 3.5 IPv6 Address and Prefix Formats 3.6 MAC vs IP in Addressing Troubleshooting
4 Endpoints, Media, Cabling, and Client Connectivity
Endpoint Devices and Network Roles Network Interface Cards and Link Status Copper, Fiber, Coax, and Connector Basics Wired, Wi-Fi, and Cellular Access Methods Interference, Signal Quality, and Physical Reliability Client Connectivity Checks by Operating System
5 Infrastructure Devices, Ports, and Physical Installation
Infrastructure Device Roles Ports, Connectors, and Device Identification Cisco Device LEDs and Status Checks Network Diagrams and Cabling Instructions Power over Ethernet and Powered Devices Racks, Patch Panels, and Installation Basics
6 Switching, Routing, and Network Services
Basic Switching and MAC Learning VLANs and Local Boundaries Routing, Default Gateway, and ARP DNS, DHCP, and NAT Services Transport-Layer Services Small Network Traffic Flow
7 Troubleshooting Methodology, Ticketing, and Documentation
Help Desk Intake and Information Gathering Scope, Impact, and Prioritization Reproduce, Isolate, and Escalate Ticket Quality and Operational Documentation User Communication and Change History Physical, Data Link, and Network Layer Triage
8 Diagnostic Commands, Packet Capture, and Device Data
Command-Line Triage and Ping Path and Client Configuration Commands DNS and Socket Diagnostics Wireshark Capture and Save Device Access and Data Collection Basic Cisco Show Commands
9 Security, Firewalls, Wireless, and Safe Defaults
Firewall Filtering and Traffic Policy Least Privilege, AAA, Passwords, and MFA Wireless Security, WPA2, WPA3, and WPAx Guest Networks, Segmentation, and Shared Devices Common Threats and Safe User Practices Secure Home Router Baseline
10 Integrated Small Network Build and Repair Labs
Lab 1: Build a Basic Office LAN Lab 2: Repair No Internet After an Office Move Lab 3: Wireless Clients Cannot Reach Local Resources Lab 4: DHCP, DNS, and Default Gateway Symptoms Lab 5: Switch, Router, and Service Boundaries Lab 6: Escalation, Documentation, and Handoff
11 CCST to CCNA Career Path and Operational Readiness
Entry-Level Networking Roles and Expectations CCST vs CCNA and the Cisco Roadmap NetAcad 70-Hour Path and Study Plan Lab Habits for Real Operational Readiness Ethical Preparation, Portfolio, and Logbook Exam Scheduling Calendar and Readiness Check
12 Final Review, Exam Day, and Remediation Plan
Final Review Map to Official Objectives 50-Minute Exam Day Timing Unsupported Facts and Ethical Preparation Retake Planning Before the First Attempt Post-Fail Remediation Workflow Post-Pass Next Steps and Validity
Cloud, On-Premises, Protocols, and Ports
Key Takeaways Explain This Topic AI
On-premises services run on infrastructure the organization owns; cloud services run on provider-managed infrastructure reached over a network.
The same app can be hosted either way, so separate local access, Internet path, DNS, authentication, and provider status when troubleshooting.
Know the purpose of DNS, DHCP, HTTP/HTTPS, SSH, SMTP, IMAP, POP3, FTP/SFTP, SNMP, and NTP.
Well-known port numbers help you read firewall rules and packet captures and identify expected services.
Last updated: June 2026
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.
- Protocol Purpose Transport + port
- DNS Name-to-IP resolution UDP/TCP 53
- DHCP Automatic IP configuration UDP 67 (server), 68 (client)
- HTTP Web (cleartext) TCP 80
- HTTPS Web (encrypted) TCP 443
- SSH / SFTP Secure CLI / file transfer TCP 22
- Telnet Legacy CLI (insecure) TCP 23
- FTP File transfer (control/data) TCP 21 / 20
- SMTP Mail transfer / submission TCP 25 / 587
- IMAP / IMAPS Mailbox access TCP 143 / 993
- POP3 / POP3S Mail download TCP 110 / 995
- SNMP Device polling / traps UDP 161 / 162
- NTP Time synchronization UDP 123
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:
Confirm the basics: is the endpoint connected with a valid IP, mask, gateway, and DNS server?
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.
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)?
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.
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.