143 Cloud Engineer Interview Questions & Answers

I would first pause CI and any concurrent Terraform applies for that state boundary. Then I would compare Terraform state with the real provider resources and identify exactly what succeeded, failed, or exists outside state. I would repair configuration first and change state only when evidence proves the binding is wrong. Next I would create and review a saved recovery plan, protect important data before any risky change, apply only the reviewed plan if changes are needed, verify the cloud resources and tests, confirm no stale lock remains, and then resume delivery.

My first goal is to stop the situation from changing while I investigate it. Some requested infrastructure may already exist, while other parts may not. I should not simply repeat the same action because that could create more problems or remove something useful. I pause other delivery work first. Then I compare what the automation recorded with what actually exists. I identify each completed, missing, failed, or uncertain item. I correct the intended setup only after I understand the difference. Before any risky change, I protect important data. I resume normal delivery only after the environment matches the reviewed intention.

1. Is this production environment using remote Terraform state with locking?
2. Are there stateful resources whose data must be protected before any replacement or removal?
3. Which Terraform and provider versions are pinned in the repository?

I would start by pausing CI and any concurrent Terraform applies that use this state boundary. Backend locking serializes Terraform operations that write the same state, but pausing delivery also prevents another pipeline from changing the environment while I investigate.

Next I would inspect Terraform state and provider reality separately. I would list and inspect the recorded resources, use a refresh only plan to observe provider changes, and check the cloud provider for resources that were actually created. I would classify each resource as completed, failed, missing, or uncertain. Configuration expresses the intended infrastructure. Terraform state records managed object bindings and observed attributes. The provider shows what really exists.

I would prefer repairing configuration, inputs, dependencies, permissions, or provider settings. I would change state only when evidence proves the resource binding is wrong. If a real resource exists and Terraform should manage it, I can import it into the correct address. I would remove a resource from state only when it should intentionally stop being managed at that address. I would use a state move when the resource address changed. I would never edit the state file manually.

Then I would create a saved recovery plan and review every proposed change. I would reject unexpected replacement or destruction. Before any destructive action, I would take required snapshots or backups, enable appropriate protection, and verify the restore procedure. If the reviewed plan contains intended changes, I would apply that saved plan. Finally I would validate provider resource status, health checks, integration tests, smoke tests, and security checks. I would confirm that no stale lock remains, then reenable CI, monitor the environment, and communicate the resolution. I would use the Terraform and provider versions pinned by the repository. For a current S3 backend design, I would prefer native S3 lockfile locking and treat older DynamoDB based locking as legacy behavior that depends on the pinned Terraform version.

Common mistakes are immediately running apply again, assuming Terraform state alone proves what exists in the provider, manually editing the state file, removing a resource from state merely because an apply failed, importing a resource without confirming its identity, accepting unexpected replacement or destruction in the next plan, skipping backups for stateful resources, treating backend locking as a complete delivery freeze, and using force unlock without first proving that no active Terraform operation owns the lock. Another mistake is assuming unpinned Terraform or provider behavior during recovery instead of using the repository pinned versions.

Explain the recovery as containment, observation, reconciliation, controlled change, and verification. Emphasize that you do not guess about state. Say what evidence you would collect before using import, state removal, state movement, or another apply. Finish by explaining how you prove that the reviewed intention, Terraform state, and provider reality agree before CI resumes.

At a high level, a VPC or VNet gives cloud resources a private network that you control. The main challenge is deciding which traffic may enter, leave, or stay private. I would explain it in three parts: address space and subnets, routing and gateways, then security and private connectivity. In this design, Internet traffic reaches the public load balancer, while the application and database tiers stay private. The trade-off is stronger network control with more routing and security configuration.

The goal is to create a private network area for a three-tier cloud workload. We need to decide which resources can receive Internet traffic and which resources should stay private. We also need clear rules for traffic leaving the network or reaching an on-premises network. The diagram organizes this into public, application, and data subnets. It then shows how route tables, gateways, security controls, DNS, and private connectivity control communication. Finally, it shows that network isolation is different from account or subscription isolation.

1. Do the private application or data resources need outbound Internet access?
2. Does the workload need private connectivity to an on-premises network?
3. Should each tier be duplicated across availability zones for resilience?

