# Day 1 — NOC Baseline: mindset, network fundamentals, service reachability

Цель дня: научиться быстро и доказательно отвечать на базовый NOC-инцидент: «сервис недоступен / медленный / нестабильный». Не просто помнить определения OSI, DNS или TCP, а уметь построить проверку, собрать evidence, назвать вероятный слой проблемы и объяснить следующий шаг на собеседовании.

## Результат к концу дня

После Day 1 Артур должен уметь:

- объяснить роль NOC: мониторинг, triage, evidence, escalation, коммуникация;
- пройти L1→L7 troubleshooting flow без хаотичных догадок;
- отличить DNS-проблему, сетевую недоступность, закрытый порт, падение сервиса и application-level ошибку;
- использовать базовые Linux/NOC-команды: `ip`, `ping`, `traceroute`/`tracepath`, `mtr`, `dig`, `curl`, `nc`, `ss`, `tcpdump`, `journalctl`;
- дать короткий incident update и interview answer в стиле production NOC.

## Формат занятия

1. 20 минут — NOC mindset и метод диагностики.
2. 35 минут — OSI/TCP-IP, DNS, ICMP, TCP/UDP, service reachability.
3. 45–60 минут — Fortinet Academy: Operator lessons 01–02, optional 03.
4. 60–90 минут — micro-drills на Linux/VPS или локальной машине.
5. 15 минут — debrief: что было симптомом, что доказали, где был root cause.
6. 30 минут — mock interview: 20 вопросов ниже.

## Academy source for Day 1

Primary course: **FortiGate 7.6 Operator - ENGLISH** — `https://training.fortinet.com/course/view.php?id=67379`.

Course context from the authenticated Academy review:

- Track: **FCA Cybersecurity / FortiGate Operator / NSE 3**.
- Estimated duration: **6.5 hours**.
- Day 1 priority: Lesson 01 **Overview** and Lesson 02 **Configuring System Settings and Basic Networking**.
- Optional if energy remains: Lesson 03 **Firewall Policies**. Only capture high-level route → policy → NAT/session/log bridge; the deep firewall-policy day is Day 3.

Important: use Academy as source material and summarize in your own words. Do not copy protected lesson text, quiz answers, screenshots, or proprietary lab content into this repo.

### What to extract from Lesson 01 — Overview

Keep it practical for NOC/interview readiness:

- Where FortiGate sits in the packet path: client/network edge/firewall/server or internet.
- The operator vocabulary you need early: interface, route, firewall policy, NAT, session, logs, monitoring.
- How FortiGate troubleshooting maps to generic NOC flow: scope → path → port/protocol → policy decision → logs/evidence.
- Interview sentence: “I use the Operator course to translate my production firewall experience into FortiGate terms: interface, route, policy, NAT, session and log evidence.”

### What to extract from Lesson 02 — System Settings and Basic Networking

Focus on baseline checks before blaming “the firewall”:

- System/admin basics: hostname, time/NTP, admin access method, management reachability.
- Interfaces: link/admin status, IP address, role/zone, allowed management protocols.
- DNS: resolver settings and how name resolution affects updates, logging, web filtering, VPN and admin workflows.
- Routing: static/default route and next-hop reachability.
- NOC bridge: before policy troubleshooting, verify that the firewall itself has correct interface/IP/DNS/route basics.

### Optional Lesson 03 — Firewall Policies

Do not try to master policy design on Day 1. Extract only the interview skeleton:

1. Traffic arrives on an ingress interface.
2. FortiGate needs a route toward the destination.
3. A firewall policy must match source, destination, service, schedule and action.
4. NAT/security profiles/logging may change behavior or visibility.
5. Sessions and traffic logs are evidence for allow/deny decisions.

Day 1 wording: “If DNS, route and TCP point to a firewall path issue, I would check the matching FortiGate policy, NAT/session state and traffic logs instead of guessing.”

### FortiGate-to-Linux/NOC mapping

