4A0-104 Nokia Services Architecture: SAPs, SDPs, and Service-Router Design

Nokia 4A0-104, Services Architecture, is a current Service Routing Certification exam that develops the service model used on Nokia routers. Nokia lists it for both Network Routing Specialist II (NRS II) and Service Routing Architect (SRA) knowledge. The associated course focuses on how customer attachment, service distribution, and service types are represented and operated on the Nokia Service Router platform.

The exam becomes easier when candidates separate three questions: where does customer traffic enter, how does it cross the provider network, and what service behavior should the far edge apply? Service access points, service distribution points, transport tunnels, and service identifiers answer different parts of that sequence. Mixing those roles together makes configuration appear arbitrary.

Within the Nokia ecosystem, 4A0-104 connects foundational routing and MPLS to actual customer services. It is therefore less about learning one protocol and more about understanding how several pieces become an operational service that can be provisioned, monitored, protected, and troubleshot.

Service architecture starts with the boundary between customer and provider

A service provider must know where customer traffic enters its managed domain and what treatment that attachment requires. On Nokia systems, a service access point represents an important part of that customer-facing boundary. Candidates should understand how a physical or logical access interface becomes associated with a specific service rather than thinking of the interface alone as the service.

This distinction matters during faults. A port can be operational while the SAP or service binding is wrong. Conversely, a correct service configuration cannot carry traffic through an administratively down or mismatched access interface. Troubleshooting should therefore check physical access, encapsulation, SAP state, and service membership as separate pieces of evidence.

SDPs describe service transport relationships across the provider network

A service distribution point represents connectivity between provider edges for service delivery. Candidates should understand why a service may need a spoke or mesh relationship, how the SDP relies on underlying transport, and why an apparently healthy service object can still fail when the tunnel beneath it is unavailable.

The transport relationship is clearer after studying 4A0-103 MPLS. MPLS explains how traffic reaches another provider edge; Services Architecture explains what service context is carried across that reachability. Keeping those layers distinct makes service faults easier to isolate and prevents the assumption that every unreachable customer is automatically an MPLS problem.

Layer 2 and Layer 3 services expose fundamentally different behavior

A Layer 2 service extends Ethernet-like connectivity, while a Layer 3 service provides routed separation and forwarding. The provider therefore learns or maintains different kinds of information and exposes different expectations to the customer. Candidates should be able to identify which service type fits a requirement before considering detailed configuration.

If the customer expects remote sites to share a broadcast domain, the design questions differ from a routed VPN in which each site exchanges prefixes. The later 4A0-105 VPLS and 4A0-106 VPRN exams deepen those two models. 4A0-104 should provide the common architecture that lets candidates compare them cleanly.

Service identifiers and objects should be read as relationships, not isolated numbers

Operational service configurations contain identifiers for services, customer contexts, access points, tunnels, and other objects. Memorizing numeric examples is a poor study strategy because production values vary. Instead, practice explaining which objects must refer to one another and what state should appear when the relationship is correct.

When reading a configuration, draw a small dependency map: customer-facing attachment, service object, transport relationship, far-end service, and any routing or MAC-learning context. Then use operational output to validate each edge in that map. This creates a reusable method that works even when the exam changes interface labels or topologies.

OAM and verification turn a configured service into an operable service

A service is not complete when the CLI accepts the configuration. Engineers need ways to verify continuity, isolate a failure domain, and confirm that traffic follows the intended path. Basic operations, administration, and maintenance concepts help distinguish a customer-access problem from a provider-core problem and provide evidence before changes are made.

Build labs with a known-good baseline. Record service state, tunnel state, relevant learned information, and a simple connectivity result. Then introduce one controlled failure—such as an access shutdown or transport break—and observe which indicators change. The correlation between service symptoms and underlying state is exactly what turns memorized configuration into troubleshooting skill.

Resiliency should be designed at both transport and service layers

A protected MPLS path does not automatically guarantee that every service attachment is redundant, and a redundant service design cannot overcome a completely unavailable provider core. Candidates should identify which failure is protected by which mechanism. Dual access, redundant service paths, and protected transport solve different problems and may need to work together.