I would start by saying that a VPC or VNet is a logically isolated cloud network. In this diagram, its address space is 10.0.0.0/16. CIDR is the notation used to describe that IP address range.

This boundary isolates network traffic from other virtual networks by default. It does not create a separate cloud account or subscription. Account or subscription boundaries separately control things such as identity, billing, and resource ownership.

Next, I would split the network into smaller subnet ranges. The Public Subnet is 10.0.1.0/24 and contains the Load Balancer with a public IP. The App Subnet is 10.0.2.0/24 and contains the App Servers. The Data Subnet is 10.0.3.0/24 and contains the Database with no public IP.

The normal application path is Users on Internet → Load Balancer → App Server → Database. This keeps the database away from direct Internet access.

Route tables decide where subnet traffic is sent. The Public Subnet Route Table has a default route, 0.0.0.0/0, toward the Internet Gateway. The Internet Gateway provides the public path between the virtual network and the Internet.

The Private Subnet Route Table sends its default route toward the NAT / Egress Gateway. NAT means Network Address Translation. It lets private resources make outbound Internet connections without giving those resources public IP addresses.

Private Connectivity Routes keep 10.0.0.0/16 traffic local. Traffic for on-premises prefixes goes through the VPN / Private Circuit.

Routing decides where traffic can go. Security controls decide whether that traffic is allowed. The diagram shows Security Groups, Network ACLs, and optional firewall rules.

The network also provides private DNS names. DNS means Domain Name System. It lets internal resources use names instead of remembering private IP addresses.

Before deployment, I would choose the CIDR block and subnet layout. I would plan subnets by tier and duplicate them across availability zones when resilience is needed. Then I would define route tables, add the required gateways, set security rules, configure private DNS, and decide whether private on-premises connectivity is needed.

The benefit is clear control over network paths and exposure. The downside is that routes, gateways, and security rules must be planned carefully.

The benefit is that each tier has a clear network role. The public load balancer can receive Internet traffic, while the App Subnet and Data Subnet stay private. The NAT / Egress Gateway can give private resources outbound Internet access without assigning them public IP addresses. The VPN / Private Circuit can provide a private path to an on-premises network. The downside is more setup. CIDR ranges, subnet routes, gateways, DNS, and security rules must work together. A wrong route can block traffic, while an overly broad security rule can allow more access than intended.

At a high level, a subnet is public or private mainly because of its routing. The key question is whether Internet traffic can reach a workload directly or whether that workload can only start outbound connections. I would explain this through the public path, the private NAT path, and the security controls. A public subnet routes through an Internet Gateway. A private subnet can route outbound traffic through NAT. Security Groups and Network ACLs still decide which traffic is allowed.

The goal is to control how workloads inside a cloud network communicate with the Internet. Some workloads need to accept connections started by Internet users. Other workloads should stay private and only start connections outward when needed. The important idea is that having a network path is different from allowing traffic on that path. The diagram explains this with a public subnet, a private subnet, an Internet Gateway, NAT, route tables, public addressing, Security Groups, and Network ACLs.

1. Should any workload accept connections started directly from the Internet?
2. Do private workloads need outbound Internet access?
3. Which inbound ports and source networks should be allowed?

I would first separate reachability from permission. A route table decides where packets can go. A firewall rule decides whether those packets are allowed.

The VPC in the diagram is 10.0.0.0/16. Both route tables keep traffic for that VPC on the local route. Their default Internet routes are different.

The Public Subnet is 10.0.1.0/24. Its route table sends 0.0.0.0/0 to the Internet Gateway, or IGW. That route is what makes the subnet public from a routing point of view.

The public instance is 10.0.1.10 and also has a public IP. Internet-initiated traffic can reach that workload when its security controls allow the connection. Return traffic can go back through the Internet Gateway.

A route to the IGW alone does not make every workload directly reachable. The workload also needs suitable public addressing and allowed security rules.

The Private Subnet is 10.0.2.0/24. Its instance is 10.0.2.10 and has no public IP. Its default route sends 0.0.0.0/0 to the NAT Gateway at 10.0.1.5.

This lets the private workload start an outbound Internet connection. The response comes back through NAT. An Internet client cannot use this NAT path to start a new unsolicited connection directly to the private instance.