| FortiGate concept | Generic NOC/Linux equivalent | Why it matters in interview |
|---|---|---|
| Interface status/IP | `ip link`, `ip addr`, switch/link state | Proves whether the path can even start. |
| DNS settings | `/etc/resolv.conf`, `resolvectl`, `dig` | Separates resolver/config failure from app failure. |
| Static/default route | `ip route`, `ip route get` | Prevents false “policy issue” conclusions when routing is broken. |
| Admin access | SSH/HTTPS reachability, allowed management service | Explains safe operator access and lockout avoidance. |
| Firewall policy | Linux firewall rule / ACL thought process | Connects Sophos experience to FortiGate terminology. |
| Session/log | `ss`, `tcpdump`, app/firewall logs | Gives evidence instead of opinion. |

### Academy notes template

Use this after each Academy lesson. Keep notes short and original.

```text
Lesson:
Fortinet term:
What it means in my words:
Sophos / Linux / NOC analogy:
Where I would check it during an incident:
Evidence I would collect:
One interview sentence:
Open question / weak spot:
```

Minimum Day 1 notes target:

- Lesson 01: 3 terms or concepts.
- Lesson 02: 5 terms or concepts.
- Optional Lesson 03: 3 terms only — policy, NAT, log/session.

## 1. NOC mindset

NOC-инженер не «угадывает фикс». Он снижает неопределенность:

- фиксирует симптом: кто, что, откуда, когда, насколько массово;
- проверяет impact: один пользователь, один сервис, один сегмент, весь сайт;
- идет от дешевых проверок к дорогим: DNS → reachability → route → port → protocol → app logs;
- собирает evidence: команды, время, IP/hostname, код ответа, packet loss, latency;
- безопасно эскалирует: передает не «не работает», а проверенный контекст.

### Мини-шаблон incident update

```text
Status: investigating / identified / mitigated / resolved
Impact: кто затронут и какой сервис
Evidence: что проверено командами и результатами
Likely layer: DNS / network / transport / application / dependency
Next step: что делаем дальше или кому эскалируем
ETA/next update: когда дадим следующий апдейт
```

Пример:

```text
Status: investigating. Impact: users from office VLAN cannot reach crm.example.com over HTTPS.
Evidence: DNS resolves to 203.0.113.10, ping is filtered/no reply, TCP 443 times out from office but works from mobile hotspot. Likely layer: path/firewall between office and upstream. Next: checking gateway/firewall logs and comparing route from affected VLAN. Next update in 15 min.
```

## 2. Troubleshooting flow: L1→L7 without panic

Практичный NOC-flow для service unreachable:

1. Scope: один клиент или все? один hostname или все сайты? Wi-Fi/VPN/LAN?
2. Name resolution: hostname резолвится? правильный IP? TTL/разные ответы?
3. Local host: есть IP, gateway, route, DNS resolver?
4. Network reachability: есть ли путь до target/gateway? packet loss/latency?
5. Transport: открыт ли порт TCP/UDP? SYN timeout, refused или connected?
6. Protocol: HTTP/TLS/SSH/DNS отвечает корректно?
7. Application: status code, logs, backend dependency, auth, certificate, overload?
8. Evidence + communication: что доказано, что исключено, следующий безопасный шаг.

Важно для собеседования: говорить «я проверю X, потому что это отделяет A от B». Например: «Сначала `dig`, чтобы отделить DNS от network path; потом `curl -v`, чтобы увидеть TCP/TLS/HTTP stage».

## 3. OSI and TCP/IP — только то, что нужно NOC

### OSI layers in troubleshooting language

| OSI | Что проверяем в NOC | Типичные симптомы | Команды |
|---|---|---|---|
| L1 Physical | link/cable/power | interface down, no carrier | `ip link`, switch/NIC LEDs |
| L2 Data Link | VLAN, MAC, ARP | same subnet unreachable, ARP fails | `ip neigh`, switch MAC table |
| L3 Network | IP, route, gateway | no route, wrong subnet, TTL exceeded | `ip addr`, `ip route`, `ping`, `traceroute` |
| L4 Transport | TCP/UDP ports | timeout/refused, firewall, listener missing | `ss`, `nc`, `curl -v`, `tcpdump` |
| L5–L6 Session/TLS | TLS/session/auth negotiation | cert error, handshake fail | `openssl s_client`, `curl -vk` |
| L7 Application | HTTP/API/app logic | 404/500/slow/login fails | `curl -I`, logs, health endpoint |

