AWS Certified Security Specialty SCS-C02 (SCS-C02) — Questions 151–225

A bucket policy can enforce server-side encryption by using the request header condition keys `s3:x-amz-server-side-encryption` and `s3:x-amz-server-side-encryption-aws-kms-key-id`. For instance, a `Deny` statement with `StringNotEquals` on `s3:x-amz-server-side-encryption` for `aws:kms`, combined with a `Null` condition that denies uploads where the header is absent, will reject every `PutObject` and `InitiateMultipartUpload` that does not specify SSE-KMS. This is a direct, request-time enforcement mechanism.

An IAM role with an instance profile is the correct approach because it provides temporary credentials to the EC2 instance through the instance metadata service (IMDSv2). The EC2 service assumes the role on behalf of the instance, and the credentials are automatically rotated and never stored as static secrets on disk. This follows the AWS security best practice of using temporary credentials for all applications running on EC2.

A strong, uniquely complex root password stored securely reduces the risk of credential compromise, since the root user cannot be restricted by IAM policies and has unrestricted account access. This satisfies the best-practise requirement for protecting that identity.

In AWS Organizations, the management account is explicitly exempt from all SCPs; SCPs can only restrict access for member accounts. If the SCP is attached at the root or to the relevant OUs and untagged instances still appear, the launches must be originating from the management account, whose principals are not evaluated against any SCP and therefore retain full permissions.

When you create a metric filter, CloudWatch Logs begins applying it only to new log events that arrive after creation; it does not scan or backfill the log group's existing history. Any events that were recorded before the filter existed will never be evaluated, even if they match the pattern. This is why a newly added filter often shows no metrics until subsequent log events are generated.

This is the correct approach because AWS KMS custom key stores let you create a CMK whose key material is stored in a CloudHSM cluster that you fully control. When you enable RDS encryption at rest, RDS uses this CMK to encrypt the storage, and the key material never leaves your HSM. This gives you the dual benefit of RDS-native transparent encryption and the cryptographic ownership of an HSM, satisfying the data protection strategy.

A security group acts as a stateful instance-level firewall with an implicit deny-all for inbound traffic, so configuring a rule that allows inbound TCP port 22 from only 10.0.0.0/16 satisfies the requirement. Because security groups only contain permissive rules, any SSH connection sourced outside that CIDR is automatically blocked by the default deny, without needing an explicit deny. This approach also automatically allows return traffic for established sessions due to statefulness, so no separate outbound rule is required.

In cross-account S3 access, the requesting IAM role must have an identity-based permissions policy that explicitly allows s3:GetObject on the specific bucket. The bucket policy alone is insufficient; if the role lacks the necessary IAM permissions, the request is denied even when the bucket policy states that access is allowed. This missing permissions policy is the most common root cause when a role cannot read from a bucket it was supposedly granted access to.

This is the correct foundational enforcement mechanism: a Deny statement with a Bool condition on aws:MultiFactorAuthPresent. When the key evaluates to "false", the request is denied, so any API or console action by a user who did not authenticate with MFA fails. The policy can be scoped with NotAction to permit MFA self-management tasks, ensuring users can enroll without being locked out. This condition-based denial is what actually enforces MFA, unlike audit-only measures.

CloudWatch Alarms work with CloudTrail by using metric filters that are applied to log groups containing CloudTrail events. When the metric filter detects a pattern such as a specific unauthorized API action or a spike in failed calls, the alarm shifts to ALARM and publishes to an SNS topic to alert operators. This threshold-based approach is one of the standard ways to turn historical CloudTrail logs into actionable alerts.

AWS CloudTrail is the audit service that records every root account sign-in (eventName ConsoleLogin with userIdentity.type Root) and every root-initiated API call, and a trail can deliver those events to CloudWatch Logs. A CloudWatch Logs metric filter can match root events and publish a metric, and a CloudWatch alarm based on that metric then invokes an SNS topic to notify administrators in real time. This combination provides deterministic, account-wide monitoring of root usage and is the standard AWS-recommended pattern.