Routing creates reachability. Security controls decide which traffic may use that reachability.

The diagram shows a stateful Security Group. Its example allows TCP 22 from 203.0.113.0/24 and TCP 80 from 0.0.0.0/0. Other inbound traffic is denied unless another rule allows it. Stateful means return traffic for an allowed connection is automatically tracked.

The diagram also shows a stateless Network ACL. A Network ACL applies at the subnet boundary. Stateless means inbound and outbound directions are checked separately, so rules must allow the required traffic in both directions.

A public subnet has a route to an Internet Gateway. An Internet-facing workload also needs public addressing and security rules that permit the traffic. A private subnet can instead send Internet-bound traffic to NAT. That gives workloads outbound Internet access without letting the Internet start new connections through NAT. The key trade-off is that routing and security are separate controls, so both must be configured correctly.

The benefit is clear separation between Internet-facing and private workloads. A public subnet can provide a direct Internet path through the Internet Gateway, while security rules still control what is accepted. A private subnet can avoid direct Internet-initiated access and still use NAT for outbound connections. The downside is more configuration. Route tables, public addresses, Security Groups, and Network ACLs must all match the intended traffic. A correct route does not automatically make traffic safe. A permissive firewall rule also cannot create a network path that does not exist.

At a high level, Security Groups and Network ACLs protect different network boundaries. The main challenge is return traffic because Security Groups are stateful, while Network ACLs are stateless. I would explain the inbound HTTPS path, the return path, and then compare their rules. Security Groups protect ENIs such as load balancers and instances. Network ACLs protect subnets. Security Groups use allow rules, while Network ACLs can allow or deny traffic and must handle both directions explicitly.

The goal is to control which network traffic can enter and leave each part of the virtual network. The important difference is how the two controls handle a connection after its first packet is allowed. One control remembers the connection. The other checks every direction separately. The diagram uses an HTTPS request from the Internet to a Public Load Balancer, followed by traffic to application instances in a Private Subnet. I would explain the incoming request first, then the response path, and finally compare rule behavior and where each control belongs.

1. Should I trace both the Internet-to-load-balancer connection and the load-balancer-to-instance connection?
2. Should I explain the default behavior of new Security Groups and both default and custom Network ACLs?
3. Should I include how ordered Network ACL rules and ephemeral return ports affect the flow?

I would start by separating their scope. A Security Group is attached to an ENI, which is a network interface used by a load balancer or instance. A Network ACL is associated with a subnet.

That means Security Groups give fine-grained control around workloads. Network ACLs give broader filtering at the subnet boundary.

The client sends HTTPS traffic on TCP port 443 from the Internet. The Public Subnet Network ACL allows inbound TCP 443 from 0.0.0.0/0. Its rules are checked by rule number, starting with the lowest number, and the first matching rule wins.

The request reaches the Public Load Balancer. Its Security Group, sg-lb, allows inbound TCP 443 from 0.0.0.0/0. Security Groups have allow rules only. Traffic that does not match an allow rule is denied.

The load balancer then connects to the application instances on TCP 443. The Public Subnet Network ACL allows TCP 443 toward 10.0.2.0/24. The Private Subnet Network ACL allows TCP 443 from 10.0.1.0/24. The application Security Group, sg-app, allows TCP 443 from sg-lb.

Security Groups are stateful. This means response traffic for an allowed connection is automatically permitted by the Security Group state. You do not need a separate reverse rule for that response.

Network ACLs are stateless. They do not remember the earlier request. The Private Subnet Network ACL must therefore allow the response toward the Public Subnet. The Public Subnet Network ACL must separately allow the matching ephemeral return port from 10.0.2.0/24.

For the response from the Public Load Balancer back to the Internet client, the Public Subnet Network ACL also needs the required outbound ephemeral-port rule.

Both controls have inbound and outbound directions. Security Group rules are evaluated together as allow rules, and state tracks permitted connections. Network ACLs support both allow and deny rules, and each direction is evaluated independently.

A new Security Group has no inbound rules and allows all outbound traffic by default. A default Network ACL allows all inbound and outbound traffic. A custom Network ACL denies traffic until rules are added.