Failure-domain thinking is more useful than counting duplicate components. Two service paths that depend on the same physical link or router may not be meaningfully diverse. During preparation, mark shared dependencies on the topology and ask what happens after each failure. This exposes designs that look resilient on paper but fail under a realistic outage.

Service troubleshooting should walk from attachment to transport to remote edge

A disciplined workflow begins with the customer-facing SAP and confirms encapsulation and state. Next verify that the service itself is operational and associated with the correct SDP or transport. Then check the far-end service and customer attachment. For Layer 2 services, learned MAC information may reveal where traffic stops; for Layer 3 services, routes and next hops provide equivalent evidence.

Avoid changing several layers at once. If a service recovers after simultaneous access, tunnel, and policy changes, the engineer has not learned the cause and may have introduced a new risk. Exam preparation should reward minimal, evidence-driven changes because that is the approach needed in production service-provider networks.

NRS II and SRA use Services Architecture in different but overlapping ways

In the current NRS II path, 4A0-104 is paired with routing, BGP Fundamentals for Services, and MPLS before the practical lab. That combination creates a general service-routing engineer. SRA then expands the service scope into architect-level BGP, VPLS, VPRN, QoS, EVPN, and a longer practical assessment.

The same 4A0-104 concepts therefore act as a bridge. A candidate who understands SAPs, SDPs, and service dependencies can learn more complex service control planes without losing track of what the network is delivering to the customer. Treat the exam as architecture literacy rather than a collection of syntax.

Final review should use complete service walks in both directions

For each lab topology, explain how a frame or packet enters at one customer site, which service object receives it, how it traverses the provider network, and how the remote edge delivers it. Then reverse the direction. Asymmetry is important because one direction can work while the return path fails due to learning, routing, or policy differences.

After the walk, remove one dependency and predict the operational output that should change first. This combines architecture and troubleshooting in one exercise. If the prediction is wrong, revisit the relationship between access, service, and transport instead of memorizing a corrective command.

4A0-104 rewards a clear service model. Candidates who can draw the customer attachment, service object, provider transport, and remote attachment will find configuration and troubleshooting far easier to reason about.

The exam remains current in Nokia’s 2026 program and supports both NRS II and advanced service-routing knowledge. Verify any announced 2027 program updates before scheduling, but keep the preparation centered on durable architecture rather than release-specific screenshots.

Service provisioning exercises should begin with a written intent statement: which customer sites must communicate, at which layer, with what encapsulation and resilience. Only then should configuration objects be selected. This prevents a common lab habit in which candidates create SAPs and SDPs because a worksheet says so without understanding why the service needs them. Intent-first design also makes verification criteria obvious.

Customer-facing encapsulation deserves careful attention because the provider must map incoming frames or packets into the correct service. A physical port can carry more than one logical attachment, and a mismatched tag or encapsulation value can send otherwise valid traffic to the wrong context or nowhere at all. Include access classification in troubleshooting before blaming the provider core.

Management and operational state should be distinguished from administrative configuration. An object may be configured and enabled yet operationally down because a dependency is missing. Learn to read both sides of that distinction. When a service is down, identify which lower-level object is preventing it from becoming operational rather than repeatedly toggling the service itself.

Change control is especially important on shared provider infrastructure. A modification to a transport relationship or common object can affect several customer services at once. Before making a change, identify dependent services and establish a rollback plan. This systems thinking is part of architecture competency because the blast radius of a change matters as much as whether the new configuration is syntactically correct.

Finally, practice explaining a service to two audiences. The customer needs a simple statement of connectivity and expected behavior; the network engineer needs the exact attachment, transport, and operational dependencies. Being able to move between those views proves that the architecture is understood rather than merely configured.

Configuration review should also verify naming and documentation. Service IDs, customer references, descriptions, and operational conventions help engineers connect a CLI object to a business service during an incident. Inconsistent labels do not always break forwarding, but they increase troubleshooting time and raise the risk of changing the wrong service. A production-quality design therefore includes traceable naming as part of the technical implementation.

Candidates can test architecture understanding by rebuilding a service from operational output alone. Given the SAP, SDP, service state, and learned information, sketch the likely topology and dependencies. This reverse-engineering exercise is valuable because support engineers often inherit networks they did not design. It proves the learner can infer relationships rather than only follow a build procedure.