Amazon Web Services SCS-C03 AWS Certified Security – Specialty Exam Practice Test

GuardDuty supports “Trusted IP lists” to suppress findings that would otherwise be generated for activity originating from known safe IP addresses (for example, corporate NAT egress IPs, security scanners, or monitoring systems). To use a trusted IP list, you create aplain textfile that contains the IP addresses (typically one per line or in supported list form) and store it inAmazon S3. You then configure GuardDuty to reference that S3 object as a trusted IP list. GuardDuty periodically retrieves the file from S3 and uses it to adjust finding generation accordingly.

That maps directly to Option A (create a plaintext file) and Option D (upload to S3 and create a trusted IP list in GuardDuty pointing to the file).

Options B and E are incorrect because GuardDuty trusted IP lists are not configured by pasting JSON into the console; they are sourced from an S3-hosted text list. Option C is not supported because GuardDuty does not accept direct file uploads into the service as the configuration source; S3 is the expected integration point for IP lists and threat intel lists.

AWS abuse notifications are delivered as AWS Health events. According to the AWS Certified Security – Specialty Study Guide, Amazon EventBridge integrates natively with AWS Health and can be used to detect specific event types such as AWS_ABUSE_DOS_REPORT in near real time.

By creating an EventBridge rule that filters for the abuse report event type and publishes directly to Amazon SNS, the solution remains fully managed, low latency, and cost effective.

Polling APIs introduces delay and complexity. CloudTrail does not log abuse notifications. EventBridge with AWS Health is the recommended mechanism for reacting to AWS service events.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Health and EventBridge Integration

AWS Abuse Notification Handling

AWS Systems Manager Session Manager provides secure, auditable shell access to EC2 instances without opening inbound ports. According to AWS Certified Security – Specialty guidance, Session Manager records all session activity to CloudWatch Logs or Amazon S3 and integrates with IAM Identity Center for centralized authentication.

This solution meets all requirements: no exposed ports, full audit logging, and identity-based access control. EC2 Instance Connect and serial console access do not integrate with Identity Center and may expose management paths.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Systems Manager Session Manager

AWS IAM Identity Center Integration

To analyze API access patterns with minimal effort andwithout parsing raw log files, the best approach is to rely onmetricsand built-in query tooling. EnablingDetailed CloudWatch Metricsfor an API Gateway stage (Option E) provides near-real-time, aggregated visibility into usage and performance patterns (such as request counts, latency, error rates like 4XX/5XX) that are ideal for identifying trends and spikes without handling logs.

For deeper pattern exploration when needed,CloudWatch Logs Insights(Option D) provides an interactive query experience over logs that are already in CloudWatch Logs, allowing quick filtering and aggregation. In practice, developers use metrics to understand access patterns at a high level and Logs Insights to slice and dice request data without building a separate parsing pipeline.

Options A and C still rely on enabling access logs and shipping them to S3/Athena, which is more setup and operational overhead (and still involves managing log storage/format). CloudTrail (Option B) records control-plane API calls to AWS services, not end-user access requests to your API methods, so it won’t provide the desired access pattern view for API consumers. Therefore, Detailed CloudWatch Metrics plus CloudWatch Logs Insights is the least-effort combination for access pattern analysis.

AWS IAM Identity Center relies on SAML assertions and attribute mappings to associate federated users with identities, groups, and permission sets. According to the AWS Certified Security – Specialty documentation, when changing identity providers while maintaining the same underlying directory, existing users and group identities can be preserved by updating attribute mappings to align with the new IdP’s SAML assertions.

By modifying the attribute mappings, IAM Identity Center can correctly interpret usernames, group memberships, and unique identifiers sent by the new IdP without requiring changes to AWS account roles or permission sets. This approach minimizes operational effort and avoids disruption to access management.

Option A unnecessarily disables identities and causes access outages. Option C is incorrect because IAM Identity Center abstracts role trust relationships, and roles do not directly trust the IdP. Option D is unrelated to federation source configuration and only affects authentication timing issues.

AWS best practices recommend updating attribute mappings when switching IdPs that share the same directory source.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS IAM Identity Center SAML Federation

AWS Identity Federation Best Practices

The most secure and AWS-recommended pattern for cross-account access is to create anIAM role in the target account (production)and allow trusted principals from the source account (developer) toassume the roleby using AWS STS. This avoids long-term credentials in the production account, supports short-lived session credentials, and enables strong controls such as MFA requirements, session duration limits, and precise least-privilege permissions attached to the role. It also centralizes ownership of production permissions in the production account, which is important for separation of duties and governance.

Option A is insecure because it requires password sharing and uses a long-lived IAM user credential, which is against AWS best practices. Option C is also poor because it relies on a long-lived IAM user in the production account and encourages credential sharing/duplication. Option B places the role in the developer account; while you can attach permissions there, access to production resources is governed by the production account. The standard approach is a production-account role with a trust policy that names the developer account principals (or a role) as allowed to assume it. Therefore, Option D is the most secure solution.

AWS CloudTrail provides authoritative records of KMS key creation, origin, and usage. Enabling log file validation ensures tamper detection. S3 Object Lock in compliance mode enforces immutability, which is a core audit requirement cited in AWS Certified Security – Specialty materials.

CloudWatch and DynamoDB do not provide immutable storage guarantees suitable for compliance evidence.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS CloudTrail Log File Validation

Amazon S3 Object Lock

AWS Organizations tag policies are designed to standardize and govern tag keys and allowed values across accounts. AWS Certified Security – Specialty documentation describes tag policies as a governance mechanism that helps enforce consistent tagging by specifying required tag keys and permitted values. To ensure every resource has the CostCenter tag at creation time, an SCP can deny create actions when aws:RequestTag/CostCenter is missing (null). This prevents resources from being created without the required tag. Tag policies then define the three approved values and can be configured to enforce or report noncompliance depending on supported services, ensuring that tag values remain within the allowed set and preventing drift to unapproved values. Compared with custom Lambda-based enforcement, this approach minimizes operational overhead and keeps enforcement within AWS native governance services. Option A partially addresses allowed values at request time but does not address ongoing governance as cleanly across many services. Option B is not preventive because Lambda runs after events and cannot reliably block all creations. Option D still relies on custom logic and is not as operationally efficient as tag policies plus SCP guardrails.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Organizations Tag Policies