### TCP/IP model mapping

- Link: physical + Ethernet/Wi-Fi/VLAN.
- Internet: IP routing, ICMP, fragmentation, TTL.
- Transport: TCP/UDP ports, sessions, retransmits.
- Application: DNS, HTTP, SSH, SMTP, FortiGate admin GUI/API, monitoring checks.

Interview shortcut: OSI is a diagnostic checklist, not a religion. In real NOC you often jump between layers but still explain your thinking by layer.

## 4. DNS baseline

DNS converts name to IP and can fail before any application traffic starts.

What to check:

- Does the name resolve? `dig example.com A`, `dig example.com AAAA`.
- Which resolver answered? `dig @1.1.1.1 example.com`, compare with corporate resolver.
- Is the answer expected? wrong private/public IP, stale record, split-horizon DNS.
- Is only IPv6 broken? AAAA record exists but route/firewall for IPv6 fails.
- Is DNS slow? query time high or intermittent timeout.

Useful commands:

```bash
resolvectl status 2>/dev/null || cat /etc/resolv.conf
dig example.com A +short
dig example.com AAAA +short
dig @1.1.1.1 example.com A
dig example.com +trace
```

NOC interpretation:

- `NXDOMAIN`: name does not exist according to DNS.
- `SERVFAIL`: resolver/authoritative problem, DNSSEC, upstream issue.
- timeout: resolver unreachable, firewall, network path, resolver overloaded.
- different answers internal vs public: could be split-horizon DNS; not automatically a bug.

## 5. ICMP baseline

ICMP is useful for reachability and latency, but blocked ICMP does not always mean service is down.

Use it for:

- local gateway reachability;
- packet loss/latency trend;
- approximate path with traceroute;
- quick comparison from affected vs unaffected host.

Avoid this mistake: «ping fails, therefore server is down». Many firewalls block echo-request while TCP/443 still works.

Commands:

```bash
ping -c 4 1.1.1.1
ping -c 4 gateway-ip
tracepath example.com
traceroute example.com 2>/dev/null || tracepath example.com
mtr -rwzc 20 example.com
```

Interpretation:

- first hop unreachable: local gateway/LAN/VPN issue;
- loss only on intermediate hop but final hop clean: likely ICMP rate-limit on router, not outage;
- loss continues to final hop: real path issue or target filtering;
- high latency starts at a specific hop and continues: possible congestion after that point.

## 6. TCP vs UDP for NOC

### TCP

TCP is connection-oriented. It has handshake, sequencing, retransmission, flow control. Good for HTTP(S), SSH, SMTP, many APIs.

NOC symptoms:

- `connection refused`: host reachable, port closed or service not listening;
- `timeout`: packet dropped, firewall/path issue, server overloaded, asymmetric route;
- TLS error after connect: L4 works, problem moves to TLS/app layer.

Commands:

```bash
nc -vz example.com 443
curl -vI https://example.com/
ss -tulpen
```

### UDP

UDP is connectionless. No handshake. Common for DNS, NTP, syslog, some VPN protocols/VoIP.

NOC symptoms:

- harder to prove open/closed without application response;
- packet loss hurts real-time traffic;
- firewall/NAT state/timeouts matter.

Commands:

```bash
dig @8.8.8.8 example.com
nc -vzu 8.8.8.8 53
sudo tcpdump -ni any udp port 53
```

Interview answer: TCP gives reliable ordered delivery with connection state; UDP is lightweight and faster but reliability must be handled by the application if needed.

## 7. Service reachability checklist

For a hostname and port, answer these in order:

```bash
# 1. DNS
host=example.com
dig "$host" A +short

# 2. route/local network
ip addr
ip route get 1.1.1.1

# 3. ICMP/path, if allowed
ping -c 4 "$host"
tracepath "$host"

# 4. TCP port
nc -vz "$host" 443

# 5. protocol/application
curl -vI "https://$host/"

# 6. local listeners, if this host owns the service
ss -tulpen
systemctl status nginx --no-pager
journalctl -u nginx -n 50 --no-pager
```

How to classify results:

| Result | Likely meaning | Next step |
|---|---|---|
| DNS fails | resolver/record/split DNS | compare resolvers, check record/TTL |
| DNS OK, no route | local routing/gateway/VPN | `ip route`, gateway, VPN state |
| ping fails, TCP works | ICMP blocked | do not escalate as outage; test app |
| TCP refused | service down/no listener/wrong port | `ss`, service status, firewall local |
| TCP timeout | firewall/path/drop/server overload | compare source networks, tcpdump/logs |
| HTTP 500 | app/backend issue | logs, dependencies, app owner |
| HTTP 401/403 | auth/policy/WAF issue | verify expected access, policy/logs |
| TLS cert error | certificate/SNI/time/CA | inspect cert, hostname, system time |

## 8. Linux command quick reference

```bash
# Identity and interfaces
hostnamectl
ip -br addr
ip link show
ip route
ip route get 8.8.8.8
ip neigh

# DNS
cat /etc/resolv.conf
resolvectl status 2>/dev/null || true
dig example.com A +short
dig @1.1.1.1 example.com A

# Reachability/path
ping -c 4 8.8.8.8
tracepath example.com
mtr -rwzc 20 example.com

# Ports and services
ss -tulpen
nc -vz example.com 443
curl -vI https://example.com/
systemctl status nginx --no-pager
journalctl -u nginx -n 50 --no-pager

# Traffic proof
sudo tcpdump -ni any host 1.1.1.1
sudo tcpdump -ni any tcp port 443
sudo tcpdump -ni any udp port 53
```

Safety note: in production, avoid destructive commands and avoid flooding (`ping -f`, heavy scans). For interview, mention that you choose minimal checks and coordinate changes.

## 9. Micro-drills

Each drill follows the bootcamp format: scenario, symptom, allowed tools, expected fix, grading rubric.

### Drill 1 — DNS broken vs service down

Scenario: user says `https://portal.example.local` does not open.

Symptom: browser says name cannot be resolved.

Allowed tools:

- `dig`, `resolvectl`/`cat /etc/resolv.conf`, `curl`, `ping`.

Task:

1. Check whether DNS resolves.
2. Compare corporate resolver and public resolver if available.
3. Explain whether this is DNS, network, or application.

Expected fix / answer:

- If DNS does not resolve but direct IP works, classify as DNS/resolver/record issue.
- Escalate with hostname, resolver IP, timestamp, query result, expected zone owner.

Grading rubric:

| Score | Criteria |
|---|---|
| 0–1 | Only says “site down”, no DNS check. |
| 2–3 | Runs DNS check but weak explanation. |
| 4–5 | Proves DNS failure, compares source/resolver, gives clear escalation evidence. |

Debrief question: what would change if DNS resolves to the wrong IP?

Mock interview prompt: “How do you prove a problem is DNS and not the web server?”

### Drill 2 — ICMP blocked but HTTPS works

Scenario: monitoring ping check marks a public web service down.

Symptom: `ping` fails, users can still browse the site.

Allowed tools:

- `ping`, `curl -I`, `nc -vz`, `mtr`.

Task:

1. Run ICMP check.
2. Test TCP/443 and HTTP response.
3. Decide whether this is real outage or bad monitoring check.

Expected fix / answer:

- If TCP/443 and HTTP are healthy, change monitoring from ICMP-only to HTTPS/TCP check or mark ICMP blocked as expected.

Grading rubric:

| Score | Criteria |
|---|---|
| 0–1 | Declares outage from ping only. |
| 2–3 | Tests HTTP but does not explain ICMP limitation. |
| 4–5 | Separates ICMP from service availability and recommends better monitor. |

Debrief question: why can an intermediate router show packet loss in MTR while the final destination is clean?