I would use Security Groups as the main workload-level control because they are stateful and attach directly to ENIs. I would use Network ACLs for broad subnet-level filtering, such as blocking unwanted address ranges. Using both gives two layers of protection. The downside is that stateless Network ACLs require careful rules for both request and return traffic.

The benefit is that the two controls protect different layers. Security Groups give precise access control around load balancers and instances. Their stateful behavior also makes normal request and response traffic easier to manage. Network ACLs add a broader filter around a whole subnet and can contain both allow and deny rules. The downside is that Network ACLs are stateless. You must think about both traffic directions and the needed return ports. Their ordered rules also require care because the first matching rule decides the result. Using both gives stronger layered filtering, but it creates more rules to maintain.

At a high level, the private application needs outbound internet access without accepting new inbound connections. The main challenge is translating its private address while keeping the return path tied to the original TCP flow. I would explain the outbound route, the NAT translation, and the return path. The instance sends traffic to the NAT Gateway, which uses its public IP and keeps connection state. Replies are translated back to the instance. The trade-off is that unsolicited inbound traffic cannot use the same path.

The goal is to let a private application connect to a public software repository without giving the application its own public internet address. The important part is keeping the outgoing connection and its reply tied together. The diagram solves this with routing, address translation, and saved connection state. Traffic first leaves the private subnet through the NAT Gateway. It then reaches the Internet Gateway and the public repository. The reply follows the saved NAT state back to the original application. A new connection started from the internet does not have that state, so it cannot use the same path.

1. Should we assume the NAT Gateway already has the public IP shown in the diagram?
2. Should we focus only on the normal TCP flow and unsolicited inbound traffic?

I would start with the Application Instance at 10.0.1.10. It sits inside the Private Subnet 10.0.1.0/24 and has only a private IP.

The application opens a TCP connection to the Public Software Repository at 198.51.100.10:443. Its source is 10.0.1.10:51514. The Private Subnet Route Table keeps traffic for 10.0.0.0/16 local. Its default route, 0.0.0.0/0, sends other traffic to the NAT Gateway.

Next, the NAT Gateway changes the source before the packet reaches the internet. This is source address translation, or SNAT. It means the private source address and port are replaced with the NAT Gateway's public address and translated port.

The diagram changes 10.0.1.10:51514 to 203.0.113.5:62001. The destination stays 198.51.100.10:443. The NAT Gateway also records this mapping in the NAT Translation Table. That state connects the translated public address and port with the original private connection.

The translated packet continues toward the Internet Gateway. The Public Subnet Route Table shown in the diagram has 0.0.0.0/0 pointing to the Internet Gateway.

The packet then leaves the VPC and reaches the Public Software Repository. From the repository's point of view, the TCP connection comes from 203.0.113.5:62001, not directly from 10.0.1.10:51514.

For the return path, the repository sends its TCP response from 198.51.100.10:443 to 203.0.113.5:62001. The response returns through the Internet Gateway toward the NAT Gateway.

The NAT Gateway checks its saved state and finds the matching entry. It reverses the translation, changing the destination back to 10.0.1.10:51514. The response is then delivered to the Application Instance that started the connection.

The key security point is that the NAT Gateway is stateful. This means it remembers connections that were started from the private side and allows matching return traffic.

If an external host starts a new connection toward 203.0.113.5, that new flow has no matching entry in the NAT Translation Table. The NAT Gateway therefore has no saved mapping that sends it to 10.0.1.10. The private address is also not directly routable on the public internet. This design gives the private workload outbound internet access while blocking unsolicited inbound connections through the same NAT path.

The benefit is that the Application Instance can reach the Public Software Repository without having its own public IP. The NAT Gateway replaces the private source address and remembers the connection so the response can return correctly. Its saved state also stops an outside host from starting a new connection through the same NAT path. The downside is that this path is designed for connections started from the private side. It is not a general inbound entry point. Routing must also be correct. The Private Subnet Route Table must send internet traffic to the NAT Gateway, and the public-side route must lead toward the Internet Gateway.

At a high level, the goal is to turn an internal service name into a private IP address. The main challenge is keeping private DNS separate from public DNS while making repeated lookups fast. I would explain the resolver lookup, the private-zone answer, and the service connection. The VPC DNS Resolver checks cached results and the Private Hosted Zone, returns 10.0.2.25, and the client connects to 10.0.2.25:443. The trade-off is that cached answers remain usable until their TTL expires.

