Foundation check: worked solutions
Original teaching examples · Activity v1.0 · November 7, 2026. These explanations do not establish exam readiness or eligibility.
Case 1 · The destination is on another subnet
Best choice: The default gateway, because the server is outside the local subnet. The server is outside 192.0.2.0/24. With no more-specific route, the workstation sends the packet through its configured default gateway.
Practice task: On paper, classify 192.0.2.80 and 198.51.100.20 as local or remote for this workstation. Draw the next hop for each; keep the packet destination separate from the gateway address.
Completion check: 192.0.2.80 is local; 198.51.100.20 uses gateway 192.0.2.1 under the stated route assumptions. You can explain why the remote server remains the packet's destination.
Why the other choices miss the requirement
- The DNS resolver, because it forwards traffic to remote networks: DNS supplies name information. It does not become the next-hop router merely because an application uses a hostname.
- The server directly on the local subnet, because both addresses use IPv4: Using IPv4 does not place two hosts on the same subnet. The workstation must consider its subnet mask and routing information.
- The HTTPS service, because port 443 determines the network next hop: A destination port identifies a transport endpoint. The routing decision uses the destination IP address and route information.
Next resource: Review IPv4 addressing and default gateways
Technical references: Microsoft Learn: TCP/IP addressing and subnetting. The case facts are original teaching examples.
Case 2 · The name points to the wrong server
Best choice: Compare the DNS record and cached answer with the approved change. Investigate the record and relevant resolver or client caches against the approved destination. Correct the mismatch through the documented change process; opening a service port cannot rewrite a DNS answer.
Practice task: Make a two-column note: DNS chooses an address; a firewall decides whether a described flow is permitted. Place the wrong A record and an HTTPS deny rule in their respective columns.
Completion check: After an approved correction, a fresh lookup should return the intended address. Then verify the application connection separately, retaining normal certificate validation.
Why the other choices miss the requirement
- Add another TCP/443 allow rule to the approved server: The required path is already allowed. Repeating that rule does not change the address returned for the hostname.
- Replace the workstation's default gateway: The evidence identifies a mismatch in name resolution. It does not show an incorrect gateway.
- Disable certificate checks so the old address can be used: Disabling certificate checks does not correct the DNS answer and would weaken server-identity verification.
Next resource: Work through ports and protocols practice
Technical references: IETF RFC 1035, section 3.4.1: IPv4 address records. The case facts are original teaching examples.
Case 3 · A working connection is only one check
Best choice: Confirm staff TCP/443 succeeds, guest TCP/443 fails, and staff TCP/22 fails; check matched-rule logs. This checks the permitted service and both stated restrictions. Matched-rule logs help confirm that the firewall enforced each expected result.
Practice task: Write a three-row test matrix with source, destination, transport/port, expected outcome and evidence. Use only these fictional flows; this worksheet does not run network tests.
Completion check: Your matrix includes one expected allow and two expected denies. Each row names the matched firewall rule or log evidence you would inspect, rather than treating every connection failure as proof of blocking.
Why the other choices miss the requirement
- Repeat the successful staff TCP/443 test several times: Repeating the allowed path can check consistency, but it does not test whether the prohibited paths are blocked.
- Ping the server from the staff and guest hosts: ICMP echo results do not establish whether the TCP/443 and TCP/22 policy is enforced.
- Confirm that the guest TCP/443 connection fails and stop: That covers one restriction only. It leaves the approved staff service and the staff TCP/22 restriction unverified.
Next resource: Explore the original Security+ PBQ examples
Technical references: NIST SP 800-41 Rev. 1: firewall policy and testing. The case facts are original teaching examples.
Case 4 · Sign-in succeeds, but a file is denied
Best choice: Authentication succeeded, and authorization correctly denied the restricted file. The service recognized the user, then applied the file's access policy. The stated help-desk role has no payroll read permission, so this denial matches the policy.
Practice task: Draw two steps: establish the account identity, then evaluate its permission for a specific resource. Add the allowed support file and denied payroll file as separate examples.
Completion check: You can explain how the same authenticated session can receive different access decisions, and why any new permission needs a legitimate approved task.
Why the other choices miss the requirement
- Authentication failed because the payroll file did not open: The identity check succeeded. A later resource-access denial does not reverse that authentication result.
- Successful authentication should grant access to every file: Proving an identity does not grant unrestricted permissions. Access still depends on authorization for the requested resource.
- The user needs an administrator role to repair the sign-in: The sign-in is already working. Granting broad administrator access would not follow the stated task or the least-privilege principle.
Next resource: Practice access decisions in the PBQ guide
Technical references: NIST: authentication · NIST: authorization · NIST: least privilege. The case facts are original teaching examples.
Case 5 · A service fails after an update
Best choice: Compare the change record, versions and logs, check dependencies, then repeat a controlled health check. Use the recorded change and failure evidence to narrow the cause. Check the installed state and dependencies, and record repeatable results before deciding on an approved fix or rollback.
Practice task: Create a timeline from the four fictional events. Add one hypothesis, the evidence needed to test it, and one repeatable health check. Keep observation and conclusion in separate columns.
Completion check: Your note distinguishes 'failure followed the update' from 'the update caused the failure.' It identifies a controlled check and treats rollback as a decision under the approved change procedure.
Why the other choices miss the requirement
- Declare the update defective because it happened before the failure: The timing makes the update a useful hypothesis, but sequence alone does not establish the cause. A dependency or another change may explain the failure.
- Disable endpoint protection and the firewall before collecting evidence: This changes several variables and weakens controls without evidence that either caused the failure.
- Reinstall every dependency immediately and discard the old logs: Broad changes can erase useful evidence and introduce additional faults. Preserve the timeline and investigate specific differences first.
Next resource: Explore the Security+ lab and tabletop guide
Technical references: NIST SP 800-40 Rev. 4: installing and verifying updates. The case facts are original teaching examples.
Case 6 · The certificate names another service
Best choice: Stop credential entry and verify the intended address and certificate configuration through an approved channel. The hostname mismatch means the intended service identity has not been verified. Investigate the address and certificate configuration without bypassing validation or sending credentials.
Practice task: Compare these two fictional checks: portal.study.example against a certificate naming portal.study.example, and against one naming files.study.example. Record the name-match result separately from trust and validity dates.
Completion check: You can identify the matching and mismatching names and explain why trust, validity dates and service identity all matter. These examples do not ask you to bypass a real browser warning.
Why the other choices miss the requirement
- Enter credentials because a trusted issuer is enough: A trusted issuer does not make a certificate valid for every hostname. The presented identity must also match the intended service.
- Continue because encrypted traffic proves the intended server's identity: Encryption and identity verification are related but distinct checks. An encrypted connection alone does not establish that this is the intended service.
- Change the workstation clock because every certificate error is a date error: The evidence explicitly says the validity-date check passed. Changing the clock does not correct the hostname mismatch.
Next resource: Connect HTTPS to transport and security checks
Technical references: IETF RFC 9525: verifying service identity in TLS. The case facts are original teaching examples.