CCNA Infrastructure Security Questions

Security groups provide stateful, instance-level filtering of inbound and outbound traffic, allowing least-privilege rules per workload. This satisfies the EC2 hardening requirement by restricting which ports and sources can reach each instance, unlike subnet-level NACLs alone.

The s3:x-amz-server-side-encryption condition key only verifies that server-side encryption was requested or applied, typically checking the value such as AES256 or aws:kms, but it does not identify which AWS KMS key was used. This condition can ensure that objects are encrypted, but it cannot distinguish between different KMS keys, so it is insufficient for restricting access to objects encrypted with a specific KMS key. The requirement specifically calls for enforcing a particular KMS key, which requires a more granular condition key like s3:x-amz-server-side-encryption-aws-kms-key-id.

Gateway endpoints for S3 and interface endpoints for CloudWatch Logs keep that traffic on the AWS network, so no NAT gateway is needed. Interface endpoints use elastic network interfaces with security groups, so permitting HTTPS from the Lambda function's security group is required for the logs path to succeed.

Security groups act as a stateful virtual firewall attached to Elastic Network Interfaces, allowing you to define allow rules for inbound and outbound traffic. Stateful means return traffic is automatically permitted for an allowed request, and you can only specify allow rules—there is no explicit deny—so managing per-instance traffic at the protocol, port, and source/destination CIDR is the core instance-level measure. This is a foundational VPC security control that directly filters traffic before it reaches an instance.

AWS Security Token Service (STS) is the correct service because it explicitly issues temporary, limited-privilege credentials—typically an access key ID, a secret access key, and a session token—with configurable durations (15 minutes to 12 hours). For a mobile app that needs scoped permissions without embedding permanent keys, STS operations like AssumeRole or GetFederationToken are the direct mechanism, and the returned credentials are automatically expired, reducing risk of long-term exposure.

This is the correct and recommended approach: AWS publishes the complete set of CloudFront IP addresses used to fetch content from origins in the ip-ranges.json file, with a specific service indicator (CLOUDFRONT_ORIGIN_FACING). By adding a security group rule that allows inbound TCP 80/443 only from those CIDR blocks, the ALB will refuse connections from any other public IP, including direct internet clients that bypass CloudFront. You can implement this effectively using a managed prefix list that AWS keeps updated, or by periodically refreshing your security group rules from the published ranges.

This is the correct pattern because it explicitly denies every request where aws:SecureTransport is false, i.e., plaintext HTTP, while leaving HTTPS requests unaffected and able to be allowed by other statements. An explicit Deny always overrides any Allow, so even a broad bucket policy cannot accidentally permit insecure HTTP traffic. This is the standard, recommended way to enforce TLS for S3 data in transit.

Enabling server-side encryption on the S3 bucket that stores CloudTrail logs ensures that every delivered log object is encrypted at rest, either with SSE-S3 using Amazon-managed keys or with SSE-KMS using a customer-managed key. This directly protects the audit trail from being read by anyone who obtains the underlying storage, and it is a core requirement for compliance frameworks that mandate encrypted audit data. CloudTrail supports SSE-KMS through its own integration, allowing you to control the encryption key separately from the bucket.

Setting the target group protocol to HTTPS instructs the ALB to establish a new TLS session with each registered EC2 target rather than forwarding plaintext HTTP. This encrypts the second segment of the request path, so combined with an HTTPS listener the data is encrypted end to end. It directly addresses the missing encryption between the load balancer and the instances, making it the correct action.

An SCP in AWS Organizations can apply a deny to s3:CreateBucket for every principal in the organization by using the condition key s3:x-amz-server-side-encryption to require an encryption header such as AES256 or aws:kms. Because service control policies are evaluated before any IAM policy and apply across the root, OU, or account level, they act as a centrally managed preventive control that blocks the creation of unencrypted buckets in all member accounts. With the correct condition, any request that omits or misconfigures the encryption parameter will be denied, meeting the company's objective.

CloudTrail is the correct choice because it records StartSession API calls as management events, capturing the IAM principal, source IP, and timestamp of each session request. This gives you a detective control to answer who initiated a session and when, which is essential for security auditing and alerting on unusual activity.

The 10.0.0.0/8 CIDR block is the entire RFC1918 Class A private address space, covering every possible 10.x.x.x network used by VPCs and internal environments. Opening SSH to this range allows any compromised host in that vast address space to attempt to connect to the instance, which is an unnecessary and overly permissive ingress rule. Best practice is to scope SSH to a specific management CIDR or single IP to maintain least privilege.

Amazon CloudTrail is the authoritative source for S3 API activity, capturing both management events (e.g., CreateBucket, DeleteBucket) and, when enabled, data events for object-level actions such as PutObject, GetObject, and DeleteObject. By delivering those CloudTrail logs to Amazon CloudWatch Logs, you can create metric filters and alarms for real-time monitoring of API calls, making this the correct combination for a complete S3 audit trail.

NODATA means the capture window closed with no matching packets, which is common for flows that are logging only accepted or only rejected traffic. REJECT means packets were observed but denied by a security group, network ACL, or similar control, so the connection attempt is visible in the record.

The aws:SourceVpce condition key is the correct way to restrict an S3 bucket to requests that came through a specific VPC endpoint. You write it in the bucket policy's Condition block using StringEquals and set the value to the full VPC endpoint ID, such as vpce-0abcdef123456789. Because this key is present in the request context only when the request traffic actually travels through the specified VPC endpoint, it gives the most precise endpoint-level control among the listed options.

AWS Config continuously records the configuration state of security groups, including each ingress and egress rule change, and can deliver configuration-history timelines and compliance snapshots. AWS CloudTrail captures the API actions that initiate those changes, logging the principal, user agent, and request parameters for every management event. Together they provide both the 'what' (configuration state via Config) and the 'who/when/how' (API activity via CloudTrail), enabling a complete audit trail of security group changes. For example, when a rule is removed, Config shows the new state while CloudTrail reveals the identity of the caller.

AWS WAF is a web application firewall that monitors and filters HTTP(S) requests based on conditions like IP reputation, country, URI, and SQL injection signatures. When integrated with AWS Shield Advanced, it provides the primary mechanism for application layer (L7) DDoS mitigation—enabling you to add rate-based rules and block anomalous traffic before it reaches the origin. This direct, request-level inspection makes it the correct option for protecting a web application.

A VPC Gateway Endpoint for S3 uses the AWS-managed prefix list (com.amazonaws.<region>.s3) as a route-table target in the private subnet, so traffic to S3 stays on the AWS backbone and never leaves the VPC. Instances do not need public IPs, NAT, or an internet gateway, and gateway endpoints do not incur hourly charges. Configuring the route table and endpoint policy enables the private instance to download patches from selected S3 buckets securely without altering the instance's public/private status.

This is the exact IAM action that authorizes the RunInstances API call, which provisions one or more EC2 instances along with associated root volumes and network interfaces. The action can be scoped with condition keys such as ec2:SubnetId to restrict launches to specific subnets, and it is the only action listed that creates the underlying compute resource. Therefore, this is the correct permission for allowing a developer to launch EC2 instances.

The VPC has a route for the on-premises CIDR pointing to the virtual private gateway, so outbound packets traverse the Direct Connect virtual interface. However, for successful two-way communication, the on-premises router must have a route for the VPC CIDR that points back to the same Direct Connect interface. Because this return route is missing, response packets are either sent to a default route or dropped, so hosts in the VPC see no replies. This is a classic asymmetric routing failure.