AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 976–1050

This is the standard cross-account access pattern. The role's trust policy specifies the vendor's account as the principal, allowing its IAM users to assume the role via STS. The permissions policy grants S3 access. No IAM users are created in the company account, and all access is audited through CloudTrail, which logs AssumeRole and S3 API calls. This meets all requirements.

Security Hub's cross-account aggregation consolidates findings from all member accounts into a single delegated administrator account, enabling a central view of threats. You can then create EventBridge rules that match specific finding types and trigger Systems Manager Automation runbooks, which can execute remediation actions directly in the affected member account. This provides centralized, event-driven response without manually managing each account individually.

AWS CloudTrail captures all API activity as events, including who made the call, which service, and the result. These events are delivered to Amazon EventBridge in near real time, where a rule can filter for a specific action (for example, `iam:CreateUser` or `sts:AssumeRole`) and route the matched event to an SNS topic or Lambda function to send a notification. Together they provide an event-driven pipeline for real-time alerting on API calls.

The second statement grants ReceiveMessage to Principal '*' but limits the request to the 10.0.0.0/8 network via aws:SourceIp. That condition only restricts the caller's IP address; it does not restrict which IAM principal or account can call, so any authenticated principal originating from that CIDR may receive messages. Production should scope the principal to a specific account or IAM role, or add aws:SourceArn if the intent is to allow only a single source service.

This is correct because security group references create a logical firewall between tiers that is independent of IP addresses. The application tier security group only accepts HTTP traffic originating from resources that are members of the web tier security group, and the database tier security group only accepts MySQL traffic from members of the application tier security group. AWS resolves the referenced security group to the private IPs of its associated instances at the time the traffic is evaluated, so scaling events and IP changes do not require rule updates.

Log file integrity validation is a CloudTrail feature that uses SHA-256 hashing and digital signatures to build a hash chain across log and digest files. CloudTrail periodically delivers a signed digest file that includes the hash of every log file delivered during that period and the hash of the previous digest. If anyone modifies or deletes a log after delivery, the hash stored in the next digest will not match, and the validation command will flag the discrepancy. This is the only option here that provides direct, detection-based integrity assurance for CloudTrail logs.

Amazon EventBridge can match events from AWS CloudTrail and trigger alerts via Amazon SNS or other targets. You can create a rule that matches specific API calls like StopLogging or DeleteConfigurationRecorder and sends a notification. This provides near-real-time alerts for the specified events.

s3:ListBucket is a bucket-level action, so IAM evaluates the Resource against the bucket's ARN (arn:aws:s3:::bucket), not the ARN of objects inside it. A resource pattern that includes only the wildcard for object keys (e.g., arn:aws:s3:::bucket/*) does not match the bucket ARN, because the bucket itself is a distinct resource. Consequently, the allow statement does not cover this request, and the user cannot list the bucket.

The IAM credential report provides a CSV file listing all IAM users and the status of their credentials, including passwords, access keys, MFA devices, and the last used date for each. It is the most direct way to obtain the required information for identifying unused credentials.

Amazon GuardDuty is a continuous threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to analyze AWS CloudTrail management events, VPC Flow Logs, and DNS query logs. It identifies suspicious API calls, potential credential compromise, and malicious network traffic, and generates detailed findings that can be sent to CloudWatch Events to trigger automated notifications or responses. This directly enables detection and alerting on suspicious activity in near real-time.

EventBridge can match CloudTrail management events in near real time. By creating a rule that filters for DeleteBucket events, you can route the full event JSON to an SNS topic, which sends email or SMS to the security team. This provides rapid notification and includes details like the IAM role and bucket name in the event payload.

SCPs can deny actions based on conditions, enforcing encryption at creation time.

Enabling S3 Block Public Access at the account level is the definitive control because it applies a centralized, organization-wide guardrail that overrides any per-bucket settings. It blocks public access through all four mechanisms—ACLs, bucket policies, access point policies, and multi-object access point policies—and, once set, cannot be overridden by a bucket policy unless the account-level setting itself is changed. This creates a hard boundary that ensures no bucket in the account can be made publicly accessible, even if a future misconfiguration or a bucket policy explicitly permits public access. The question asks for actions to 'ensure' protection, making this the strongest and most reliable answer as it covers all existing and future buckets.