Create a bucket policy whose Principal is the intended IAM role or account and add a Condition using the aws:SourceVpc key set to the VPC ID. This allows requests only when they originate from that exact VPC, so traffic from any other VPC or the public internet is blocked. To make this work, requests must arrive through a VPC endpoint for S3, because the aws:SourceVpc condition key is populated only for traffic that uses an endpoint.

Amazon GuardDuty is purpose-built for threat detection, analyzing continuous data from VPC Flow Logs, AWS CloudTrail events, and DNS query logs with machine learning and threat intelligence. It recognizes SSH brute force patterns, such as a single source IP making a large number of TCP connections to port 22 on an EC2 instance, and surfaces findings like UnauthorizedAccess:EC2/SSHBruteForce. Those findings can be pushed to Amazon EventBridge to trigger automated alerting or remediation, making it the correct service here.

AWS CloudTrail captures every KMS API request as a management event, including kms:Encrypt, kms:Decrypt, and kms:ScheduleKeyDeletion, and delivers those logs to an S3 bucket. You can then define a CloudWatch Logs metric filter on the JSON field of the CloudTrail event to match a specific KMS action, and attach a CloudWatch Alarm to that metric to trigger an SNS notification. This combination provides the required trackable, alertable audit trail for KMS API calls made when S3 encrypts objects using customer-managed KMS keys.

When the HTTP packet from the public client reaches the instance, the security group already allows it, so it is not rejected at the VPC edge. In the INPUT chain, the ACCEPT rule for 10.0.0.0/16 does not match because the source IP is outside that range, and the subsequent DROP rule or default policy DROP terminates the packet. This drop happens inside the instance OS, not in the security group.

To read SSE-KMS-encrypted CloudTrail logs, an IAM principal must have both s3:GetObject on the object and kms:Decrypt on the key. The KMS key policy is a resource-based policy that must include a statement allowing the engineer's role to call kms:Decrypt. If that grant is absent, the S3 GET can succeed but retrieval fails during decryption, causing the access denied error. This option correctly identifies the missing authorization.

This is the correct approach because GuardDuty publishes each finding to Amazon EventBridge as an event, and EventBridge rules can target a Lambda function with an event pattern that matches the finding's type or severity. The Lambda function can then call the ec2:RevokeSecurityGroupIngress or ModifyInstanceAttribute API to remove the instance from the offending security group, providing automated, near-real-time remediation without manual intervention. EventBridge handles the event delivery, Lambda executes the remediation logic, and IAM roles grant the necessary permissions, forming the standard architecture for GuardDuty-based automated responses.

AWS IAM Identity Center (AWS SSO) is the correct service for centrally managing IAM users across multiple AWS accounts because it provides a single identity source and allows users to sign in once with temporary credentials issued through AWS STS. It supports creating users directly, connecting an external identity provider for federation, and assigning permission sets that control access across all accounts in an AWS Organization, eliminating the need for long-lived IAM user access keys and enabling a single sign-on experience.

Detaching the instance from the Auto Scaling group before termination marks it as a manual removal from the group's lifecycle, so the scaling policy does not immediately spin up a replacement. After detaching, you can terminate it to stop the attack or preserve it for forensic analysis, while maintaining the group's desired capacity if you intentionally adjust it. This is the correct immediate response because it eliminates the compromised resource and prevents the same vulnerable workload from being automatically reintroduced.

When an S3 bucket uses SSE-KMS encryption, CloudTrail must have permission to call the KMS key to encrypt each delivered log file. Specifically, CloudTrail needs kms:Decrypt and kms:GenerateDataKey actions in the key policy. If those permissions are missing, CloudTrail cannot write the encrypted log objects and stops delivering logs, producing a delivery failure shown on the trail configuration page.

Network ACLs are stateless and can explicitly deny traffic. If the NACL denies SSH from all IPs except the specific one, it would override the permissive security group rule, explaining why only that IP can connect.

