DEV Community

Tejas Shinkar
Tejas Shinkar

Posted on

AWS VPC Extended — Route Tables, Blackhole Routes, Flow Logs, VPC Endpoints & Transit Gateway

#aws #cloud #devops #beginners

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This builds directly on the previous VPC session — going deeper into how routing actually decides where traffic goes, and how VPCs connect privately to AWS services and to each other.

This is dense, interconnected material — the goal here isn't to memorize every term on the first pass, but to build a reference to come back to once the full picture settles.

📋 Topics Covered

# Topic Type
1 Route Table — The Traffic Director Concept
2 Destination vs Target Concept + Analogy
3 Longest Prefix Match — Deep Dive with Scenarios Concept + Interview
4 Route Propagation Concept + Cert
5 Static Routes vs Propagated Routes Concept + Interview
6 Blackhole Routes Concept + Interview
7 Managed Prefix Lists Concept + DevOps
8 Edge Ingress Route Table Association Concept + Cert
9 Troubleshooting Checklist — Traffic Not Reaching EC2 Interview + DevOps
10 VPC Flow Logs Concept + Lab
11 VPC Endpoints — Gateway vs Interface Concept + Interview
12 VPC Endpoint Policy Concept + Cert
13 Transit Gateway Concept + DevOps
14 Interview Questions Interview
15 Practice Scenarios Practice

Route Table — The Traffic Director

A Route Table is the rulebook that decides where every packet goes next, based purely on its destination IP address. Every subnet is associated with exactly one route table, and every route table contains one or more rules.

Analogy: A route table is GPS navigation for your network. You type in a destination (IP address), and the GPS tells you which road (target) to take. If multiple roads could technically get you there, GPS picks the most direct, specific route — not the broadest general highway.

Basic structure:

Destination Target
10.0.0.0/16 Local
0.0.0.0/0 nat-0abc123

Destination vs Target — The Core Distinction

This is the single most important mental model for understanding routing.

Destination = WHERE you're going (the IP range you're trying to reach)
Target = HOW you get there (which gateway/component forwards it)

The analogy:

  • Destination: Mumbai → Target: Mumbai-Pune Expressway
  • Destination: Pune → Target: Local roads (already there)
  • Destination: Anywhere else → Target: National Highway (catch-all)

In AWS terms:

Destination Target Meaning
10.200.0.0/16 Local VPC's own network — no gateway needed
0.0.0.0/0 igw-0a1b2c3d Anywhere else — go through Internet Gateway
172.31.0.0/16 pcx-0x1y2z3 Peered VPC — go through Peering Connection
192.168.0.0/16 vgw-0p1q2r3 On-premise network — go through VPN Gateway

Possible targets in a route table:

Target What it connects to
local Always present — traffic within the VPC's own CIDR
Internet Gateway (igw-) Public internet
NAT Gateway (nat-) Internet, for private subnet outbound only
VPC Peering Connection (pcx-) Another VPC (peered)
Virtual Private Gateway (vgw-) On-premise network via VPN
Transit Gateway (tgw-) Multiple VPCs/networks via central hub
VPC Endpoint Specific AWS service, privately

Longest Prefix Match — Deep Dive with Scenarios

This is the rule AWS uses whenever a destination IP could match more than one route in the table. AWS always picks the route with the most specific (longest) prefix — not the broadest one.

Core rule: A more specific CIDR (larger number after the /) always wins over a broader CIDR (smaller number). /32 beats /24 beats /16 beats /0 (most specific → least specific catch-all).

Scenario Comparisons:

Scenario 1 — Basic internet vs local

Route Table Traffic to 10.200.0.55 Traffic to 8.8.8.8
10.200.0.0/16 → Local
0.0.0.0/0 → IGW 		Matches /16 (more specific)
→ Local ✅		 Doesn't match /16
Matches /0 (catch-all)
→ IGW ✅

Because 8.8.8.8 doesn't fall within the VPC's CIDR, the only matching route is the default 0.0.0.0/0, so it goes to the Internet Gateway.

Scenario 2 — Peered VPC with overlapping catch-all

Route Table Traffic to 172.31.5.10 Traffic to 142.250.1.1 (Google)
10.200.0.0/16 → Local
172.31.0.0/16 → pcx-xyz
0.0.0.0/0 → IGW 		Matches /16 peering route
→ Peering Connection ✅		 No specific match
Falls to /0 catch-all
→ IGW ✅