The application knows the internal service name, but it needs an address before it can connect. The important part is making sure an internal name returns a private address without exposing private DNS data to public DNS. The design handles this in two stages. First, the application resolves app.internal through the cloud virtual network's DNS resolver. Then it uses the returned private address to connect to the service. Caching makes repeated lookups faster. Split-horizon DNS keeps private and public answers on the correct side of the trust boundary.

1. Should app.internal resolve only from inside this cloud virtual network?
2. How quickly must clients see a changed service IP after a DNS update?
3. Should names missing from private zones be allowed to use public DNS?

I would start with the private application asking for app.internal. The application's OS resolver sends the DNS query to the Recursive Resolver, labeled VPC DNS in the diagram. This resolver sits inside the Cloud Virtual Network boundary. Its job is to decide where the name should be resolved and return the answer to the client.

The fast path is a valid cached answer. The VPC DNS Resolver keeps DNS results in its TTL-based cache. TTL means time to live, which tells the resolver how long an answer may be reused. If a cached app.internal answer is still valid, the resolver can return it without another zone lookup. The diagram also notes that clients may cache DNS answers according to their OS or library behavior and the TTL.

If the resolver needs a fresh answer, it checks the Private Hosted Zone associated with the VPC. It looks for the matching record for app.internal. The diagram shows an A record, which maps a name to an IP address. That record maps app.internal to private address 10.0.2.25 and has a 60-second TTL. The resolver returns 10.0.2.25 to the client and can cache that answer for the TTL.

This is the split-horizon behavior shown in the diagram. Internal names can receive private answers inside the VPC, while public names use public DNS. The same naming system can therefore give private and public clients different answers when separate private and public records exist. Private hosted-zone data stays inside the VPC trust boundary.

DNS resolution only finds the destination. It does not carry the application's service traffic. After receiving 10.0.2.25, the client connects to 10.0.2.25:443 using the application data path shown in the diagram. That connection reaches the internal Service in the private Service Subnet. The diagram also shows multiple service replicas behind that service, while the DNS answer shown to the client is 10.0.2.25.

If the name is not in a private zone, the resolver applies its rules and can forward the lookup to Public DNS on the Internet. Public DNS resolves public names and returns a public IP answer. The diagram gives example.com as an example and shows 93.184.216.34 in its example box. That answer returns through the resolver to the client.

The trust boundary is important. Private hosted-zone records are not sent to public DNS. Only names that need the public path are forwarded outside. The benefit is clear separation between private and public naming. The downside is caching. An older DNS answer may remain usable until its TTL expires.

The benefit is that private service names stay private and resolve to private IP addresses inside the cloud virtual network. Caching also makes repeated DNS lookups faster and reduces DNS traffic. The downside is that a cached answer can remain until its TTL expires, even after the record changes. A shorter TTL lets clients learn changes sooner, but it creates more DNS lookups. Split-horizon DNS also needs careful rules because private names and public names can follow different paths. Public DNS is used only when the resolver's private rules do not provide the needed answer.

At a high level, the goal is to keep the Application Tier and database private while still serving internet users. The main challenge is allowing safe inbound HTTPS and controlled outbound API calls without giving workloads public IPs. I would explain this in three flows: users enter through Route 53 and the internet-facing Application Load Balancer, the application reaches the private database, and outbound HTTPS leaves through NAT Gateways. The trade-off is more network cost and setup for stronger isolation and multi-AZ resilience.

The goal is to let people use the application from the internet without exposing the Application Tier or database directly. The difficult part is that traffic must cross several trust boundaries safely. User requests need a public entry point. The Application Tier also needs outbound access to a third-party API. The database should have no route to the internet. The diagram solves this by separating Public Subnets, Private App Subnets, and Private Data Subnets across two Availability Zones. Inbound traffic and outbound traffic then use different controlled paths.

1. Should users connect only through HTTPS on port 443?
2. Does the Application Tier need outbound HTTPS to any external API or only approved destinations?
3. Which database port should the Application Tier use?
4. Is multi-AZ availability required for every tier?