Permission sets are the correct IAM Identity Center construct because they define reusable collections of AWS permissions, similar to IAM roles, that can be assigned to users or groups across multiple AWS accounts. You attach managed policies, customer managed policies, inline policies, permissions boundaries, and session duration to a permission set, then assign it to accounts and principals. Using permission sets lets you enforce least privilege consistently across the entire AWS Organization and change permissions in one place, which is exactly what a multi-account user-access solution requires.

AWS CloudTrail is the service explicitly designed to log every API call made in your AWS account, recording details like caller identity, source IP, request parameters, and response data. You can configure a trail to deliver these JSON log files to an S3 bucket, and enabling encryption on that bucket (e.g., with SSE-KMS or SSE-S3) protects the logs at rest. This satisfies the requirement to ensure all API calls are logged and stored securely.

A CloudWatch Events rule pattern-matching the CreateAccessKey API call routes the event straight to an SNS topic, delivering near-real-time alerting. This event-driven approach is more efficient than polling or log-scanning because CloudTrail already streams management events to CloudWatch Events.

AWS Network Firewall is correct because it can perform stateful inspection of DNS traffic at the application layer and log each DNS request that traverses the firewall. To capture the queries, you configure a stateful rule group with the DNS protocol and enable logging to Amazon S3, CloudWatch Logs, or Kinesis Data Firehose. The resulting DNS logs include the queried domain name and the source interface, allowing the security engineer to retain a complete record of DNS activity.

AWS CloudTrail is the authoritative source for KMS API activity because it records KMS calls as data events, including Decrypt, Encrypt, GenerateDataKey, and ReEncrypt. Each KMS data event in CloudTrail includes the key ID, whether decryption succeeded, the principal and ARN of the caller, the source IP, and the request timestamp. By enabling CloudTrail data events for a customer-managed KMS key, you get a complete audit trail that you can search in Athena or deliver to CloudWatch Logs for alerting.

VPC Traffic Mirroring copies traffic from the instance's ENI to a specified target—such as a Network Load Balancer configured with a capture appliance—without installing agents or SSHing into the instance. Because the mirroring runs in the VPC data path (at the hypervisor), it is transparent to the instance and does not alert the attacker or affect system performance. This makes it the recommended approach for real-time, full-packet capture during incident response while preserving the integrity of the evidence.

In the client-side encryption envelope scheme, the SDK creates a one-time data key, encrypts the object with it, then wraps that data key with a KMS customer master key. The resulting encrypted data key is stored in the S3 object's metadata, for example the x-amz-meta-x-amz-key-v2 attributes, so a decrypter can later retrieve it and unwrap it to get the plaintext data key. Without this metadata, the ciphertext cannot be decrypted, so this storage step is a required part of client-side encryption.

AWS Security Hub is the correct choice because it aggregates and correlates security findings from multiple sources, including GuardDuty, Inspector, and Config, into a single, prioritized view. It applies continuous security best-practice and compliance checks, and its integration with Amazon EventBridge allows you to automate responses by triggering AWS Lambda, Systems Manager, or Step Functions workflows. This centralized detect-and-respond architecture is exactly what the company needs for operational security monitoring.

Network ACLs are stateless filters applied at the subnet boundary and are evaluated before Security Groups. A custom network ACL with an explicit deny rule, or with an inbound allow rule that lacks a matching outbound ephemeral-port allow rule, will drop traffic even when Security Groups permit it. Since stateful Security Groups do not validate the complete bidirectional flow, a misconfigured network ACL remains a common cause of unexplained communication failures between instances.

This policy correctly denies S3 actions when aws:SecureTransport is false, meaning it blocks all HTTP requests that do not use TLS. The aws:SecureTransport key is true only for requests made over HTTPS, so this conditional deny rejects any insecure request while allowing encrypted traffic. This is the AWS-recommended bucket policy pattern for enforcing encryption in transit and satisfies the requirement.

To launch an EC2 instance with an IAM role, the caller must have iam:PassRole permission for that role. An SCP that denies iam:PassRole blocks this action, so the RunInstances call fails. Even though ec2:RunInstances is allowed, the missing PassRole permission prevents the role association, making the launch unsuccessful. This is the intended security control.

