AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 301–375

This is the correct approach: referencing the application server's security group (SG) as the source in the RDS inbound rule permits only traffic originating from network interfaces attached to that specific SG. This pattern—often called SG chaining—is dynamically updated if the instance's private IP changes, is not tied to subnet boundaries, and automatically covers any additional instances that later receive the same SG, making it the most precise and maintainable solution.

AWS Identity and Access Management enforces authentication and authorisation through policies, satisfying the stem's requirement that only authorised users access S3 objects. It provides the permission boundary, while a logging service supplies the audit trail of that access.

Amazon CloudWatch Logs can receive CloudTrail events and apply a metric filter, for example matching $.userIdentity.type = 'Root' and $.eventName = 'ConsoleLogin', to count root credential activity. A CloudWatch alarm on that metric threshold can then trigger an SNS notification to alert the company in near real time. This is the correct service because it directly enables custom, log-driven alerting on the root account usage pattern.

Restricting access to the S3 bucket with a bucket policy that includes the aws:MultiFactorAuthPresent condition ensures that every request requires MFA authentication, significantly reducing the risk of unauthorized log access even if a user's long-term credentials are compromised. Adding an encryption enforcement condition, such as requiring TLS (aws:SecureTransport) or mandatory SSE-KMS headers, further protects the logs in transit and at rest. This layered access control is a best practice because it hardens the audit trail against both external attacks and accidental exposure.

In the management account, edit the existing organization trail and update its event selectors to include S3 data events, choosing 'All S3 buckets' for object-level operations such as GetObject, PutObject, and DeleteObject. CloudTrail propagates this configuration to every member account, so all current and future accounts are captured automatically without per-account changes. This is the intended, least-effort method and keeps delivery centralized in the original destination bucket.

Under SSE-C, the customer must provide the encryption key in the headers of every S3 request, such as x-amz-server-side-encryption-customer-key. S3 uses that key to encrypt the object at write time and to decrypt it at read time, then discards the key after the request completes. Because the key is never stored by AWS, it must be supplied again for each upload, download, or header retrieval.

Amazon CloudWatch Alarms watch the EC2 instance's CPUUtilization metric published to CloudWatch and transition to ALARM when the value crosses a defined threshold for consecutive evaluation periods. Because this metric and the alarm's state are specifically designed for performance monitoring, an alarm can directly trigger actions such as SNS notifications or Auto Scaling policies when CPU load becomes unacceptable.

The AWS managed key for EBS (aws/ebs) is a KMS key that AWS creates and manages in the customer's account, and AWS KMS automatically rotates it once per year. Because EBS volumes can use this key by default and no customer action is required for rotation, it satisfies the requirement for automatic rotation. This is the key type that the question is asking to identify.

AWS CloudTrail is the authoritative audit trail for AWS API activity, recording every management and data event with the invoking IAM identity, source IP address, user agent, and timestamp. For a credential investigation, CloudTrail lets you reconstruct exactly which programmatic or console actions were performed with the suspected credentials, including failed authentication attempts and sign-in events from the us-east-1 region. It can also be configured to deliver those immutable logs to S3 for long-term forensics and to CloudWatch Logs for real-time alerting, making it the primary service to answer 'who did what, when, and from where'.

Amazon Route 53 Resolver DNS Firewall enables you to filter and log DNS queries that are made through Amazon Provided DNS within a VPC. By associating DNS Firewall rule groups with a VPC and enabling Route 53 Resolver query logging, you capture detailed DNS query metadata, including the queried domain name, query type, response code, and the source IP of the requester. This makes it a direct fit for the security requirement to capture all DNS queries, because it both monitors and optionally blocks DNS traffic at the resolver level.

AWS Direct Connect with VPN is the correct combination because Direct Connect gives you a dedicated, private network connection that bypasses the public internet, offering consistent latency and bandwidth. Since Direct Connect alone does not encrypt your traffic, the VPN overlay (typically IPsec) is added to encrypt data in transit over that private connection. This pairing satisfies both explicit requirements: a dedicated transport path and encryption for all data between the on-premises environment and AWS.

