Back to AWS Certified SysOps Administrator - Associate (SOA-C02)

Security and Compliance

Implement and manage security policies, data protection, and compliance requirements (~16% of exam).

Covers implementing and managing IAM policies including policy types (identity-based, resource-based, SCPs), IAM roles, instance profiles, cross-account access, and AWS Organizations. Also covers implementing data protection including encryption at rest (KMS, EBS encryption, S3 encryption), encryption in transit (TLS/SSL, ACM certificates), AWS Secrets Manager, and Systems Manager Parameter Store. Covers compliance and auditing using AWS Config rules, AWS CloudTrail, Amazon Inspector, AWS Security Hub, Amazon GuardDuty, and AWS Trusted Advisor security checks. Also includes security groups, NACLs, and VPC security best practices.
5 minutes 5 Questions

Security and Compliance in AWS is a fundamental domain for the SysOps Administrator certification, focusing on protecting AWS resources and meeting regulatory requirements. AWS operates on a Shared Responsibility Model where AWS manages security OF the cloud (physical infrastructure, hardware, netw…

Concepts covered: Resource-based policies, IAM policy evaluation logic, AWS managed keys, EBS encryption, S3 encryption options, IAM permission boundaries, Config conformance packs, Encryption at rest, AWS IAM policies, Identity-based policies, IAM roles and instance profiles, Cross-account access, AWS Organizations, Service control policies (SCPs), IAM Access Analyzer, Security groups, Network ACLs, VPC security best practices, AWS KMS key management, KMS key policies, Customer managed keys, RDS encryption, Encryption in transit, AWS Certificate Manager, TLS/SSL certificates, AWS Secrets Manager, Secrets rotation, AWS CloudTrail for auditing, CloudTrail log analysis, AWS Config compliance, Amazon Inspector, AWS Security Hub, Amazon GuardDuty, AWS Trusted Advisor security, Amazon Macie, AWS Artifact, Shared responsibility model

Test mode:
Start practice test
SOA-C02 - Security and Compliance Example Questions

Test your knowledge of Security and Compliance

Question 1

A media streaming company hosts video transcoding servers in a private subnet (10.0.70.0/24) that must download source files from an S3 bucket via a Gateway VPC endpoint. The subnet uses a custom Network ACL with the following configuration: Inbound Rule 100: ALLOW TCP 443 from 10.0.0.0/16; Outbound Rule 100: ALLOW TCP 443 to 0.0.0.0/0; Rule *: DENY ALL (default). Security groups permit all HTTPS traffic. Route tables correctly direct S3-prefixed traffic to the Gateway endpoint. Transcoding jobs fail when attempting to download files from S3, with connection timeout errors in the application logs. VPC Flow Logs show outbound packets reaching S3 successfully, but response packets are rejected at the subnet boundary. The S3 service responds using source ports that vary based on the AWS region's S3 infrastructure. What Network ACL modification will restore S3 connectivity through the Gateway endpoint?

Correct Answer: Add an inbound rule allowing TCP ephemeral ports (1024-65535) from the S3 managed prefix list or AWS IP ranges

The correct answer is to add an inbound rule allowing TCP ephemeral ports (1024-65535) from the S3 managed prefix list or AWS IP ranges.

This is the correct solution because Network ACLs are stateless, meaning they do not automatically allow return traffic. When the transcoding servers make HTTPS requests to S3 on port 443, S3 responds using ephemeral ports (typically in the range 1024-65535) as the source port. The current inbound NACL configuration only allows TCP 443 from the VPC CIDR (10.0.0.0/16), which does not cover S3 response traffic coming through the Gateway VPC endpoint.

The VPC Flow Logs confirm this diagnosis - outbound packets reach S3 successfully, but response packets are rejected at the subnet boundary. This is classic stateless NACL behavior where the return traffic is being blocked.

The option suggesting adding an inbound rule for TCP 443 from the S3 prefix list is incorrect because S3 responses use ephemeral source ports, not port 443. The S3 service listens on port 443 but responds FROM ephemeral ports.

The option about adding an outbound rule for ephemeral ports is incorrect because the problem is with inbound traffic (response packets being rejected), not outbound traffic. The current outbound rule allowing TCP 443 to 0.0.0.0/0 is sufficient for the requests.

The option to modify the inbound rule to allow TCP 443 from 0.0.0.0/0 is incorrect for the same reason - S3 responses don't come from port 443, they come from ephemeral ports. Even with Gateway endpoints, the NACL must account for the stateless nature and allow ephemeral port responses.

Question 2

A SysOps Administrator at a logistics company is setting up Amazon CloudWatch Logs encryption for the first time. The team wants to encrypt log groups containing shipment tracking data but has limited budget and prefers minimal configuration overhead. When the Administrator navigates to the CloudWatch Logs console to enable encryption on a log group, they notice an option to use an AWS managed key. A team member asks whether they can use the AWS managed key (aws/logs) to encrypt CloudWatch Logs and what prerequisites exist for this approach. What should the Administrator explain about using AWS managed keys with CloudWatch Logs?

Correct Answer: CloudWatch Logs does not support AWS managed keys for encryption; a customer managed key must be created and configured with appropriate key policy permissions for the CloudWatch Logs service principal

CloudWatch Logs encryption requires the use of customer managed keys (CMK) and does not support AWS managed keys. This is a specific design decision by AWS for CloudWatch Logs.

When encrypting CloudWatch Logs log groups, you must:
1. Create a customer managed key in AWS KMS
2. Configure the key policy to grant the CloudWatch Logs service principal (logs..amazonaws.com) the necessary permissions (kms:Encrypt, kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey, kms:DescribeKey)
3. Associate the customer managed key with the log group using the AWS CLI, API, or CloudFormation (the console can also be used)

Unlike many other AWS services that offer the convenience of AWS managed keys (like aws/s3 for S3 or aws/ebs for EBS), CloudWatch Logs specifically requires customer managed keys. This means there is no aws/logs AWS managed key available for use.

The other answers are incorrect because:

  • The option suggesting AWS managed keys are supported and created automatically is false - CloudWatch Logs does not have this capability, and no aws/logs managed key exists.

  • The answer mentioning a service-linked role requirement is incorrect - while CloudWatch Logs does require proper permissions, the encryption setup uses key policies on the CMK rather than a service-linked role for KMS access.

  • The suggestion about activating an aws/logs key in the KMS console is also incorrect - no such AWS managed key exists for CloudWatch Logs, and you cannot activate something that doesn't exist.

Question 3

A software development company runs a CI/CD pipeline in AWS. Build agents in subnet 10.0.80.0/24 pull source code from a Git server in subnet 10.0.90.0/24 over TCP port 22 (SSH). The build agents initiate connections using ephemeral source ports 49152-65535. Both subnets have custom Network ACLs. The build agent subnet's NACL has: Inbound Rule 100: ALLOW TCP 22 from 10.0.90.0/24; Outbound Rule 100: ALLOW TCP 22 to 10.0.90.0/24. The Git server subnet's NACL has: Inbound Rule 100: ALLOW TCP 22 from 10.0.80.0/24; Outbound Rule 100: ALLOW TCP 22 to 10.0.80.0/24. Security groups on both tiers permit SSH traffic bidirectionally. Build jobs fail with 'Connection timed out' errors when attempting to clone repositories. Network packet captures show that SSH connection requests from build agents reach the Git server, and the server generates response packets from source port 22 to the agents' ephemeral destination ports. These response packets successfully leave the Git server subnet but are dropped when entering the build agent subnet. What is preventing the SSH responses from reaching the build agents?

Correct Answer: The build agent subnet's NACL lacks an inbound rule allowing TCP traffic from 10.0.90.0/24 on the ephemeral port range 49152-65535

The correct answer is that the build agent subnet's NACL lacks an inbound rule allowing TCP traffic from 10.0.90.0/24 on the ephemeral port range 49152-65535.

Network ACLs are stateless, meaning they do not automatically allow return traffic. When the build agents initiate SSH connections to the Git server, they use ephemeral source ports (49152-65535) and connect to destination port 22 on the Git server.

The connection flow works like this:
1. Build agent sends packet: Source port (ephemeral 49152-65535) → Destination port 22 on Git server
2. Git server responds: Source port 22 → Destination port (the same ephemeral port the client used)

The problem states that response packets successfully leave the Git server subnet but are dropped when entering the build agent subnet. This pinpoints the issue to the build agent subnet's inbound NACL rules.

Looking at the build agent subnet's NACL:
- Inbound Rule 100: ALLOW TCP 22 from 10.0.90.0/24
- Outbound Rule 100: ALLOW TCP 22 to 10.0.90.0/24

The inbound rule only allows traffic on port 22, but the return traffic from the Git server comes FROM port 22 TO the ephemeral ports (49152-65535). The NACL evaluates the destination port of incoming packets, and since there's no rule allowing inbound traffic to ephemeral ports, these response packets are dropped.

The other answers are incorrect because:

  • The Git server subnet's NACL outbound rule already allows the response packets to leave (the problem confirms packets successfully leave the Git server subnet).

  • The build agent subnet's outbound rule for ephemeral ports is not needed because outbound SSH requests go TO port 22, not from ephemeral ports as the destination.

  • The Git server subnet doesn't need an inbound rule for ephemeral ports because the initial SSH connection comes in on port 22, which is already allowed.

More Security and Compliance questions
1764 questions (total)
Start 100 question test