The IAM policy grants ec2:RunInstances but includes a Condition element that restricts the ec2:InstanceType to t2.micro. When the user attempts to launch any other instance type, the condition fails, causing the action to be denied even though the principal has an Allow for the action. This is an implicit deny resulting from the condition not being satisfied, not a missing action or a separate limitation. Thus, the exact reason the launch is blocked is the requested instance type falls outside the allowed value.

A custom AWS Config rule powered by a Lambda function can evaluate security groups on every configuration change. The Lambda function uses the AWS Config API to receive the resource's details, parses the IpPermissions, and checks for any rule with CidrIp 0.0.0.0/0 or ::/0. If public inbound traffic is found, the function returns NON_COMPLIANT, enabling continuous, automated compliance monitoring and remediation. This is exactly the kind of custom, resource-specific logic that Config supports.

The userIdentity block in a CloudTrail record is the authoritative field for identifying the principal, containing the ARN, type (IAMUser, AssumedRole, Root, etc.), and session context for the call. By inspecting this block, the security engineer can determine the exact IAM user or role and then review the identity-based and attached policies that governed the request. Without userIdentity, there is no reliable way to map an API call to the IAM entity whose permissions should be audited.

Deactivating the user in the connected identity provider is the correct action because AWS SSO relies on the IdP as the authoritative identity source. Once the user is disabled in Active Directory (or another connected IdP), they can no longer authenticate to the AWS access portal, so no new SSO sessions or temporary AWS credentials can be issued. Any active role sessions inherited from a prior sign-in remain only until their configured session duration expires, but this operation is the only option that cleanly terminates access at the identity's source.

CloudTrail is designed to record every API request made on an account, including actions that fail authorization. When the IAM user attempts CreateTrail, CloudTrail writes a management event with the userIdentity of that user, even if the call is denied with AccessDenied and an errorCode and errorMessage. The presence of this attempt in the logs is therefore normal, and it does not indicate that a trail was successfully created.

The AWS Config managed rule s3-bucket-server-side-encryption-enabled evaluates every S3 bucket against your encryption policy and marks those without default encryption as non-compliant. By attaching an automatic remediation action, Config invokes an SSM Automation document that runs PutBucketEncryption on the non-compliant bucket, bringing it into compliance without manual intervention. This detects buckets that CloudFormation created without encryption and repairs them, making it an effective retrospective and continuous control.

When a request reaches S3 through a VPC endpoint, the request context includes the endpoint ID, so an IAM policy can use the aws:SourceVpce condition to require that the request came from that specific endpoint. This effectively blocks access from public internet or other VPCs even if the IAM principal is valid. It is a common pattern for enforcing network-layer isolation in addition to identity-based permissions.

S3 server access logs capture every request made to the bucket, including requester IP, IAM role/user, action, and HTTP status, providing a detailed audit trail for forensic analysis. Amazon GuardDuty's S3 protection continuously monitors object-level operations and uses threat intelligence and anomaly detection to flag suspicious patterns, such as mass downloads or access from unusual geographies, in near-real time. Together they deliver both historical evidence and proactive alerting, making this the only option that addresses both detection and investigation of unauthorized access.

Permissions boundaries are a valid use case to prevent IAM users from escalating privileges because they set a hard ceiling on the maximum permissions a principal can receive. Even if a user is allowed to attach IAM policies to their own role, the effective permissions are the intersection of the attached policy and the boundary, so they cannot grant themselves additional privileges beyond the boundary. This mitigates the risk of an IAM user creating an administrative policy or modifying their own permissions to gain elevated access.

AWS CloudHSM supports taking point-in-time backups of an entire cluster, and those backups can be copied to other regions using the CopyBackupToRegion API or the console. After copying, you restore the backup in the destination region to create a new cluster that contains all original keys, HSMs, and settings. This preserves FIPS 140-2 validated protection because key material never leaves the HSM boundary, and it is the officially supported method for cross-region disaster recovery.

Create an IAM execution role granting the Lambda function the minimal CloudWatch Logs permissions required (e.g., logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents) and attach that role to the function via the function's configuration. This identity-based policy defines what the function can do as its authorized identity, allowing it to write logs securely. Following least privilege here is correct because the role grants only the specific log-writing actions, not broader access.