I would first separate internet-facing resources from private workloads. The internet-facing Application Load Balancer sits in the Public Subnets across two Availability Zones. The Application Tier runs in Private App Subnets. The Primary DB and Standby DB stay in Private Data Subnets. The Application Tier and database workloads have no public IPs. This creates clear Internet, Public Subnet, Private App Subnet, and Private Data Subnet trust boundaries.

For inbound traffic, users send HTTPS on port 443. Route 53 provides public DNS and directs users to the internet-facing Application Load Balancer. AWS WAF protects this public entry point with controls such as request filtering, rate limiting, IP reputation checks, and bot control. The ALB then forwards allowed traffic to the Application Tier in the private app subnets. The ALB SG accepts inbound port 443. The App SG accepts application traffic only from the ALB SG. The Application Tier receives the original client address through the ALB X-Forwarded-For header.

The Application Tier sends database traffic directly to the private database tier. This traffic stays inside the private network. The DB SG allows port 5432, or the selected database port, only from the App SG. The Primary DB replicates to the Standby DB in the second Availability Zone. The Private Data Subnets have no default internet route. This keeps the database isolated from direct internet access.

For outbound calls, the Application Tier sends HTTPS on port 443 toward a NAT Gateway. The design has NAT Gateways per Availability Zone. The Private App route sends 0.0.0.0/0 to NAT. NAT then sends the connection through the internet to the third-party API. The application workloads still have no public IPs. Return packets follow the existing stateful connection back through NAT to the Application Tier.

The Public route table sends 0.0.0.0/0 to the Internet Gateway. The Private App route sends 0.0.0.0/0 to the NAT Gateway. The Private Data tier has no internet default route. Security groups add stateful filtering between tiers. The benefit is strong isolation with required internet connectivity. The downside is extra cost and operational work from the ALB, NAT Gateways, multiple subnets, routing, WAF, and multi-AZ design.

The benefit is that the Application Tier and database stay private. Only the internet-facing Application Load Balancer accepts inbound internet traffic. The database has no route to the internet, which reduces its exposure. Using two Availability Zones also avoids putting everything in one failure area. The downside is more cost and setup work. The ALB and NAT Gateways add managed-service cost. Multiple subnets, route tables, and security groups also need careful configuration. A wrong route or security rule can break traffic even when the application is healthy. We accept this extra complexity because it gives clearer trust boundaries, controlled egress, and stronger isolation.

At a high level, I would trace one TCP 443 connection from the failing private instance to the public package repository. The main challenge is finding exactly where that path breaks. I would check DNS and effective routes first, then NAT and Internet Gateway connectivity, then Security Groups, Network ACLs, and return routing. Finally, I would use VPC Flow Logs and packet evidence. I would also compare every step with the working subnet because that quickly narrows the difference.

The goal is to find why one private Linux instance cannot reach a public package repository while another subnet works. I would follow one connection from the instance toward the internet and check each place where it could stop. The working subnet is useful because it gives me a known-good path for comparison. I would start with name resolution and routing. Then I would check the NAT Gateway and Internet Gateway. After that, I would verify the security rules, return path, Flow Logs, and packet evidence.

1. Does the repository name resolve successfully on the failing instance?
2. Does the working subnet use the same NAT Gateway or a different NAT Gateway?
3. Were any route table, Security Group, or Network ACL rules changed recently?
4. Do VPC Flow Logs show ACCEPT or REJECT records for the failing connection?

I would first prove that the instance can resolve the package repository name. I can use nslookup or dig. A successful lookup gives me the public repository IP to test. If DNS fails, I would solve name resolution before troubleshooting TCP 443.

Next, I would separate the Linux route from the cloud route. ip route get <repo_ip> shows whether Linux sends off-subnet traffic toward its subnet gateway. It does not prove that the VPC route uses NAT. I would then inspect the private subnet route table. Its 0.0.0.0/0 route should target the intended NAT Gateway. I would compare this with the working subnet's route table.

The NAT Gateway should be Available and located in a public subnet. A public NAT Gateway needs an Elastic IP. Its public subnet must have 0.0.0.0/0 routed to the Internet Gateway, and that Internet Gateway must be attached to the VPC. A same-AZ NAT Gateway is preferred for resilience and lower cross-AZ cost, but cross-AZ routing can still work.