AWS Organizations SCP Condition Keys for Tag Enforcement

To keep S3 accessoff the public internet, the standard AWS approach is to use anAmazon S3 gateway VPC endpoint(AWS PrivateLink for S3 is not used; S3 uses gateway endpoints). A gateway endpoint adds routes in the VPC route tables so traffic destined for S3 stays on the AWS backbone network rather than traversing an internet gateway, NAT gateway, or public IP paths. This satisfies the “cannot send traffic over the public internet” requirement while allowing the application in Account A to reach S3 in the same Region.

Cross-account bucket access is controlled byIAM and the S3 bucket policy, not by networking between the two accounts’ VPCs. The bucket resides in S3 (a regional service), not inside Account B’s VPC, so connecting VPC-to-VPC (peering, transit gateway, VPN) does not inherently provide private access to S3. Those options would add complexity and still typically require internet/NAT unless S3 endpoints are used.

With the gateway endpoint in Account A, the application can privately reach S3, and because permissions are already granted to write to the bucket in Account B, the write operations will succeed without public internet routing.

To ensure traffic from a VPC to AWS KMS stays on the AWS network and does not use public endpoints, you should use aninterface VPC endpoint (AWS PrivateLink) for KMS. Creating aVPC endpoint for KMS with private DNS enabled(Option C) causes standard KMS DNS names (for example, kms. < region > .amazonaws.com) to resolve to theprivateendpoint IPs inside the VPC, routing requests over the AWS private network rather than through the internet. This is the core networking control that satisfies “no public service endpoints.”

To enforce that only calls that come through the intended VPC endpoint can use the key, add an authorization guardrail in theKMS key policyusing the aws:sourceVpce condition (Option A). This ensures that even if a principal has credentials, KMS will deny usage unless the request is made via the specified VPC endpoint, preventing accidental or malicious use over public paths.

Option B is neither necessary nor sufficient: removing an internet gateway does not prevent all public endpoint use (NAT, other egress paths, or other VPCs could still be involved) and can break workloads. Option D is unrelated to runtime KMS API traffic. Option E is weaker because SourceIp checks can be bypassed via other AWS network paths and does not guarantee PrivateLink usage the way sourceVpce does.

The findingInstanceCredentialExfiltrationindicates that credentials available to the EC2 instance (from the instance profile / IMDS) were likely stolen and then used from an unusual location. The fastest way todeny the malicious actor immediatelyis to invalidate the stolen, currently usable credentials. Because these aretemporary credentialsissued to the instance profile role, the correct first containment action is torevoke active sessionsfor that role so the stolen session credentials stop working. This directly blocks continued API use while you continue investigation and remediation.

Changing security groups (Option A) affects inbound network access to the website but does not stop an attacker from using stolen API credentials against AWS APIs. Installing agents and running assessments (Options B and C) are investigative steps that take time and do not immediately cut off the attacker’s current access. After revoking sessions, best practice incident response typically continues with additional containment and eradication steps such as rotating credentials, reviewing CloudTrail for actions taken, checking for persistence (new IAM users/keys, modified policies), patching the instance, and restricting IMDS (for example, enforcing IMDSv2) to reduce risk of further credential theft.

AWS Config provides managed rules that continuously evaluate resource configurations against compliance requirements. The AWS Certified Security – Specialty documentation highlights AWS Config managed rules as the preferred mechanism for enforcing configuration compliance at scale. The managed rule for encrypted RDS storage automatically detects DB instances and clusters that are created without encryption enabled.

By configuring automatic remediation, AWS Config can immediately invoke corrective actions without manual intervention. Integrating remediation with an Amazon SNS topic enables automated email notifications, while an AWS Lambda function can terminate the noncompliant resource. This creates a fully automated detect-alert-remediate workflow.

Option B requires manual remediation, which increases operational effort and delays enforcement. Options C and D rely on Amazon EventBridge, which evaluates events rather than configuration state and does not provide continuous compliance monitoring. AWS Config is explicitly designed for configuration compliance and governance use cases.

This solution aligns with AWS governance best practices by combining continuous monitoring, automated remediation, and centralized alerting with minimal operational overhead.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Config Managed Rules

AWS Config Automatic Remediation

AWS WAF logs capturedetailed request-level information, including source IP address, request URI, headers, and rule evaluation results. According to the AWS Certified Security – Specialty documentation, AWS WAF logging is acritical detection controlwhen application-level attacks are suspected, especially when host-based logs are unreliable or can be erased by attackers.

By configuring the AWS WAF web ACL to send logs toAmazon Data Firehose, the company ensures that all future requests are centrally captured and delivered to a durable storage service such as Amazon S3. UsingAmazon Athena, the security team can query these logs to identify requests targeting specific application paths such as new-user-creation.php and extract the originating client IP addresses.

Option A is incorrect because VPC Flow Logs operate at the network layer and do not capture HTTP request paths. Option B is invalid because ALBs do not support CloudWatch agents. Option C is viable but introduces additional operational complexity and cost, making it less appropriate than the native WAF logging solution.

AWS documentation highlightsAWS WAF logging combined with Athenaas a best practice for forensic analysis and attacker identification.

AWS Certified Security – Specialty Official Study Guide

AWS WAF Logging Documentation

Amazon Athena User Guide

AWS Detection and Monitoring Best Practices

In a properly segmented VPC architecture,public subnets route internet-bound traffic to an internet gateway, whileprivate subnets route outbound internet traffic through a NAT gatewaythat resides in a public subnet. According to the AWS Certified Security – Specialty Official Study Guide and Amazon VPC documentation, private subnets must never have a direct route to an internet gateway.

The issue described indicates that private subnets are incorrectly routing traffic directly to the internet gateway. To remediate this, aNAT gateway must be provisioned in each public subnetto ensure high availability across Availability Zones. This satisfies the requirement that private resources can initiate outbound connections without being directly reachable from the internet.

Next, the route tables associated with theprivate subnets must be updatedso that the default route (0.0.0.0/0) points to the NAT gateway in the same Availability Zone. This ensures proper traffic flow and prevents cross-AZ dependencies.

Option B is incorrect because NAT gateways must reside in public subnets. Option C is unnecessary because local routes to the VPC CIDR range are automatically created. Option E is explicitly insecure, as it would reintroduce direct internet gateway access from private subnets.

