AWS SCS-C02 Free Practice Questions — Page 3

Correct Answer: C. Create an Amazon EventBridge rule to detect critical Security Hub findings. Create an Amazon Simple Notification Service (Amazon SNS) topic as the target of the EventBridge rule. Subscribe an email endpoint to the SNS topic to receive published messages.

Why C is correct: Amazon EventBridge is the native AWS service for event-driven architectures and integrates directly with AWS Security Hub. You can create an EventBridge rule with a filter pattern to detect critical findings (e.g., filtering by severity or specific finding types). EventBridge can then target an SNS topic, which handles the email notification through subscribed endpoints. This is the simplest, most direct solution using AWS-native integrations without requiring custom Lambda code. Why A is wrong: This solution requires writing and maintaining custom Lambda function code to identify critical findings, which adds unnecessary complexity and operational overhead. EventBridge can filter events natively without Lambda. While this would work, it's not the simplest or most maintainable solution compared to using EventBridge's built-in filtering capabilities. Why B is wrong: Amazon Kinesis Data Firehose is designed for streaming data delivery to destinations like S3, Redshift, or Elasticsearch, not for sending email notifications. Firehose does not support email addresses as a destination. Additionally, while Firehose integrates with EventBridge, it's designed for high-throughput data ingestion and transformation, which is overly complex for simple notifications. Why D is wrong: Amazon SES (Simple Email Service) is not a target type for EventBridge rules. EventBridge cannot directly invoke SES as a target. Valid EventBridge targets include SNS, SQS, Lambda, Step Functions, and others, but not SES directly. Additionally, there's no such thing as an "SES topic"—SNS has topics, not SES. This answer confuses SES with SNS.

Correct Answers: A. Ensure that the Amazon CloudWatch agent is installed on all the EC2 instances that the Auto Scaling groups launch. Generate a CloudWatch agent configuration file to forward the required logs to Amazon CloudWatch Logs.; B. Set the log retention for desired log groups to 7 years.; C. Attach an IAM role to the launch configuration or launch template that the Auto Scaling groups use. Configure the role to provide the necessary permissions to forward logs to Amazon CloudWatch Logs.

Why A is correct: The CloudWatch agent must be installed on EC2 instances to collect system and application logs. The agent configuration file specifies which log files to forward to CloudWatch Logs. This ensures that logs are continuously streamed from instances to CloudWatch, so even if an instance is terminated during scaling, the logs are already safely stored in CloudWatch Logs. Why B is correct: CloudWatch Logs supports retention settings from 1 day to 10 years (or indefinite). Setting retention to 7 years ensures logs are kept for the required period and automatically deleted afterward, meeting the compliance requirement without manual intervention. Why C is correct: EC2 instances need IAM permissions to send logs to CloudWatch Logs. Attaching an IAM role to the launch configuration/template ensures all instances launched by Auto Scaling automatically have the necessary permissions. The role should include the logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents permissions. Why D is wrong: While S3 can store logs for 7 years, this answer doesn't provide the mechanism for continuously capturing logs from instances before they're terminated. CloudWatch Logs is the service designed for real-time log streaming from EC2 instances, ensuring no data loss during scaling events. S3 is better suited as an archive destination rather than the primary log collection mechanism. Why E is wrong: Using a custom log forwarding application adds operational overhead and complexity compared to the native CloudWatch agent. Custom applications require maintenance, updates, and monitoring. Additionally, "periodically bundle" suggests batch processing, which could result in log loss if an instance is terminated between bundle intervals, violating the "no logging data is lost" requirement. Why F is wrong: While S3 Lifecycle policies can expire objects after 7 years, this answer is incomplete without specifying how logs get to S3 in the first place. More importantly, CloudWatch Logs with retention settings (option B) is the correct approach when using the CloudWatch agent. Lifecycle policies are for S3-based log storage, not CloudWatch Logs.

Correct Answers: A. "Bool": {"aws:MultiFactorAuthPresent": "true"}; C. "NumericLessThan": {"aws:MultiFactorAuthAge": "7200"}