Mock interview prompt: “Ping fails but the website works. How do you explain it?”

### Drill 3 — TCP refused vs timeout

Scenario: alert says `app01:8443` is unreachable.

Symptom A: `nc -vz app01 8443` returns connection refused.

Symptom B: same command times out from another subnet.

Allowed tools:

- `nc`, `curl -vk`, `ss`, `ip route`, `tcpdump` if on server.

Task:

1. Explain difference between refused and timeout.
2. If on server, check listener with `ss -tulpen`.
3. If from client, compare source networks.

Expected fix / answer:

- Refused: host replied but nothing listens / local firewall rejects.
- Timeout: packet drop/path firewall/asymmetric route/server overload.
- Fix depends on evidence: start service/open listener, correct firewall policy, or route.

Grading rubric:

| Score | Criteria |
|---|---|
| 0–1 | Treats refused and timeout as same. |
| 2–3 | Defines difference but misses source comparison. |
| 4–5 | Uses L4 evidence to choose service vs network/firewall next step. |

Debrief question: what packet would you expect to see in tcpdump for refused vs timeout?

Mock interview prompt: “What does connection refused tell you that timeout does not?”

### Drill 4 — Wrong local route / gateway

Scenario: one Linux host cannot reach internet, same VLAN hosts can.

Symptom: DNS may fail, ping to 8.8.8.8 fails, local IP exists.

Allowed tools:

- `ip -br addr`, `ip route`, `ip route get`, `ping gateway`, `tracepath`.

Task:

1. Verify IP address and default route.
2. Ping default gateway.
3. Explain whether issue is local host, gateway, or upstream.

Expected fix / answer:

- Missing/wrong default gateway: correct route/network config through normal change path.
- Gateway unreachable: L2/VLAN/NIC/switch path issue.

Grading rubric:

| Score | Criteria |
|---|---|
| 0–1 | Starts with random public pings only. |
| 2–3 | Checks route but weak conclusion. |
| 4–5 | Proves local route/gateway state and scopes issue to one host/VLAN/upstream. |

Debrief question: why test gateway before public IP?

Mock interview prompt: “A server has an IP but no internet. What do you check first?”

### Drill 5 — HTTP error after network is fine

Scenario: monitoring says API health is failing.

Symptom: DNS resolves, TCP connects, HTTPS returns `500 Internal Server Error`.

Allowed tools:

- `dig`, `nc`, `curl -v`, service logs if allowed.

Task:

1. Prove DNS and L4 are healthy.
2. Capture HTTP status and headers.
3. Escalate to app/backend owner with network evidence.

Expected fix / answer:

- Classify as application/backend dependency issue, not network outage.
- Provide HTTP status, request ID if present, timestamp, source IP, endpoint.

Grading rubric:

| Score | Criteria |
|---|---|
| 0–1 | Keeps debugging network after HTTP 500. |
| 2–3 | Identifies app issue but lacks evidence. |
| 4–5 | Cleanly proves lower layers, gives useful app escalation package. |

Debrief question: what if HTTP returns 403 instead of 500?

Mock interview prompt: “How do you know when to stop network troubleshooting and escalate to application?”

## 10. Debrief template

Use this after each drill:

```text
Scenario:
Symptom:
Commands run:
Key evidence:
Layer classification:
Root cause or likely root cause:
Fix / escalation:
How I would explain it in 30 seconds:
What I would monitor to avoid repeat:
```

## 11. 20 interview questions with model answers

### 1. What is the role of a NOC engineer?

Model answer: A NOC engineer monitors infrastructure, triages alerts, verifies impact, performs first-line troubleshooting, communicates status, and escalates with evidence when deeper network/security/system ownership is needed. The key is not only fixing issues but reducing uncertainty quickly and keeping stakeholders informed.

### 2. How do you troubleshoot a service unreachable alert?

Model answer: First I scope the impact: affected users, source network, service, time. Then I check DNS resolution, local route/gateway, reachability, TCP/UDP port, protocol response, and logs if I own the service. I document evidence such as `dig`, `curl -v`, `nc`, MTR, timestamps, and then either fix the proven cause or escalate with a clear package.