AWS documentation consistently identifiesNAT gateways plus correct private subnet routingas the standard design for secure VPC segmentation.

AWS Certified Security – Specialty Official Study Guide

Amazon VPC Route Table Documentation

AWS Well-Architected Framework – Security Pillar

AWS Health providesreal-time visibility into events that affect AWS accounts, including abuse notifications such asAWS_ABUSE_DOS_REPORT. According to the AWS Certified Security – Specialty Study Guide, AWS Health events are natively integrated withAmazon EventBridge, enabling automated, near-real-time responses without polling or custom code.

By creating an EventBridge rule that listens for AWS Health events related to abuse reports and configuring the rule to publish messages to an SNS topic, the security engineer ensures immediate notification to the security team whenever AWS issues a DoS-related abuse report for the account.

Option A and C rely on periodic polling using Lambda functions, which introduces latency and operational complexity. Option D is incorrect because CloudTrail does not log AWS abuse notifications.

AWS documentation explicitly identifiesAWS Health + EventBridge + SNSas the recommended architecture for near-real-time operational and security alerts originating from AWS.

AWS Certified Security – Specialty Official Study Guide

AWS Health User Guide

Amazon EventBridge Documentation

AWS Incident Response Best Practices

AWS networking best practices require private subnets to access the internet only through NAT gateways located in public subnets. According to the AWS Certified Security – Specialty Study Guide, NAT gateways must be provisioned in public subnets and used as the default route for outbound traffic from private subnets.

Verifying NAT gateways in each Availability Zone ensures high availability and fault tolerance. Updating the private subnet route tables to send 0.0.0.0/0 traffic to the NAT gateway prevents direct internet access while allowing outbound connectivity.

Routing private subnet traffic directly to an internet gateway violates subnet isolation principles. NAT gateways must never be placed in private subnets.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon VPC Routing and NAT Gateways

AWS Network Segmentation Best Practices

The most efficient approach is to useAWS Configbecause Config is designed for continuous compliance evaluation and can automatically triggermanaged remediationwhen a resource drifts from the desired state. A managed Config rule that detects when CloudTrail is not logging, combined with theAWS-EnableCloudTrailremediation action, provides an automated way to re-enable CloudTrail without building and maintaining custom event processing code. This is especially valuable in multi-Region environments because Config can evaluate configurations across Regions and enforce the intended posture consistently.

Option B is illogical: triggering on StartLogging does not help when CloudTrail is turned off. Option C is not as operationally efficient because CloudWatch alarms are not the standard mechanism for reacting to CloudTrail API events; EventBridge is the proper event bus for API call events, but you would still be writing and maintaining Lambda logic and multi-Region plumbing. Option D is manual and delayed, not automated remediation.

Therefore, AWS Config with a managed rule and the AWS-provided remediation to enable CloudTrail is the most maintainable and efficient solution.

Amazon CloudWatch Logs provides a centralized, scalable service for collecting and storing logs from Amazon EC2 instances, regardless of whether the instances are On-Demand or Spot Instances. According to the AWS Certified Security – Specialty Official Study Guide, CloudWatch Logs is therecommended service for centralized log aggregation and near-real-time analysisof application and system logs.

By configuring all EC2 instances to send logs to asingle CloudWatch Logs log group, the security engineer ensures that logs from all instances are available in one centralized location. Access to the log group can be restricted by using IAM policies, ensuring that only authorized users can view and analyze the logs.

CloudWatch Logs Insights provides apowerful query language with SQL-like syntax, enabling users to search, filter, aggregate, and analyze log data efficiently. This directly satisfies the requirement for SQL-style queries to identify event patterns and perform root cause analysis without requiring data movement or additional services.

Option B is incorrect because CloudWatch Logs Insights cannot query log files stored in Amazon S3. Option C is inefficient and operationally complex, as Athena cannot directly query CloudWatch Logs log groups. Option D is invalid because Amazon Detective is designed for security investigations using GuardDuty findings, not for general application log analysis.

AWS documentation explicitly states thatCloudWatch Logs combined with CloudWatch Logs Insightsis the most efficient and secure approach for centralized log analysis in EC2-based architectures.

AWS Certified Security – Specialty Official Study Guide

Amazon CloudWatch Logs Documentation

CloudWatch Logs Insights Query Guide

Amazon Macie is the AWS service designed to discover and classify sensitive data in S3. Delegated administration enables centralized visibility across an organization. Security Hub aggregates Macie findings for a single-pane-of-glass view.

Inspector does not scan S3 data. Trusted Advisor is not a sensitive data discovery tool.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon Macie Multi-Account Architecture

AWS WAF allows security engineers to createstring match rule statementsthat inspect specific parts of web requests, including HTTP headers such as theUser-Agentheader. According to the AWS Certified Security – Specialty Study Guide and AWS WAF documentation, string match rules are ideal for blocking requests that contain known malicious identifiers, such as a distinctive user agent associated with a specific bot or IoT device brand.

In this scenario, the attack originates from a specific IoT device brand that uses aunique user agent. A string match rule that inspects the User-Agent header can precisely block malicious requests while allowing legitimate customer traffic to continue uninterrupted. This approach provides targeted mitigation for both current and future attacks originating from the same device signature.

Option A is incorrect because IP addresses cannot be derived from user agent strings, and IoT botnets frequently rotate IP addresses, making IP-based blocking ineffective. Option B is incorrect because geographic blocking is overly broad and risks blocking legitimate customers in the same regions as the attacking devices. Option C is incorrect because rate-based rules limit request volume per IP address and do not specifically identify malicious device signatures; legitimate high-traffic users could be unintentionally blocked.

AWS documentation emphasizes thatheader inspection with string match conditionsis a best practice for mitigating attacks that use identifiable request characteristics such as custom user agents, especially in DDoS and bot mitigation scenarios.

AWS Certified Security – Specialty Official Study Guide

AWS WAF Developer Guide – Rule Statements

AWS DDoS Resiliency Best Practices

AWS Well-Architected Framework – Security Pillar

Amazon CloudFront includes a built-in geo restriction feature that allows content to be allowed or denied based on the viewer’s country. According to AWS Certified Security – Specialty documentation, CloudFront geo restriction is the most cost-effective method for country-based blocking because it does not require AWS WAF or additional rule processing.