Amazon CloudWatch Logs can ingest CloudTrail events when a trail is configured to send events to CloudWatch Logs, and then you can create a metric filter that uses pattern matching to identify specific API calls such as 'StopInstances' or 'DeleteBucket'. The metric filter counts occurrences of matching events in near-real time, and a CloudWatch alarm on that metric can trigger an SNS notification or other action. This is a native, fully managed solution for custom API call detection and alerting, directly satisfying the security team's requirement.

In S3, an explicit deny in a bucket policy takes precedence over any allow from an identity-based IAM policy. When a bucket policy includes a Deny statement that matches the principal, action, and resource, the request is rejected regardless of the user's IAM permissions. This is the most direct and common cause of an Access Denied error when the user's IAM policy already grants the s3:ListBucket action.

This is the correct approach because Amazon EventBridge can ingest CloudTrail API calls in near real time via the default event bus in each account. You can then attach a rule that matches specific CloudTrail event names (e.g., ConsoleLogin, CreateAccessKey) and routes them to a centralized event bus in a monitoring account using an EventBridge cross-account target. This enables immediate, event-driven processing through AWS Lambda, Step Functions, or SNS, and avoids the multi-minute batching delays inherent in CloudTrail S3 delivery.

Amazon Athena is the correct choice because it allows you to query ALB access logs directly in S3 using standard SQL without needing to load or transform the data. You can create an external table over the gzipped log files, then run SQL queries that look for SQL injection indicators such as 'OR 1=1', suspicious quotes, or UNION SELECT statements in the request and URL fields. This serverless, on-demand query engine is ideal for post-incident forensic analysis of historical access logs stored in S3.

HTTPS endpoints for S3 API calls use Transport Layer Security (TLS) to encrypt the entire HTTP request and response payload between the on-premises client and the S3 service. This protects the confidentiality and integrity of data in transit, preventing eavesdropping and tampering. Using HTTPS is the standard, built-in mechanism for securing S3 API traffic, and it applies regardless of whether the client is in your VPC or on-premises.

The Deny statement applies to all actions, including sts:AssumeRole, because its Action element is the wildcard '*'. Its condition, typically 'aws:MultiFactorAuthPresent' being false, is true for a user who has not authenticated with MFA, so the explicit deny is in effect. Under IAM's evaluation logic, an explicit deny always blocks the request, regardless of any other matching Allow statements, so the role assumption fails.

Tabletop exercises and game days on AWS simulate realistic compromise scenarios (e.g., a compromised EC2 instance or leaked access key) so responders can validate runbooks, verify IAM escalation/containment steps, and identify gaps before a real event. AWS Well-Architected and Security Incident Response guides recommend periodic testing to improve procedural accuracy, tool effectiveness, and decision-making under stress. This is a core preparedness activity.

Systems Manager Automation is the correct service because it runs SSM runbooks in response to events via Amazon EventBridge. A GuardDuty finding event can invoke a public or custom runbook, which then performs steps such as updating a VPC Network ACL with a deny rule for the offending IP address. This service provides built-in approval gates, rollback controls, and parameterized execution, making it the native orchestration layer for GuardDuty-driven incident response rather than a mere compute or provisioning tool.

With the condition key aws:SecureTransport set to false, the Deny effect triggers only when the request travels over plain HTTP. Since the Action is limited to s3:PutObject, only object uploads are blocked; other operations remain unaffected. The result is that any PUT request without TLS is rejected, effectively mandating HTTPS for uploads to the bucket while still allowing secure uploads to proceed.

S3 Glacier Deep Archive satisfies the seven-year retention mandate at the lowest storage cost, while the lifecycle policy automates both the transition and the expiry date. This removes manual intervention entirely, delivering the least operational overhead compared with custom archival pipelines or third-party tooling.

