Specialist security certification validating AWS security architecture, data protection, and compliance expertise.
Amazon GuardDuty, Amazon Detective, AWS Security Hub, Amazon EventBridge, Incident Response Automation, AWS Systems Manager Incident Manager
AWS CloudTrail, Amazon CloudWatch Logs, VPC Flow Logs, AWS Config, Amazon Athena Log Analysis, Amazon OpenSearch Service
Amazon VPC Security, AWS WAF, AWS Shield, AWS Network Firewall, AWS PrivateLink, Edge Security & CloudFront
AWS IAM Policies, AWS IAM Identity Center, Amazon Cognito, AWS Organizations SCPs, Federation & SAML, Permission Boundaries
AWS KMS, AWS CloudHSM, AWS Certificate Manager, Amazon Macie, S3 Encryption & Bucket Policies, AWS Secrets Manager
AWS Organizations, AWS Control Tower, AWS Audit Manager, AWS Trusted Advisor, Compliance Frameworks, AWS Artifact
Try real exam-style questions from the free sample set. Each answer comes with a full explanation.
A global financial services company's security team wants to configure multiple workload account applications to access an S3 bucket in a central data account within an AWS Organizations environment.
The IAM roles in the workload accounts have been granted S3 access permissions, but access errors are occurring during actual access attempts. The security team wants to resolve this issue while maintaining the principle of least privilege and minimizing operational overhead.
What MUST be additionally configured to correctly allow cross-account S3 access in this situation?
Answer: A. S3 bucket policy, allow cross-account Principal
For cross-account S3 access, AWS requires explicit Allow in both the requestor-side IAM policy and the resource-side S3 bucket policy. Even if the IAM role in the workload account has S3 permissions, an access error will occur if the central account's S3 bucket policy does not explicitly allow the workload account Principal. Adding the cross-account Principal (workload account IAM role ARN or account ID) to the S3 bucket policy is mandatory.
The S3 bucket policy is a resource-based policy. For a Principal from another account to access the bucket, explicit Allow must be present in that bucket policy. In an Organizations environment, you can specify the account ID or IAM role ARN as the Principal in individual bucket policies to maintain least privilege.
On the exam, cross-account S3 errors are always caused by a missing bucket policy. S3 ACLs are a legacy mechanism making least privilege management difficult, SCPs are for restrictions not grants, and IAM policies alone cannot enable cross-account S3 access.
A global energy company's security team has a security requirement to immediately block all developers in an IAM group from creating and modifying AWS resources outside a specific region. However, access to globally classified services such as IAM, CloudFront, and Route 53 must continue to be allowed.
Which IAM policy configuration BEST allows applying a bulk restriction to the entire group without modifying individual user policies, while handling global service exceptions?
Answer: B. IAM group policy, aws:RequestedRegion Deny, global services excluded with NotAction
The two key conditions in this scenario are: the restriction must apply to the entire IAM group at once, and global services (IAM, CloudFront, Route 53) must be exempted. Using NotAction with the aws:RequestedRegion condition in an IAM group policy allows you to block all requests outside a specific region except for the listed global service actions. This is the most direct approach for immediately enforcing group-level restrictions without touching individual user policies.
In an IAM group policy Deny statement, NotAction excludes only the listed global service actions, applying the region-condition Deny to all other actions. The aws:RequestedRegion condition key filters based on the AWS region the request is directed to, and since global services do not target a specific region, explicit exclusion via NotAction is necessary.
In the exam, it is easy to confuse SCPs with IAM group policies. SCPs apply at the AWS Organizations hierarchy level and cannot be directly attached to IAM groups, and Permission Boundaries only define the maximum allowed scope and are not suitable for bulk group blocking.
A global software company's security team needs to allow the development team to directly create IAM roles and users for CI/CD pipelines, while centrally controlling that the IAM principals created by the development team cannot exceed the maximum permission scope defined by the security team. The goal is to prevent privilege escalation where the development team could create roles with near-administrator permissions and assign them to pipelines, while maintaining the development team's autonomy.
Which access control approach BEST allows the security team to centrally manage maximum permission guardrails while permitting the development team to create IAM principals?
Answer: B. IAM permissions boundary, grant condition for development team role creation
A software company's security team needs to centrally control the maximum permission ceiling while ensuring the development team's autonomy in creating IAM resources. IAM permissions boundary defines the maximum permission limit an IAM principal can have, so even if the development team creates a role with powerful permissions, any permissions exceeding the boundary will not actually be applied. By having the security team centrally manage the boundary policy and requiring the development team to attach this boundary when creating roles, privilege escalation can be prevented while maintaining team autonomy.
IAM permissions boundary is applied alongside identity-based policies, and only the intersection of both policies becomes the effective permissions. This means even if the development team attaches AdministratorAccess-level policies to a role, permissions not included in the boundary are automatically blocked. Unlike SCPs, the key characteristic is that it applies at the individual IAM principal level rather than to the entire account.
In exams, SCPs and permissions boundary are easy to confuse. SCPs apply at the AWS Organizations level to entire accounts, while permissions boundary applies to individual IAM principals. When the scenario involves limiting IAM creation scope for a specific development team, choose permissions boundary; when restricting service usage across an entire organizational account, choose SCP.
A global consulting company security team must restrict access so that external partner IAM users can only upload objects to designated S3 buckets during a specific contract period. Access must be automatically blocked when the contract period ends, and they want to implement this without operations teams manually modifying policies.
Which is the MOST appropriate approach to allow S3 PutObject only during a specific period using time conditions in IAM identity-based policies?
Answer: C. IAM policy, aws:CurrentTime condition Allow
The most critical condition in this scenario is automatic access blocking using time conditions in IAM identity-based policies. Adding aws:CurrentTime conditions (DateGreaterThan/DateLessThan) to an IAM Allow policy allows S3 PutObject only during the specified period, and after the period ends, the condition is not met, resulting in implicit Deny. This approach is the most concise way to implement automatic blocking without separate operational work.
The aws:CurrentTime condition is an IAM global condition context key that compares dates and times in ISO 8601 format. Specifying the start time with DateGreaterThan and the end time with DateLessThan allows only requests within that window to pass. When this condition is applied to an Allow statement, the policy does not apply when the condition is not met, denying access unless there is another Allow.
In exams, when automatic time-based access control appears, choose aws:CurrentTime condition Allow. Applying conditions to Deny statements reverses the logic and complicates management, and STS session expiration is suitable for short sessions (up to 12 hours), making it unsuitable for long-term contract control.
A development team at a global media company is experiencing an issue where small file uploads to an SSE-KMS encrypted S3 bucket succeed normally, but large file uploads fail with permission errors. The Lambda function's execution role has kms:GenerateDataKey permission granted.
What is the cause of this error, and what additional KMS permission is required during the multipart upload process for large files?
Answer: A. Missing kms:Decrypt permission
The difference between small and large file uploads in multipart upload lies in KMS permission requirements. Small file single PUT uploads can encrypt using only kms:GenerateDataKey to create a data key, but during the CompleteMultipartUpload phase of multipart uploads, S3 requires kms:Decrypt permission to decrypt the encrypted data keys for each part. Since the Lambda execution role lacks kms:Decrypt, large file uploads fail.
SSE-KMS multipart upload consists of three phases. First, CreateMultipartUpload generates the data key, then each part is sent via UploadPart, and finally CompleteMultipartUpload merges all parts into a single object. In this final phase, S3 must decrypt the encryption key information for each part to regenerate the DEK (Data Encryption Key) for the final object, which requires kms:Decrypt.
On the exam, when SSE-KMS permission errors appear, distinguish between single PUT vs. multipart upload. For single uploads, kms:GenerateDataKey is sufficient; for multipart, both kms:GenerateDataKey and kms:Decrypt are required.
The AWS Certified Security - Specialty (SCS-C03) exam consists of 65 questions with a 170-minute time limit.
The passing score for the SCS-C03 exam is 750 out of 1000.
The SCS-C03 sample set (20 questions with full explanations) is free. The full bank of 340+ questions is available with a CloudMasterIT subscription.
The SCS-C03 certification is valid for 3 years after passing. Recertification is required after that.