CertifyDeckCargando contenido…
The official AWS Certified Solutions Architect - Associate syllabus, organized by domain. Check off each point as you review it.
Inicia sesión para guardar tu progreso entre sesiones.
Design secure access to AWS resources
Use the root user only for tasks that require it: protect it with phishing-resistant MFA and several devices, never create root access keys, and use a group email address. In AWS Organizations you can centralize root access and delete root credentials from member accounts. To require MFA for API calls, use the aws:MultiFactorAuthPresent condition with temporary STS credentials.
Root user best practices for your AWS account ↗Secure API access with MFA ↗
Put users in IAM groups (which cannot be nested or used as a Principal) and use reusable managed policies instead of one-to-one inline policies. To scale permissions without editing policies, apply ABAC with tags on principals and resources. To delegate role creation, require a permissions boundary that sets the maximum; workloads on EC2 use roles through instance profiles.
Define permissions based on attributes with ABAC authorization ↗Permissions boundaries for IAM entities ↗
For cross-account access, create a role in the trusting account whose trust policy names the other account or principal, and grant that principal sts:AssumeRole; switching to a role sets aside your own permissions and returns temporary credentials. Require an external ID from third parties that serve many customers to prevent the confused deputy problem, and give each ECS task its own role.
Access for an IAM user in another AWS account that you own ↗Access to AWS accounts owned by third parties ↗
AWS Control Tower builds a multi-account landing zone, provisions accounts with Account Factory and applies controls to whole OUs: preventive (SCPs, RCPs), detective (AWS Config rules) and proactive (CloudFormation hooks). SCPs limit principals in member accounts, including the root user, and RCPs limit access to their resources by external principals; neither grants permissions or affects the management account.
Control behavior and guidance ↗Service control policies (SCPs) ↗
Resource-based policies (S3 bucket, SQS queue, SNS topic, Lambda function, KMS key) state which principals or services can use the resource. Use aws:PrincipalOrgID to grant access to a whole organization and aws:SourceVpce to limit a bucket to one endpoint. Cross-account access needs an Allow on both sides, and a KMS key always needs permission in its key policy.
Cross account resource access in IAM ↗Key policies in AWS KMS ↗
Federate the corporate directory instead of creating IAM users: with SAML 2.0, employees assume roles through AssumeRoleWithSAML, and in multi-account environments IAM Identity Center uses Active Directory (through AD Connector or AWS Managed Microsoft AD) as its identity source. Directory attributes can be passed as session tags for ABAC, and mobile app users get temporary credentials from Cognito identity pools.
Design secure workloads and applications
Security groups are the primary control: they are stateful, support only allow rules and can reference other groups. Network ACLs act at the subnet level, are stateless (responses must also be allowed) and support deny rules evaluated by number. A public NAT gateway in a public subnet gives private subnets outbound IPv4 access without allowing inbound connections; for IPv6, use an egress-only internet gateway.
Use separate VPCs to isolate workloads or organizational units, and subnets to separate application tiers. Routing decides the subnet type: public with a route to an internet gateway, private without one, VPN-only, or isolated with no routes outside the VPC. Each subnet lives in one AZ, load balancers reach targets on private IPs, and gateway endpoints give access to S3 without NAT.
Subnets for your VPC ↗Infrastructure security in Amazon VPC ↗
AWS WAF filters HTTP(S) requests on CloudFront, ALB or API Gateway, for example against SQL injection; Shield Standard protects at no extra cost against network and transport DDoS, and Shield Advanced adds layer 7 mitigation, a response team and cost protection. Secrets Manager replaces hard-coded credentials and rotates them. Macie finds sensitive data in S3, GuardDuty detects threats and Inspector finds vulnerabilities.
AWS Shield Advanced capabilities and options ↗What is AWS Secrets Manager? ↗
Site-to-Site VPN connects on-premises networks with IPsec tunnels (two per connection; add a second customer gateway for redundancy), and Client VPN gives individual users TLS access. Direct Connect is a dedicated link that bypasses internet providers, with private interfaces to the VPC and public ones to services such as S3, but it does not encrypt by default: use private IP VPN over it or point-to-point MACsec.
Encryption in AWS Direct Connect ↗What is AWS Site-to-Site VPN? ↗
Determine appropriate data security controls
AWS Artifact provides AWS compliance reports and lets you accept agreements such as the BAA for a whole organization. AWS Config records configuration history and, with conformance packs, deploys rules and remediation as one unit; CloudTrail records who performed each action and Amazon Macie discovers sensitive data in S3.
Managing agreements in AWS Artifact ↗Conformance Packs for AWS Config ↗
EBS encryption by default is a per-Region setting that encrypts new volumes. In S3, SSE-KMS with a customer managed key lets you control the key policy and share across accounts, and an S3 Bucket Key reduces calls to KMS. EFS and RDS are encrypted only at creation: replicate to a new file system or restore from an encrypted snapshot copy.
Encrypting Amazon RDS resources ↗Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys ↗
An ALB HTTPS listener with an ACM certificate terminates TLS on the load balancer; if TLS must be decrypted on the targets, use an NLB with a TCP listener on port 443. In S3, reject unencrypted traffic with aws:SecureTransport, and in CloudFront enforce HTTPS with the viewer and origin protocol policies.
Listeners for your Network Load Balancers ↗Use HTTPS with CloudFront ↗
The key policy is the primary control for a KMS key: unless it enables IAM policies, they grant no access. It separates key administrators (manage, cannot encrypt) from key users (cryptographic operations). Cross-account access needs permission in the key policy and in IAM in the other account, and kms:ViaService limits use to a given service.
Default key policy - AWS KMS ↗Allowing users in other accounts to use a KMS key ↗
AWS Backup centralizes backup plans across services and copies backups to other Regions and accounts in the organization; Vault Lock in compliance mode stops anyone, even the root user, from deleting backups. S3 replication requires versioning and copies only new objects unless S3 Batch Replication is used. DynamoDB point-in-time recovery always restores to a new table.
S3 Lifecycle moves objects between storage classes and deletes them when they expire. Object Lock in compliance mode prevents deletes and overwrites, even by the root user; governance mode allows exceptions. Block Public Access and Object Ownership set to Bucket owner enforced control S3 access, and Lake Formation filters columns and rows in the data lake.
Locking objects with Object Lock ↗Data filtering and cell-level security in Lake Formation ↗
KMS automatic rotation creates new key material without changing the logical key and decrypts older data with its original material. ACM renews only the certificates it issues, automatically with DNS validation; imported certificates are tracked with EventBridge events and reimported. Secrets Manager rotates database credentials that the application reads at runtime.
Rotate AWS KMS keys ↗Managed certificate renewal in AWS Certificate Manager ↗