GuardDuty is a continuous, intelligent threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to identify unexpected and potentially malicious activity within your AWS environment. It analyzes CloudTrail management and data events, VPC Flow Logs, and DNS query logs to detect suspicious API calls, unusual network traffic, and compromised credentials. Findings are generated with severity levels and can automatically trigger remediation workflows via EventBridge, making it the ideal service for investigating a potential compromise.

The role can decrypt objects in S3 because the policy grants kms:Decrypt and includes a condition that limits the key's use to the S3 service in us-east-1 (for example, kms:ViaService with s3.us-east-1.amazonaws.com). This allows S3 to use the key to decrypt SSE-KMS-encrypted objects. However, the same condition prevents any other service (such as EC2, Lambda, or EBS) from using the key, even within us-east-1. The role also cannot use the key with S3 in other regions, so the overall scope is exactly S3 in us-east-1 for the allowed actions.

The SCP's Deny effect triggers when the ec2:InstanceType condition does not equal t2.micro, typically using StringNotEquals. A t2.small instance does not match t2.micro, so the condition evaluates to true and the Deny takes effect, blocking the RunInstances call. Since SCPs are implicit deny guardrails applied at the OU level, not even the developer's IAM permissions can override this denial, so the launch fails with an unauthorized operation error.

Launching an instance with a resource-scoped IAM policy requires the ec2:RunInstances action to be granted on each dependent resource, including the subnet ARN (e.g., arn:aws:ec2:region:account-id:subnet/subnet-...). If the policy's Resource element omits the subnet but references the instance or AMI, the request fails with an explicit access denied because RunInstances is a 'create' action that conditionally requires subnet permission. This is the exact reason a user can have broad EC2 permissions yet still be blocked for a specific subnet.

Amazon EventBridge is the event-routing backbone of the remediation workflow: it receives compliance state-change events published by AWS Config, such as a bucket transitioning to NON_COMPLIANT for the s3-bucket-server-side-encryption-enabled rule. Using an EventBridge rule, you filter for these S3 compliance events and target an AWS Lambda function for automatic response. Without EventBridge, AWS Config would only generate history or console notifications and would not have a native, low-latency path to invoke custom remediation code.

AWS CloudTrail records every IAM control-plane API call, including CreateUser and AttachUserPolicy, as management events with the user identity, source IP, and timestamps. By delivering the trail to Amazon CloudWatch Logs and creating a metric filter that matches on the eventName field for these API calls, you can trigger an Amazon CloudWatch alarm to alert a security engineer in near real-time. This gives you both a complete audit trail and an automated detection mechanism, making it the appropriate detective control for this scenario.

CloudTrail trails capture management events by default, but S3 data events such as PutObject require explicit enablement through trail configuration. Without adding S3 object-level data events for the bucket (or a prefix), PutObject requests will not appear in the CloudTrail history.

The CloudWatch agent (or unified agent) runs inside the EC2 instance and can tail local log files such as /var/log/secure on Amazon Linux/RHEL (or /var/log/auth.log on Ubuntu), streaming them to CloudWatch Logs. The sshd daemon writes entries like 'Failed password for ...' to this file for every failed authentication attempt. Reviewing the collected log group in CloudWatch Logs Insights, for example with a query filtering on 'Failed password', directly reveals the failed SSH login attempts and their source IPs.

The policy condition uses the aws:SourceIp global condition key and requires the request to originate from 10.0.0.0/16, a private RFC 1918 CIDR range. IAM compares this against the actual source IP recorded in the request, so if the IAM user is connecting from outside that range—for example, from a public internet address—the condition fails. When a condition fails, the Allow statement is skipped and the request is implicitly denied.

To enable encryption-at-rest on an existing unencrypted Amazon RDS DB instance, you must create a manual snapshot, make an encrypted copy of that snapshot (either with the default AWS-managed key or a customer-managed KMS key), and then restore a new DB instance from the encrypted snapshot. During the snapshot copy you can also specify a KMS key; the restored instance will be encrypted, and you can then update your applications' connection strings to point to the new endpoint. This is the documented and only supported approach, since encryption cannot be added in place.

