Lautaro Martinez
Cloud & Infrastructure Engineer
I troubleshoot cloud infrastructure, diagnose network and system issues, and automate operational workflows. Day-to-day work across VMware, AWS, and Azure environments.
About
I work in cloud infrastructure support, diagnosing issues across the full stack — from network connectivity and OS-level behavior to application failures and platform misconfigurations. When something breaks in production, I find out why.
Before cloud, I spent years doing independent IT support and system administration — provisioning servers, configuring networks, writing automation scripts. That operational background shapes how I approach every problem: layer by layer, starting from the infrastructure up.
I also build backend services with Node.js/NestJS and Python, with emphasis on deployment, observability, and writing code that works reliably once it hits a real environment.
Experience
Hitss Argentina
- ›Define repeatable validation workflows for Zabbix agents across service groups — checking both runtime health and boot-time enablement for restart persistence
- ›Work with Zabbix media-type flows involving JavaScript preprocessing, outbound API calls, and event tagging for incident correlation
- ›Investigate abnormal disk consumption by tracing usage down directory trees with du/sort and isolating oversized paths before taking retention decisions
- ›Work through AWS image-based deployment flows, distinguishing what an AMI preserves from what must be managed through launch templates and instance configuration
- ›Perform day-to-day cloud operations including instance resizing, service troubleshooting, and provider-specific tasks across AWS and Azure
Hitss Argentina
- ›Investigate failures across network, OS, application, and platform layers instead of treating incidents as single-layer problems
- ›Identify issues involving NAT/SNAT behavior, routing mismatches, DNS resolution, and SSH algorithm incompatibility
- ›Isolate failures with ss, tcpdump, journalctl, traceroute, curl, and systemd service inspection before escalating — Linux CLI is the first tool, not the last
- ›Coordinate with L3 teams when issues require platform-side changes, keeping root-cause analysis grounded in evidence
- ›Work with monitoring data and logs to detect anomalies early and reduce noisy escalations
Independent
- ›Provision Linux servers and keep them operable end-to-end: SSH access, service startup, firewall policy, package and runtime configuration
- ›Debug environment-level issues affecting developer and operator tooling, including terminal defaults, session managers, and CLI workflows
- ›Resolve real networking and accessibility problems — firewall rule drift, port reachability, cross-platform connectivity — instead of stopping at "service is running"
- ›Automate repetitive tasks with Bash and Python where manual operations become brittle
- ›Built REST APIs with NestJS, PostgreSQL, TypeORM, Docker, and CI/CD pipelines
- ›Served as Teaching Assistant after graduating — mentored students on backend architecture and debugging
Current Focus
Working through Kubernetes in practice, expanding infrastructure automation with scripting and IaC patterns, and improving how I use observability tooling to catch problems earlier.
Tech Stack
Engineering Cases
How I approach diagnostics in production — isolate the layer, verify assumptions, find the root cause.
Symptom
Tried to SSH into a host with a .pem key. Got "sign_and_send_pubkey: no mutual signature supported." The key was valid — other operators were using it fine from different machines.
Investigation
First instinct was to suspect the key file itself, but the error said "no mutual signature," not "invalid key." That pointed to the handshake, not the credential. Checked what my client was offering vs. what the server accepted — turned out the server only supported ssh-rsa, but my client's OpenSSH version had dropped it from the default list. Tested with ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -i key.pem — connected instantly.
Fix
Used the PubkeyAcceptedAlgorithms override as a temporary workaround. Flagged the server for sshd reconfiguration to support ed25519/ecdsa so the override wouldn't be needed long-term.
Symptom
Set up a UFW rule to allow SSH only from 192.168.105.0/24. Ran ufw status — the rule was there. But when I checked iptables -L, the active chain still had an old allow for 192.168.0.0/24 and nothing for the new subnet.
Investigation
The UFW frontend was showing what I expected, but the actual packet filter wasn't enforcing it. Something had gone out of sync — probably a manual iptables edit at some point that prevented UFW from cleanly applying its ruleset. Ran ufw reload, then iptables -L again to verify.
Fix
After the reload, the correct 192.168.105.0/24 rule appeared in the active iptables chains and the stale one was gone. The takeaway was that trusting the frontend output without checking the kernel-level enforcement can give you a false sense of security.
Symptom
Barrier (KVM sharing) running on an Arch host, listening on 24800. From the Ubuntu client, nc -zv to that port succeeded — TCP handshake completed fine. But Barrier itself wouldn't establish a session.
Investigation
The port was reachable and nothing was being filtered, so the network was not the problem. ss -tlnp on the server confirmed the process was listening. The failure was happening above TCP — during Barrier's own protocol negotiation between the two ends. Stopped looking at firewall rules and routing and focused on the application config.
Fix
Fixed it at the application layer. The important part was recognizing early that "I can reach the port" doesn't mean "the service works" — saved time by not chasing network changes that wouldn't have helped.
Projects
REST API handling product catalog, orders, and user management. The focus was on getting the operational side right: containerized deployment, automated pipelines, proper auth, and schema migrations that don't require manual intervention.
Technical Highlights
- ›RBAC with granular permission guards per route — not just admin/user binary
- ›JWT auth with refresh token rotation and expiration handling
- ›Dockerized with multi-stage builds — same image runs in dev and prod
- ›GitHub Actions pipeline: lint, test, build, deploy on every push to main
- ›TypeORM migrations for schema versioning — no manual DDL in production
- ›Swagger/OpenAPI spec auto-generated from decorators, always in sync with code
Stack
Contact
Open to cloud engineering, infrastructure, and backend roles. Let's talk.