The resource ID in the flow log output is prefixed with "vpc-", which indicates the flow log was created at the VPC level rather than at the subnet level. As a result, the flow log captures all traffic in the VPC, and the query is not filtering for the specific subnet due to the resource scope. To see subnet-specific flow logs, you must create a separate flow log with the subnet ID as the resource ID.

Removing the inbound SSH rule and using AWS Systems Manager Session Manager closes the port 22 listener entirely, so the instance is not reachable over SSH from the network. Session Manager authenticates the user through IAM, authorizes actions with IAM policies, and sends the interactive shell session over an encrypted channel initiated by the SSM Agent. Sessions can be audited and recorded via S3 or CloudWatch Logs, and you can use a VPC endpoint so traffic never traverses an open internet-facing port. This avoids the need for SSH key management and eliminates brute-force exposure.

Deactivating the access key immediately stops its use, and attaching an explicit deny policy blocks the user from making further calls with any credentials or sessions. This revokes access quickly while preserving the key's metadata and the user's configuration for later analysis, which supports evidence preservation.

Account-level S3 Block Public Access is a set of controls (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets) that act as a centralized guardrail across every bucket in the AWS account. When enabled, it overrides any bucket policy, owner policy, or object ACL that would grant public access, and it blocks both existing public grants and future attempts to make objects or buckets public. This is the most comprehensive control because it applies even if a developer mistakenly attaches a permissive bucket policy or uploads an object with a public-read ACL.

Enabling SSL/TLS on the RDS instance forces the database server to accept only encrypted connections, typically by setting the force_ssl parameter (for PostgreSQL) or the SSL/TLS requirement (for MySQL) in the DB parameter group. The application must then connect using TLS with the RDS-generated CA certificate in its trust store, and it should enforce certificate verification to prevent man-in-the-middle attacks. This encrypts all data in transit between the EC2 instances and the RDS endpoint, satisfying the confidentiality requirement with minimal latency overhead and without needing extra networking equipment.

AWS CloudFormation Guard is the correct choice because it is a policy-as-code engine designed to validate CloudFormation templates (and JSON/YAML in general) against custom rules before deployment. You define guards, such as 'every S3 bucket must have encryption enabled' or 'no IAM user with administrator access', and the Guard CLI or CI/CD integration checks the template's structure and properties. Any noncompliant resource is flagged in the pre-deployment phase, letting you fail the pipeline before infrastructure is created.

This is correct. The bucket policy in Account A acts as a resource-based policy that grants the external user access to the object, while the IAM policy in Account B gives that user the identity-based permission to make the request. Both policies are evaluated, and the union of permissions allows the cross-account S3 GetObject. This follows the standard S3 cross-account access model where both the resource-based and identity-based policies must allow the action.

A NAT gateway must reside in a public subnet with an internet gateway as the next-hop for 0.0.0.0/0 so it can perform source NAT for outbound traffic. Placing a single NAT gateway there and adding a 0.0.0.0/0 route in every private subnet route table pointing to that gateway ID centralizes internet egress while keeping instances private. This is the standard minimal design, though it is a single point of failure if that availability zone goes down.

A service control policy attached to the organization root, an OU, or individual accounts can explicitly deny the IAM:CreateAccessKey action, and because SCP deny statements override all identity-based and resource-based allows in the affected accounts, no principal in those accounts can create a new access key. This provides a centralized, preventive guardrail that scales across all accounts without requiring per-account configuration or custom automation. It is important to note that an SCP only prevents future creation and does not remove or invalidate access keys that already exist.

Each CreateVpc API call in CloudTrail is recorded with a distinct event ID and returns a unique VPC ID. The current describe-vpcs output shows only one VPC, so one of the two created VPC IDs is absent. That absence indicates a DeleteVpc call (or another deletion mechanism) removed the VPC after creation; CloudTrail's management events would capture that deletion, confirming the lifecycle.

