Security and Compliance: free practice questions

Using an IAM role with cross-account trust is the AWS-recommended pattern for granting external parties access. The auditors assume the role from their own account, receiving temporary STS credentials scoped to the read-only policy—no long-term credentials are needed. Creating an IAM user with an access key produces long-term credentials that must be managed and rotated, violating the requirement. AWS Artifact provides compliance documents, not live resource access. Sharing a console login URL and temporary password still involves long-term credentials and is not a scalable or secure practice for cross-account access.

AWS Certificate Manager (ACM) provisions, manages, and automatically renews public SSL/TLS certificates for use with AWS services like ALB, CloudFront, and API Gateway at no additional cost. AWS KMS manages encryption keys for data at rest and does not issue or manage SSL/TLS certificates. AWS Secrets Manager stores and rotates secrets such as database passwords and API keys, but it does not provision or renew public TLS certificates. AWS CloudHSM provides a dedicated hardware security module for custom key management and can be used for private certificate authorities, but it requires significant manual operational overhead and is not the purpose-built solution for automatic public certificate management.

The two highest-priority IAM best practices for a new account are: (1) enabling MFA on the root account to protect it from unauthorized access, and (2) creating a separate IAM administrative identity so the root account is not used for daily tasks. Option B is explicitly prohibited by AWS—root account access keys should never be created. Option D violates least privilege; not all users need administrative access. Option E violates individual accountability and is a severe security risk—root credentials must never be shared.

AWS WAF rate-based rules are specifically designed for this scenario. They count requests from individual IP addresses over a configurable time window and automatically block IPs that exceed the threshold, mitigating HTTP flood attacks even when many source IPs are involved. Option A (AWS Shield Standard) provides automatic protection against common DDoS infrastructure attacks but does not offer customizable rate-based rules for HTTP-layer floods. Option B (GuardDuty) detects threats and generates findings but does not automatically block traffic—it is a detection service, not a mitigation tool. Option D (AWS Network Firewall) can perform packet filtering but is not the purpose-built tool for HTTP rate limiting at the application layer; WAF is more appropriate for this use case.

Correct: 'Enable MFA on the AWS account root user' — the root user has unrestricted access to all resources, so enabling MFA immediately is a critical first step to protect it. Correct: 'Create individual IAM users for each person who needs AWS access' — creating individual IAM users allows unique credentials, individual permissions, and auditability for each person. | Wrong: 'Create IAM access keys for the root user' — AWS explicitly recommends never creating root user access keys; use IAM users or roles for programmatic access. | Wrong: 'Share the root user credentials' — credentials should never be shared; this violates the principle of least privilege and makes auditing impossible. | Wrong: 'Attach AdministratorAccess to every user' — this violates least privilege; users should receive only the permissions they need to perform their job functions.