AWS WAF geo match rules incur additional cost and are more appropriate when advanced inspection or layered security controls are required. IP-based blocking is impractical due to frequent IP changes. Geolocation headers do not enforce access control.

CloudFront geo restriction is evaluated at the edge and efficiently blocks disallowed countries with minimal latency and cost.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon CloudFront Geo Restriction

AWS Edge Security Best Practices

Amazon S3 Block Public Access configured at the AWS account level is the recommended and most effective approach to protect data stored in Amazon S3 while minimizing operational overhead. AWS Security Specialty documentation explains that S3 Block Public Access provides centralized, preventative controls designed to block public access to S3 buckets and objects regardless of individual bucket policies or object-level ACL configurations. When enabled at the account level, these controls automatically apply to all existing and newly created buckets, significantly reducing the risk of accidental exposure caused by misconfigured permissions.

The AWS Certified Security – Specialty Study Guide emphasizes that public access misconfiguration is a leading cause of data leaks in cloud environments. Account-level S3 Block Public Access acts as a guardrail by overriding any attempt to grant public permissions through bucket policies or ACLs. This eliminates the need to manage security settings on a per-bucket or per-object basis, thereby reducing administrative complexity and human error.

Configuring Block Public Access at the object level, as in option B, requires continuous monitoring and manual configuration, which increases operational overhead. Disabling ACLs alone, as described in option C, does not fully prevent public access because bucket policies can still allow public permissions. Using AWS PrivateLink, as in option D, controls network access but does not protect against public exposure through misconfigured S3 policies.

AWS security best practices explicitly recommend enabling S3 Block Public Access at the account level as the primary mechanism for preventing unintended public data exposure with minimal management effort.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon S3 Security Best Practices Documentation

Amazon S3 Block Public Access Overview

AWS Well-Architected Framework – Security Pillar

AWS best practices recommend using a shared secret header between CloudFront and ALB origins to prevent direct access. CloudFront injects a custom header, and the ALB listener rules validate its presence.

IP-based controls are brittle due to CloudFront IP changes. PrivateLink and internal ALBs are not supported as CloudFront origins. Header validation is the most reliable and widely recommended pattern.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

CloudFront Origin Protection

AWS WAF and ALB Integration

In AWS IAM Identity Center (formerly AWS Single Sign-On), users and groups do not automatically gain access to all accounts in an AWS Organization simply because the accounts exist. Access is explicitly granted by assigning aprincipal(user or group) to a specific AWS account along with apermission set. Permission sets define the IAM policies that are provisioned into the target account as IAM roles.

In this scenario, employees in theCloudActive Directory group can access nearly all AWS accounts, which confirms that AD Connector synchronization is functioning correctly, eliminating option B. The fact that Account A exists but is inaccessible strongly indicates that the required account assignment is missing. Without explicitly assigning the Cloud group to Account A with a valid permission set, IAM Identity Center will not provision the necessary IAM role, and users will not see or access the account in the AWS access portal.

Option A is incorrect because accounts do not need to be placed in an OU to be accessible through IAM Identity Center. Option D is incorrect because IAM permissions boundaries do not control access to entire accounts and are not applied at the account level to block IAM Identity Center access.

AWS Security Specialty documentation emphasizes thataccount assignments are mandatoryfor IAM Identity Center access, making option C the correct answer.

WithSSE-KMS, authorization is a two-part check: the caller must have S3 permissions to read the objectandthe caller must be allowed to use the KMS key for decryption. Even if an IAM policy grants kms:Decrypt, the request will still fail if theKMS key policydoes not allow the principal (or does not allow the account to delegate use of the key). KMS key policies are authoritative: they can prevent key usage even when IAM policies appear to allow it.

A common misconfiguration is editing the key policy and removing the statement that grants the AWS account (or key administrators) the ability to manage and delegate permissions for the key—often described as removing “Enable IAM user permissions” or otherwise blocking the account from using IAM policies to authorize key usage. In that case, the IAM user’s kms:Decrypt permission in IAM is not sufficient because the key policy no longer permits it, resulting in Access Denied when S3 attempts to call KMS on the user’s behalf during GetObject.

Option A is not required for decrypting data (DescribeKey is useful for discovery but not necessary for GetObject). Option B would not inherently cause access denied if permissions align. Option C is incorrect because same-account S3 access can be granted purely via IAM without a bucket policy. Therefore, the key policy change is a valid reason.

Amazon Inspector provides native CI/CD integration capabilities that allow security checks to occur before container images are pushed to Amazon ECR. According to AWS Certified Security – Specialty documentation, Inspector does not block image pushes automatically. Instead, prevention must occur inside the CI/CD pipeline itself.

By generating a Software Bill of Materials (SBOM) using the Amazon Inspector SBOM generator and submitting it to Inspector for scanning, the pipeline can detect critical vulnerabilities before the image is uploaded. If vulnerabilities exceed policy thresholds, the pipeline fails, preventing deployment.

Post-push scanning solutions only detect vulnerabilities after exposure. Event-driven blocking does not prevent the initial risk.

AWS best practices require “shift-left” security controls to prevent vulnerable artifacts from entering production.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon Inspector CI/CD Integration

Cross-account access for an external auditor typically usesSTS AssumeRoleinto a role that exists in each target account. Three common failure points are: (1) therole ARNbeing wrong or missing, (2) the auditor lacking permission to callsts:AssumeRoleon that role, and (3) anexternal IDmismatch when the role trust policy requires it. Theexternal IDis a best practice for third-party access to mitigate the confused-deputy problem; if the trust policy includes an sts:ExternalId condition, the auditor must supply the exact expected value. If it’s absent or incorrect, AssumeRole will be denied.

The auditor must also be authorized on their side (IAM user/role policy) to call sts:AssumeRole (permission), and the destination role’strust policymust trust the auditor principal. If either side is misconfigured, the assume operation fails. Finally, the auditor must reference the correctrole ARNfor each account; using an incorrect ARN (wrong account ID/role name/path) is a frequent reason only “some accounts” fail.

Incorrect password (B) is irrelevant if the auditor is using API/STS federation rather than console password auth, and EC2 instance roles (D) are not required for an external auditor. Missing/incorrect secret key (E) is possible for API auth, but the question centers on cross-account role access issues; the canonical causes are external ID, AssumeRole permission, and role ARN.