The instance Security Group must allow outbound TCP 443. Security Groups are stateful, so reply traffic for that allowed connection is automatically permitted. Network ACLs are stateless. They must allow outbound TCP 443 and inbound return traffic to the client's ephemeral source-port range. I would also confirm that the private subnet sends its default route to the intended NAT and that the NAT public subnet sends its default route to the Internet Gateway.

If the configuration looks correct, I would inspect VPC Flow Logs. ACCEPT and REJECT records help show whether traffic is observed and where filtering may occur. Flow Logs do not prove that TCP or TLS completed. I would then use ss, curl -v, and tcpdump -nn -i eth0 host <repo_ip> and tcp port 443. Repeated SYN packets without a SYN-ACK suggest a network or remote-path problem. SYN, SYN-ACK, and ACK prove TCP is established. A later TLS error means the network path works, but TLS or application negotiation failed.

The benefit of this troubleshooting order is that each check proves one small part of the connection. Comparing the broken subnet with the working subnet can make the failure much easier to find. Security Groups are simpler for return traffic because they are stateful. Network ACLs need more care because they are stateless. A NAT Gateway in each Availability Zone improves resilience and can reduce cross-AZ traffic costs. The downside is that more NAT Gateways cost more. Flow Logs help locate filtering, but packet evidence is still needed to understand whether TCP and TLS actually succeed.

At a high level, I would connect the two organizations without directly routing their overlapping private addresses. The main challenge is avoiding ambiguous routes while still allowing selected HTTPS and database flows. I would explain the solution in three parts: controlled proxy connectivity, DNS and security controls, and migration. Traffic crosses through L7 proxies, a Private Service Publishing Endpoint, and private connectivity. The downside is extra proxy latency and operational work until readdressing or IPv6 removes the overlap.

The two organizations need selected applications and databases to communicate, but both networks use overlapping private IPv4 addresses. A destination address can therefore mean different machines on each side. Direct routing would be unsafe because routers could not reliably decide which network owns that address. The diagram solves this by keeping the networks isolated and making proxies the controlled crossing point. DNS sends approved service names to proxy endpoints. Private connectivity carries the approved traffic. Readdressing or IPv6 removes the overlap later.

1. Which HTTPS services and database ports must cross the boundary?
2. Which organization initiates each required connection?
3. Can either environment move to non-overlapping CIDR ranges?
4. Can both environments support dual-stack IPv4 and IPv6?

I would start by keeping the Cloud Network and Acquired Network as separate routing domains. The diagram shows no transitive routing between them. Both sides can use the overlapping 10.10.0.0/16 range without exchanging direct routes for those addresses. This prevents an application from accidentally sending traffic toward the wrong copy of an overlapping address.

For the HTTPS path, the Cloud App Service sends traffic to the Cloud Egress Proxy. That L7 proxy forwards the connection through the Private Service Publishing Endpoint, private connectivity, and the On-Prem Ingress Proxy. The ingress proxy then connects to the acquired Web/App Service. The database flow uses the same controlled boundary for approved SQL traffic. The proxies use mTLS, meaning both proxy endpoints authenticate each other with certificates. Responses return through the stateful proxy path instead of using a direct overlapping route.

The middle of the design provides private connectivity using options shown as IPsec VPN, Private Link, or Interconnect. The Private Service Publishing Endpoint exposes only the services that are meant to cross the boundary. This keeps the two address spaces isolated while still giving applications a reachable service endpoint. It also avoids making the acquired network a transit path for the cloud network, or the reverse.

Split-horizon DNS gives internal clients the correct view of a service name. A or AAAA records resolve to proxy endpoints instead of remote overlapping private addresses. Human access uses OIDC or SAML. Workload identity can use SPIFFE or SVID. Least-privilege rules allow only required services and ports. Rate limits, WAF controls, validation, DLP, and allow lists provide additional policy checks shown in the diagram.

