Infrastructure / Delivery & labs

Systems, with their boundaries visible.

A view of how this portfolio ships and how the personal Azure and identity labs are designed. Each diagram names what is deployed, what is authored and what still needs runtime evidence.

01 / Portfolio delivery

Static content, checked before release.

GitHub Pages deployed; verified 9 September 2026. GitHub Actions validates the generated surface, stages only public files and uploads a Pages artifact before the deployment job can publish it.

Portfolio source flows through dependency-light validation and GitHub Actions into a scoped GitHub Pages artifact. A deployment job publishes the artifact to the user site after merge, while the retired Azure resource definition remains historical evidence only. — The production origin is `yossefseit.github.io`. The deployment job uses `pages: write` and a short-lived OIDC token; it stores no Azure credential. The public routes and byte-identical CV were verified on 9 September 2026. Open successful deployment ↗

Source & checks

Dependency-light by design

Semantic HTML, shared CSS and vanilla JavaScript are checked for local links, headings, metadata, meta CSP consistency and syntax before delivery.

Hosting

GitHub Pages

The checked-in workflow packages only the public static surface. A github-pages environment receives the artifact after a validated main update.

Historical boundary

Retired Azure definition

infra/main.bicep records the former Static Web App shape for review. It is not part of the current delivery path and no live Azure resource is claimed.

View source Architecture notes

02 / Personal Azure networking lab

Secure Azure Hub-and-Spoke.

Lab: CI validated; Azure deployment pending. A private-by-default Bicep design with three VNets, explicit peering, isolated spokes and Blob access through Private Link.

Authored Azure topology with a hub VNet peered to application and data spokes, a Blob private endpoint in the app spoke, private DNS linked to hub and app, and Blob diagnostics sent to Log Analytics. — Hub peering is not transitive. There is no direct app-to-data peering, Azure Firewall, gateway or public IP in the baseline. Select the diagram to open a scalable version.

Address plan

Three trust zones

Hub 10.0.0.0/16, app 10.10.0.0/16 and data 10.20.0.0/16, with NSGs, ASGs and cross-spoke blackhole routes.

Private service path

Endpoint and DNS together

The Blob private endpoint sits in the app spoke. The private DNS zone links to the hub and app only; public network access is disabled.

Optional validation

Compute stays off

The private test VM and VNet flow logs default to disabled. A live connectivity and isolation run remains pending.

Read case study Open repository

03 / Personal Azure governance lab

Guardrails with a deliberate lifecycle.

Lab: CI validated; Azure deployment pending. Subscription-scoped Bicep for audit-first policy, bounded access, cost notifications and a protected governance resource group.

Offline Bicep and guard checks lead to reviewed Bash and PowerShell operations, then an authored subscription baseline containing an audit-first policy initiative, budget alerts and a protected governance resource group. — The default path audits without modifying resources. Enabling Modify creates an identity and role assignment; remediation remains a separate opt-in. A budget raises alerts and does not cap spending.

Policy

Audit before enforcement

Three custom definitions form one initiative. Required resource-group tags and allowed locations default to Audit; tag inheritance starts Disabled.

Cost signal

Actual and forecast alerts

A subscription budget routes notifications to an action group. The example deliberately contains no personal receiver.

Lifecycle

Ownership before cleanup

Scripts check subscription context, review what-if, require exact confirmation and use a manifest to guard deletion.

Read case study Open repository

04 / Personal identity lab

Samba Active Directory, isolated.

Lab: CI validated; runtime validation pending. Guarded Ubuntu automation for a first domain controller, DNS-based discovery, Kerberos, signed time, verification and recovery planning.

Administrator and Windows client use an isolated Ubuntu Samba domain controller that provides DNS, Kerberos, LDAP, SMB and signed time, with upstream DNS and time plus an operator-managed offline backup path. — The scripts create a root-only local archive and checksum. Encrypted offline retention is an operator step. Provisioning, client authentication and recovery evidence remain pending.

Read case study Open repository

All lab diagrams describe Yossef’s personal portfolio work. They do not represent Electrolux, Aegis, El Mostafa or any employer system.