Try 10 focused AWS SAA-C03 questions on Design Secure Architectures, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
| Field | Detail |
|---|---|
| Exam route | AWS SAA-C03 |
| Topic area | Design Secure Architectures |
| Blueprint weight | 30% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Design Secure Architectures for AWS SAA-C03. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 30% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Design Secure Architectures
A company has a single AWS account. Auditors found that the root user does not have MFA enabled and some administrators regularly sign in as the root user for daily tasks. The company wants to improve the security of the root user and administrative access without changing any application code. Which actions should a solutions architect recommend? (Select TWO.)
Options:
A. Create long-term access keys for the root user, store them in AWS Secrets Manager, and use these credentials for all administrative automation to avoid using the console.
B. Create an administrative IAM role that requires MFA by using the aws:MultiFactorAuthPresent condition key, and require administrators to sign in with individual IAM users and assume this role instead of using the root user.
C. Configure a strong IAM account password policy with complexity and expiration requirements for IAM users, and allow administrators to continue using the root user for critical tasks when needed.
D. Delete the AWS account root user password and remove all existing access keys to effectively disable the root user, and rely only on IAM users for all console and programmatic access.
E. Enable MFA for the root user, securely store the MFA device, and configure an Amazon CloudWatch alarm on AWS CloudTrail for any root user activity so that root is used only for break-glass situations.
Correct answers: B and E
Explanation: The scenario highlights two core problems: the root user does not have MFA enabled, and administrators are using the root user for daily tasks. AWS best practices state that the root user should be secured with MFA, tightly controlled, monitored, and used only for a small set of account- and billing-level tasks. Routine administration should be done with IAM roles and users, ideally protected by MFA.
The best response therefore combines hardening the root account itself (MFA and monitoring) with migrating daily administrative activity to non-root identities. This reduces blast radius, enforces least privilege, and directly addresses the audit findings without requiring any change to application code or programmatic access patterns.
Topic: Design Secure Architectures
Which of the following statements about designing AWS IAM permissions is NOT aligned with the principle of least privilege and AWS security best practices?
Options:
A. Define multiple IAM roles with narrowly scoped permissions tailored to specific applications or job functions.
B. Prefer attaching permissions to IAM roles and groups instead of directly to individual IAM users whenever possible.
C. Create a single IAM role with full access to all AWS services and share its credentials with the entire development team to simplify permission management.
D. Use IAM policy condition keys to further restrict when, where, or how granted permissions can be used.
Best answer: C
Explanation: Least privilege means granting only the permissions that are strictly necessary for a user, role, or service to perform its tasks, and nothing more. In AWS IAM, this is typically implemented by using narrowly scoped policies, attaching those policies to roles and groups rather than directly to individual users, and applying condition keys to further constrain how permissions can be used.
Creating a single, highly privileged role and sharing its credentials across a team is the opposite of least privilege. It makes it impossible to distinguish who did what, expands the blast radius of any credential compromise, and grants far more permissions than most users require.
In contrast, designing multiple roles with specific, limited permissions; centralizing permissions through roles and groups; and using IAM policy conditions are all recommended approaches that help implement least privilege and improve security posture.
Topic: Design Secure Architectures
Which statement correctly describes how a security group in an Amazon VPC controls network traffic?
Options:
A. A security group is a stateful virtual firewall attached to elastic network interfaces that allows only explicitly permitted inbound and outbound traffic, and automatically allows response traffic.
B. A security group is a managed web firewall that performs deep packet inspection and filters HTTP and HTTPS requests based on application-layer rules.
C. A security group is a regional routing configuration that determines the path packets take between subnets, internet gateways, and virtual private gateways.
D. A security group is a stateless firewall applied at the subnet boundary that supports both allow and deny rules and evaluates inbound and outbound traffic independently.
Best answer: A
Explanation: In an Amazon VPC, a security group acts as a stateful virtual firewall for your instances. It is attached to elastic network interfaces (ENIs) and uses only allow rules for inbound and outbound traffic. Because it is stateful, when you allow an inbound request, the corresponding response traffic is automatically allowed, even if there is no explicit outbound rule for that response, and vice versa.
This behavior is different from stateless controls such as network ACLs, which evaluate each packet against both inbound and outbound rules independently, and from routing components such as route tables, which determine where traffic goes rather than whether it is permitted. Security groups also differ from application-layer firewalls like AWS WAF, which inspect HTTP/HTTPS requests at Layer 7 rather than controlling basic IP and port access at the ENI level.
Topic: Design Secure Architectures
Which TWO statements are true regarding securing the AWS account root user and IAM users? (Select TWO.)
Options:
A. You should enable MFA for the AWS account root user and use the root user only for tasks that explicitly require root permissions.
B. To simplify administration, it is recommended to share the root user credentials among administrators instead of creating separate IAM users.
C. If an IAM user has not used its password recently, you should disable MFA for that user to reduce the chance of sign-in failures.
D. Because the root user has full access, signing in as the root user for everyday console work is considered an AWS security best practice.
E. Long-lived access keys for IAM users should be rotated regularly, and any unused access keys should be deactivated and deleted.
Correct answers: A and E
Explanation: Securing the AWS account root user and IAM users is foundational to a secure AWS environment. AWS recommends enabling MFA for the root user immediately after account creation and using the root user only when absolutely necessary. For IAM users, good credential hygiene includes regularly rotating access keys, disabling and deleting unused keys, and avoiding shared credentials.
Everyday administrative tasks should be performed using IAM users or federated identities with least-privilege permissions, not the root user. MFA is a critical control that adds a second factor to authentication and should be enabled, not removed, for sensitive identities.
Topic: Design Secure Architectures
A company uses AWS KMS customer managed keys to encrypt production data in multiple AWS accounts. Requirements are:
kms:* on all keys must be avoided.Which of the following proposed policy designs should you AVOID implementing? (Select TWO.)
Options:
A. Allow the production application IAM role to assume the SecurityAdmin role so the application can rotate, disable, and schedule deletion of its own KMS keys without human intervention.
B. Configure KMS key policies so that a SecurityAdmin role has kms:CreateKey, kms:EnableKeyRotation, kms:DisableKey, and kms:ScheduleKeyDeletion on production keys, and explicitly deny kms:Encrypt and kms:Decrypt for that role.
C. Attach an IAM policy to a DevOpsAdmin role that grants kms:* on all KMS keys in the account to simplify operations and avoid future access issues.
D. Grant the production application IAM role only kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey on specific KMS keys, and do not grant it kms:DisableKey or kms:ScheduleKeyDeletion.
E. Allow an Audit role to use kms:DescribeKey and kms:ListResourceTags on all keys and read CloudTrail logs, while explicitly denying kms:Encrypt, kms:Decrypt, and kms:ScheduleKeyDeletion for that role.
Correct answers: A and C
Explanation: The scenario emphasizes data security controls for AWS KMS keys, including least privilege, separation of duties, and restricting who can manage versus who can use keys. Key management operations (create, rotate, disable, schedule deletion) must be restricted to a security-focused role, while application roles should only perform cryptographic operations on specific keys. Auditors require visibility but no power to use or change keys. Very broad permissions such as kms:* on all keys are explicitly against the requirements.
The designs that must be avoided either grant excessively broad permissions over all keys or allow an application role to take over key administration, undermining separation of duties and potentially exposing production data to loss or misuse.
Topic: Design Secure Architectures
A company hosts a web application on EC2 instances in private subnets behind an internet-facing Application Load Balancer (ALB) in public subnets. Compliance requires that only a partner’s IP range (203.0.113.0/24) can ever reach the application from the internet, even if an ALB security group is accidentally made too permissive. Which design meets this requirement BEST?
Options:
A. Modify the public subnet route tables to include a route for 203.0.113.0/24 and remove the 0.0.0.0/0 internet route so only the partner CIDR is routable to the ALB.
B. Restrict the ALB security group inbound rules to only allow 203.0.113.0/24 on port 443; leave the public subnet network ACLs with the default “allow all” rules.
C. Configure a custom network ACL on the public subnets that allows inbound 203.0.113.0/24 on port 443 and denies all other inbound HTTP/HTTPS traffic; keep the ALB security group allowing 0.0.0.0/0 on port 443.
D. Attach an AWS WAF web ACL to the ALB that allows only 203.0.113.0/24 and denies all other IP addresses; keep the public subnet network ACLs open to the internet.
Best answer: C
Explanation: The key discriminating factor in this scenario is that the partner IP restriction must be enforced even if a security group is accidentally made too permissive. That means the control cannot rely solely on the security group attached to the ALB or instances; it needs a separate, lower-level network control at the VPC subnet layer.
Network ACLs (NACLs) operate at the subnet level and are stateless. They can explicitly allow and deny traffic based on source IP, protocol, and port. By configuring a NACL on the public subnets that host the ALB to allow only the partner CIDR 203.0.113.0/24 on port 443 and deny all other HTTP/HTTPS traffic, you ensure that only the partner’s IP range can ever reach the ALB, regardless of future security group misconfigurations.
Security groups are still important and should be configured correctly, but in this case the compliance requirement explicitly asks for protection even when a security group is misconfigured. Route tables cannot filter traffic by IP; they only determine the next hop. AWS WAF works at the application layer and is not a substitute for the required subnet-level, defense-in-depth network control.
The best design therefore layers a restrictive network ACL on the public subnets with standard security group rules, providing defense in depth and meeting the compliance requirement.
Topic: Design Secure Architectures
Which of the following statements about Amazon GuardDuty is INCORRECT?
Options:
A. Amazon GuardDuty is a threat detection service that continuously monitors AWS accounts and workloads for malicious activity.
B. Amazon GuardDuty requires you to deploy and manage security agents on each Amazon EC2 instance that you want to monitor.
C. Amazon GuardDuty can be centrally managed across multiple AWS accounts using AWS Organizations.
D. Amazon GuardDuty analyzes data from AWS CloudTrail event logs, VPC Flow Logs, and DNS logs to generate security findings.
Best answer: B
Explanation: Amazon GuardDuty is a fully managed, intelligent threat detection service that analyzes AWS data sources such as CloudTrail events, VPC Flow Logs, and DNS logs to identify suspicious or malicious activity. It operates at the account and Region level, does not require host-based agents, and supports centralized administration across multiple accounts through AWS Organizations.
The incorrect statement is the one claiming that GuardDuty requires deployment and management of agents on each EC2 instance. That describes a host-based intrusion detection model, while GuardDuty is a service-level, log-based detection system that requires only that the relevant log sources be available in the account (GuardDuty enables and consumes them internally; you do not manage agents yourself).
Topic: Design Secure Architectures
A company is deploying a containerized microservices application on Amazon ECS with separate development, staging, and production environments. The services need to access database credentials and third-party API keys, and also require non-sensitive settings such as feature flags and timeout values. Security policies require that credentials are never stored in source code or container images and can be rotated automatically without redeploying the services. The solution should minimize operational overhead and cost for managing non-sensitive configuration while keeping environments logically separated. Which solution BEST meets these requirements?
Options:
A. Store database credentials and API keys in AWS Secrets Manager with automatic rotation enabled and separate secrets per environment, and store non-sensitive configuration in AWS Systems Manager Parameter Store, with ECS task IAM roles retrieving all values at runtime.
B. Encrypt all secrets and configuration into JSON files stored in an S3 bucket using an AWS KMS key, and configure the containers to download and decrypt the files at startup whenever a new image is deployed.
C. Store all secrets and configuration values as AWS Secrets Manager secrets, use separate secrets for each environment, and grant ECS task IAM roles access to retrieve values at runtime.
D. Define all credentials and configuration as encrypted environment variables in ECS task definitions using AWS KMS, and update the task definitions whenever a secret changes so that new tasks use the updated values.
Best answer: A
Explanation: Using AWS Secrets Manager for sensitive credentials with automatic rotation and separate secrets per environment, combined with AWS Systems Manager Parameter Store for non-sensitive configuration, provides secure, low-operations, and cost-aware configuration management that keeps secrets out of code and allows rotation without redeploying workloads.
Topic: Design Secure Architectures
A company uses AWS IAM Identity Center in a centralized security account. Security engineers must read CloudTrail logs and AWS Config data in multiple production accounts without using long‑lived credentials and while following least privilege. Which solutions meet these requirements? (Select TWO.)
Options:
A. In the security account, create an IAM role with read‑only permissions to CloudTrail and AWS Config in all production accounts and configure the role’s trust policy to trust each production account root; have engineers assume this role in the security account.
B. In each production account, create an IAM role (for example, SecurityAuditRole) with read‑only permissions to CloudTrail and AWS Config, and a trust policy that allows the IAM Identity Center federated principal in the security account to assume the role using AWS STS.
C. In each production account, create an IAM user with a SecurityAudit policy, generate access keys, and store the keys in a shared password manager for the security engineers to use when needed.
D. Use AWS Organizations with AWS IAM Identity Center to provision a SecurityAudit permission set that creates IAM roles in each member production account, trusted by the Identity Center instance, and assign this permission set to the security engineers.
E. Enable CloudTrail integration with CloudWatch Logs in each production account and use VPC peering so security engineers in the security account can connect to CloudWatch Logs endpoints in those VPCs to view trails and AWS Config data.
Correct answers: B and D
Explanation: The scenario calls for a cross‑account, role‑based access pattern using AWS STS and centralized identities from AWS IAM Identity Center. The production accounts own the CloudTrail and AWS Config resources, so any IAM roles granting access must be created in those production accounts. Their trust policies should allow principals from the central security account (via IAM Identity Center federation) to assume them. This produces temporary STS credentials instead of long‑lived keys and can be scoped to read‑only permissions for least privilege.
AWS IAM Identity Center can manage this either directly through manually created roles with appropriate trust policies, or automatically via permission sets integrated with AWS Organizations. In both cases, the key pattern is: users sign in centrally, then assume roles in the target accounts via STS.
Topic: Design Secure Architectures
A company uses Microsoft Entra ID (Azure AD) for all employees and has 50 AWS accounts in an AWS Organizations structure. Security requires centrally managed SSO access across all accounts from a single place and strictly no long-lived IAM users. Which solution BEST meets these requirements?
Options:
A. Use AWS IAM Identity Center with the built-in Identity Center directory, create local users and groups there, and assign them permission sets for each AWS account.
B. Configure SAML federation directly from Azure AD to IAM roles defined separately in each AWS account, managing role mappings on a per-account basis.
C. Use AWS IAM Identity Center integrated with Azure AD via SAML as the identity source, and assign permission sets that create roles in each AWS account for federated access.
D. Create IAM users in a central security account, attach IAM policies, and share access keys with teams who need to access other AWS accounts.
Best answer: C
Explanation: The scenario focuses on centralized SSO and access management across many AWS accounts while avoiding long-lived IAM users and still using the existing corporate IdP.
AWS IAM Identity Center is designed for multi-account access management. When you integrate an external IdP such as Microsoft Entra ID (Azure AD) via SAML and set it as the identity source, users authenticate with the IdP and then are granted short-lived, role-based sessions in AWS accounts based on permission sets.
Permission sets in IAM Identity Center are defined once and then applied to multiple accounts, where they are materialized as IAM roles. This allows administrators to centrally manage which Azure AD users and groups can assume which roles in which accounts, without creating or managing any IAM users or their long-lived access keys.
Other options either depend on long-lived IAM users, fragment access management across accounts, or fail to use the corporate IdP as the source of identity, so they do not fully meet the stated requirements.
Use the AWS SAA-C03 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try AWS SAA-C03 on Web View AWS SAA-C03 Practice Test
Read the AWS SAA-C03 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.