AWS SAA-C03 Domain 1: Secure Architectures Complete Guide

When you begin preparing for the AWS Certified Solutions Architect – Associate (SAA-C03) exam, the first wall most candidates hit is Domain 1: Design Secure Architectures. It carries 30 percent of the scored content, the largest of the four domains, so weakness here puts the whole exam at risk.

Many people try to clear Domain 1 by memorizing IAM service names, and they fail. SAA-C03 security questions do not ask whether you know IAM. They ask which authentication model and which encryption approach you would choose for a stated requirement. The exam rewards design judgment, not recall.

This guide frames the core of AWS secure design as a repeatable set of three parts: a typical scenario, the deciding factor, and the common pitfall. The aim is to get you past that exam-day moment when you have narrowed four options to two and still hesitate.

Why Domain 1 is the make-or-break domain

The SAA-C03 format is 65 questions in 130 minutes, with a scaled passing score of 720 on a 100 to 1000 scale. Of those questions, 50 are scored and 15 are unscored items used for future exam development. Domain weights are: Domain 1 Design Secure Architectures 30 percent, Domain 2 Design Resilient Architectures 26 percent, Domain 3 Design High-Performing Architectures 24 percent, and Domain 4 Design Cost-Optimized Architectures 20 percent. Because Domain 1 is 30 percent, it maps to roughly 15 of the 50 scored questions.

IAM design judgment: User, Group, Role, and Policy

Start from the principle of least privilege. Attach permissions to groups rather than individual users, and prefer roles over long-lived access keys for any workload running on AWS, such as EC2, Lambda, or ECS tasks. Roles deliver short-lived credentials automatically, which removes the risk of leaked static keys. Protect the root user with MFA and use it almost never.

Deciding factor: if a question describes an application on AWS that needs to call another AWS service, the correct answer is almost always an IAM role, not an access key stored in code or configuration.

Temporary credentials: STS, AssumeRole, and federation

AWS STS issues temporary credentials made of an access key id, a secret access key, and a session token. Use AssumeRole for role switching inside an account and for cross-account access, and use federation such as IAM Identity Center or SAML and OpenID Connect so corporate or web identities never need standalone IAM users. Keep session duration short, default to one hour, and extend only when necessary.

Pitfall: when an external party assumes a role in your account, require an ExternalId to prevent the confused deputy problem, and require MFA where the scenario allows it.

Cross-account access and resource-based policies

There are two ways to grant access across accounts. Use a role with a trust policy when the external principal should assume an identity in your account, and use a resource-based policy, for example an S3 bucket policy or an SQS queue policy, when you want to grant access directly on the resource. Resource-based policies let a principal in account A act on a resource in account B without switching roles.

Permission evaluation logic: explicit Deny, SCP, and permission boundaries

Memorize the order. An explicit Deny in any applicable policy always wins and can never be overridden. After that, the request is allowed only if every applicable policy type allows it: the identity-based policy, any Service Control Policy in AWS Organizations, and any permission boundary. The effective permission is the intersection of all of them. SCPs do not grant permissions; they set a maximum guardrail. A permission boundary sets the maximum an entity can ever have, which is ideal when you let developers create their own roles.

Data protection: choosing the right KMS key

Encrypt data at rest with AWS KMS and data in transit with TLS using AWS Certificate Manager. The key choice is the deciding factor. AWS managed keys are free and rotate automatically every year, but you cannot edit their policy or rotation. Customer managed keys cost a monthly fee per key and give you full control of the key policy, grants, enable and disable, and optional automatic rotation with a configurable period. Choose customer managed keys when the scenario demands strict governance, custom key policies, or cross-account key use.

Secrets management: Secrets Manager vs Parameter Store

The single deciding factor is automatic rotation. AWS Secrets Manager costs about 0.40 USD per secret per month and provides built-in automatic rotation, including native integration that rotates database credentials for RDS, Aurora, Redshift, and DocumentDB on a schedule with no downtime. Systems Manager Parameter Store offers free standard parameters and advanced parameters at about 0.05 USD per month, but it does not rotate secrets. Use Parameter Store for plain configuration and feature flags; use Secrets Manager when credentials must rotate regularly.

Network-layer security: security groups, NACLs, and defense in depth

Security groups are stateful and operate at the instance level, allowing return traffic automatically and supporting allow rules only. Network ACLs are stateless and operate at the subnet level, evaluate numbered rules in order, and support both allow and deny, which makes them the right tool for blocking a specific IP range. Combine them as layers, place workloads in private subnets, and add Shield for DDoS and WAF for application-layer filtering at the edge.

Detection and audit: CloudTrail, GuardDuty, and Config

Keep their roles distinct. CloudTrail is the audit trail that answers who called which API and when. AWS Config answers what the current configuration of a resource is and how it has changed over time, and it evaluates resources against compliance rules. Amazon GuardDuty is intelligent threat detection that continuously analyzes CloudTrail, VPC Flow Logs, and DNS logs for malicious behavior. On the exam, match the verb in the question: audit trail points to CloudTrail, configuration compliance points to Config, and threat detection points to GuardDuty.

Scenario practice: five typical questions

• An EC2 app must read from S3 without stored keys. Answer: attach an IAM role to the instance.
• A partner in another account needs temporary access. Answer: a cross-account role with a trust policy and an ExternalId.
• Database passwords must rotate every 30 days automatically. Answer: AWS Secrets Manager with native RDS rotation.
• You must block a single malicious IP range for a whole subnet. Answer: a deny rule in a network ACL, not a security group.
• Compliance requires a full record of configuration changes. Answer: AWS Config, complemented by CloudTrail for API history.

Summary: the Domain 1 checklist

• Prefer roles and temporary credentials over static access keys.
• Remember that an explicit Deny always wins and effective permissions are an intersection.
• Pick customer managed KMS keys when you need policy control or cross-account use.
• Reach for Secrets Manager only when automatic rotation is required.
• Use security groups for instance allow rules and NACLs for subnet deny rules.
• Map audit to CloudTrail, configuration to Config, and threats to GuardDuty.

References

AWS Certification official SAA-C03 exam guide and the AWS Identity and Access Management, AWS KMS, and AWS Organizations documentation.

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.