The peering route is the only specific match for the peered VPC's range — it wins over the general internet catch-all route.

Scenario 3 — Specific /24 override within a /16

Route Table Traffic to 10.200.5.20 Traffic to 10.200.1.5
10.200.0.0/16 → Local
10.200.5.0/24 → tgw-abc
0.0.0.0/0 → IGW 		Matches BOTH /16 and /24
/24 is more specific → Transit Gateway ✅		 Only matches /16
→ Local ✅

This is the key exam trap: even though 10.200.5.20 falls inside the broader /16 local range, the more specific /24 route to the Transit Gateway wins. AWS always prefers the longest (most specific) prefix, regardless of which route was added first.

Scenario 4 — VPN + Internet coexisting

Route Table Traffic to 192.168.10.5 (on-prem) Traffic to Facebook.com
10.200.0.0/16 → Local
192.168.0.0/16 → vgw-onprem
0.0.0.0/0 → IGW 		Matches /16 VPN route
→ VPN Gateway ✅		 No specific match
→ IGW ✅

🎯 Interview trap to remember: Longest Prefix Match is about specificity of the CIDR, not the order routes were added, not alphabetical order, not which target "seems more important." Just count the prefix length — bigger number after the / always wins.

Route Propagation

Static routes are ones you manually type into a route table. Propagated routes are learned automatically — AWS discovers them from a dynamic routing source and adds them to your route table without manual entry.

How it flows:

On-Premise Network → (VPN or Direct Connect) → Virtual Private Gateway / Transit Gateway → (BGP advertises routes) → AWS learns the on-prem CIDR ranges automatically → Route Table (with Route Propagation enabled) → Routes to on-premise networks appear automatically, no manual entry, updates as the on-prem network changes.

Why this matters: Without propagation, every time your on-premise network team adds a new subnet, someone would have to manually update every AWS route table. With propagation enabled, AWS learns the change automatically via BGP.

Static Routes vs Propagated Routes — Conflict Resolution

What happens if a static route and a propagated route both match the same destination with the same prefix length?

Rule: Longest Prefix Match is applied first. If multiple routes have the same prefix length, the static route wins over the propagated route.

Example:

Route Type Destination Target
Static (you typed this) 10.50.0.0/16 pcx-manual
Propagated (learned via BGP) 10.50.0.0/16 vgw-learned

Same prefix length (/16) → the static route wins. Traffic to 10.50.5.5 goes through pcx-manual, not vgw-learned.

This gives you an override mechanism — if AWS learns a route via propagation that conflicts with what you want, you can add a static route with the same prefix to take priority.

Blackhole Routes

A Blackhole Route is a route that still exists in the table, but its target no longer exists or is unavailable. Traffic matching this route gets silently dropped — packets vanish into nowhere, hence "blackhole."

Most common cause:

Route table has 0.0.0.0/0 → nat-0abc123. Someone deletes the NAT Gateway (nat-0abc123). The route table still has 0.0.0.0/0 → nat-0abc123 — now shown as Blackhole. Any traffic matching 0.0.0.0/0 is dropped silently, with no error sent back to the sender.

Analogy: It's like your GPS still showing directions to a building that was demolished last week. The road exists, the GPS still routes you there, but there's nothing at the destination — you just vanish into a void.

How to spot it: In the AWS Console, Route Tables show a "Blackhole" status directly next to the affected route — AWS flags it visually so you don't have to guess.

Common triggers:

  • NAT Gateway deleted while route table still references it
  • VPC Peering connection deleted/rejected while routes still point to it
  • VPN connection terminated while VGW routes remain
  • Transit Gateway attachment removed

🎯 Classic interview question: "Your EC2 in a private subnet suddenly cannot access the internet, but it was working yesterday. What would you check?"

Answer — the troubleshooting sequence:

  1. Is the NAT Gateway still available? (check EC2 → NAT Gateways console)
  2. Does the route table still point to the correct NAT Gateway ID?
  3. Is the route marked "Blackhole"? (visible directly in Console)
  4. Are Security Groups and NACLs still allowing the traffic?

Managed Prefix Lists

