Infrastructure Security for AWS SCS-C03

Infrastructure Security is 18% of the current AWS SCS-C03 blueprint. The domain covers security controls at the network edge, compute workloads, and network layer. It is where identity, routing, segmentation, encryption, inspection, and observability meet, so exam questions often present several technically valid controls and ask which one fits the stated risk and architecture.

The useful mindset is to work from trust boundaries. Identify what is exposed to the internet, what is private, which workloads communicate east-west, where administration enters, and which components cross account or on-premises boundaries. Then decide what should be prevented, inspected, encrypted, logged, or isolated at each boundary.

Candidates should resist equating infrastructure security with one firewall. The broader ideas in identity-aware access beyond traditional VPNs and network segmentation show why modern designs combine network controls with identity and workload context. Security groups, NACLs, route tables, WAF, inspection services, endpoints, and workload controls each solve different problems.

Security groups and network ACLs have different roles

Security groups are stateful controls attached to supported resources and are usually the primary mechanism for workload-level network authorization. Network ACLs are stateless subnet-level controls. The difference matters in troubleshooting because return traffic behavior and rule evaluation are not identical.

A common exam scenario provides a broad security group and asks whether a network ACL should compensate. The better response is usually to fix the control closest to the requirement rather than layering complexity unnecessarily. NACLs are useful for coarse subnet controls and explicit deny cases, but they are not a substitute for disciplined security-group design.

Edge security begins before traffic reaches the workload

Internet-facing architectures may involve CloudFront, load balancers, API endpoints, WAF controls, Shield protections, and route-level decisions before a packet reaches an application instance. Security requirements such as DDoS resilience, request filtering, TLS policy, and origin protection should be matched to the layer that can enforce them most effectively.

If a question is about malicious HTTP patterns, a web-aware control belongs in the reasoning. If the risk is volumetric denial of service, resilience and DDoS protections matter. If the requirement is private administrative access, exposing an SSH port and compensating with a narrow source CIDR may still be weaker than using a managed, identity-controlled access path.

Private connectivity reduces exposure but does not remove authorization

VPC endpoints and private service connectivity can keep traffic off public internet paths, which reduces exposure and can simplify egress control. But endpoint policies, resource policies, IAM permissions, DNS, and routing still determine what the caller can do. A private path is not equivalent to unrestricted trust.

Exam scenarios often combine a private endpoint with a resource policy. Read both. A principal might have IAM permission but be blocked by the endpoint policy, or the endpoint may allow a service broadly while the bucket or secret resource still restricts access. Infrastructure security is strongest when network location and identity permissions reinforce each other.

Private networking reduces internet exposure, but a reachable private endpoint still needs identity, resource policy, and service-level authorization. The security question is therefore layered: can the workload reach the endpoint, is the principal authenticated, is the request permitted, and is the data action itself appropriate? Private address space is not a substitute for access control.

Hybrid paths need encryption and routing discipline

Site-to-Site VPN, Direct Connect, and Transit Gateway can all appear in security architectures. VPN fundamentals separate connectivity from confidentiality: a dedicated private circuit is not automatically an encrypted tunnel, and a VPN backup only meets the requirement when routing, encryption, and capacity support the failover path.

Security engineers should also understand route propagation and segmentation. An inspection appliance is ineffective if sensitive traffic can route around it. A private subnet is not isolated if its route table sends unrestricted traffic through a broad egress path. Trace the actual forwarding path rather than relying on resource names such as ‘private’ or ‘security VPC.’

Central inspection creates state and symmetry requirements

Centralized firewalls and inspection VPCs can enforce consistent controls across many networks, but they introduce architecture requirements. Stateful devices often need symmetric forward and return paths. Transit Gateway route tables, appliance-mode behavior where applicable, and VPC routes must work together so the same logical inspection path sees both directions.

The security trade-off is scale versus dependency. Centralization reduces duplicated policy and can simplify logging, yet it can also create a high-impact shared service. Build redundancy, capacity monitoring, and change control around the inspection layer rather than treating it as an invisible hop.

Inspection paths should be designed for failure as well as normal traffic. Stateful controls may require return traffic to traverse the same inspection point, so routing changes during failover can create asymmetric behavior that looks like an application problem. Architecture diagrams should make both directions visible and show what happens if an inspection component or attachment is unavailable.

Workload security includes the compute boundary

Infrastructure security is not only the network. Compute workloads need hardened images, controlled instance metadata access, least-privilege roles, patching, vulnerability management, secure bootstrap, and appropriate isolation. Containers and serverless workloads shift some responsibilities but do not eliminate the need to secure code, dependencies, configuration, and runtime permissions.

If an instance is compromised, ask what the attacker can reach next. Overly broad instance roles, unrestricted egress, flat network access, and exposed management channels turn one workload compromise into a larger incident. Strong designs assume a component can fail and limit the resulting blast radius.

Observability is a preventive control as well as an incident tool