Amazon S3 with SSE-S3 is the correct choice because S3 provides a cost-effective, highly durable object store optimized for high-volume log ingestion and retention, and SSE-S3 automatically encrypts each object with strong AES-256 encryption managed by AWS. S3 integrates natively with CloudTrail, VPC Flow Logs, and AWS Config to centralize logs from multiple accounts, and it supports lifecycle policies that can later transition older logs to S3 Glacier for further cost reduction. The encrypted-at-rest capability satisfies compliance requirements without the operational overhead of managing customer keys.

Route 53 Resolver DNS Firewall query logging captures every DNS query that instances resolve through the Amazon-provided VPC resolver, publishing records to CloudWatch Logs, S3, or Kinesis Data Firehose. This satisfies the requirement to log all EC2 DNS requests for exfiltration detection, since instances use that resolver by default.

AWS Config continuously evaluates resources such as AWS::IAM::User against managed rules, and the iam-user-mfa-enabled rule specifically designates IAM users without a registered MFA device as noncompliant. Config can then invoke an AWS Systems Manager Automation document or a custom remediation action to remediate noncompliant IAM users, making it the only listed service that can both detect and act on missing MFA across all IAM users.

To add encryption to an existing Redshift cluster, take a snapshot of the source cluster and restore it as a new cluster while specifying a KMS key in the restore settings. The restore operation initializes a fresh cluster with encryption enabled at the storage layer, then you can update your application's JDBC/ODBC connection strings and DNS to point to the new endpoint. Once verified, you can retire the old cluster. This is the only AWS-supported path for retrofitting encryption.

VPC Traffic Mirroring copies the actual packet payloads from the EC2 instance's Elastic Network Interface and forwards them through a mirror session to a monitoring appliance—which can be hosted in a separate VPC via a Gateway Load Balancer or a Network Load Balancer. Because mirroring is out-of-band and does not insert in the data path, the original traffic is unaffected and the attacker is not alerted by any inline inspection or blocking. This provides full packet capture, enabling deep forensic analysis of the attacker's actions, commands, and any exfiltrated data with no impact on the live environment.

The policy's Deny effect on s3:PutObject with a condition checking that the encryption header is absent or not SSE-KMS means any upload lacking SSE-KMS encryption is rejected. Requests specifying SSE-KMS satisfy the condition and are permitted.

This is the standard, supported migration path. First, create a manual snapshot of the unencrypted RDS instance. Then copy that snapshot and select 'Enable encryption' (or specify a KMS key ID), because the copy operation re-encrypts the data at rest. Finally, restore the encrypted snapshot to a new DB instance, redirect application traffic to the new instance, and retire the old unencrypted instance once validation is complete.

S3 Versioning is the correct data-protection mechanism because a regular DELETE on a versioned object only inserts a null-version delete marker while preserving all prior versions, allowing recovery by deleting that marker. Granting the s3:DeleteObjectVersion permission (only where appropriate) enables administrators to permanently purge specific object versions when retention or compliance demands actual deletion, while ordinary deletions remain reversible. This creates a two-tier deletion model where accidental deletes can be untangled and legitimate permanent deletes are still possible, exactly matching the requirement.

AWS Config continuously records resource configurations and evaluates them against managed or custom rules, so a rule can flag IAM policies whose statements contain Action: * with Resource: *. This satisfies the requirement to detect overly permissive policies across accounts.

Applying a restrictive security group that blocks all outbound traffic is the right containment step because security groups act as a stateful instance-level firewall. This prevents the compromised EC2 instance from establishing new outbound connections to a command-and-control server or performing data exfiltration, while leaving the instance running so forensic artifacts like memory and processes can be collected. Inbound rules can still permit limited SSH access from approved forensic workstations, allowing incident responders to investigate without fully disconnecting the instance.

An IAM policy with a condition key such as aws:SourceIp is valid for restricting S3 actions to specific source IP addresses when the request originates from an authenticated principal. This identity-based policy attaches to IAM users, groups, or roles, and the condition is evaluated against the public IP address of the caller's client. It works for requests made over the internet, but note that when traffic comes through a VPC endpoint, aws:SourceIp is not available and aws:VpcSourceIp would be needed instead.