Imagine you have 20 Security Groups and 10 Route Tables, all referencing the same set of 5 office IP ranges. If those office IPs change, you'd have to update 30 different places manually.

A Managed Prefix List solves this — it's a named, reusable group of CIDR blocks you can reference in Security Groups and Route Tables. Update the list once, and every place referencing it gets the update automatically.

Example — Prefix List "company-offices":

Office CIDR
Mumbai 10.1.0.0/24
Bangalore 10.2.0.0/24
Pune 10.3.0.0/24

You'd write a Security Group rule as "Allow SSH from pl-company-offices" instead of listing all three CIDRs individually. Add a new office IP → update the Prefix List once → every Security Group and Route Table referencing it updates automatically. ✅

AWS also provides pre-built Managed Prefix Lists for its own services — e.g., a prefix list containing all CloudFront IP ranges, so you don't have to track them manually as AWS's infrastructure changes.

💡 DevOps relevance: Managed Prefix Lists are a genuine time-saver in infrastructure-as-code — instead of hardcoding IP ranges across dozens of Terraform resources, reference one prefix list ARN.

Edge Ingress Route Table Association

This is an advanced feature — most engineers won't touch it often, but it's worth understanding conceptually.

Normally, route tables are associated with subnets. Edge Ingress lets you associate a route table with an Internet Gateway or Virtual Private Gateway itself — meaning you can intercept and redirect traffic the moment it enters your VPC, before it even reaches a subnet.

Without Edge Ingress: Internet → IGW → directly to subnet → EC2

With Edge Ingress: Internet → IGW → Edge Route Table → redirected through a Firewall/Inspection Appliance → then to subnet → EC2

Use case: Route all inbound internet traffic through a third-party firewall or intrusion detection appliance before it reaches your actual application servers — a centralized security inspection point at the very edge of your VPC.

🎯 Cert-level awareness only: You're unlikely to configure this often in early-career roles, but knowing it exists (and what problem it solves — centralized traffic inspection at the VPC edge) is enough for interviews and certification.

Troubleshooting Checklist — Traffic Not Reaching EC2

This is the master checklist that ties everything from both VPC sessions together. When traffic isn't reaching an EC2 instance, work through this in order:

  1. Route Table Association — Is the correct route table associated with this subnet? (or with the IGW, in edge ingress scenarios)
  2. Longest Prefix Match — Is AWS selecting the route you expect it to select? Check for a more specific route accidentally overriding your intended path.
  3. Target Status — Is the target still valid? Is the route marked "Blackhole"? (target deleted/unavailable)
  4. Address Translation Path — Via Internet Gateway: does the EC2 have a Public IP or Elastic IP? Via NAT Gateway: is the NAT Gateway available, and is the route pointing to it correctly?
  5. Security Layer — Are Security Groups allowing the traffic? (stateful) Are NACLs allowing the traffic? (stateless — check BOTH inbound AND outbound, including ephemeral ports 1024-65535 for return traffic)

💡 This exact sequence — Route Table → Prefix Match → Target Status → Address Translation → Security — is the professional troubleshooting flow used in real production incidents. Memorizing this order (not just the individual pieces) is what makes you effective in an actual outage, not just in an exam.

VPC Flow Logs

VPC Flow Logs capture metadata about IP traffic flowing to and from network interfaces in your VPC. This is your forensic tool — when something goes wrong (or when security needs to investigate), Flow Logs tell you exactly what traffic happened, where, and whether it was allowed or blocked.

What Flow Logs capture (metadata, NOT packet content):

Field Meaning
Source IP Who sent it
Destination IP Who it was sent to
Source Port Which port on sender
Destination Port Which port on receiver
Protocol TCP, UDP, ICMP
Packets & Bytes Volume of traffic
Action ACCEPT or REJECT
Timestamp When it happened

💡 Flow Logs capture metadata only — not the actual content/payload of the traffic. You'll know that 10.200.1.5 sent 500 bytes to 8.8.8.8 on port 443 and it was accepted — but not what was inside that HTTPS request.

Where Flow Logs can be published: VPC / Subnet / ENI → sends a Flow Log to either CloudWatch Logs (real-time monitoring, alarms, dashboards) or an S3 Bucket (long-term storage, cost-effective, Athena queries).