AWS WAF logs contain detailed request-level information, including source IP addresses, requested URIs, and rule matches. According to AWS Certified Security – Specialty guidance, enabling AWS WAF logging provides the most reliable and tamper-resistant method to investigate web-based attacks, especially when instance-level logs are unavailable.

By streaming WAF logs through Amazon Kinesis Data Firehose to Amazon S3, the company ensures durable, centralized log storage that is independent of EC2 lifecycle events. Amazon Athena can then query the logs efficiently to identify repeated requests to the new-user-creation.php endpoint and extract attacker IP addresses.

VPC Flow Logs do not capture HTTP-level details. ALB access logs alone may not capture blocked requests. WAF logs provide the best forensic visibility for future detection.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS WAF Logging and Monitoring

Amazon Athena Log Analysis

For centralized, organization-wide user access to AWS services and supported applications, AWS best practice is to useAWS IAM Identity Center(successor to AWS SSO). IAM Identity Center provides a single place to manage workforce identities, permission sets, and account assignments across AWS Organizations. Amazon Q Developer is integrated for centralized access using IAM Identity Center, where you can assign the relevant permissions to users and groups and enable access consistently across multiple AWS accounts. Setting Amazon Q Developer up as anAWS managed applicationaligns with IAM Identity Center’s model for centrally provisioning and controlling access with minimal operational overhead.

Amazon Cognito is primarily intended forcustomer identity and application sign-up/sign-inscenarios, not for workforce access to AWS managed developer tools across multiple AWS accounts. “Identity pools” are a Cognito concept for exchanging identities for AWS credentials, which adds unnecessary complexity and is not the standard approach for centrally granting employees access to Amazon Q Developer in an organization. Therefore, enabling IAM Identity Center and configuring Amazon Q Developer as an AWS managed application is the correct solution.