A `CopyObject` call that copies objects from a production bucket to a bucket in another AWS account is a direct, API-driven transfer of data to an external destination. This operation effectively bypasses traditional network egress controls because the data moves over AWS's internal infrastructure to an account outside the organization's management. It is a common exfiltration technique used by attackers with compromised credentials to quietly duplicate sensitive objects to a location they control.

Taking an EBS snapshot first preserves the root and data volumes as a point-in-time forensic copy of the disk, while leaving the instance running so volatile state is not yet lost. Then you isolate the instance by swapping its security group to a deny-all rule set and deregistering it from the load balancer, which cuts all network paths without modifying the guest OS or killing processes. This containment step prevents lateral movement and further data exfiltration while preserving the ability to later analyze memory, network connections, and disk state.

Security Hub custom actions do not invoke Lambda functions directly. When an analyst triggers a custom action in the Security Hub console, Security Hub publishes an event to Amazon EventBridge with a detail-type like 'Security Hub Findings - Custom Action'. You must configure an EventBridge rule that matches this event and has the Lambda function as a target. Without that rule, the Lambda function receives no invocation, regardless of IAM roles or resource policies.

The bucket policy contains a Deny statement targeting all S3 actions and keyed on the Bool condition aws:SecureTransport=false. Requests made with HTTP set this key to false, so the condition evaluates true, the Deny is applied, and the PutObject upload is rejected. Only HTTPS requests would have SecureTransport=true and therefore would not match this particular Deny; however, an explicit Allow statement is still required to authorize the request.

Creating a symmetric KMS key in a CloudHSM-backed custom key store with key usage set to ENCRYPT_DECRYPT ensures that the key material is generated and used only inside the customer's dedicated HSM cluster. The HSM performs all encryption and decryption operations for that key, and the unencrypted key material never leaves the HSM or becomes visible to AWS KMS service processes. This satisfies both the HSM residency requirement and the need for a general-purpose data encryption key.

CloudTrail records every IAM API call as an event, including AccessDenied responses, and can deliver those events to CloudWatch Logs. A CloudWatch Logs metric filter can count occurrences of a specific pattern, such as an IAM-issued authorization failure, and a CloudWatch alarm can then trigger an Amazon SNS notification. This combination provides near-real-time detective monitoring without inserting latency into the original IAM request.

Amazon Route 53 Resolver DNS Firewall is the correct answer because it operates at the DNS layer, inspecting outbound DNS queries from a VPC. It can both log full DNS query details (through Resolver query logging) and filter/block malicious or unwanted domains before resolution. This is directly applicable to a serverless Lambda application that needs DNS visibility and control, whereas other services operate at different layers or lack native DNS logging.

To encrypt data in transit, you must configure the database client and server to negotiate a TLS session. On RDS, this means importing the Amazon RDS CA certificate into the client's trust store and setting the database parameter group's `rds.force_ssl` (PostgreSQL) or `require_secure_transport` (MySQL/MariaDB) parameter to 1. Once enabled, TLS encrypts the entire database protocol stream, including authentication, query text, and result sets, and the client can verify that it is connecting to the genuine RDS endpoint, not an impostor.

For ec2:RunInstances, tags supplied in the request are evaluated through the aws:RequestTag condition key; ec2:ResourceTag evaluates tags on existing resources, which do not yet exist at launch. The SCP therefore never matches the request, so untagged instances launch despite the deny statement.

The Kinesis Data Firehose delivery stream is configured with an IAM role that it assumes to write to the destination S3 bucket. If that role does not have a permissions policy allowing s3:PutObject (and s3:GetBucketLocation) on the target bucket, Firehose attempts to deliver records but receives an AccessDenied error from S3. The delivery stream may still accept records from WAF, but the data is never written to the bucket, leaving the bucket empty. This is the most direct explanation for logs being absent, because the Firehose-to-S3 step is where the chain fails.

A manual snapshot immediately captures a consistent, point-in-time copy of the RDS instance, including its data, storage configuration, and parameters, independent of the automated backup window. This snapshot can be stored even if automatic backups are disabled, and it can later be restored to an isolated instance for forensic analysis without affecting the original. It is the correct first step to preserve volatile database evidence that could otherwise be modified or deleted during the investigation.

