Cybersecurity Career Foundations · Beginner · ~8 hours
Networking & Internet Fundamentals
Learn how devices and services communicate across local networks and the internet.
Status: Catalogue ready. This lesson version is available in review mode while subject-matter, accessibility and assessment checks are completed.
How networks deliver services
Network boundaries and addressing
By the end of this lesson
- Describe the difference between a device, interface, network and service endpoint.
- Explain private and public addressing at a conceptual level.
- Use network boundaries to reason about exposure, trust and troubleshooting ownership.
A network is a set of connected decisions
A network allows systems to exchange information, but it is not a single invisible cloud. It is a set of connected devices, interfaces, paths, rules and services. A laptop may have a wireless interface, a phone hotspot may provide another path and a web application may be reachable through several managed services before it reaches the application itself. The useful beginner question is not “where is the internet?” but “which systems are connected, through which boundary, using which address and under whose control?” An address identifies a destination at a particular layer and scope. On an IP network, an IP address helps a packet reach an interface or routing domain. A private address is normally used inside an organisation or local environment and is not directly reachable from the public internet. A public address is globally routable through the internet, although a service may still have additional controls in front of it. Network address translation can allow many private devices to share a public address, but it does not replace application authentication or authorisation. These terms describe reachability, not trustworthiness. A subnet or network segment groups addresses according to a routing plan. Teams may separate staff devices, guest devices, servers, management systems and sensitive workloads so that a mistake in one area is less likely to affect another. Boundaries can be physical, virtual or policy-based. A firewall or security group may permit only selected traffic between segments. Segmentation is not a claim that a zone is automatically safe; it is a way to make allowed communication deliberate and easier to review. The same service can have several identities: a public hostname, a private address, a load-balancer endpoint and an internal service name. Good diagrams label these carefully. Avoid publishing real addresses, credentials or sensitive topology in learning work. Use fictional names and simplified flows. The purpose of the model is to understand ownership and safe communication, not to reveal a real organisation's attack surface.
Boundaries clarify responsibility
When a user reports that a portal is unavailable, boundaries help divide the question into manageable parts. Is the device connected to a local network? Can it resolve the service name? Can it establish the expected transport connection? Is the service returning a response? Are other users or regions affected? Each question produces evidence and points to a different owner. A support adviser should record what was observed and the time of the observation rather than guessing that the application team is at fault. Trust boundaries are also business boundaries. A managed office network may be operated by one team, a hosted platform by a supplier, and the application by a product team. An external identity provider may determine who can sign in, while the application determines which records they may view. Contracts, service-level expectations and escalation paths should reflect these divisions. A technical diagram that does not show ownership can create delays during an outage or security review. Network access should follow the principle of least connectivity. A service should accept only the traffic needed for its purpose, and administration paths should be separate from ordinary customer paths where possible. Rules should have an owner, a reason and a review date. Temporary access for a migration or support event should not remain forever. Logging at the boundary can help explain what was allowed or denied, but logs should be protected and designed to avoid unnecessary personal information. A learner can practise this without touching a live system: draw a fictional diagram with a user device, local network, boundary control, public service endpoint and application. Mark which team owns each component and which observations are safe to collect. That exercise builds a reliable mental model without requiring scanning, probing or any activity outside explicit permission.
Workplace example
A fictional retailer's customer portal has a public web endpoint, a private application network and a separate data service. When users report errors, support records whether the name resolved, whether the service responded and whether the issue is widespread before escalating to the correct owner.
Try this walkthrough
- 1.Draw a five-step fictional path from user device to application service.
- 2.Label each boundary, address scope and owner.
- 3.Write three observations a support person can make safely without probing an unauthorised system.
- 4.Identify one rule that should have a reason and review date.
Watch for these traps
- Treating a private address as proof that a system is safe.
- Confusing reachability with authentication or authorisation.
- Publishing real topology or endpoints in an educational exercise.
- Escalating an outage without recording time, scope and observable evidence.
Knowledge check
Choose the response you think is strongest. These checks are practice until the course version has passed subject-matter review; graded attempts will be handled server-side.
For the reviewed pilot, answers are checked on the server. This draft result is not yet added to your official learning record.
Practice studio
Make a decision. Test a response. Leave evidence.
Use the case from this lesson to practise judgement without creating a score or changing your course record.
Scenario decision
A fictional retailer's customer portal has a public web endpoint, a private application network and a separate data service. When users report errors, support records whether th…
Choose a response
Branching roleplay
A colleague asks you to move this situation forward. What do you say next?
Evidence workspace
Draft a short known / assumed / next note from the fictional case. Use fictional details only.
This is a session-only practice draft. It is not saved, graded or added to your learning record. Never enter real personal or confidential information.
Practical assignment
Create a fictional network-boundary diagram for a customer portal. Include a user device, local network, public endpoint, application boundary and data service, plus the owner and evidence for one safe support check at each step.
Pass this lesson's knowledge check before recording it as complete.
Portfolio evidence
Practical portfolio project
Interpret a fictional network diagram, trace a connectivity issue and document the troubleshooting steps.
Turn the practical project into a bounded evidence record. Save a draft while you work, then submit it for human review when it is ready.
Sign in to save practical evidence. Sign in