Setup sequence (what was done in class):

  1. Create a Log Group in CloudWatch → CloudWatch → Log groups → Create log group → name it /vpc/flowlogs
  2. Create the Flow Log → VPC Console → Your VPC → Flow Logs → Create flow log → set filter (All / Accept / Reject) → destination: CloudWatch Logs → select the log group → attach an IAM role with permission to write logs
  3. Watch logs flow in → CloudWatch → Log groups → /vpc/flowlogs → Log streams → real traffic metadata appears

Sample Flow Log entry (this one is real syntax, kept as code):

2 123456789010 eni-1235b8ca 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK
Enter fullscreen mode Exit fullscreen mode

Breaking this down: version, account ID, ENI ID, source IP, dest IP, source port, dest port, protocol (6=TCP), packets, bytes, start time, end time, action (ACCEPT), log status.

🎯 Security use case: If you suspect unauthorized access, filter Flow Logs for REJECT actions from unfamiliar IPs — this shows every blocked connection attempt, which is exactly what a security investigation needs. This is one of the most useful forensic tools in AWS networking.

VPC Endpoints — Private Connectivity to AWS Services

Normally, when a private EC2 instance wants to talk to S3, DynamoDB, or another AWS service, that traffic would need to go through a NAT Gateway → Internet Gateway → out to the public internet → to the AWS service's public endpoint → back.

A VPC Endpoint creates a private connection directly from your VPC to the AWS service — traffic never leaves the AWS network, never touches the public internet, no NAT Gateway or Internet Gateway required.

The analogy:

🏠 Private EC2 = Your house
🏢 AWS Service (S3, SSM, CloudWatch) = Office

Without a VPC Endpoint: House → Public Road (internet, via NAT + IGW) → Office. Longer path, exposed to the public internet, costs a NAT data processing fee.

With a VPC Endpoint: House → Private Tunnel (stays inside AWS network) → Office. Shorter, more secure, often cheaper — no NAT processing charge.

Two Types of VPC Endpoints

Gateway Endpoint

  • Only supports S3 and DynamoDB
  • Works by adding a route table entry — a target pointing to the endpoint
  • Free — no hourly charge
  • Cannot be accessed from on-premises networks (VPN/Direct Connect)

Route table example: destination pl-xxxxxx (the S3 prefix list) → target vpce-gateway-xxxxx. A private EC2 making an S3 request matches the S3 prefix list route, goes through the Gateway Endpoint, and reaches S3 — no internet involved.

Interface Endpoint

  • Supports most other AWS services (SSM, CloudWatch, SNS, SQS, KMS, Secrets Manager, etc.)
  • Works by creating an ENI with a private IP inside your subnet
  • Has an hourly charge + data processing charge
  • Can be accessed from on-premises networks via VPN/Direct Connect
  • Optionally enables Private DNS — makes the standard AWS service DNS name resolve to the private endpoint automatically

Example: an Interface Endpoint for SSM creates an ENI at 10.200.1.100 in your private subnet. With Private DNS enabled, ssm.ap-south-1.amazonaws.com resolves to 10.200.1.100 instead of the public AWS IP. So when your EC2 calls the standard SSM endpoint name, DNS quietly resolves it privately, and traffic stays inside the VPC.

Gateway vs Interface — Comparison

Gateway Endpoint Interface Endpoint
Supported services S3, DynamoDB only Most other AWS services
How it works Route table entry ENI with private IP
Cost Free Hourly + data charge
On-premise access ❌ No ✅ Yes (via VPN/DX)
DNS N/A Private DNS optional

The Interview Trap — Gateway vs Interface for S3

🎯 Interviewer: "You have both an S3 Gateway Endpoint AND an S3 Interface Endpoint, and Private DNS is enabled on the Interface Endpoint. Which one actually gets used?"

Answer: The Interface Endpoint is used. Enabling Private DNS overrides the default S3 DNS resolution — so when your application calls the standard S3 endpoint name (s3.ap-south-1.amazonaws.com), DNS resolves it to the Interface Endpoint's private IP instead of routing through the Gateway Endpoint via the route table. The Gateway Endpoint sits unused in this scenario even though it's still technically active.

This is a genuinely tricky, DNS-resolution-based gotcha — worth remembering exactly because it's counterintuitive.