Outbound RDP from an internal EC2 instance to an external host on port 3389 is inherently suspicious because RDP is a remote administration protocol and is not a normal outbound service. This direction of traffic can indicate a compromised instance serving as a pivot, data exfiltration, or an attacker maintaining persistent control. The flow log shows source 10.0.1.5 (private) to destination 203.0.113.50 on port 3389, so the correct interpretation is that the instance is attempting an outbound RDP connection.

AWS Config does not natively record IAM groups, so a Lambda-backed custom rule is required. The Lambda function can call the IAM API to retrieve a group's policies and evaluate them against your compliance logic, then report compliance via PutEvaluations. This approach gives you full flexibility to assess inline and attached managed policies for groups, which no managed Config rule can do.

Service control policies (SCPs) are an AWS Organizations feature that specify the maximum permission boundary for all IAM entities in the accounts, OUs, or root to which they are attached. By adding an SCP that denies or allows specific services, you can prevent member-account users and roots from using services outside the approved set, even if they have IAM policies that allow those actions. SCPs inherit down the organizational hierarchy and are evaluated as a top-level guardrail, making them the appropriate tool to restrict how teams use AWS services in a new account structure.

Setting default encryption on the bucket is the correct way to ensure that all objects are encrypted at rest automatically. When enabled, Amazon S3 applies server-side encryption (SSE-S3 by default, or SSE-KMS if configured) to every object uploaded to the bucket, even if the upload request does not include an encryption header. This provides a security baseline for sensitive documents and guarantees that no object is stored in an unencrypted state. Unlike policies or lifecycle rules, default encryption directly acts on the data itself at write time.

Origin Access Control (OAC) is the recommended way to keep an S3 bucket private while allowing only CloudFront to retrieve objects. You create an OAC, associate it with the distribution's origin, and update the bucket policy to permit s3:GetObject for the cloudfront.amazonaws.com principal under a condition like aws:SourceArn that matches your specific distribution. This prevents direct S3 access via the bucket URL, supports SSE-KMS encryption, and works seamlessly with S3 Block Public Access for a least-privilege, secure static website architecture.

Service control policies set permission guardrails across every account in AWS Organizations, so an SCP denying s3:CreateBucket without default encryption blocks non-compliant buckets organisation-wide. This satisfies the requirement to enforce encryption centrally in all accounts, which bucket policies cannot do.

Using an AWS managed key such as the aws/s3 key automatically satisfies the rotation requirement because AWS KMS rotates AWS managed keys automatically every year (approximately 365 days) without any customer action. These keys are provisioned and managed by AWS, so the restrictive customer key policy on the existing customer managed key does not apply, and you cannot disable or alter their automatic rotation. For S3 server-side encryption with KMS, simply selecting the aws/s3 managed key encrypts objects with a key that is automatically rotated.

The web tier is the only component that needs to accept unsolicited traffic from the internet. By allowing HTTP/HTTPS from 0.0.0.0/0, you enable clients to reach the application via the public IP of the load balancer or the web servers. This is a standard and secure configuration because the web tier acts as the entry point that forwards requests to the application tier, and the other tiers remain hidden from direct internet access.

An SCP such as 'DenyCloudTrailDisable' can be attached to the root or OU to explicitly deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, and cloudtrail:UpdateTrail (along with PutEventSelectors actions that could stop recording), preventing any principal—including the root user—from disabling the trail. CloudFormation StackSets then deploys a consistent multi-region trail template to every account in the organization, automatically creating the required trail, S3 bucket, and bucket policy. Because SCPs are evaluated in addition to IAM policies and cannot be overridden by account admins, this combination provides both automated enablement and a hard preventive boundary.

A NAT gateway performs source network address translation for outbound traffic, letting private subnet instances initiate internet connections for updates while remaining unreachable inbound. The private route table's 0.0.0.0/0 route to the NAT gateway satisfies both requirements.