### 3. Explain OSI model in a practical troubleshooting way.

Model answer: I use OSI as a checklist. L1/L2 are link, VLAN, ARP. L3 is IP and routing. L4 is TCP/UDP ports and sessions. L7 is the actual application response. In practice I may jump between layers, but I explain which layer I have proven healthy or broken.

### 4. What is the difference between OSI and TCP/IP models?

Model answer: OSI has seven conceptual layers and is useful for structured troubleshooting. TCP/IP is the practical internet model: link, internet, transport, application. For NOC work, the exact model matters less than isolating whether the issue is link, route, transport, or application.

### 5. What does DNS do, and how can it fail?

Model answer: DNS maps names to records such as A/AAAA/CNAME. It can fail with NXDOMAIN, SERVFAIL, timeout, wrong/stale record, split-horizon mismatch, or IPv6 record that clients cannot actually reach. I test with `dig`, compare resolvers, and verify the returned IP is expected.

### 6. How do you prove a problem is DNS?

Model answer: I compare hostname and direct IP behavior. If direct IP or known endpoint works but hostname fails or resolves incorrectly, the evidence points to DNS. I also compare corporate and public resolver responses and include query output, resolver IP, timestamp, and expected record in escalation.

### 7. What is ICMP used for?

Model answer: ICMP supports diagnostics and control messages, including echo request/reply for ping and TTL exceeded for traceroute. It helps check reachability, latency, and path behavior, but it can be filtered or rate-limited, so ICMP failure alone does not prove the application is down.

### 8. Ping fails but HTTPS works. What does that mean?

Model answer: It usually means ICMP is blocked or deprioritized while TCP/443 is allowed. I would verify with `curl -I` or `nc -vz host 443`. For monitoring, I would recommend an HTTPS or TCP check instead of ICMP-only for that service.

### 9. What is the difference between TCP and UDP?

Model answer: TCP is connection-oriented with handshake, ordering, retransmission, and flow control, so it is used for HTTP, SSH, SMTP and many APIs. UDP is connectionless and lightweight, used for DNS, NTP, syslog, VoIP, and VPN cases where low latency or application-managed reliability matters.

### 10. Explain TCP three-way handshake.

Model answer: The client sends SYN, the server replies SYN-ACK, and the client sends ACK. After that the connection is established. If SYN gets no response, I think timeout/drop/path/firewall. If the server sends RST, I think closed port or rejecting service.

### 11. What is the difference between connection refused and timeout?

Model answer: Refused means the destination host or firewall actively rejected the connection, often because no service listens on that port. Timeout means packets are being dropped or no reply returns, which can be firewall, routing, asymmetric path, or overload. The next troubleshooting path is different.

### 12. DNS resolves but the application still fails. What next?

Model answer: I move down the flow: route to the IP, TCP/UDP port, TLS/protocol, then application status. For HTTPS I use `curl -vI` to see whether failure happens at TCP connect, TLS handshake, or HTTP response. DNS success only proves name resolution, not service health.

### 13. How do you check if a service is listening on Linux?

Model answer: On the server I use `ss -tulpen` to list listening TCP/UDP sockets and process info. I also check `systemctl status <service>` and recent logs with `journalctl -u <service>`. From a client I test the port with `nc -vz` or the real protocol with `curl`.

### 14. What does `curl -v` help you see?

Model answer: It shows DNS resolution, TCP connection, TLS handshake details, HTTP request/response headers, status code, redirects, and certificate errors. It is useful because it tells me at which stage the request fails instead of only saying “site not working”.

### 15. What information do you include when escalating to network/firewall team?

Model answer: Source IP/subnet, destination IP/hostname/port/protocol, time window with timezone, command outputs, expected behavior, actual behavior, affected scope, and whether other sources work. For firewall cases I add whether it is timeout/refused and any packet capture evidence.

### 16. What is service reachability?