This is correct because it follows the principle of least privilege by limiting SSH inbound traffic to the specific IP range (or security group) that represents the company's administrators. By restricting the source to known administrative egress addresses, the attack surface is dramatically reduced and unauthorized internal or external actors cannot initiate SSH connections. For a production web tier, SSH should typically be allowed only from a bastion jump host or a dedicated admin VPN CIDR, not from a broad public range. This ensures that only authenticated, expected users can establish a management session.

Route 53 Resolver query logging captures DNS queries from within a VPC and can deliver them directly to an S3 bucket, meeting both the query-visibility and compliance-storage requirements. Resolver logging is the VPC-scoped mechanism; public hosted zone logging would not capture instance queries.

S3 Object Lock in compliance mode prevents deletion or overwrite of log objects for the retention period, satisfying the immutability requirement. CloudTrail log file validation adds a digest file so tampering with delivered logs is detectable. An EventBridge rule matching the StopLogging event (and other trail-modification APIs) provides the alerting on attempts to disable logging.

AWS Systems Manager Run Command can invoke a memory acquisition utility on the live instance, such as one using the Linux kernel module LiME, to copy the contents of RAM to an EBS volume or S3 without requiring a reboot or instance stop. This preserves volatile evidence like loaded kernel modules, open network sockets, and running processes, which are essential for determining the scope of compromise. Storing the memory dump in S3 protects chain of custody if versioning and object lock are enabled, and it does not alter the underlying disk volumes.

AWS IAM Identity Center (formerly AWS SSO) is the purpose-built service for centrally managing workforce access and single sign-on across multiple AWS accounts, business applications, and SAML 2.0/OIDC-capable solutions. It can connect to an external identity provider (such as Okta or Azure AD) and map that provider's identity groups to AWS permission sets, issuing temporary credentials for the console or CLI. This makes it the correct choice for allowing employees to authenticate to AWS with their existing corporate credentials.

SSE-KMS with a customer-managed key gives you independent control over the CMK, including the ability to set key policies, grant and revoke permissions, and force rotation. With CloudTrail for KMS enabled, every Decrypt, GenerateDataKey, and ReEncrypt request against that key is recorded with the user, role, and principal ARN, directly tying each S3 object access to an auditable event. Customer-managed keys also let you align the key with your own governance model, and because the key is in KMS, you can use key policies to enforce conditions (such as VPC endpoints or MFA) and can respond to a breach by disabling the key to instantly block all future decrypt operations.

Correct. The trust policy of the role in Account B must include Account A as a trusted entity, and the user in Account A must have the sts:AssumeRole permission (via an IAM policy attached to their user or group).