VPC Traffic Mirroring copies the full packet payload from the instance's elastic network interface to a target such as a Network Load Balancer or another ENI, operating at the hypervisor level without installing agents or consuming the instance's CPU and memory. Because the capture is passive and out-of-band, it preserves the forensic integrity of the evidence and enables thorough inspection of both inbound and outbound traffic.

AWS CloudTrail is the service designed to record AWS API activity, and it captures every security group change as an API event such as AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, AuthorizeSecurityGroupEgress, RevokeSecurityGroupEgress, CreateSecurityGroup, or DeleteSecurityGroup. Each event includes the identity of the caller, the source IP address, the request parameters, and the response elements, giving a complete audit trail of who changed what and when. This makes CloudTrail the appropriate service for auditing all changes to security group rules.

VPC Flow Logs is the only option that captures network traffic itself. It records flow metadata for every accepted and rejected connection at the VPC, subnet, or elastic network interface (ENI) level, including intra-subnet traffic between instances. The logs contain source/destination addresses, source/destination ports, protocol, packets, bytes, and the connection action, and can be published to CloudWatch Logs or Amazon S3 for analysis. While it captures flow metadata rather than packet payloads, it fully meets a requirement to log all network traffic for audit and troubleshooting.

To encrypt traffic for the entire path, the ALB must terminate the client-facing TLS connection on an HTTPS listener and then originate a new TLS session to each registered target using an HTTPS target group. This ensures the request is decrypted only inside the ALB and re-encrypted before traversing any network segments to the EC2 instances. Both the listener and the target group certificate must be trusted, and health checks also run over HTTPS, maintaining encryption from edge to backend.

Setting the source of the RDS security group's inbound rule to the application server's security group ID restricts MySQL access to only those instances whose network interfaces are associated with that security group, regardless of their IP addresses. This is the recommended least-privilege pattern because it ties the rule to a logical group of resources rather than a static IP range, so the rule remains valid if the application server's private IP changes. It also prevents any unrelated VPC or subnet resource from reaching the database, as only resources carrying that specific security group are allowed.

The managed rule s3-bucket-public-read-prohibited inspects the bucket's access control list (ACL) for grants to AllUsers or AuthenticatedUsers and reports NON_COMPLIANT only if those ACL grants are present. It does not parse or evaluate bucket policies, even though bucket policy statements with Principal '*' can also enable public read access. Therefore a bucket with a private ACL and a public bucket policy will show COMPLIANT even though it is actually publicly readable.

Enabling SSL/TLS on the RDS instance makes the database server accept and require encrypted connections, and configuring the EC2 clients to connect with SSL (for example, using sslmode=require or verify-full in PostgreSQL, or useSSL=true in MySQL) encrypts all data in flight between the application and the database. RDS provides server certificates for each region that clients can validate to prevent man-in-the-middle attacks. This directly satisfies the requirement that all data in transit be encrypted.

Config can aggregate rules and compliance across accounts.

Access keys for the root user are long-term static credentials that bypass the password and MFA protections on the AWS console, enabling direct API calls with full account authority. AWS explicitly warns that root access keys cannot be rotated like IAM user keys and can only be deleted, making any leak a catastrophic risk. Avoiding root access keys entirely -- and using temporary credentials from IAM roles or federation -- is the recommended safeguard.

CloudTrail LookupEvents is the correct tool because it queries the CloudTrail event history for actual API calls made by an access key, including action name, source IP address, user agent, and timestamp. You can specify the AccessKeyId in the lookup filter to see every call attributed to that key, then correlate those calls with unusual IP addresses or times to spot anomalous behavior. This gives the security analyst direct evidence of what the compromised key did across AWS services, which is exactly the goal of the investigation.

To encrypt an existing unencrypted database, you must provision a new DB instance with the StorageEncrypted flag set to true, using either the AWS Management Console, the AWS CLI (--storage-encrypted), or an SDK. You can choose the default aws/rds KMS key or a custom customer-managed key. After the encrypted instance is available, migrate the data from the original instance, for example by restoring an encrypted snapshot or using a logical export/import.

