Module 20 Lesson 3 of 6 🕑 ~50 min

> cat module-20-3-portfolio-applying.md

Building a Portfolio & Applying Strategically

A portfolio demonstrates capability beyond a certificate. This lesson covers which projects are worth building, how to apply without either giving up after three rejections or blasting hundreds of irrelevant applications, and how to walk into an interview already knowing something about the company.

1 Building a Portfolio

Four project types cover most of what this course has taught, and each demonstrates something specific:

  • Active Directory project — Windows Server → Active Directory → Windows client → users/groups → Group Policy. Document domain creation, DNS, user creation, Group Policy, authentication, and troubleshooting (Module 19's home lab is exactly this project, already built).
  • SOC investigation — document a simulated incident with a real timeline (e.g. failed login, failed login, successful login, PowerShell execution, suspicious outbound connection) and explain what happened, which logs you reviewed, what indicators looked suspicious, what you'd investigate next, and how you'd contain it.
  • IAM project — Application → Identity Provider → Authentication → MFA → Token → Application Session, explaining SAML, OAuth, OpenID Connect, MFA, claims, and access tokens along the way.
  • API project — demonstrate a call in Postman or PowerShell (GET /users with Authorization: Bearer <token>), then deliberately produce 401, 403 and 404 responses and explain the troubleshooting process for each.

2 Portfolio Quality Over Quantity

Ten incomplete projects are worth less than three well-documented ones. A strong project follows the same shape as real engineering work: problem → environment → investigation → technical work → troubleshooting → result → lessons learned. A reviewer skimming your GitHub can tell within seconds whether a project follows that shape or whether it's just a screenshot with no explanation — the shape matters more than the topic.

3 Applying for Jobs Strategically

Two common mistakes: applying to three jobs and getting discouraged, or applying to hundreds of completely unrelated jobs. The better approach is targeted volume — identify job families (IT Support, Service Desk, Technical Support, Desktop Support, Junior Sysadmin, NOC Analyst, SOC Analyst, IAM Analyst, Cybersecurity Analyst, Cloud Support) and apply to those consistently.

Don't treat every requirement as absolute — a posting saying "2 years experience" often describes the ideal candidate, not the minimum viable one, and if you understand most of the core technology it's worth applying anyway. But be realistic too: a role requiring 10 years of security architecture, CISSP, AWS enterprise architecture, Kubernetes, Terraform, Python and team leadership is not an entry-level role. Spend your time where you have a credible chance.

4 Researching the Company

Before an interview, research what the company does, where it operates, who its customers are, its major products, its technology environment if publicly known, recent announcements, the role itself, and the team's likely responsibilities. You should be able to answer "Why do you want to work here?" without saying "Because I need a job" — the difference between a generic answer and a specific one is almost entirely a function of five minutes of research beforehand.