AWS Certified Solutions Architect – Associate — All Questions
The figures these questions turn on, pooled by value and printable, with a side to write them from memory: the cram packet, $6.99 →
109 questions
An application running on EC2 instances needs to read objects from an S3 bucket. What is the most secure way to grant this access?
- a.Store long-lived credentials in a file on the instance
- b.Make the S3 bucket public and filter by source IP
- c.Attach an IAM role to the EC2 instances with a policy granting least-privilege S3 read access✓
- d.Embed an IAM user's access keys in the application code
IAM roles provide temporary, automatically rotated credentials to EC2 instances via the instance metadata service, eliminating the need to store long-lived keys. Scoping the role's policy to only the required bucket and actions follows the principle of least privilege. Hard-coded access keys and public buckets create serious security risks and violate the Security pillar of the Well-Architected Framework.
A company must encrypt data at rest in S3 while retaining full control over the key material, key rotation policy, and the ability to audit every key usage via CloudTrail. Which option best meets this requirement?
- a.Client-side encryption with a hard-coded static key
- b.Server-side encryption with Amazon S3 managed keys (SSE-S3)
- c.Server-side encryption with AWS KMS customer managed keys (SSE-KMS)✓
- d.No encryption, relying on bucket policies only
SSE-KMS with a customer managed key lets you define rotation, key policies, and grants while logging each decrypt/encrypt call in CloudTrail for auditing. SSE-S3 encrypts data but gives you no control over or visibility into the key. Bucket policies control access but do not encrypt data at rest.
A web application behind an Application Load Balancer is being targeted by SQL injection and cross-site scripting attempts at the HTTP layer. Which service should be added to filter this malicious traffic?
- a.A network ACL on the public subnet
- b.Amazon GuardDuty
- c.AWS WAF with managed rule groups✓
- d.AWS Shield Standard
AWS WAF inspects HTTP/HTTPS requests and can block SQL injection and XSS using AWS managed rule groups attached to the ALB. Shield Standard protects against network/transport-layer DDoS, not application-layer exploits. NACLs operate on IP/port and cannot parse request content.
An RDS database must be reachable only from application servers in a private subnet and never from the internet. Which configuration achieves this?
- a.Open the database security group to 0.0.0.0/0 on port 3306
- b.Place the database in a private subnet and set its security group to allow inbound traffic only from the application tier's security group✓
- c.Attach an internet gateway route to the database subnet
- d.Place the database in a public subnet with an Elastic IP
Deploying RDS in a private subnet with no route to an internet gateway keeps it unreachable from the internet. Referencing the application tier's security group as the source in the database security group restricts access to just those instances, following least privilege. Opening 0.0.0.0/0 or using public subnets would expose the database.
An application needs to retrieve database credentials at runtime, and the credentials must be automatically rotated on a schedule. Which service is purpose-built for this?
- a.AWS Secrets Manager✓
- b.Amazon S3 with encryption
- c.AWS Systems Manager Parameter Store standard parameters
- d.IAM instance profile tags
Secrets Manager stores credentials encrypted with KMS and provides native automatic rotation, including built-in integration with RDS to rotate database passwords. Standard Parameter Store parameters can hold secrets but do not offer managed rotation. Storing credentials in S3 or tags is insecure and lacks rotation.
A mobile and web application needs user sign-up, sign-in, and federated identity with Google and Apple, returning tokens the app can use to call an API. Which service should be used?
- a.Amazon Cognito user pools with identity federation✓
- b.AWS KMS
- c.AWS IAM users, one per end user
- d.AWS Directory Service
Amazon Cognito user pools provide managed user directories, sign-up/sign-in flows, and federation with social and enterprise identity providers, issuing JWT tokens for authorizing API calls. Creating an IAM user per application end user does not scale and is not intended for app-user authentication. KMS handles encryption keys, not identity.
A security team wants to allow developers to launch EC2 instances but must ensure they cannot detach or modify IAM policies. Which approach follows AWS best practice?
- a.Grant developers the AdministratorAccess managed policy
- b.Attach a least-privilege IAM policy granting only the specific EC2 actions needed, with no IAM write permissions✓
- c.Give every developer full IAM permissions and monitor with CloudTrail
- d.Share the root account credentials for convenience
Least privilege means granting only the specific permissions required for the task, so a scoped policy allowing EC2 launch actions without IAM write access is correct. AdministratorAccess and root credentials violate least privilege and separation of duties. Monitoring after over-permissioning does not prevent misuse.
An application in Account A must read objects from an S3 bucket owned by Account B. What is the recommended way to grant this cross-account access?
- a.Define an IAM role in Account B that trusts Account A, and have the application assume it via STS for temporary credentials✓
- b.Make the bucket public so any account can read it
- c.Create an IAM user in Account B and email its access keys to Account A
- d.Copy the bucket's KMS key material into Account A
Cross-account access is best implemented with an IAM role in the resource-owning account (B) whose trust policy allows the calling account (A) to assume it, returning temporary STS credentials scoped to least privilege. Sharing long-lived access keys or making the bucket public violates security best practices, and KMS key material cannot be exported.
A compliance rule requires that every object uploaded to an S3 bucket must be encrypted, and any unencrypted upload must be rejected. How can this be enforced?
- a.Turn on S3 Transfer Acceleration
- b.Attach a bucket policy that denies s3:PutObject requests lacking the required server-side encryption header✓
- c.Enable S3 versioning on the bucket
- d.Rely on IAM policies attached to each individual user
A bucket policy with an explicit Deny on PutObject when the encryption header/condition is absent rejects any unencrypted upload at the bucket level, enforcing the requirement uniformly regardless of who uploads. Versioning protects against overwrite, Transfer Acceleration only speeds uploads, and per-user IAM policies do not guarantee bucket-wide enforcement.
An organization with dozens of AWS accounts must prevent any account from disabling CloudTrail or using unapproved Regions, as a guardrail that even account administrators cannot override. Which feature enforces this centrally?
- a.A permissions boundary on one IAM user
- b.Service Control Policies (SCPs) applied through AWS Organizations✓
- c.Tagging each account
- d.A security group rule
SCPs in AWS Organizations set the maximum available permissions for member accounts, so even an account administrator cannot exceed them, making them ideal for organization-wide guardrails like protecting CloudTrail or restricting Regions. Permissions boundaries apply to individual principals, security groups filter network traffic, and tags do not enforce permissions.
Want these explained in order? AWS Solutions Architect Associate (SAA-C03) — Complete Study Guide (2026) — PDF + EPUB, $14.99 · 14-day refund →
A third-party SaaS vendor needs limited, temporary access to resources in your account to perform monitoring. What is the most secure way to grant it?
- a.Add the vendor's IP address to a security group
- b.Share your root credentials over a secure channel
- c.Create an IAM role the vendor can assume, protected with an external ID and scoped to least privilege✓
- d.Create an IAM user for the vendor with a permanent access key
A cross-account IAM role that the vendor assumes provides temporary credentials, and requiring an external ID prevents the confused-deputy problem where another of the vendor's customers could trick it into assuming your role. Permanent access keys and root credentials are long-lived and dangerous, and a security group rule only controls network reachability, not API permissions.
A security team wants to continuously monitor for anomalous API activity, credential compromise, and communication with known malicious IPs across the account, using machine learning and threat intelligence. Which service is purpose-built for this?
- a.Amazon Inspector
- b.AWS WAF
- c.Amazon GuardDuty✓
- d.AWS Config
Amazon GuardDuty is a managed threat-detection service that analyzes CloudTrail, VPC Flow Logs, and DNS logs with machine learning and threat intelligence to surface compromised credentials, reconnaissance, and malicious communication. AWS Config tracks resource configuration compliance, WAF filters web requests, and Inspector scans workloads for software vulnerabilities.
A company wants to guarantee that every new EBS volume and snapshot created in a Region is encrypted, without relying on users to select encryption each time. What should be configured?
- a.EBS encryption by default for the account in that Region, backed by a KMS key✓
- b.A bucket policy
- c.A security group rule
- d.An IAM permissions boundary
Enabling EBS encryption by default at the account/Region level ensures all newly created volumes and snapshots are automatically encrypted with a KMS key, removing reliance on manual selection. Bucket policies apply to S3, security groups control traffic, and permissions boundaries limit IAM permissions rather than enforce volume encryption.
Instances in a private subnet must access Amazon S3 without their traffic traversing the public internet or a NAT gateway. Which solution meets this most securely and cost-effectively?
- a.Create a VPC gateway endpoint for S3 and route bucket traffic through it✓
- b.Assign public IP addresses to the instances
- c.Deploy a proxy server in a public subnet
- d.Route S3 traffic through an internet gateway
A VPC gateway endpoint for S3 lets private instances reach S3 over the AWS network without an internet gateway or NAT, improving security and avoiding NAT data-processing charges. Public IPs and internet-gateway routing expose traffic to the internet, and a proxy adds cost and complexity without the private-path guarantee.
According to AWS security best practices, how should the account root user be protected and used?
- a.Disable MFA to simplify account recovery
- b.Enable MFA on the root user, use it only for the few tasks that require it, and manage daily work through IAM roles and users✓
- c.Use the root user for all daily administration
- d.Create root access keys and embed them in automation
Best practice is to lock down the root user with MFA, avoid using it for routine tasks, and perform day-to-day work with least-privilege IAM identities and roles. Using root daily, creating root access keys, or disabling MFA all dramatically increase the blast radius if credentials are exposed.
On-premises servers need to call AWS APIs, and the security team wants to avoid distributing long-lived IAM access keys to them. What should be used?
- a.Create one shared access key for all servers
- b.Make the target S3 buckets public
- c.Hard-code an IAM user's keys in each server's configuration
- d.Use IAM Roles Anywhere so servers exchange certificates for short-lived credentials✓
IAM Roles Anywhere lets non-AWS workloads exchange X.509 certificates for temporary IAM credentials, eliminating long-lived keys on-premises. Hard-coding keys or sharing a single key spreads long-lived secrets that are hard to rotate and audit, and making buckets public removes access control entirely.
A team wants to identify S3 buckets, roles, and other resources that are shared with external accounts or the public, and to validate that IAM policies follow least privilege. Which tool helps?
- a.AWS Shield
- b.IAM Access Analyzer✓
- c.Amazon Macie
- d.Amazon Cognito
IAM Access Analyzer identifies resources whose policies grant access to external principals and can validate and refine policies toward least privilege. Macie discovers and classifies sensitive data in S3, Shield mitigates DDoS, and Cognito handles application user authentication, none of which perform external-access analysis.
Instances in a private subnet must download OS patches from the internet but must not accept any inbound connections initiated from the internet. Which component provides this?
- a.An egress-only internet gateway for IPv4 traffic
- b.A public IP address on each instance
- c.An internet gateway attached directly to the private subnet
- d.A NAT gateway in a public subnet with a route from the private subnet✓
A NAT gateway allows instances in a private subnet to initiate outbound IPv4 connections (such as fetching patches) while blocking unsolicited inbound traffic. An internet gateway or public IPs would make instances directly reachable, and an egress-only internet gateway serves IPv6 traffic, not IPv4.
A three-tier app has web instances that must reach app-tier instances on port 8080. How should the app tier's security group be configured to follow least privilege?
- a.Allow all inbound traffic from the entire VPC CIDR
- b.Allow inbound port 8080 with the web tier's security group as the source✓
- c.Allow inbound port 8080 from 0.0.0.0/0
- d.Disable the security group and rely on a network ACL
Referencing the web tier's security group as the source restricts inbound traffic to exactly those instances and adapts automatically as instances scale, which is the least-privilege pattern. Opening 0.0.0.0/0 or the whole VPC CIDR is overly permissive, and NACLs are coarse, stateless subnet filters that cannot reference security groups.
An auditor requires a complete, tamper-resistant record of every API call made in the AWS account, including who made it and when, stored durably for years. Which service provides this?
- a.AWS Config rules
- b.AWS CloudTrail with logs delivered to a protected S3 bucket✓
- c.VPC Flow Logs
- d.Amazon CloudWatch metrics
CloudTrail records management and data-plane API activity across the account, and delivering the trail to an S3 bucket (optionally with log-file validation and Object Lock) gives a durable, tamper-evident audit history. CloudWatch metrics show performance data, VPC Flow Logs capture network traffic, and Config tracks configuration state, not full API call history.
A company must encrypt traffic in transit between clients and its Application Load Balancer and wants AWS to manage certificate provisioning and renewal at no additional cost. What should be used?
- a.A self-signed certificate rotated manually each year
- b.IPsec tunnels to each client
- c.An AWS Certificate Manager (ACM) certificate on an HTTPS listener of the ALB✓
- d.Client-side encryption of every request payload
ACM provisions and automatically renews public TLS certificates at no extra charge, and attaching one to the ALB's HTTPS listener encrypts traffic in transit with minimal operational overhead. Self-signed certificates require manual rotation and are not trusted, per-request client-side encryption is unnecessary complexity, and IPsec to every client is impractical for web traffic.
A team needs to store a small, rarely changing API token securely and encrypted, and wants the lowest-cost option that does not require automatic rotation. Which service fits best?
- a.Hard-code it in the application
- b.Store it in a public S3 bucket
- c.AWS Systems Manager Parameter Store as an encrypted SecureString parameter✓
- d.AWS Secrets Manager with automatic rotation enabled
For a static secret that does not need managed rotation, a Parameter Store SecureString encrypted with KMS stores it securely at the lowest cost. Secrets Manager also encrypts secrets but charges more per secret and is best when you need built-in rotation. Hard-coding or using a public bucket exposes the secret.
Certain sensitive fields must be encrypted by the application before they are ever sent to and stored in DynamoDB, so that even AWS operators cannot read the plaintext. Which approach meets this?
- a.Store the fields in plaintext but restrict table access with IAM
- b.Rely solely on DynamoDB's built-in encryption at rest
- c.Client-side encryption of the sensitive fields using a KMS data key before writing to DynamoDB✓
- d.Encrypt only the network connection with TLS
Client-side encryption (for example with the AWS Database Encryption SDK using a KMS data key) ensures fields are encrypted before leaving the application, so the service only ever stores ciphertext. DynamoDB's built-in encryption at rest protects storage but AWS manages that layer, TLS only protects data in transit, and IAM restricts access but does not encrypt the field values.
A regulated workload requires single-tenant, FIPS 140-2 Level 3 validated hardware where the customer has exclusive control of the cryptographic keys. Which service meets this requirement?
- a.AWS KMS with an AWS managed key
- b.AWS CloudHSM✓
- c.AWS Secrets Manager
- d.Amazon S3 SSE-S3
AWS CloudHSM provides dedicated, single-tenant hardware security modules that are FIPS 140-2 Level 3 validated and give the customer sole control of the keys. KMS is multi-tenant (though it can be backed by a custom key store on CloudHSM), SSE-S3 uses AWS-managed keys, and Secrets Manager stores secrets rather than providing dedicated HSM hardware.
A Lambda function needs permission to write records to a specific DynamoDB table and nothing else. Which approach follows least privilege?
- a.Store an IAM user's access keys in a Lambda environment variable and reference them in the code
- b.Run the function with the same IAM role that the account administrators use for day-to-day console operations
- c.Attach the AmazonDynamoDBFullAccess AWS managed policy to the function's execution role so it never lacks a permission it might need later
- d.Create an execution role with an inline policy scoped to dynamodb:PutItem on that table's ARN only✓
A scoped execution role granting only dynamodb:PutItem on the specific table ARN gives the function exactly the access it needs and nothing more, which is least privilege. Full-access managed policies and admin roles grant far more than required, and embedding long-lived access keys in environment variables is insecure and unnecessary because Lambda assumes its execution role automatically.
A security review finds an IAM policy that grants Action "*" on Resource "*" to an application role. What is the correct remediation?
- a.Rewrite the policy to grant only the specific actions and resource ARNs the application actually calls✓
- b.Add the application role to an IAM group that also has administrator access for convenience
- c.Leave the policy in place but enable CloudTrail so that any misuse of the broad permissions can be investigated afterward
- d.Move the wildcard permissions from the identity policy into a resource policy instead so the wording changes
Replacing the wildcard with the specific actions and resource ARNs the workload uses enforces least privilege and shrinks the blast radius if the role is compromised. Logging with CloudTrail helps investigate abuse but does not prevent it, relocating the wildcard to a resource policy keeps it just as broad, and adding administrator access makes the problem worse.
A company wants to let users in its corporate Active Directory sign in to the AWS Management Console using their existing corporate credentials, without creating IAM users for each person. Which solution fits?
- a.Create one IAM user per employee and synchronize passwords with Active Directory manually every night
- b.Configure IAM Identity Center (or SAML federation) so users authenticate against the corporate directory and assume roles✓
- c.Share a single IAM user among all employees so only one set of credentials must be maintained
- d.Embed the corporate directory password into an EC2 user-data script for automatic console login
IAM Identity Center or SAML-based federation lets employees sign in with existing corporate credentials and assume IAM roles, avoiding per-user IAM identities and password duplication. Creating an IAM user per employee does not scale and duplicates identities, sharing one IAM user destroys accountability, and putting credentials in user data exposes them.
An administrator must ensure that developers can never grant themselves more permissions than a defined maximum, even when they create new IAM roles for their applications. Which mechanism enforces this ceiling?
- a.Attach an IAM permissions boundary that caps the maximum permissions any role they create can effectively use✓
- b.Ask developers to review each other's policies before deployment and document approvals in a spreadsheet
- c.Enable multi-factor authentication on the developer accounts so their logins require a second factor
- d.Turn on CloudTrail data events for IAM so every policy change generates a log entry for later review
A permissions boundary sets the maximum permissions an IAM principal can have, so even if developers attach broad policies, the effective permissions cannot exceed the boundary. MFA protects sign-in but not permission scope, manual peer review is not an enforced control, and CloudTrail only records changes after they happen.
Which statement correctly distinguishes a security group from a network ACL in a VPC?
- a.A network ACL can reference another security group as its source, while a security group can only use CIDR ranges
- b.A security group is stateful and operates at the instance level, while a network ACL is stateless and operates at the subnet level✓
- c.Both are stateless and evaluate only the numbered rules that come before the first matching allow or deny entry
- d.A security group is attached to a subnet and a network ACL is attached to an individual elastic network interface
Security groups are stateful and applied to instance network interfaces, so return traffic is automatically allowed, whereas network ACLs are stateless subnet-level filters that evaluate numbered rules in order and require explicit rules for both directions. The other options reverse these properties or invent capabilities that do not exist.
A subnet must explicitly block a small list of known-malicious IP addresses from reaching any instance in it, while still allowing all other inbound traffic. Which control is appropriate?
- a.An IAM policy that denies the malicious IP addresses using an aws:SourceIp condition on the instances
- b.A Route 53 health check that removes the malicious addresses from DNS responses automatically
- c.A network ACL with deny entries for the specific malicious IP ranges plus an allow entry for other traffic✓
- d.A security group with deny rules for each malicious IP address applied to every instance in the subnet
Network ACLs support explicit deny rules and operate at the subnet level, making them the right tool to block specific IP addresses while permitting everything else. Security groups have no deny rules (only allows), IAM policies govern API permissions rather than raw network packets, and Route 53 controls DNS resolution, not packet filtering.
A company encrypts data in S3 with SSE-KMS and must be able to prove which principals decrypted specific objects and when, for a compliance audit. How is this evidence obtained?
- a.Turn on S3 Versioning so that each decrypt event creates a new object version that can be reviewed
- b.Configure an S3 lifecycle policy that tags objects with the identity of the last principal to read them
- c.Review AWS CloudTrail, which logs every KMS Decrypt call including the calling principal and timestamp✓
- d.Enable S3 server access logging, which records the KMS key ID used for every decrypt operation on each object
KMS integrates with CloudTrail so that every Decrypt (and Encrypt) call is logged with the calling identity, key, and timestamp, providing the audit evidence required. S3 access logging records object requests but not KMS key-usage detail, versioning tracks object changes rather than decrypt events, and lifecycle policies manage storage transitions, not access auditing.
A team wants a KMS key whose key material is automatically rotated once a year while keeping the same key ID and existing ciphertext readable. What should they configure?
- a.Manually create a brand-new KMS key each year and re-encrypt every object with the new key on a schedule
- b.Switch the objects to SSE-S3 so that Amazon rotates the underlying keys without any customer configuration at all
- c.Enable automatic key rotation on a customer managed KMS key so new material is generated yearly under the same key ID✓
- d.Export the KMS key material to a file, rotate it locally, and import the replacement material every twelve months
Enabling automatic rotation on a customer managed key makes KMS generate new backing material annually while retaining the same key ID, and older ciphertext remains decryptable because KMS keeps prior material. Manual re-encryption is unnecessary overhead, SSE-S3 gives you no control over the key, and KMS key material generated by AWS cannot be exported.
An application must call the AWS KMS API to decrypt data, but the traffic must not leave the AWS network or traverse the public internet. What should be configured?
- a.A NAT gateway so the private instances can reach the public KMS endpoint over an outbound internet path
- b.A gateway VPC endpoint for KMS routed through the subnet route table like the one used for S3 access
- c.A customer gateway and site-to-site VPN tunnel connecting the VPC to the regional KMS service endpoint
- d.An interface VPC endpoint (AWS PrivateLink) for KMS so API calls stay on the private AWS network✓
KMS is reached through an interface VPC endpoint powered by PrivateLink, giving instances a private IP to call the API without internet exposure. A NAT gateway still sends traffic to the public endpoint, KMS is not one of the services offered as a gateway endpoint (only S3 and DynamoDB are), and a VPN is for connecting on-premises networks, not for keeping in-VPC API calls private.
A new S3 bucket will hold internal financial reports that must never be exposed publicly, even if someone later adds a permissive bucket policy or ACL by mistake. What is the strongest safeguard?
- a.Encrypt the objects with SSE-KMS so that anyone without the key cannot read the report contents
- b.Rely on the default private ACL that every new S3 bucket receives when it is first created by a user
- c.Add a bucket policy that allows access only from the corporate office IP range and hope no one edits it
- d.Enable S3 Block Public Access at the bucket (and account) level so public policies and ACLs are overridden✓
S3 Block Public Access overrides any bucket policy or ACL that would grant public access, providing a durable guardrail against accidental exposure even if permissive settings are later added. An IP-restricted policy can be edited away, the default private ACL does not prevent someone from making the bucket public later, and encryption protects confidentiality but does not stop an object from being served to whoever is granted access.
A static website in S3 is served through a CloudFront distribution, and the security team wants users to be unable to bypass CloudFront and fetch objects directly from the S3 bucket URL. What achieves this?
- a.Make the bucket public and rely on users choosing to use the CloudFront URL instead of the bucket endpoint
- b.Enable S3 Transfer Acceleration on the bucket so that only accelerated CloudFront requests succeed reliably
- c.Use CloudFront Origin Access Control and a bucket policy that allows only the distribution to read objects✓
- d.Put the bucket in a different Region from CloudFront so the direct S3 endpoint resolves to a slower path
Origin Access Control lets CloudFront sign requests to the origin, and a bucket policy that grants read access only to that distribution blocks direct S3 access, so users must go through CloudFront. Making the bucket public defeats the goal, Region choice does not restrict access, and Transfer Acceleration is an upload-speed feature unrelated to access control.
A company must automatically discover and classify sensitive personally identifiable information, such as credit card numbers and names, stored across hundreds of S3 buckets. Which service is purpose-built for this?
- a.Amazon GuardDuty
- b.Amazon Macie✓
- c.AWS WAF
- d.AWS Config
Amazon Macie uses machine learning and pattern matching to discover and classify sensitive data such as PII in S3, producing findings and dashboards. AWS Config tracks resource configuration compliance, GuardDuty detects threats from log analysis, and WAF filters web requests, none of which classify the content of stored objects.
A public-facing API on API Gateway is being abused by clients sending huge volumes of requests from many IP addresses, and the team wants to throttle and block requests by rate and by geography. Which service should be attached?
- a.A network ACL that denies the abusive client IP ranges at the subnet hosting the API Gateway endpoint
- b.AWS WAF with a rate-based rule and geo-match conditions attached to the API Gateway stage✓
- c.AWS Shield Standard, which is automatically enabled and can be tuned to apply per-client HTTP rate limits
- d.Amazon GuardDuty configured with a rate-based threat list that automatically drops the abusive source addresses
AWS WAF supports rate-based rules and geo-match statements and integrates with API Gateway, so it can throttle high-volume clients and block by country at the application layer. Shield Standard mitigates network/transport DDoS and cannot apply HTTP rate limits, GuardDuty only detects and does not block, and NACLs cannot be attached to the managed API Gateway endpoint.
An organization running a high-profile web application wants managed DDoS protection with 24/7 access to the AWS DDoS Response Team and cost protection against scaling charges during an attack. Which offering provides this?
- a.AWS WAF managed rule groups applied to the Application Load Balancer in front of the web application
- b.AWS Shield Advanced subscribed for the protected resources✓
- c.AWS Shield Standard, which every AWS account already receives at no additional cost for all resources
- d.Amazon GuardDuty with DNS and flow-log analysis enabled across the account to spot attack patterns
Shield Advanced adds enhanced DDoS mitigation, 24/7 access to the DDoS Response Team, real-time attack visibility, and cost-protection credits for scaling during attacks. Shield Standard is free but lacks these premium features, WAF filters application requests but is not a DDoS response service, and GuardDuty is threat detection, not DDoS mitigation.
Application code currently reads a database password from a plaintext configuration file baked into the AMI. The team wants a more secure approach with automatic rotation and no secrets in the image. What should they use?
- a.Store the credential in AWS Secrets Manager and have the application retrieve it at runtime with rotation enabled✓
- b.Base64-encode the password in the configuration file so it is not stored as readable clear text anymore
- c.Store the password in a public S3 bucket and restrict who knows the exact object key used to fetch it
- d.Move the plaintext password into an EC2 instance tag and read it at boot from instance metadata each time
Secrets Manager stores the credential encrypted with KMS, serves it to the application at runtime, and can rotate the database password automatically, removing secrets from the image. Instance tags and base64 encoding are not secure storage, and a public bucket with an obscure key relies on secrecy of the key rather than real access control.
A mobile app authenticates users through an Amazon Cognito user pool and then needs to grant those signed-in users temporary, scoped AWS credentials to upload files to a specific S3 prefix. Which Cognito feature provides the AWS credentials?
- a.A Cognito identity pool that exchanges the user pool token for temporary IAM credentials mapped to a scoped role✓
- b.A KMS grant issued to each authenticated user so they can encrypt and upload objects without IAM involvement
- c.A Cognito user pool app client secret that the mobile app presents directly to S3 for each upload request
- d.An IAM user automatically created for every person who signs up through the Cognito user pool hosted UI
A Cognito identity pool takes the user pool's token and returns temporary AWS credentials tied to an IAM role, which can be scoped to the specific S3 prefix. User pools handle authentication but do not themselves vend AWS credentials, S3 does not accept an app client secret for authorization, and KMS grants govern key use rather than S3 upload permissions.
Showing 40 of 109