Why A is correct: The condition "Bool": {"aws:MultiFactorAuthPresent": "true"} enforces that the user must have authenticated with MFA for the session. This AWS global condition key checks whether MFA was used during authentication. Setting it to "true" ensures only MFA-authenticated sessions can perform the specified actions. Why C is correct: The condition "NumericLessThan": {"aws:MultiFactorAuthAge": "7200"} ensures the MFA authentication is less than 7200 seconds (2 hours) old. The aws:MultiFactorAuthAge key represents the number of seconds since MFA authentication occurred. This enforces the session validity requirement of 2 hours. Why B is wrong: Setting aws:MultiFactorAuthPresent to "false" would allow sessions WITHOUT MFA, which is the opposite of what's required. This would weaken security rather than enforce MFA. Why D is wrong: NumericGreaterThan with aws:MultiFactorAuthAge of 7200 would require the MFA authentication to be OLDER than 2 hours, which contradicts the requirement. This would only allow expired sessions and block recent MFA authentications. Why E is wrong: MaxSessionDuration is a property of IAM roles that defines how long a role session can last (1-12 hours), but it's not a condition key for IAM policies. Additionally, this doesn't specifically enforce MFA or check the age of MFA authentication. The correct keys for this requirement are aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge.

Correct Answer: C. Activate Amazon GuardDuty in each production account. In a dedicated logging account, aggregate all GuardDuty logs from each production account. Remediate incidents by using Amazon EventBridge to invoke a custom AWS Lambda function from the GuardDuty findings. Configure the Lambda function to also publish notifications to the SNS topic.

GuardDuty is the right service for proactive detection of suspicious behavior (threats/compromise) across accounts. GuardDuty findings are delivered to Amazon EventBridge (CloudWatch Events), which is the supported mechanism to route findings and trigger automated actions. GuardDuty itself does not directly invoke Lambda, so option A is technically incorrect. Using EventBridge → Lambda lets you implement centralized or per-account remediation logic and also have that Lambda publish to the SNS topic for critical findings. Aggregating GuardDuty logs/findings into a dedicated logging account (via Organizations/delegated admin + cross-account delivery or central EventBridge routing) meets the requirement to send all incident logs to a dedicated account. Options B and D rely on Security Hub as the primary detector; Security Hub is an aggregator/insights layer (it consumes sources such as GuardDuty) but GuardDuty is the service that actually detects suspicious behavior, so C is the best fit.

Correct Answer: C. Create SCPs that include the Condition, Resource, and NotAction elements to allow access to only the Regions and services that are needed.

Why C is correct: Service Control Policies (SCPs) are specifically designed to set permission guardrails across all accounts in an AWS Organization. SCPs can use the Condition element with aws:RequestedRegion to restrict Regions, and the NotAction element to deny access to services not explicitly allowed. SCPs are applied at the organization, OU, or account level, automatically affecting all accounts including new ones, making this the solution with the LEAST operational overhead. SCPs override all identity-based policies, ensuring developers cannot bypass restrictions. Why A is wrong: IAM Identity Center roles (permission sets) would need to be configured separately for each account or user group, creating significant operational overhead. Additionally, identity-based policies can be less effective than SCPs because SCPs apply regardless of the identity's permissions. This approach doesn't centrally enforce restrictions at the organization level as effectively as SCPs. Why B is wrong: AWS STS operates globally, and while you can deactivate STS endpoints in specific Regions, this doesn't prevent the use of AWS services in those Regions. Services don't require regional STS endpoints to function—they can use the global STS endpoint. This approach doesn't actually restrict service usage and would create authentication issues rather than enforcing regional restrictions. Why D is wrong: Creating tailored identity-based policies for each account requires significant operational overhead—policies must be created and maintained for each account and user group. This doesn't scale well as the organization grows. Additionally, identity-based policies are less effective than SCPs for organizational guardrails because users with sufficient permissions might be able to modify their own policies.