The current policy only lists the object ARN (arn:aws:s3:::bucket/*) in the Resource element, so the Deny statement applies to object-level operations like s3:GetObject and s3:PutObject. To also block bucket-level actions such as s3:ListBucket, the Resource must include the bucket ARN itself (arn:aws:s3:::bucket). Adding the bucket ARN (without the trailing /*) ensures both the bucket and its objects are covered by the Deny, satisfying the rule's requirement for bucket-level HTTP denial.

An SQL injection match rule in AWS WAF inspects the request components you configure—such as the query string, body, header, or cookie values—for known SQLi signatures like ' OR '1'='1, UNION SELECT, or comment and quote sequences. It uses pattern matching, optionally normalized with rule-specific text transformations to reduce evasive bypasses like URL encoding or case variation. This is the only rule type among the options that performs payload-level content inspection and produces a match based on the actual malicious input in the request, making it the correct choice for detecting SQL injection.

AWS CloudTrail records S3 API activity, including object-level data events when enabled, satisfying the compliance requirement to log all bucket access. Unlike S3 server access logging, which captures only bucket-level requests, CloudTrail delivers detailed API call records to an S3 bucket or CloudWatch Logs for auditing.

A network ACL (NACL) is a stateless firewall applied at the subnet level, and it explicitly supports both allow and deny rules. By adding a deny rule for inbound TCP port 22 from 0.0.0.0/0 with a low rule number, you block all SSH traffic from any source from entering the subnet. This is the correct method because security groups cannot provide an explicit deny, and the NACL rule operates at the subnet boundary rather than at individual resources.

VPC Flow Logs capture metadata about IP traffic to and from network interfaces, including source and destination IPs, ports, protocol, and packet/byte counts. This enables you to see large outbound transfers to an unusual external IP, which is a classic sign of data exfiltration. Note that flow logs do not contain payload contents, but they are the foundational raw network log for investigating suspected exfiltration.

AWS CloudTrail is the correct service because it provides a continuous, immutable audit log of every API call made in your AWS account, including the IAM actions that modify policies such as PutRolePolicy, AttachUserPolicy, and DeletePolicy. Each event captures the identity of the caller, the source IP, the time, and the request parameters, making it the definitive source for security audits of IAM changes. CloudTrail's event history is viewable for 90 days, and you can extend retention with a trail that delivers events to an S3 bucket or CloudWatch Logs for long-term compliance.

An EBS snapshot captures a point-in-time, block-level copy of every attached volume, preserving disk artefacts such as logs, malware and deleted files without altering the running instance. It satisfies evidence preservation while keeping the original instance available for further collection.

PutLogEvents requires access to the log group resource as well.

Security Hub natively publishes findings to an Amazon EventBridge default event bus, so a rule in the administrator account can match the source 'aws.securityhub' and invoke a Lambda function for immediate remediation. The Lambda function can parse the finding ID, AwsAccountId, and compliance status, then execute corrective action such as modifying an IAM policy or enabling encryption. In a multi-account organization, this is the intended native path for turning Security Hub findings into automated responses, especially when cross-Region aggregation is enabled.

Amazon GuardDuty is a continuous, intelligent threat detection service that ingests CloudTrail management events, VPC Flow Logs, and DNS query logs to detect suspicious API calls. It builds a baseline of normal account behavior and uses anomaly detection, machine learning, and threat intelligence to identify actions such as unusual logins, IAM privilege escalation, or resource exposure. Enabling it in each account gives complete coverage of API activity across the organization.

SSE-KMS (Server-Side Encryption with AWS KMS) instructs S3 to encrypt each object at rest using a customer managed KMS key, AWS managed KMS key, or AWS owned key. S3 calls KMS to generate a plaintext data key and an encrypted copy of that key, using envelope encryption to protect the object while maintaining the ability to rotate the KMS key independently. This gives you separation of duties, centralized key management, and auditability, making it a valid way to enforce at-rest encryption.

Ingress from 0.0.0.0/0 on port 22 exposes SSH to the entire internet, permitting brute-force and credential-stuffing attempts against every instance in that security group. This unrestricted CIDR is the concrete exposure the log reveals, regardless of other fields present.

IAM Access Analyzer continuously analyzes resource-based policies and creates findings whenever access to a resource like an S3 bucket is granted to an external principal — an AWS account outside your zone of trust or an anonymous principal. Each finding details the external account/principal, the exact actions allowed, and the policy statement causing the access, so you can determine whether that access is intended. In the console you can then mark the finding as 'Archive' for intended access or take remediation action for unintended access, which is the only option here that directly answers the security engineer's question.

AWS Firewall Manager is the designated service for centrally managing VPC security group rules across all accounts and resources within an AWS Organization. It allows administrators to create security group policies, enforce common security group rules, remediate noncompliant rules automatically, and apply consistent protection to new accounts as they join the organization. This directly matches the requirement for central management of security group rules, making it the correct answer.

AWS Config's managed rule `s3-bucket-server-side-encryption-enabled` continuously evaluates each S3 bucket for the presence of server-side encryption. When a bucket is found non-compliant, an automatic remediation action—typically a Systems Manager Automation document that calls `PutBucketEncryption`—is invoked to enable default encryption on that bucket. This provides a closed loop that both detects drift and corrects it for existing and newly created buckets, making it the only option that satisfies 'ensure all S3 buckets' proactively and reactively.

A VPC peering connection privately connects two VPCs using AWS's internal backbone, with no traffic traversing the public internet and no need for a public IP address, VPN appliance, or gateway. It creates direct layer-3 route table entries between the VPC CIDRs, and because the relationship is native to AWS, traffic stays isolated from external carriers. For a single application-to-database pair with non-overlapping CIDRs, VPC peering is the simplest and most cost-effective way to establish low-latency private connectivity.

A public subnet routes 0.0.0.0/0 to an internet gateway, so web servers can receive inbound internet traffic and respond outbound. This satisfies the requirement that web servers be internet-accessible, while application servers remain in private subnets with no such route.

EventBridge is the least-overhead, near-real-time option because CloudTrail automatically delivers all management events to the default EventBridge bus without extra configuration. A rule with an event pattern that matches eventSource="iam.amazonaws.com" and eventName="CreateAccessKey" triggers an SNS topic immediately when the API call occurs, enabling instantaneous security notifications. This is fully event-driven and serverless: there is no polling, no custom code, no log parsing, and no separate metric filter to maintain, which makes it the architecturally cleanest solution.

Allowing SSH (port 22) from 0.0.0.0/0 in the security group exposes the instance's administration interface to the entire internet, enabling brute-force attacks, credential stuffing, and potential unauthorized access. This directly violates the principle of least privilege and is a well-known high-severity misconfiguration, making it the most immediate security risk in the template.

The bucket policy contains two separate allow statements that combine as an OR. One allow statement grants s3:PutObject when the request header s3:x-amz-server-side-encryption is set to aws:kms, covering KMS-encrypted uploads. The second allow statement grants s3:PutObject when the encryption header is absent, covering unencrypted uploads. Because AWS policies evaluate allow statements additively, the effective permission is exactly that uploads with KMS encryption or without encryption are allowed.

The kms encrypt API returns a CiphertextBlob, and the AWS CLI base64-encodes this binary field in its JSON output. The ciphertext is encrypted under the customer master key specified in the command, so the same KMS key can decrypt it by calling kms decrypt after base64-decoding the blob. This matches the actual behavior of the command and is therefore the correct answer.

The alternating users rotation strategy creates a second set of database credentials while the original remains valid, then promotes the new credentials to AWSCURRENT and demotes the old ones to AWSPREVIOUS. Applications can continue using either credential during the transition, so there is no window where no valid password exists. This makes it the right choice when a database cannot tolerate even brief downtime during Secrets Manager rotation.

AWS CloudTrail is the correct service because it records management events for all IAM actions, including CreatePolicy, PutRolePolicy, AttachUserPolicy, and DetachUserPolicy, and includes the identity of the caller, the time of the request, source IP, request parameters, and response elements. Management events are logged by default for every region, and you can create a trail to deliver them to S3 for long-term retention and protection with features such as S3 object lock and CloudWatch Logs integration. This gives the security team a complete, chronological audit trail of every IAM policy change.

Two separate deny statements ensure that an upload is denied if it lacks the correct encryption algorithm or if it uses a different KMS key. The first statement denies any upload not using aws:kms. The second denies any upload not using the specified key ARN. Together they enforce both requirements. This is the recommended approach in AWS documentation.

Security Hub aggregates and prioritises findings from GuardDuty, which performs the actual threat detection for compromised instances and malicious activity. Together they satisfy the requirement for comprehensive detection plus centralised alerting across the AWS environment.

Creating a new CMK every 90 days and then updating the alias to reference the new key provides a stable abstraction because applications point to the alias, not the key ID. The alias update is immediate and atomic, requiring no application changes, restarts, or downtime; the old CMK remains enabled to decrypt data encrypted under previous keys. This pattern is the recommended AWS KMS approach for custom rotation periods and satisfies crypto-period separation.

GuardDuty ingests VPC Flow Logs from enabled VPCs to analyze network traffic metadata, including source and destination IPs, ports, and packet counts. It uses this telemetry to detect malicious activities like port scanning, brute-force attempts, and communication with known command-and-control or cryptocurrency-mining infrastructure. Flow Logs must be enabled for the VPCs you want monitored, and GuardDuty consumes them through an integrated service-linked role.

AWS Config continuously records S3 bucket configuration and evaluates it against managed or custom rules, flagging buckets lacking default encryption. This satisfies the requirement for ongoing detection and alerting, unlike one-off scans or CloudTrail, which logs API activity rather than resource compliance state.

Create a dedicated inspection VPC that hosts a firewall appliance or a Gateway Load Balancer, and use separate Transit Gateway route tables to force inter-VPC traffic through that VPC. For example, associate each spoke VPC attachment with a route table that has a target route pointing to the inspection VPC attachment for all destination CIDRs, while the inspection VPC uses its own route table to reach the final destination VPCs. This design leverages Transit Gateway's transitive routing and supports high availability through multiple firewall instances behind a Gateway Load Balancer. It is a best practice for centralized east-west traffic inspection in a multi-VPC topology.

AWS Config continuously records each supported resource's configuration history and evaluates that state against customizable rules and conformance packs. When a resource violates a rule, Config can invoke an AWS Systems Manager Automation document to perform auto-remediation, such as restoring security group rules or untagging resources. This combination of continuous evaluation and corrective action is exactly what is needed to enforce the intended deployed state from CloudFormation.

The web ACL contains two rules evaluated in order. The first is a rate-based rule with a threshold of 2,000 requests per IP address over the evaluation window; when that limit is exceeded, the Block action immediately terminates the request. Requests that stay below the threshold continue to the second rule, an XSS match rule whose action is set to Allow, so any request with `<script>` in its body is explicitly permitted rather than blocked. The net effect is therefore IP-based volumetric blocking only, with no content-based blocking.

Route 53 Resolver query logging is the native capability that records the full DNS query and response data for queries handled by Route 53 Resolver, including those from VPCs, inbound, and outbound endpoints. It can directly write logs to a central S3 bucket, and using a cross-account bucket policy, you can allow Route 53 in your account to deliver into the consolidated logging bucket. This approach avoids any intermediate compute, scales automatically, and is the most straightforward secure delivery mechanism.

The DeliverLogsPermissionArn role must have a trust policy allowing vpc-flow-logs.amazonaws.com to assume it and an IAM permissions policy granting logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. Without logs:PutLogEvents, the Flow Logs service cannot append records to the CloudWatch log stream, so the flow log remains in a FAILED state. Adding the missing PutLogEvents permission is the standard fix for this symptom.

CloudTrail can be configured to deliver events to Amazon CloudWatch Logs within minutes, and a subscription filter can immediately forward matching events to Amazon Kinesis Data Firehose. Firehose then buffers and delivers a continuous stream to Amazon OpenSearch Service, which indexes documents as they arrive for near-real-time search and visualization with OpenSearch Dashboards/Kibana. This managed pipeline gives the low-latency ingestion and querying the requirement asks for.

Cross-account access needs two sides: the trust policy in the owning account and an identity-based policy in the external account granting sts:AssumeRole on the role ARN. Without that permission attached to the calling principal, the AssumeRole call is denied.

This standard three-tier design places only the web tier in public subnets with a route to an internet gateway so it can serve external users. The app and database tiers are in private subnets with no internet gateway route, preventing direct inbound connections from the internet; the app tier receives traffic from the web tier through an internal load balancer or security group rules, and the database is isolated to app-tier-only access. This minimizes the attack surface and is the correct pattern for a public-facing web application.

AWS Organizations tag policies are a centralized policy type that define which tag keys and values are allowed on resources across all accounts in the organization. Attached to the root, an OU, or an account, they act as a preventive guardrail during resource creation and modification, so a resource that is tagged outside the allowed rules can be denied. This makes them the native service for enforcing specific tags organization-wide.

SCPs set permission guardrails by defining the maximum actions that principals in an account or organizational unit can perform. When attached at the organization, OU, or account level, an SCP constrains all IAM users and roles in that account—including the account root user—by filtering what identity-based and resource-based policies are allowed to grant. They act as a boundary that limits, but never grants, permissions, making them the correct mechanism for organization-wide controls such as denying the deletion of CloudTrail logs or restricting access to certain AWS services.

Suspending HealthCheck and ReplaceUnhealthy stops the Auto Scaling group terminating or replacing the instance while it is isolated for forensics. This preserves volatile memory and disk state, which would otherwise be lost if the group launched a replacement.

End-to-end encryption requires TLS on both hops: an HTTPS listener terminates client TLS, while an HTTPS target group re-encrypts traffic to the instances. Installing certificates on the EC2 instances lets them present them, satisfying the requirement that ALB-to-instance traffic is encrypted.

AWS Config is the correct answer because its managed rule "s3-bucket-logging-enabled" checks the configuration state of each S3 bucket and determines whether server access logging is pointed at a valid destination bucket. AWS Config records bucket resource configurations as configuration items, evaluates them against desired policies, and provides continuous compliance results, which matches the security requirement precisely. It can optionally trigger automatic remediation via Systems Manager Automation if a bucket is found noncompliant.

IAM roles for Amazon EC2 instances provide temporary security credentials through the instance metadata service, eliminating the need to store any long-term secret material inside the instance. These credentials are automatically rotated and can be scoped with a precise permissions policy, so even if the instance is compromised, the blast radius is limited. This approach also simplifies key management because there is no auth material to embed, rotate, or revoke individually.

Adding a security group rule to allow inbound SSH (port 22) only from the corporate IP range is the correct solution because security groups are stateful and act at the instance's network interface level. This rule denies all other inbound SSH traffic by default, since security groups have an implicit deny-all inbound rule, and because it is stateful, return traffic for allowed connections (e.g., ephemeral ports) is automatically permitted. This directly restricts SSH to the corporate range without requiring separate outbound rules, making it the appropriate mechanism for this use case.

AWS Security Hub aggregates security findings from across AWS accounts and services and runs automated, continuous compliance checks against standards such as CIS AWS Foundations, AWS Foundational Best Practices, and PCI DSS. It provides a consolidated security score and actionable insights, enabling automated enforcement of security best practices. This integration and standard-based evaluation make it the correct service for the stated requirement.

CloudTrail Log File Integrity Validation is correct because it generates a SHA-256 hash of each log file and signs it with a private key, enabling you to detect any tampering or deletion of log files. You can retrieve the public key from a pre-signed URL to verify both the hash and the digital signature, ensuring the logs have not been altered. This provides strong, cryptographic proof of integrity, which is exactly what the requirement demands.

The key policy scopes kms:Decrypt to calls whose encryption context contains department=finance. The decrypt request supplies a different encryption context, so the kms:EncryptionContext:department condition key does not match. As a result, the condition in the key policy is false and KMS denies the Decrypt operation. This is expected behavior: encryption context conditions are a way to limit key usage to specific data or workloads.

This trust policy is correct because it grants the external account's root principal (arn:aws:iam::123456789012:root) permission to call sts:AssumeRole only when the aws:MultiFactorAuthPresent condition evaluates to true. This enforces that any IAM principal from that account must have authenticated with an MFA device before assuming the role, which is a security best practice for external auditors. Using the account root ARN as Principal is the standard pattern because it delegates the actual user and role management to the external account.

Applying an SCP to the organization root or to all member accounts that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail ensures that even an IAM admin or the root user in a member account cannot disable or delete the trail. An organization trail automatically delivers CloudTrail logs from every account to a designated central S3 bucket, and the bucket policy can explicitly Deny actions such as s3:DeleteBucket, s3:DeleteBucketPolicy, and s3:DeleteObject for all principals, making the log data tamper-proof. This combination provides a centralized, immutable audit record while removing the ability of individual account administrators to interfere with logging. It directly satisfies the requirement to prevent disabling and to protect the integrity of the logs.

A suppression rule filters findings matching specified criteria, such as the IAM user's principal ID, and automatically archives them so the security team stops receiving alerts. This satisfies the requirement to suppress the false-positive findings while keeping GuardDuty fully enabled and monitoring all other activity.

Security Hub aggregates findings from GuardDuty, Inspector, and IAM Access Analyzer into a single view. Custom actions allow you to define remediation steps, and EventBridge rules can trigger Lambda functions to automate remediation based on severity. This meets the requirement for centralized management and automated response.

An organization trail created in the management account automatically logs events from every member account into one S3 bucket, removing the need to configure and maintain individual trails per account. This directly satisfies the centralised collection requirement.

AWS CloudTrail is the authoritative service for recording API activity: it captures every management and data event with details such as the event name, IAM user or role that made the call, source IP address, request parameters, and response elements. When you send those CloudTrail events to CloudWatch Logs via a trail, you can define a metric filter on a specific pattern — such as eventName for a sensitive action or an errorCode indicating failed access — and attach a CloudWatch Alarm to trigger an SNS notification. That pipeline gives a deterministic, near-real-time alert for account activity, which is exactly what the security engineer needs.

PrivilegeEscalation:EKS/KubernetesAPICallFromContainer is correct because GuardDuty specifically samples Kubernetes audit logs and correlates the source IP and user agent to identify when a container makes API calls to the Kubernetes control plane. A container that calls sensitive APIs, such as creating privileged pods, binding cluster roles, or listing secrets, may be attempting to escalate privileges and potentially escape the container runtime. Since this finding directly matches the suspicious API activity from a container using EKS audit logs, it is the most appropriate detection for a container escape.

The KMS key policy acts as the resource-based authorization for the key and must explicitly grant the Amazon EFS service principal (elasticfilesystem.amazonaws.com) the kms:GenerateDataKeyWithoutPlaintext, kms:Decrypt, and kms:DescribeKey permissions. Without these grants in the key policy, EFS cannot create or use data keys to encrypt or decrypt the file system, even if the IAM principal has full EFS permissions. This is a mandatory, non-optional part of enabling EFS encryption at rest — the key policy is the authoritative control over which AWS services may use the CMK. Therefore, configuring the key policy correctly is a required action, not merely a best practice.

Referencing the ALB's security group as the source is a security group-to-security group rule: it dynamically matches any IP address associated with an elastic network interface that belongs to that ALB security group. This means EC2 instances behind the ALB accept traffic only from the ALB's ENIs, even as the ALB scales and its private IPs change. The rule is stateful, so return traffic flows automatically, and no internet CIDR is ever exposed. This is the AWS-recommended pattern for placing an ALB in front of a web tier.

IAM policy conditions allow you to add context-aware requirements to an allow statement, such as restricting the source IP with 'aws:SourceIp', requiring an MFA token with 'aws:MultiFactorAuthPresent', or limiting EC2 actions based on resource tags with 'ec2:ResourceTag'. This goes beyond identity alone by enforcing that the request also looks like it comes from a trusted network or satisfies other organizational controls. Conditions are a core defense against stolen credentials and are essential for implementing least privilege in real-world environments where access should depend on more than just who is calling.