An S3 bucket policy is a resource-based policy attached directly to the bucket, and it can specify which IAM users or roles are permitted to perform actions such as s3:GetObject or s3:PutObject. Since the policy is evaluated against the principal, action, resource, and conditions, it can restrict access to only specific AWS identities while denying all other principals. This is a native, effective way to protect the bucket and is the recommended resource-based control for enforcing such restrictions.

A StopLogging API call is the direct way to disable CloudTrail log delivery; if it originates from an unknown or unrecognized IP address, it strongly suggests an attacker is attempting to hide their activity by pausing audit logging. This action would create a window where no logs are recorded, allowing subsequent actions to go undetected. Because CloudTrail itself logs the StopLogging event in a separate admin trail (if one is configured) or via the CloudTrail management event log, its presence with an unusual source IP is a clear indicator of compromise.

The real security gap is that `kmsKeyId` is null, meaning the CloudTrail log files are encrypted with S3-managed keys (SSE-S3) rather than a customer-managed AWS KMS key. With SSE-S3, AWS handles all key management, so the security team cannot control key rotation, define key policies, or revoke access for investigative or compliance purposes. Configuring a KMS key enables envelope encryption, provides a separate audit trail for KMS decrypt operations, and is the more secure option for CloudTrail log protection.

Amazon GuardDuty publishes all generated findings to Amazon EventBridge (formerly CloudWatch Events) as events with a detail type of 'GuardDuty Finding'. By creating an EventBridge rule that matches the finding severity (for example, using the 'severity' field in the event detail) and setting the target to an SNS topic, you can send near-real-time alerts to security teams. This is the native, recommended integration path, and it also allows you to route findings to AWS Lambda, Step Functions, or other targets for automated remediation.

For a private subnet to use a NAT gateway, its route table must have a route with destination 0.0.0.0/0 pointing to the NAT gateway. If that route is missing or misconfigured, instances cannot send traffic to the NAT gateway, resulting in zero active connections. This is the most likely cause given the symptoms.

Server-side encryption with AWS KMS (SSE-KMS) encrypts CloudTrail log objects at rest using envelope encryption with a customer-managed CMK, ensuring that the API activity data is unreadable to unauthorized parties. CloudTrail integrates natively with SSE-KMS, and you can configure the bucket to use a KMS key for all delivered logs, which also provides an additional layer of protection for sensitive information such as user credentials or IP addresses. This is the correct choice because it directly addresses the confidentiality of the logs, a fundamental security requirement.

The unified CloudWatch Logs agent (or legacy logs agent) installed on the EC2 instance tails /var/log/auth.log and streams each new line to a CloudWatch Logs log group. Once the log data is in CloudWatch Logs, you can create a metric filter that matches patterns such as 'Failed password for' or 'authentication failure' and then alarm on that metric. The agent needs an IAM role with logs:PutLogEvents permissions, but no other AWS service can natively reach into the guest OS to read auth logs.

Amazon Route 53 Resolver query logging captures DNS queries made by resources within your VPCs, including queries to on-premises networks. It satisfies the stem's requirement to collect DNS query logs centrally, publishing them to CloudWatch Logs, S3, or Kinesis Data Firehose for aggregation across accounts.

This is the correct answer. VPC Flow Logs capture the source IP address in the srcaddr field for every accepted or rejected network connection, as part of the standard flow log record. The srcaddr field is available in all flow log versions and is used to identify the origin of the traffic. It is recorded regardless of whether the traffic was allowed or denied by security groups or network ACLs.

AWS Config is purpose-built for recording configuration item changes and evaluating them against desired policies. When a security group rule is added, removed, or modified, Config generates a configuration item and can trigger an AWS Config rule (e.g., a managed rule or a custom Lambda rule) that determines whether the new state is compliant with the organization's requirements. It provides a timeline of every change, so you can identify exactly what was unauthorized and when it happened, and it can automatically remediate noncompliant rules via Systems Manager Automation. This is why AWS Config is the core service for this monitoring need.