VPC Endpoint Policy

Just like S3 has bucket policies and IAM has permission policies, a VPC Endpoint Policy is a resource policy attached directly to the endpoint itself — controlling exactly which AWS resources and API actions can flow through that specific endpoint.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-approved-bucket/*"
  }]
}
Enter fullscreen mode Exit fullscreen mode

This policy says: "Through this specific VPC Endpoint, only GetObject on this one specific bucket is allowed — nothing else, even if IAM would otherwise permit it."

Why this matters: It's an additional restriction layer, not a replacement. A request must pass IAM policy AND the VPC Endpoint policy AND (if applicable) the bucket policy. This lets you say: "Even if someone has full S3 permissions via IAM, when they go through THIS endpoint, they can only touch THIS bucket."

🎯 Production use case: A company wants private subnets to reach only their own company's S3 buckets via the Gateway Endpoint — not any random public S3 bucket on the internet. The VPC Endpoint Policy restricts this precisely.

Transit Gateway

As companies grow, they end up with many VPCs — one per team, per environment (dev/staging/prod), per project. Connecting all of them directly to each other via VPC Peering becomes a mess very quickly.

The peering problem:

VPC Count Peering Connections Required
5 VPCs 10 connections
10 VPCs 45 connections
20 VPCs 190 connections

Each peering connection needs its own route table entries everywhere. This does not scale.

Transit Gateway solves this — it's a fully managed, regional network hub that all your VPCs connect to once, and it handles routing between them.

Without Transit Gateway (Peering Mesh): VPC-A ↔ VPC-B ↔ VPC-C ↔ VPC-D — every VPC needs a direct connection to every other VPC.

With Transit Gateway (Hub and Spoke): VPC-A, VPC-B, VPC-C, and VPC-D each connect once to the central Transit Gateway. The Transit Gateway routes traffic between all of them centrally.

What Transit Gateway connects:

  • Multiple VPCs
  • VPN connections (site-to-site)
  • Direct Connect Gateways (dedicated network link to on-premise)
  • Other Transit Gateways (even across Regions, via peering)

Analogy: VPC Peering is like every house in a neighborhood digging a private tunnel directly to every other house — expensive and chaotic to maintain. Transit Gateway is like a central roundabout — every house connects to the roundabout once, and the roundabout directs traffic to wherever it needs to go.

🎯 Interview/Cert scenario: "A company has 15 VPCs across different teams that all need to communicate with each other and with an on-premise data center. What's the best approach?" → Transit Gateway. VPC Peering would require dozens of individual connections and doesn't scale; Transit Gateway centralizes routing through one hub and also connects to on-premise via VPN/Direct Connect.

⚡ Quick Revision

Route Table Core

  • Destination = WHERE (the IP range) · Target = HOW (gateway/component used to get there)
  • Longest Prefix Match = most specific CIDR always wins
  • Same prefix length? Static route beats Propagated route

Route Propagation

  • Auto-learned routes from VGW/Transit Gateway via BGP — no manual entry needed, updates automatically

Blackhole Route

  • Route still exists, target no longer exists → traffic silently dropped
  • Common cause: NAT Gateway or Peering connection deleted
  • AWS flags it visibly as "Blackhole" in console

Managed Prefix List

  • Reusable named CIDR group, reference in many SGs/Route Tables
  • Update once → propagates everywhere it's referenced

Troubleshooting Order (memorize this sequence)

  1. Route Table Association → 2. Longest Prefix Match → 3. Target Status → 4. Address Translation Path → 5. Security (SG + NACL)

VPC Flow Logs

  • Metadata only (not packet content) — source/dest IP+port, protocol, bytes, ACCEPT/REJECT
  • Destinations: CloudWatch Logs or S3 — forensic + security investigation tool

VPC Endpoints

  • Gateway Endpoint: S3 + DynamoDB only, free, route table based
  • Interface Endpoint: most other services, ENI + private IP, hourly cost
  • Private DNS on Interface Endpoint OVERRIDES default DNS resolution
  • Endpoint Policy = extra restriction layer on top of IAM

Transit Gateway

  • Central hub connecting many VPCs + VPN + Direct Connect
  • Solves the peering mesh scalability problem — one connection per VPC to the hub, not to every other VPC

💼 Interview Questions

Q1: What is Longest Prefix Match and why does it matter?
It's the rule AWS uses when multiple routes in a table could match a destination IP — the route with the most specific (longest) CIDR prefix always wins, regardless of when it was added. For example, a /24 route wins over a /16 route even if the /16 was configured first, as long as the destination IP falls within the /24 range.

Q2: What is a Blackhole route and how do you detect it?
A Blackhole route is a route whose target (like a NAT Gateway or Peering connection) no longer exists or is unavailable. Traffic matching that route gets silently dropped. AWS visually flags it as "Blackhole" directly in the Route Table console, making it easy to spot during troubleshooting.

Q3: A private EC2 instance suddenly lost internet access. Walk through your troubleshooting steps.
First check if the NAT Gateway is still available. Then verify the route table still points to the correct NAT Gateway ID and isn't marked Blackhole. Then check Security Groups and NACLs are still allowing the traffic in both directions. This systematic order — route table, target status, then security — quickly isolates whether it's a routing problem or a security rule problem.

Q4: What is the difference between a Gateway Endpoint and an Interface Endpoint?
Gateway Endpoints only support S3 and DynamoDB, work via a route table entry, and are free. Interface Endpoints support most other AWS services, work by creating an ENI with a private IP inside your subnet, have an hourly + data processing cost, and can be accessed from on-premises networks via VPN or Direct Connect — Gateway Endpoints cannot.

Q5: If both an S3 Gateway Endpoint and an S3 Interface Endpoint exist with Private DNS enabled, which is used?
The Interface Endpoint. Enabling Private DNS overrides the default S3 DNS resolution, so standard S3 endpoint calls resolve to the Interface Endpoint's private IP instead of routing through the Gateway Endpoint via the route table.

Q6: Why would a company use Transit Gateway instead of VPC Peering?
VPC Peering requires a direct connection between every pair of VPCs — this becomes unmanageable at scale (10 VPCs need 45 individual peering connections). Transit Gateway acts as a central hub — each VPC connects once to the Transit Gateway, which handles routing between all of them, and it also connects to on-premise networks via VPN or Direct Connect. Far more scalable for organizations with many VPCs.

Q7: What do VPC Flow Logs capture, and what don't they capture?
Flow Logs capture metadata about IP traffic — source/destination IP and port, protocol, packet/byte counts, timestamps, and whether traffic was accepted or rejected. They do NOT capture the actual content/payload of the traffic — you know that a connection happened and whether it was allowed, but not what data was inside it.

🔬 Practice Scenarios

Since this session is dense and interconnected, these scenarios are designed to be worked through slowly — the goal is confidence explaining "why," not just naming the term. Come back to these once the full VPC picture has settled after revisiting the lectures.

  1. Longest Prefix Match drill: Given a route table with 10.0.0.0/16 → Local, 10.0.5.0/24 → pcx-abc (peering), and 0.0.0.0/0 → igw-xyz — for each of these destination IPs, state which route wins and why: 10.0.5.10, 10.0.9.10, 52.1.1.1.

  2. Blackhole diagnosis: You delete a NAT Gateway to save cost. Two days later, private EC2 instances report they can't reach the internet. Walk through the full troubleshooting checklist and identify exactly where the problem would surface.

  3. VPC Endpoint decision: Your app needs private access to S3, DynamoDB, and Secrets Manager without traffic touching the internet. Which endpoint type do you use for each service, and why?

  4. Transit Gateway vs Peering: Your company has 3 VPCs today but plans to add 12 more over the next year, plus a VPN to the head office. Would you start with VPC Peering or Transit Gateway? Justify with the connection-count math.

  5. Flow Logs investigation: You suspect someone is trying to SSH into your EC2 from an unauthorized IP. Describe exactly how you'd set up Flow Logs and what you'd filter for to confirm or rule this out.

  6. Full lab (when ready): Build two VPCs, peer them, then replace the peering with a Transit Gateway once you have a third VPC. Add an S3 Gateway Endpoint to one VPC and confirm S3 traffic never leaves the AWS network by checking Flow Logs.

AWS VPC Extended | Cloud + DevOps learning journey — Systems Engineer → Cloud/DevOps Engineer

Top comments (0)