Flow logs, load-balancer logs, WAF logs, DNS logs, firewall telemetry, CloudTrail, and service metrics contribute different evidence. The principles of network observability help because security monitoring should show both expected baselines and meaningful deviations. Logging everything without analysis is not the same as visibility.

Build alerts around high-value conditions: unexpected public exposure, route changes, security-group broadening, denied traffic spikes, suspicious egress, and inspection failures. The exact service varies by architecture, but the security objective is consistent—detect when the infrastructure no longer matches the intended trust model.

Infrastructure controls should support incident response

Detection and response are separate SCS-C03 domains, but infrastructure choices influence response speed. The practices in AWS security incident response and infrastructure security become easier when workloads can be isolated, routes can be changed safely, logs are centralized, and forensic data is retained. Architecture should preserve options during an incident rather than forcing destructive recovery.

For example, a compromised instance may need quarantine without terminating it immediately. A suspicious subnet may need egress restrictions while evidence is collected. Teams should understand how security groups, route changes, snapshots, identity revocation, and automation can contain impact without erasing the data responders need.

Preventive controls are stronger when they also preserve evidence. Flow logs, firewall events, configuration history, and centralized findings help responders determine what path traffic took and which control allowed or blocked it. A design that is difficult to observe can slow containment even if its preventive rules are technically sound.

Troubleshoot from policy intent to packet path

When a legitimate connection fails, start with the intended policy: should this source reach this destination on this protocol? Then trace DNS, route tables, security groups, NACLs, inspection rules, endpoint policies, and application listeners. This sequence avoids the dangerous habit of opening controls broadly just to see whether the problem disappears.

Infrastructure Security tests whether candidates can defend an architecture without making it unmanageable. The SCS-C03 domain objectives frame trade-offs among segmentation, private connectivity, inspection, encryption, workload controls, and monitoring. Strong answers identify which layer enforces the requirement and how the team will know that control is still working.

Egress control is an important complement to inbound protection. Workloads that never need arbitrary internet access can use private service endpoints, controlled NAT paths, proxies, or firewall policies to reduce opportunities for data exfiltration and command-and-control traffic. The design should still support software updates and external dependencies through documented paths rather than simply blocking all outbound traffic without an operating model.

DNS security belongs in infrastructure reasoning as well. Route 53 Resolver logs, DNS Firewall where appropriate, and private-zone design can help detect or restrict suspicious name resolution. A network can block known malicious IPs and still allow an attacker to use DNS for discovery or command channels if resolver traffic is completely unobserved.

Administrative access should avoid permanently exposed management ports. Systems Manager capabilities, bastion patterns where required, identity-aware access, or private administrative networks can reduce internet-facing attack surface. The best option depends on workload and platform, but the goal is controlled, attributable access without distributing long-lived keys to operators.

Security testing should verify forbidden paths. A penetration or architecture validation exercise should confirm that a workload in one segment cannot reach a protected database segment except through the expected application path, that public subnets cannot bypass inspection, and that sensitive services are not reachable from unintended accounts. Positive connectivity tests prove only half of the security model.

Infrastructure changes deserve security regression checks. A new route, load balancer, VPC endpoint, peering connection, or shared service can alter reachability even if no security-group rule changes. Mature teams therefore review network topology and exposure continuously rather than treating infrastructure security as a one-time firewall configuration task.

IPv6 deserves the same security attention as IPv4. An environment can be tightly controlled on one address family while unintentionally exposing services on the other. Route tables, security groups, inspection devices, and monitoring should be evaluated for dual-stack behavior instead of assuming that an IPv4-centric design automatically governs all traffic.

Architecture reviews should also distinguish north-south and east-west controls. Internet ingress may receive strong WAF and edge protections while lateral application traffic remains broadly open. A compromised internal workload can exploit that gap. Segmenting service tiers and using identity-aware workload controls where appropriate reduces the assumption that internal traffic is inherently trusted.

Shared-responsibility reasoning should sit behind every infrastructure answer. AWS protects the underlying cloud infrastructure, while customers still configure network exposure, identity, guest or container workloads where applicable, data handling, and service-specific controls. The exact split changes by service model. Candidates should identify the layer they actually control before choosing a remediation, otherwise they may propose a change at a boundary the customer cannot operate.

Start with the intended trust boundary, then verify DNS, route selection, security groups, network ACLs, inspection policy, endpoint permissions, and application listening state. Following the path in order makes it easier to distinguish a packet that never arrived from a request that arrived and was rejected at a higher layer.

Infrastructure-security troubleshooting should also separate reachability from authorization. A packet can fail before it reaches a workload because of route selection, security-group state, network ACL behavior, endpoint policy, inspection routing, or an appliance path; it can also arrive successfully and then fail at the application or identity layer. Treating every timeout as a firewall problem leads to noisy configuration changes. A better method is to prove the path hop by hop, then inspect the narrowest control that can explain the observed symptom. That reasoning is more durable than memorizing isolated AWS networking features.