Centralized logs collect authentication, WAF, and proxy records. Metrics, traces, alerts, request IDs, and audit records help operators follow cross-network activity. The interim phase builds proxies and private connectivity first. The medium-term phase readdresses one environment or introduces dual-stack IPv6. Native service-to-service traffic can then move away from the proxy boundary where safe. In the long term, proxies that are no longer needed can be removed. The main trade-off is temporary latency and operational complexity in exchange for predictable routing and strong isolation.

The benefit is that overlapping networks never need direct routes to each other. Proxies create a clear place to control identity, mTLS, allowed services, ports, and logging. Private connectivity also keeps selected traffic on controlled network paths instead of exposing it publicly. The downside is that each cross-network request takes an extra proxy path, which adds some latency and more components to operate. Readdressing gives a simpler long-term network, but changing addresses takes planning and migration work. IPv6 gives a much larger non-overlapping address space, but applications and networks must support it. The interim complexity is accepted because it keeps routing predictable.

At a high level, the goal is to let both regions serve users while keeping cross-region traffic secure. The hard part is moving replication and control traffic safely while handling failures and avoiding asymmetric network paths. I would explain three flows: user traffic, private inter-region traffic, and regional failover. Global DNS steers users, BGP routes the private link, and strict network policy limits access. The trade-off is better isolation and resilience with more routing, security, and operational complexity.

The application runs in two regions, and each region can serve users. The difficult part is keeping traffic secure between those regions while still surviving link or regional failures. User requests, replication traffic, and control traffic have different needs, so the diagram keeps those paths separate. The normal cross-region path is private or encrypted. An optional IPsec VPN provides another path. Health checks and global traffic steering move users away from an unhealthy region. During a regional partition, each region keeps serving local users while cross-region work is limited.

1. How much replication and control traffic should the inter-region link carry?
2. How quickly should users move away from an unhealthy region?
3. Are stale local reads acceptable during a regional partition?
4. Which cross-region writes may pause if the regions lose connectivity?

I would start with how a user reaches a healthy region. Users reach DNS & Global Traffic Manager, which uses health checks to help choose where traffic should go. Traffic then passes through Global Edge & Protection, including DDoS protection, WAF, bot mitigation, and rate limiting.

The selected region receives HTTPS traffic through its Regional Edge. The External LB passes traffic toward the Internal LB. Requests then enter the Application Tier in private subnets.

Each region contains API Service, Web Service, and Worker Service. They use private Data Tier, Cache Tier, and Messaging Tier components.

Access follows least privilege. The diagram shows IAM or roles, MFA or SSO, security groups, NACLs, micro-segmentation, egress filtering, and service-to-service mTLS. Network policy starts with default deny and allows only required communication.

The main cross-region path is the Inter-Region Private Network. It uses a dedicated private or encrypted inter-region link with BGP for routing. Replication traffic covers database, cache, and queue traffic. Control traffic carries cluster state and heartbeat messages.

Both traffic types use TLS 1.3 plus mTLS. Routing policy should keep the forward and return path consistent for a flow, which avoids problems with stateful firewalls caused by asymmetric routing. The optional Backup Inter-Region Path uses an IPsec VPN over the Internet through a secondary or different provider.

Edge and regional health checks detect failures. Automated failover updates DNS so clients can be steered toward a healthy region. This is not instant because DNS changes need time to reach clients.

Observability uses flow logs, metrics and alerts, distributed tracing, and centralized logs. These signals help operators find link, routing, and application failures.

During a regional partition, both regions continue serving local users independently. Cross-region writes pause, queues buffer local work, and retries use exponential backoff. Reads prefer local data, so stale reads may occur. When connectivity returns, replication catches up and the regions reconcile their data.

Capacity planning starts by measuring replication and control traffic. The link is sized for peak traffic plus headroom. Compression, batching, QoS or traffic prioritization, and utilization monitoring help protect important traffic. The benefit is strong isolation and resilience. The downside is more routing, security, and recovery complexity.

The benefit is that both regions can serve users while sensitive cross-region traffic stays on private or encrypted paths. Strict network rules also reduce what a compromised service can reach. The backup IPsec VPN gives another possible path if the main link fails. The downside is more complexity. BGP routing, DNS failover, firewalls, certificates, health checks, and monitoring all need careful operation. During a partition, local reads may be slightly old and cross-region writes may pause. We accept that because the design lets each region continue serving local users instead of depending on one working inter-region path.