AWS Shield Advanced is purpose-built for DDoS protection, providing enhanced always-on detection and automatic inline mitigation for network-layer (L3/L4) attacks such as SYN floods and UDP reflection. It works by absorbing attack traffic and rerouting it to AWS's global scrubbing infrastructure while maintaining availability of protected resources like EC2 instances. Advanced also adds cost protection (DDoS-induced spikes are charged back as credits), access to the AWS DDoS Response Team (DRT), and integration with AWS WAF for additional Layer 7 defense. This is the service designed to directly protect EC2 from DDoS attacks.

AWS Config rules continuously evaluate bucket policies and ACLs, flagging any bucket granting public read access as noncompliant. EventBridge then routes those compliance-change events to a notification target, delivering the automatic detection and alerting the stem requires without polling.

CloudTrail records every API call as a management event, capturing the identity, source IP and error code. Filtering for AccessDenied errors lets you detect unauthorised calls, and delivering trails to CloudWatch Logs enables real-time metric filters and alarms.

AWS WAF is a Layer 7 web application firewall that you can associate with an Application Load Balancer to inspect incoming HTTP(S) requests. It uses managed rule groups, such as the AWS Managed Rules for SQL injection (SQLi_RULE), to match request patterns like malicious query strings, bodies, or headers. When a rule matches, WAF can immediately block the request, return a custom response, or count it, providing inline detection and blocking at the ALB. This is exactly what the security team needs for identifying and stopping SQL injection attempts before they reach the application.

AWS Site-to-Site VPN creates an encrypted IPsec tunnel between your on-premises VPN device and the AWS VPN endpoint, using protocols like IKE and ESP to authenticate and encrypt all traffic traversing the public internet. The VPN tunnels support AES-128 or AES-256 encryption, along with perfect forward secrecy, ensuring confidentiality and data integrity. This native AWS service directly provides secure encryption of data in transit between your network and the VPC, making it a valid method to protect sensitive data.

AWS CloudTrail captures the complete audit trail of API calls made to your account, including the identity, time, source IP, and request parameters. By integrating CloudTrail with Amazon CloudWatch Events, you can create rules that match specific API events—such as unauthorized or denied actions—and trigger immediate alerts via SNS, Lambda, or other targets in real time. CloudTrail delivers each API event as a JSON object, and CloudWatch Events helps filter those objects by fields like `errorCode` or `userIdentity` to detect suspicious activity. This combination is the recommended native mechanism for monitoring and reacting to unauthorized API calls.

Inline policies are identity-based policies that are embedded directly into a single IAM user, group, or role. They are maintained as part of the entity itself, rather than as standalone managed policies, which ensures a strict one-to-one relationship between the policy and the identity. This direct attachment qualifies inline policies as a valid type of identity-based policy in IAM. They are particularly useful when you need to guarantee that a specific policy cannot be accidentally attached to another entity.

Default encryption on the destination S3 bucket automatically applies server-side encryption (SSE-S3, SSE-KMS, or SSE-C) to every CloudTrail log object, satisfying the encryption-at-rest requirement. Server access logging captures detailed records of every request made to the bucket, including the source IP, requester, and operation, which provides the needed audit trail of access to those logs. Together, these features ensure the CloudTrail logs are protected and their access activity is observable.

When a destination bucket uses SSE-KMS, CloudTrail must have permission to call kms:GenerateDataKey for encrypting each log file and kms:Decrypt for delivering or reading those files. If the KMS key policy does not explicitly grant CloudTrail these actions, PutObject requests to the bucket will fail even if the bucket policy is correct. CloudTrail’s role also needs the appropriate KMS permissions in the trail’s advanced settings, but the key policy is the critical constraint here.

Amazon Cognito Identity Pools are built specifically to trade identity tokens from any public or custom identity provider for temporary, least-privilege AWS credentials. The service assigns an IAM role per authenticated or guest user, and returns credentials with a short expiration that map to permissions defined in that role. This makes them the standard choice for mobile and web apps that need direct AWS API access without embedding long-term keys on devices.