Model answer: It means not just that an IP responds to ping, but that the required application endpoint is reachable from the right source over the right protocol and port and returns expected behavior. For a web app that means DNS, route, TCP/443, TLS, and HTTP health all matter.

### 17. How do you distinguish network issue from application issue?

Model answer: I prove lower layers first. If DNS resolves, route exists, TCP connects, TLS completes, and the app returns HTTP 500, that is likely application/backend. If TCP times out from one subnet but works from another, that is more likely path/firewall/routing. The evidence decides.

### 18. What is MTR/traceroute useful for, and what is its limitation?

Model answer: It helps visualize the path and where latency or loss begins. The limitation is that routers may rate-limit or deprioritize ICMP/TTL-expired replies, so loss on an intermediate hop is not necessarily a problem unless it continues to the destination or correlates with the symptom.

### 19. What is a good NOC handover?

Model answer: A good handover includes current status, impact, timeline, what was checked, key evidence, suspected layer/root cause, actions taken, pending actions, owners, and next update time. It should let the next engineer continue without repeating basic checks.

### 20. Tell me about your troubleshooting mindset.

Model answer: I try to stay calm and evidence-driven. I start with scope and simple checks, isolate by layer, compare affected and unaffected paths, avoid risky changes without proof, and communicate frequently. My goal is to restore service safely and make escalation useful if the issue belongs to another team.

## 12. Day 1 pass criteria

Day 1 is passed when Artur can do all of this without notes:

- give a 30-second NOC troubleshooting flow;
- explain TCP vs UDP and connection refused vs timeout;
- run `dig`, `ping`, `tracepath`/`mtr`, `nc`, `curl -v`, `ss` and explain output;
- classify at least 4/5 micro-drills by layer and next step;
- answer at least 16/20 interview questions clearly and without long rambling;
- write a short incident update with impact, evidence, likely layer, next action.

## 13. Homework

### A. Academy homework

1. Open **FortiGate 7.6 Operator - ENGLISH**: `https://training.fortinet.com/course/view.php?id=67379`.
2. Complete/watch Lesson 01 **Overview** and Lesson 02 **Configuring System Settings and Basic Networking**.
3. Optional: watch Lesson 03 **Firewall Policies** only for the high-level packet-flow bridge; do not go deep yet.
4. Fill the Academy notes template above:
   - Lesson 01: 3 concepts minimum.
   - Lesson 02: 5 concepts minimum.
   - Optional Lesson 03: policy/NAT/session/log in 3 bullets.
5. Write one sentence that connects Sophos production experience to FortiGate operations without pretending to be FortiGate-certified.

### B. NOC evidence homework

Pick three real targets:

1. one public website over HTTPS;
2. one SSH host or known TCP service;
3. one DNS resolver.

For each, run DNS/reachability/port/protocol checks and save evidence. Then classify the likely layer if the target were failing: DNS, local route, network path, transport, firewall/policy, application.

Recommended evidence file format:

```text
Target:
Source:
Time:
DNS result:
Route/ping/MTR result:
Port/protocol result:
Conclusion:
Interview-ready answer:
```

### C. Interview outputs to produce

By the end of Day 1, write and rehearse these outputs:

1. **60-second answer:** “How do you troubleshoot a service unreachable alert?”
2. **45-second answer:** “How does your Sophos firewall experience transfer to FortiGate?”
3. **30-second Academy progress story:** “I started FortiGate 7.6 Operator lessons 01–02 to map my NOC/firewall experience into Fortinet terminology.”
4. **5-line incident update** using the template from section 1.
5. Rehearse questions 2, 8, 11, 15, 17, and 20 out loud.

### D. Grading rubric for Day 1 homework

| Score | Criteria |
|---|---|
| 0–1 | No Academy notes, only generic commands, cannot explain evidence. |
| 2–3 | Has basic notes and commands, but weak FortiGate mapping or interview wording. |
| 4 | Clear NOC flow, useful evidence, Academy lessons 01–02 summarized in own words. |
| 5 | Strong interview-ready answers, Sophos→FortiGate bridge, and clean incident update with likely layer/next owner. |