Amazon GuardDuty generates security findings when it detects suspicious or malicious activity, includingCryptoCurrency:EC2/* findings that indicate an EC2 instance may be involved in unauthorized cryptocurrency mining. According to AWS Certified Security – Specialty documentation, GuardDuty findings are published as events toAmazon EventBridge(formerly Amazon CloudWatch Events).

Amazon EventBridge is the recommended service for buildingautomated incident response workflows. By creating an EventBridge rule that listens for GuardDuty findings of type CryptoCurrency:EC2/*, the security engineer can automatically invoke a Lambda function to isolate the affected EC2 instance by modifying its security group attachments.

Option A is incorrect because GuardDuty does not directly invoke Lambda functions. Option B and Option D are incorrect because AWS Config tracks configuration compliance and resource changes, not real-time threat detection events. Cryptocurrency findings are security detections, not configuration changes.

AWS documentation explicitly describes this pattern—GuardDuty → EventBridge → Lambda → remediation action—as a best practice for automated threat response and containment.

AWS Certified Security – Specialty Official Study Guide

Amazon GuardDuty User Guide – Findings

Amazon EventBridge User Guide

AWS Incident Response Best Practices

Amazon RDS supports point-in-time recovery (PITR) using automated backups within the configured retention window. According to the AWS Certified Security – Specialty Study Guide, PITR allows recovery to any second within the retention period, making it the most precise recovery method following a security incident.

By restoring the database cluster to a point just before the attack occurred, such as 3:14 PM, the security engineer ensures that the restored database reflects the last known good state without including malicious changes. This method is more accurate than restoring from snapshots, which are created at fixed intervals and may not align with the exact recovery time.

Options B and C rely on snapshot timing and may reintroduce compromised data. Option D restores to an arbitrary time and does not meet the requirement to recover to the last known good version.

AWS documentation explicitly recommends point-in-time recovery for incident response scenarios that require precise restoration.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon RDS Automated Backups and PITR

AWS Incident Response and Recovery Guidance

AWS Secrets Manageris the AWS service designed to store secrets securely and to supportautomatic rotationon a schedule—commonly used for Amazon RDS credentials. Storing credentials in Secrets Manager removes them from source code, enables fine-grained access control, and supports auditability of secret retrieval through CloudTrail. Rotation can be configured to periodically change the database password and update the stored secret automatically, minimizing operational overhead compared to manual rotation processes.

To ensure the credentials are accessibleonly to the application, the correct ECS pattern is to useIAM roles for tasks. A task role can be scoped to allow only secretsmanager:GetSecretValue (and related actions if needed) for the specific secret ARN. Only tasks running with that role can retrieve the secret at runtime, which prevents broad access. This also helps reduce the risk of database administrators sharing plaintext credentials, because the recommended operational model is that humans should not need direct access; the application retrieves the secret programmatically, and access can be limited to break-glass workflows if required.

Systems Manager Parameter Store can store encrypted parameters, but Secrets Manager provides stronger native secret lifecycle features (notably rotation) for databases. Inline policies (Option B) are not necessary; managed or attached policies on the task role achieve the same goal with cleaner administration.

Network Load Balancers operate at Layer 4 and are optimized for extreme performance, ultra-low latency, and handling sudden traffic spikes. According to AWS Certified Security – Specialty documentation, using a TCP listener on an NLB allows TLS traffic to pass through directly to backend containers without termination, preserving true end-to-end encryption.

This approach eliminates the overhead of decrypting and re-encrypting traffic at the load balancer, reducing latency and maximizing throughput. NLBs scale automatically to handle volatile traffic patterns and millions of requests per second.

Application Load Balancers operate at Layer 7 and introduce additional latency due to TLS termination and HTTP processing. Route 53 multivalue routing does not provide load balancing at the transport layer and does not ensure encryption handling.

AWS recommends NLB TCP pass-through for high-performance, end-to-end encrypted container workloads.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Elastic Load Balancing Architecture

Network Load Balancer Performance Characteristics

Delegated administration for IAM Identity Center allows the organization to designate an account (or administrators) to manage Identity Center tasks without giving broad control to everyone in the management account. Before configuring delegated administration, the organization should ensure that appropriate administrative access is set up following least privilege (Option A) so only the intended administrators can manage Identity Center configuration and assignments.

Next, IAM Identity Center relies onpermission setsandassignments(users/groups to accounts/permission sets) to deliver access through the AWS access portal. Creating the requiredpermission sets(Option D) and establishing the necessaryuser assignments(Option F) in the management account provides the baseline Identity Center configuration that will be administered and delegated. These are core Identity Center primitives and are commonly prepared as part of initial setup so delegated admins have clearly defined roles and scope to manage.

Option B is not required because IAM Identity Center uses an identity source (such as AWS Directory Service, an external IdP, or the Identity Center directory) that is configured once; you don’t typically “create a new directory” as a prerequisite for delegated admin unless you are changing identity sources. Option C is irrelevant; delegated administration is not dependent on adding a second Region. Option E is incorrect because IAM Identity Center is intended to reduce reliance on IAM users for workforce access, not require creating new IAM users.

AWS Systems ManagerSession Managerprovides interactive shell access to managed instanceswithout inbound SSH,without bastion hosts, andwithout managing SSH keys. Access is controlled through IAM policies, and every session can be logged to CloudWatch Logs/S3 for auditability. This directly satisfies the “no SSH keys” requirement and reduces the network exposure surface because you can keep port 22 closed and still obtain shell access when needed.

To meet the isolation requirement, the instances can be placed in private subnets with no inbound access, and you can use Systems Manager connectivity (via SSM endpoints/agents) for administrative sessions only when required. On-premises servers can also be managed by Systems Manager by registering them as managed instances (hybrid activations), allowing the same no-SSH-key operational model across EC2 and on-prem environments.

Options A and D still require network paths and do not eliminate key management; a bastion host is additional infrastructure that must be secured and maintained. CloudShell (Option C) is an AWS-managed shell environment but does not provide a direct, managed, keyless session channel into arbitrary EC2/on-prem hosts by itself. Therefore, Session Manager is the best solution.

AWS Key Management Service (KMS) customer managed keys areregional resources. According to the AWS Certified Security – Specialty Official Study Guide and KMS documentation, a KMS key created in one AWS Regioncannot be used directly in another Region. When copying an encrypted Amazon Aurora DB snapshot across Regions, the destination Region must have access to a KMS keythat exists in that Region.

Because the original KMS key resides in us-east-1, it cannot be accessed or referenced in us-west-1. The correct and supported approach is tocreate a new customer managed KMS key in us-west-1and specify that key when performing the cross-Region snapshot copy. Amazon RDS automatically decrypts the snapshot using the source Region key and re-encrypts it using the destination Region key during the copy process.

Option A is invalid because KMS keys cannot be stored or transferred through AWS Secrets Manager. Options C and D are incorrect because IAM policies cannot grant cross-Region usage of a KMS key; KMS enforces strict regional boundaries regardless of IAM permissions.

AWS documentation clearly states thatcross-Region encrypted snapshot copies require a KMS key in the destination Region, making this approach mandatory for compliance and encryption continuity.

AWS Certified Security – Specialty Official Study Guide

AWS Key Management Service Developer Guide

Amazon Aurora Security Documentation

AmazonMacieis the AWS service purpose-built todiscover and classify sensitive data in S3(PII, financial data, credentials, etc.) and produce findings that can be aggregated centrally. In a multi-account organization, the recommended centralized model is to designate adelegated administrator accountfor Macie so the security team can manage discovery across member accounts from one place.

To make the findings visible from a single location and integrate them with broader security visibility,AWS Security Hubprovides centralized aggregation of security findings across accounts and services. By also configuring the security account as thedelegated administrator for Security Hub, the company can aggregate findings across the organization. Macie integrates with Security Hub so that sensitive data discovery findings flow into Security Hub’s centralized view, giving the security team a single console and API surface to build an “inventory” of sensitive data locations and severity.

Inspector (options B and C) is focused on vulnerability management (EC2, ECR, and related scanning use cases), not sensitive data classification in S3. Trusted Advisor is not the primary destination for sensitive data discovery findings at organizational scale. Therefore, Macie + Security Hub with delegated administration in the security account is the correct solution.

Amazon CloudWatch Logs is designed to collect, store, and analyze log data from ephemeral compute resources such as EC2 instances in Auto Scaling groups. According to the AWS Certified Security – Specialty Study Guide, using the CloudWatch agent to stream logs off instances ensures log durability even when instances are terminated during scale-in events.

CloudWatch Logs Insights provides a fully managed, serverless query engine that enables ad hoc querying, filtering, and aggregation of log data without requiring additional infrastructure. This directly satisfies the requirement to query logs for application sessions and user troubleshooting.

Option A introduces operational risk because logs could be lost between cron executions. Option B requires additional services and data pipelines, increasing cost and complexity. Option E adds storage cost and management overhead and is not necessary for log analytics.

AWS best practices recommend CloudWatch Logs and Logs Insights as the most cost-effective and scalable solution for centralized log retention and analysis in Auto Scaling environments.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon CloudWatch Logs and Logs Insights

AWS Logging Best Practices

In IAM Identity Center, a permission set that includes acustomer managed policydoes not “carry” that policy into each target account automatically unless the policy exists there. When you attach a customer managed policy by name to a permission set, IAM Identity Center expects that policy to be present in each account where the permission set is provisioned. If the policy is missing in any account (common when assigning across multiple accounts), provisioning/assignment can fail because Identity Center cannot attach a non-existent policy to the role it creates in that account.

The correct fix is tocreate the customer managed policy in every target account, ensuring it has thesame nameand the intended permissions in each account. Once the policy exists consistently across accounts, IAM Identity Center can successfully provision the permission set in each account and complete the user assignment.

Options B and D are workarounds that increase complexity and do not address the underlying requirement to use the customer managed policy across accounts. Option C is not the issue here; policy “conflicts” typically do not prevent provisioning—missing referenced customer managed policies do. Therefore, ensuring the customer managed policy exists in each assigned account resolves the failure with the intended multi-account design.

AWS incident response best practices emphasize rapid containment to prevent further data exposure. According to the AWS Certified Security – Specialty Study Guide, the fastest and least disruptive containment method for compromised compute resources is to immediately revoke credentials and permissions rather than modifying data or infrastructure.

Revoking the IAM role’s active sessions prevents the EC2 instance from continuing to access AWS services. Updating the S3 bucket policy to explicitly deny access to the IAM role ensures immediate enforcement, even if temporary credentials remain cached. Removing the IAM role from the instance profile further prevents new credentials from being issued.

Option A and D involve large-scale data movement or re-encryption, which is time-consuming and operationally expensive. Option B relies on network-level controls that do not prevent access through private AWS endpoints.

AWS guidance explicitly recommends credential revocation and policy-based denial as the fastest containment step during active incidents.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Incident Response Best Practices

AWS IAM Role Session Management

Amazon GuardDuty is afully managed, organization-aware threat detection servicethat continuously analyzes AWS logs such as CloudTrail events, VPC Flow Logs, DNS logs, EKS audit logs, and RDS activity. According to the AWS Certified Security – Specialty Official Study Guide, GuardDuty is designed to operate atscale across AWS Organizations with minimal operational overhead.

By designating a GuardDuty administrator account in the organization’s management account and enabling GuardDuty organization-wide, the company can automatically enable threat detection across hundreds of AWS accounts. EnablingEKS Protectionallows GuardDuty to analyze Kubernetes audit logs for suspicious activity, whileRDS Protectionprovides anomaly detection for Amazon Aurora databases.

Options B, C, and D require custom log aggregation, processing, and analytics pipelines, which significantly increase operational effort and maintenance complexity. Amazon Inspector does not analyze logs, Athena-based analysis is manual, and Kinesis plus Lambda requires custom detection logic.

AWS documentation explicitly identifiesGuardDuty with AWS Organizations integrationas the recommended solution for centralized, automated threat detection across multi-account environments with minimal operational effort.

AWS Certified Security – Specialty Official Study Guide

Amazon GuardDuty User Guide

GuardDuty Organization Administration Documentation

AWS KMS keys are regional resources and cannot be used across Regions. According to AWS Certified Security – Specialty documentation, applications that are deployed in multiple Regions should use region-specific customer managed keys while referencing keys by alias instead of key ID.

By creating a new customer managed key in eu-north-1 and assigning it the same alias as the key in eu-west-1, the application code can continue to reference the alias without modification. Each Region resolves the alias to the correct local key, ensuring encryption continues to function correctly.

Option A is invalid because KMS keys are regional. Option B requires application changes. Option D introduces unsupported alias patterns.

AWS best practices recommend alias-based key references for multi-Region deployments.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS KMS Regional Keys and Aliases

AWS KMS Best Practices

GuardDuty’s DNS-related detections depend on GuardDuty being able to observeDNS query behaviorthrough AWS-provided DNS resolution paths in the VPC. If a VPC is configured to use acustom DNS resolvervia DHCP options (for example, an OpenDNS resolver) instead of the AmazonProvidedDNS resolver, DNS queries may bypass the visibility path GuardDuty relies on for DNS analysis and pattern detection. In that case, the test traffic (queries to example.com) might not be evaluated by GuardDuty’s DNS finding logic, so no DNS finding is generated—and therefore nothing is forwarded into Security Hub.

Option A is incorrect because VPC flow logs are not a prerequisite for GuardDuty to produce DNS findings; GuardDuty uses native telemetry sources and does not require customer-managed flow logs to be enabled. Option D is irrelevant because the company operates in a single Region, and cross-Region aggregation would not be required for the delegated administrator to see findings from the same Region. Option C is less likely given the setup explicitly states GuardDuty and Security Hub are automatically enabled across accounts; also, even if enabled, the specific lack of a DNS finding points to DNS visibility/configuration rather than a downstream integration toggle.

Amazon SQS is an AWS-managed service and does not operate within customer VPCs. Therefore, security groups and network ACLs cannot be used to control access to SQS, making options A and B invalid. According to AWS Certified Security – Specialty documentation, the recommended approach to securely access AWS services from within a VPC is throughinterface VPC endpoints (AWS PrivateLink).

By creatinginterface VPC endpoints for Amazon SQS, the company ensures that traffic to SQS stays within the AWS network and does not traverse the public internet. Adding anSQS resource policywith the aws:SourceVpce condition restricts access so that only requests originating from the specified VPC endpoint are allowed. Additionally, using the aws:PrincipalOrgId condition ensures that only principals belonging to the same AWS Organization can access the queue.

Option D introduces an external tool, increasing cost and compliance complexity, which directly violates the requirement to minimize investment outside AWS.

AWS documentation clearly identifiesVPC endpoints combined with IAM condition keysas a best practice for securing service access in multi-account environments.

AWS Certified Security – Specialty Official Study Guide

Amazon SQS Security Best Practices

AWS Organizations Documentation

AWS PrivateLink User Guide

A credential stuffing attack at the ALB is aLayer 7problem and is best mitigated withAWS WAF. The attacker is distributed across many IPs, so blocking by IP in a security group (Option B) is ineffective and operationally heavy. A CloudWatch alarm (Option A) only alerts; it does not block or mitigate requests.

Because the malicious traffic uses a distinctive, knownUser-Agentstring associated with a mobile device emulator, AWS WAF can quickly reduce the attack by inspecting the User-Agent header and blocking matching requests. This approach is targeted: it blocks the identified automated attack pattern while allowing legitimate users who do not present that emulator User-Agent to continue logging in. The WAF rule can be deployed immediately on the existing ALB-associated web ACL and can be further refined (for example, applied only to /login paths, combined with rate-based rules, or integrated with Bot Control) to minimize false positives.

Option D is risky because “allow only legitimate user agents” is brittle: user agents are diverse and change frequently, and a strict allow-list can accidentally block real users. Therefore, a WAF custom block rule for the known malicious User-Agent string is the correct solution.

AWS Audit Manager is specifically designed to help organizations continuously audit their AWS usage against compliance frameworks and generate audit-ready reports. According to AWS Certified Security – Specialty documentation, Audit Manager includes AWS managed frameworks for compliance standards, including PCI DSS v4.0.

Audit Manager automatically collects evidence from AWS services such as API Gateway, Lambda, RDS, CloudTrail, and Config, and maps the evidence directly to PCI DSS controls. Importantly, Audit Manager allows compliance teams to upload and attach manual evidence, which is a key requirement in this scenario.

Option C provides visibility into control status but does not support adding manual evidence. Option B evaluates configuration compliance but does not generate formal compliance reports. Option A requires extensive manual effort and is not aligned with PCI reporting workflows.

AWS documentation positions Audit Manager as the authoritative service for compliance reporting and audit evidence management.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS Audit Manager PCI DSS Framework

AWS Compliance Reporting Best Practices

The correct Config rule for finding buckets that are not usingSSE-KMS by defaultiss3-default-encryption-kms. It evaluates the bucket’s default encryption settings and flags buckets that do not have KMS default encryption enabled. The s3-bucket-ssl-requests-only rule focuses on enforcing HTTPS-only requests and does not validate encryption-at-rest settings, so it cannot satisfy the “identify not encrypted with KMS” requirement.

For preventing uploads of objects that are not encrypted with KMS, an organization-wide control is needed. AnSCPcan restrict s3:PutObject so that uploads succeed only when the request specifiesSSE-KMS(and optionally a specific KMS key). This provides broad, low-touch enforcement across many accounts and buckets. While bucket policies can also enforce SSE-KMS, managing and verifying hundreds of bucket policies is more operationally heavy than a centrally managed SCP guardrail.

Option B enforcesSSE-S3, which does not meet the requirement forKMSencryption. Option D uses the wrong Config rule and relies on an “allow-only” pattern rather than explicit deny logic, making it an unreliable fit for the stated goal. Therefore, A is the best answer.

AWS best practices require CloudFormation to assume a dedicated service role. This ensures consistent permissions regardless of the user. Users must have iam:PassRole permission to pass the role. Updating stacks to use the service role enforces uniform deployment behavior.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS CloudFormation Service Roles

AWS IAM Identity Center centrally manages user access across an AWS Organization. Disabling the user in Identity Center immediately revokes access to all AWS accounts. According to AWS Certified Security – Specialty documentation, organizational CloudTrail event data stores provide centralized, queryable access to all events across accounts.

Using CloudTrail Lake enables direct querying of activity without exporting logs. Disabling the user at the Identity Center level ensures full containment.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

AWS IAM Identity Center Incident Response

AWS CloudTrail Lake

AWS incident response best practices emphasizerapid containment, credential revocation, and threat detectionto minimize the blast radius of a compromise. According to the AWS Certified Security – Specialty Official Study Guide, when unauthorized resources such as an Amazon S3 bucket hosting malware are discovered, immediate action must be taken to stop further misuse of the account and to prevent recurrence.

Rotating or deleting all AWS access keys (Option D)is a critical containment step. If an IAM user has been compromised, any long-term credentials associated with that user must be revoked immediately to prevent continued unauthorized access. AWS guidance explicitly lists access key rotation or deletion as a first-response action for suspected credential compromise.

Deleting unrecognized or unauthorized resources (Option F)directly removes the malicious infrastructure that is being abused. In this case, deleting the unauthorized S3 bucket immediately stops malware distribution and reduces reputational and compliance impact.

Turning on Amazon GuardDuty (Option B)enables continuous threat detection by analyzing CloudTrail events, VPC Flow Logs, and DNS logs. GuardDuty can identify additional malicious activity, compromised credentials, or persistence mechanisms that the attacker may have established. AWS documentation recommends enabling GuardDuty during or immediately after an incident to detect ongoing or future threats.

Option A does not reduce the impact of the current compromise. Option C is overly disruptive and not recommended; credential rotation should be targeted. Option E is unnecessary because there is no indication that EBS-backed compute resources are involved.

AWS incident response guidance clearly prioritizescredential revocation, malicious resource removal, and threat detectionto minimize consequences.

AWS Certified Security – Specialty Official Study Guide

AWS Incident Response Best Practices

Amazon GuardDuty User Guide

AWS IAM Security Best Practices

Amazon Cognito identity pools are designed to provide temporary AWS credentials for applications by exchanging an authenticated identity token for AWS Security Token Service (STS) credentials. AWS Certified Security – Specialty guidance distinguishes between Cognito user pools (authentication) and identity pools (authorization to AWS resources). A user pool can authenticate a user and issue tokens, but an identity pool is required to obtain AWS credentials that can be used to sign AWS API requests, such as S3 API calls. The correct mechanism is for the application to use AssumeRoleWithWebIdentity through STS (which is the underlying federation method used by identity pools) to receive temporary credentials for an IAM role that grants S3 permissions. GetId alone does not provide credentials; it returns an identity identifier that is used as part of the credential exchange flow. Options C and D are incorrect because user pool tokens are not AWS credentials and cannot directly sign S3 requests. The solution therefore must use identity pools to map users to IAM roles and retrieve temporary credentials, satisfying the requirement for authenticated API calls using short-lived credentials.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon Cognito Identity Pools and STS Federation

AWS STS AssumeRoleWithWebIdentity

Amazon OpenSearch Service is designed for near real-time log ingestion, indexing, and search across large volumes of data. According to the AWS Certified Security – Specialty Study Guide, OpenSearch supports advanced log analytics use cases and integrates with OpenSearch Security Analytics, which provides prebuilt and custom detection rules.

Security Analytics can continuously evaluate incoming logs from multiple AWS services and generate alerts when detection rules are matched. These alerts can be forwarded to Amazon SNS with minimal configuration. OpenSearch also provides powerful search and query capabilities through APIs and dashboards.

Option C supports detection but lacks advanced correlation and scalable search capabilities. Option B is not a log analytics service. Option D is a visualization service and does not support real-time detection.

AWS guidance recommends OpenSearch Service for centralized, near real-time log analysis and alerting.

Referenced AWS Specialty Documents:

AWS Certified Security – Specialty Official Study Guide

Amazon OpenSearch Service Security Analytics

AWS Logging and Monitoring Architecture

EC2 Instance Connect can performserver/host authenticity checksby validating the instance’s SSHhost keyagainst atrusted host keyssource. When you rotate the instance’s host keys, the host presents anewfingerprint. If the trusted host keys source still contains theoldhost key, connections that enforce host key verification will fail with ahost key validationerror. The fix is to update the trusted host key record so the new host key fingerprint is recognized as valid. Therefore, the correct action is toupload the new host keyto the trusted host keys database used for EC2 Instance Connect host key verification.

Option A is unrelated: AWS KMS does not store or manage SSH host keys for EC2 Instance Connect validation. Option C is for AWS Systems Manager managed instances and has no effect on SSH host key validation. Option D rotatesuser/client authentication keys(SSH key pair used to log in) but does not resolve a failure that occurs specifically because theserver host keychanged and is no longer trusted. Updating the trusted host keys database restores the expected trust chain and allows Instance Connect to work again with the rotated host keys.