Security and Compliance practice questions

Use AWS Single Sign-On (SSO) to assign permissions to users across accounts.

Why wrong: Incorrect. AWS SSO manages user access to accounts but does not centrally manage cross-account IAM roles as described.

Create an IAM role in the Security account with a trust policy that references a service control policy (SCP) in AWS Organizations.

Why wrong: Incorrect. Trust policies cannot reference SCPs; SCPs are attached at the OU or account level and are not referenced within a trust policy.

Create a resource-based policy on each IAM role in the member accounts that allows the Security account to assume the role.

Why wrong: Incorrect. IAM roles use trust policies, not resource-based policies. Resource-based policies are for services like S3 buckets.

AWS Config

Why wrong: AWS Config is incorrect because it does not record API calls; instead, it records the configuration state of your AWS resources and tracks changes to those configurations over time. It uses rules to evaluate whether resources comply with your desired policies (e.g., checking if an S3 bucket is public), and it maintains a configuration history and configuration snapshots. Although AWS Config may indirectly reflect the outcome of an API call (like a modified resource), it does not capture the API call itself, so it cannot provide a complete audit trail of who performed what action.

Amazon CloudWatch Logs

Why wrong: Amazon CloudWatch Logs is incorrect because it is a log management service that stores, monitors, and queries log files from sources you explicitly configure, such as application logs, system logs, or AWS service logs. It does not automatically capture AWS API calls unless you separately configure CloudTrail to send its event logs to CloudWatch Logs. Even then, CloudWatch Logs is merely the destination for the events; the actual recording and API-call auditing capability resides in CloudTrail, not in CloudWatch Logs itself, so this service alone cannot fulfill the requirement.

Amazon VPC Flow Logs

Why wrong: Amazon VPC Flow Logs is incorrect because it captures IP traffic information at the network interface level, not the API call level. It records metadata about network flows, including source and destination IP addresses, ports, protocol, packet counts, and byte counts, which helps with network troubleshooting and security analysis. Flow Logs cannot identify the IAM user or service that made an API call, nor does it include the request parameters or identity context, so it is fundamentally incapable of providing an audit trail of API calls.

Create an S3 bucket policy that denies kms:Decrypt unless the request includes a specific tag.

Why wrong: S3 bucket policies are resource-based policies that only authorize S3 data-plane actions such as s3:GetObject and s3:PutObject; they are not evaluated by the KMS service when a caller makes a kms:Decrypt API call. Even if you add a Deny statement for kms:Decrypt, S3 will ignore it because S3 does not enforce KMS permissions. Furthermore, S3 bucket policies cannot reference request tags or SAML attributes in a way that would affect KMS decryption because the KMS key policy and IAM policies are the authoritative documents for that KMS action.

Attach a resource-based policy to the S3 bucket that allows decryption only for users with the specific attribute.

Why wrong: S3 bucket policies control access to S3 actions, not to KMS keys, so attaching a resource-based policy to the S3 bucket cannot directly allow or deny kms:Decrypt. Even if the bucket policy allows the GetObject action, a separate kms:Decrypt permission is still required when the S3 object is encrypted with SSE-KMS, and that permission must come from the KMS key policy or an IAM policy. Moreover, S3 bucket policies do not evaluate the SAML assertion or its attributes in the context of KMS; they only govern S3 operations.

Use an IAM policy that grants kms:Decrypt only if the user has the specific attribute.

Why wrong: IAM identity-based policies can grant kms:Decrypt, but they cannot directly inspect the contents of an SAML assertion because SAML attributes are processed by STS to create role session tags. An IAM policy could use a condition like aws:PrincipalTag, but that would require at least one identity policy per user or role and is not the native place to enforce key-specific constraints. The KMS key policy is more appropriate because it is evaluated once for the key and can directly incorporate SAML-derived context keys, whereas IAM policies are less centralized and cannot directly reference raw SAML attributes.

Create a scheduled job that runs every 30 days to update the secret in Secrets Manager with a new password.

Why wrong: A scheduled job that simply calls UpdateSecret every 30 days is flawed because it changes the stored credential without updating the actual RDS database password. The database would continue accepting the old password, so the rotated secret value would be invalid. Secrets Manager rotation is not just a scheduled update; it requires a Lambda function that coordinates modifying the DB password and the secret in a single integrated flow.

Store the credentials in AWS Systems Manager Parameter Store and configure automatic rotation using a Lambda function.

Why wrong: AWS Systems Manager Parameter Store has no native rotation feature for RDS credentials, and the proposed solution would require you to build and manage a custom Lambda function to rotate the password. Parameter Store also lacks the staging labels (AWSCURRENT, AWSPENDING, etc.) and built-in integration with RDS that Secrets Manager provides for safe, automated rotation. Even with a Lambda function, Parameter Store does not automatically trigger rotation or manage the secret version lifecycle in a way that makes this a fully managed solution.

Use the AWS RDS automatic password rotation feature, which automatically updates the password every 30 days.

Why wrong: Amazon RDS does not provide a native 'automatic password rotation' feature that cycles the master password every 30 days on its own. RDS only supports manual password modification via the console, CLI, or API, or through the integrated rotation that Secrets Manager orchestrates. Therefore, selecting this option describes a nonexistent capability, and the correct approach is to use Secrets Manager's rotation configuration.

Create an SCP to deny cloudtrail:UpdateTrail.

Why wrong: Creating an SCP to deny cloudtrail:UpdateTrail is insufficient because UpdateTrail only modifies trail configuration (e.g., changing the S3 bucket, log prefix, or enabling file validation) — it does not stop delivery of events or remove the trail. A malicious or accidental call to cloudtrail:StopLogging would still succeed, and an administrator could also delete the trail outright. Moreover, SCPs do not affect the management account, so this SCP would not protect the trail if it is owned by the management account.

Create an IAM policy in each member account to deny cloudtrail:StopLogging.

Why wrong: An IAM policy deny for cloudtrail:StopLogging in each member account is ineffective as a security guardrail because those policies are scoped within the member account and can be modified, detached, or entirely replaced by an account administrator with sufficient permissions. SCPs are the appropriate mechanism in AWS Organizations to apply a hard boundary that member account administrators cannot bypass — IAM policies are subject to the very accounts you are trying to control.

Enable AWS CloudTrail from the management account with organization trail.

Why wrong: Enabling CloudTrail from the management account as an organization trail is not a sufficient control by itself because an organization trail creates the trail in the management account and delivers events to a designated S3 bucket, but it does not prevent an IAM user or role in a member account from calling cloudtrail:StopLogging or cloudtrail:DeleteTrail on that same trail. SCPs are needed to restrict those actions at the organization level; otherwise, any member account with the appropriate IAM permissions can disable or delete the trail, breaking your audit chain.

Store database credentials in AWS Systems Manager Parameter Store.

Why wrong: AWS Systems Manager Parameter Store can store database credentials, but by default it does not encrypt parameter values; they are stored as plaintext unless you explicitly specify a KMS key. Using Parameter Store without KMS encryption leaves sensitive credentials exposed at rest, failing the security requirement for data protection. To correctly use it, you would need to configure a KMS customer master key and assign a SecureString parameter to ensure encryption.

Use VPC endpoints to access ECS and ECR APIs.

Why wrong: VPC endpoints for ECS and ECR keep API traffic within the AWS network, but they do not provide encryption of data in transit or any logging of access. Traffic over a VPC endpoint is still subject to the same TLS requirements for encryption, and endpoint access itself is not logged by CloudTrail as a security audit mechanism. They address network isolation, not the stated need for encryption-at-rest, encryption-in-transit, or auditing, so they are an incomplete security control.

The SCP requires an explicit allow statement in the IAM policy to override the deny.

Why wrong: SCPs are not an override mechanism where an IAM explicit allow can cancel a deny; effective permissions are the intersection of all policies. If an SCP denies or omits an action, even an explicit IAM allow for that action cannot make it permitted. The statement confuses the relationship between SCPs and IAM, as SCPs act as boundary controls that cannot be bypassed by adding an allow in the role's policy.

The IAM role does not have permission to tag resources.

Why wrong: The IAM role is described as having full DynamoDB access, which includes the DynamoDB:TagResource action through the wildcard resource and action permissions. Therefore, the failure to create the table is not caused by insufficient tagging permissions; the role can tag resources when the correct API call is made. The real limitation is that the CreateTable request does not carry tag information, so a tag-on-create condition cannot be evaluated.

The SCP is not applied to the development account because it is in a different OU.

Why wrong: The account's location in a different OU is not the cause because the scenario states the SCP applies to the development account, and SCPs can be attached directly to an account regardless of OU structure. Even if the SCP were attached only to the OU, being in a different OU would mean the SCP is not in effect, but that would produce a different error than a permissions denial. The observed denial is due to the tag condition, not the organizational hierarchy.

Enable AWS CloudTrail to log all S3 API calls and send alerts when noncompliant buckets are created.

Why wrong: AWS CloudTrail records all S3 API calls and can trigger alerts when noncompliant buckets are created, but it is strictly a detective control. Logging does not prevent the bucket from being created with insecure settings, nor does it automatically remediate the resource after the fact. Alerting requires you to build and maintain monitoring infrastructure, which adds complexity without enforcing the required encryption or public-access protections.

Attach an IAM permissions boundary to all users that prevents them from creating or modifying S3 buckets.

Why wrong: An IAM permissions boundary that denies s3:CreateBucket and s3:PutBucketEncryption would prevent users from creating or modifying S3 buckets entirely, which is more restrictive than the requirement to enforce specific security settings. It also fails to protect against other principals such as the account root user, existing roles, or service accounts that may already have permissions. The boundary treats all bucket activity as forbidden instead of allowing creation only when the required encryption and public-access controls are present.

Apply an S3 bucket policy to each existing bucket that denies all access unless encryption is enabled.

Why wrong: Applying a bucket policy to each existing bucket that denies access unless encryption is enabled only affects buckets that exist at the time of application. Newly created buckets would not inherit this policy, and nothing stops a bucket owner from later modifying or removing the policy. It is a static, one-time control that lacks the continuous, automated enforcement needed to guarantee every current and future bucket remains encrypted and non-public.

The Null condition incorrectly allows uploads without encryption.

Why wrong: Null condition denies when encryption header is missing, but if AES256 is provided, the header is not null.

The bucket policy does not apply to cross-account uploads.

Why wrong: The policy applies to all principals, including cross-account.

The bucket policy lacks an explicit Allow statement for s3:PutObject.

Why wrong: Deny statements are effective without an explicit Allow.

Create the parent template, then upload the nested stack template, then validate the templates, then create the stack, then monitor the stack creation.

Why wrong: Creating the parent template before uploading the nested stack template breaks the dependency chain: the parent template's AWS::CloudFormation::Stack resource includes a TemplateURL property that must point to a real S3 object. Without the nested template in place, CloudFormation cannot resolve that reference during stack creation, even if a syntactic validation might pass. The nested template must be uploaded first so the parent's reference is resolvable when the templates are validated and the stack is launched.

Validate the templates, then upload the nested stack template, then create the parent template, then create the stack, then monitor the stack creation.

Why wrong: Validation cannot occur before the templates exist because ValidateTemplate requires the template body as input; you cannot validate a template that has not yet been written. In this sequence, validation is mistakenly placed ahead of both the nested template upload and the parent template creation. Only after both templates exist and the nested template is accessible in S3 can you meaningfully validate syntax and resource definitions, so this order fails at the first step.

Upload the nested stack template, then create the parent template, then create the stack, then validate the templates, then monitor the stack creation.

Why wrong: Creating the stack before validating the templates puts the cart before the horse: CloudFormation will implicitly reject invalid templates at creation time, but by then you may have already begun provisioning resources or incurring costs. Moreover, any validation you perform after creation is useless because the stack is either already created or failed. The explicit validation step must precede stack creation so that errors are caught early, before any resources are touched.

IAM: Protect against DDoS attacks

Why wrong: IAM's scope is the control plane of authentication and authorization; it has no visibility into network traffic, protocol analysis, or volumetric attack patterns. Assigning DDoS protection to IAM confuses the identity plane with the network plane—IAM policies grant or deny API actions, but they cannot inspect or filter inbound packets. Real DDoS mitigation is handled by AWS Shield, AWS WAF, and edge services like CloudFront and Global Accelerator, not by IAM.

AWS Organizations: Manage user identities and permissions

Why wrong: AWS Organizations uses service control policies (SCPs) to establish guardrails on what actions are allowed within member accounts, but it does not create or manage IAM users, groups, roles, or their individual permissions. SCPs function as boundary constraints that define the maximum allowable permissions, while actual user identity management remains entirely within IAM. Therefore, saying Organizations manages user identities mischaracterizes its governance role and conflates account-level policy with identity-level access control.

AWS Shield: Centrally manage multiple AWS accounts

Why wrong: AWS Shield operates exclusively in the network and application availability layer, monitoring traffic to detect and mitigate distributed denial-of-service attacks. It has no feature for creating accounts, organizing OUs, or applying service control policies—those are functions exclusive to AWS Organizations. Even if Shield Advanced can be centrally configured across accounts through the Shield console, that does not make it an account-management service; its mission is availability protection, not centralized multi-account oversight.

Amazon CloudWatch

Why wrong: Amazon CloudWatch is a monitoring and observability service that collects metrics, logs, and alarms but is not the source of API audit trails. While CloudTrail can deliver KMS API events to CloudWatch Logs for metric filters and alarm thresholds, CloudWatch itself does not record or capture the raw KMS calls such as Decrypt or GenerateDataKey. The authoritative record of KMS API activity is maintained by CloudTrail, which then may be forwarded to CloudWatch for operational alerting.

Amazon GuardDuty

Why wrong: Amazon GuardDuty is a threat detection service that uses machine learning and anomaly detection on AWS data sources like DNS queries, VPC Flow Logs, and CloudTrail management events, but it does not produce its own audit trail of KMS API calls. GuardDuty can flag suspicious patterns in CloudTrail logs—such as an unusually high volume of GenerateDataKey calls—but it is not the service to query for a complete, chronological record of who called KMS operations. For auditing the actual KMS API activity, you need CloudTrail, and GuardDuty's findings are separate from the auditable events themselves.

AWS Config

Why wrong: AWS Config is a configuration auditing service that records resource provisioning and configuration changes—for example, whether KMS key rotation is enabled, the key policy, or the state of a CMK—not the API operations that use the key. While Config can help enforce compliance rules like 'ensure KMS keys have automatic rotation', it does not log individual data-plane calls such as Decrypt or Encrypt performed by IAM principals. The only service that provides the requested API-level audit trail for KMS is CloudTrail.

Use AWS Config rules to detect unencrypted buckets and automatically apply encryption using a remediation action.

Why wrong: AWS Config rules are detective and reactive: they evaluate resource state after a bucket is created or modified, and the automatic remediation action (for example, an SSM automation document) runs only after the non-compliant bucket already exists. During the time between the prohibited action and the remediation, the bucket is unencrypted, violating the intended security posture. Config rules also require per-account or per-region setup and do not stop the original PutBucketEncryption call, so they are not a genuine preventive control.

Enable AWS CloudTrail to log all S3 API calls and send alerts when non-compliant buckets are created.

Why wrong: CloudTrail records API activity but has no ability to block or modify an S3 request. When a non-compliant bucket is created, CloudTrail delivers the event to the configured S3 bucket or CloudWatch Logs after the fact, and any alarm triggered from the event simply alerts you to a violation that has already succeeded. This is a detective control that helps with auditing and forensics, but it does not enforce encryption requirements at the moment the API call is made.

Create an IAM policy in each account that denies PutBucketEncryption unless encryption is enabled.

Why wrong: IAM policies are scoped to individual accounts and identities, so applying deny statements to every account requires manual distribution and must be repeated whenever a new member account joins the organization. Account administrators with IAM permissions could also modify or remove these policies locally, which weakens the control. In the context of AWS Organizations, the service control policy at the root is the appropriate mechanism because it is centrally managed, continuously enforced, and automatically applies to all current and future accounts.

Use an IAM role in each account that grants write access to the central bucket, and use S3 default encryption.

Why wrong: Relying on per-account IAM roles and S3 default encryption is insufficient because default encryption uses SSE-S3, which lacks the auditability and fine-grained control of SSE-KMS, and the bucket policy cannot enforce that every writer actually applies encryption or uses HTTPS. Managing separate IAM roles in each account also increases complexity and the risk of misconfiguration, leaving central logging without a single, enforced access boundary.

Configure each account to write logs to its own S3 bucket, then replicate to a central bucket using S3 Cross-Region Replication.

Why wrong: Using per-account S3 buckets with S3 Cross-Region Replication to a central bucket adds latency and operational overhead, and replication does not automatically preserve encryption settings or access controls. CRR only replicates new objects after a source bucket is configured, and you must build cross-account IAM roles and handle encryption key differences, making the solution brittle and less secure because the destination bucket cannot enforce the same security posture on the original writes.

Use Amazon CloudWatch Logs in each account and export logs to a central S3 bucket using a Lambda function.

Why wrong: Exporting CloudWatch Logs through a Lambda function to S3 introduces custom code, Lambda timeouts, and potential data loss if the function fails, making it less reliable than a direct, managed integration. CloudWatch Logs does not encrypt at rest by default unless you configure KMS manually, and the Lambda-based export path is operationally complex, with no built-in monitoring or retry semantics, so it is not a secure or simple solution for centralizing audit logs.

Configure security groups to allow only HTTP/HTTPS traffic.

Why wrong: Security groups function as a stateful virtual firewall at the instance or ENI level and make allow/deny decisions based on source/destination IP addresses, ports, and protocols. They cannot inspect HTTP headers, query strings, or request bodies, so SQL injection and XSS payloads carried inside legitimate HTTPS requests on port 443 will pass through untouched. Restricting the ALB's security group to only HTTP/HTTPS merely controls which ports are reachable, not whether the application-layer content is malicious.

Configure network ACLs to block common attack patterns based on IP ranges.

Why wrong: Network ACLs are stateless per-subnet firewall rules that evaluate traffic only against IP address, port number, and protocol fields. They cannot parse HTTP request attributes such as URI, headers, or body that are needed to detect SQLi or XSS. Even if you add rules to deny known malicious source IP ranges, attackers can easily rotate origins, and common attack patterns are signature-based, not IP-based. Also, because NACLs are stateless, you must configure both inbound and outbound rules, but that still doesn't enable application-layer inspection.

Enable AWS Shield Advanced to protect the ALB.

Why wrong: AWS Shield Advanced is a managed Distributed Denial of Service (DDoS) protection service that provides always-on network and transport layer monitoring and mitigates volumetric attacks. It offers enhanced detection, DDoS cost protection, and access to the DDoS Response Team, but its core function is not blocking SQL injection or XSS. While Shield Advanced can be paired with AWS WAF for broader layer 7 DDoS mitigation, deploying Shield alone to the ALB will not evaluate HTTP application payloads and therefore will not protect against injection-based attacks.

Attach an Internet Gateway to the VPC and route the private subnet to it.

Why wrong: Attaching an Internet Gateway to the VPC and routing the private subnet to it directly violates the definition of a private subnet. Such a route makes the subnet effectively public, giving every instance a publicly reachable IP and allowing inbound traffic to bypass the ALB entirely. This defeats the security architecture's principle of a single controlled entry point and exposes instances to direct scanning and attacks.

Configure a network ACL on the private subnet to allow inbound traffic on all ephemeral ports.

Why wrong: Configuring a network ACL (NACL) to allow inbound traffic on ephemeral ports is unnecessary and ineffective here because the ALB typically communicates with instances on a fixed port (e.g., 80 or 443) defined in the security group, not on ephemeral ports. NACLs are stateless, so you would also need symmetric outbound rules, and they apply at the subnet boundary rather than per-instance. Most importantly, the real control should be the instance security group referencing the ALB's security group, which provides stateful, identity-aware filtering that NACLs cannot offer.

Set up an AWS Direct Connect connection for the instances to access the internet.

Why wrong: Setting up AWS Direct Connect does not provide internet access for the instances; it provides a dedicated private network connection from your on-premises data center to your VPC, bypassing the public internet. For inbound web traffic, you still need an internet-facing endpoint such as an ALB with an IGW, and for outbound internet from private instances you would use a NAT gateway. Direct Connect is irrelevant to the ALB-to-EC2 traffic flow inside the VPC and introduces unnecessary cost and complexity without addressing the security requirement.

AWS CloudTrail to log all API calls.

Why wrong: AWS CloudTrail is a governance and auditing service that records every API call request, who made it, and when, storing the logs as encrypted objects in S3; however, it does not perform encryption on cardholder data or databases. Enabling CloudTrail alone leaves sensitive payloads unencrypted at rest and in transit, making it an incorrect substitute for an encryption service. It helps you detect unauthorized activity but does not cryptographically protect the data itself.

AWS WAF to protect web applications.

Why wrong: AWS WAF is a web application firewall operating at Layer 7 to inspect incoming HTTP/S traffic and block common attack patterns like SQL injection, cross-site scripting, and bot traffic. It has no capability to encrypt data, because it needs visibility into the plaintext request (after TLS termination) to apply rules, and it cannot protect data stored in S3 or databases. Thus WAF is a security control, not a cryptography control, and is incorrect for this requirement.

Enable S3 Block Public Access on the bucket.

Why wrong: Enabling S3 Block Public Access on the bucket is a protective measure that prevents public exposure, but it does not restrict access to a specific AWS account. It only disables public bucket policies and ACLs; it does not evaluate the source account of IAM principals. Legitimate cross-account requests, even from an allowed account, are unaffected by Block Public Access unless the policy itself is public. Therefore, it cannot serve as an access-control mechanism to limit access to a particular account.

Generate pre-signed URLs for each object and distribute them only to users in the target account.

Why wrong: Pre-signed URLs provide temporary, time-limited access to a specific S3 object, but the URL itself is the only credential—anyone who possesses it can download the object, regardless of their AWS account. The signature does not bind the request to a particular account or identity; it is based on the signer's credentials. Thus this method cannot enforce a restriction to a specific target account; it only controls the duration and scope of the URL. This makes it unsuitable for limiting access to a designated account.

Set a bucket ACL that grants read access to the target account's canonical ID.

Why wrong: Bucket ACLs are a legacy access-control mechanism that allow you to grant permissions to another account's canonical ID, but they lack the granularity and condition support of bucket policies. They cannot restrict based on IAM roles, IP addresses, or source account—only on the canonical ID of the account. Additionally, ACLs are non-transitive and are generally not recommended because they are harder to maintain and audit. For these reasons, using an ACL to grant read access to a target account is not a secure or scalable method to restrict access to a specific account.

Use an SCP to deny ec2:TerminateInstances for the entire account.

Why wrong: An SCP attached at the account or OU level acts as a permission boundary for every principal in that account, not just the offending IAM user. Using it to deny ec2:TerminateInstances would block termination for all users and roles, including legitimate administrative workflows, which violates the principle of least privilege and is far broader than the single-user fix required here.

Modify the existing policy to include ec2:StopInstances and remove ec2:TerminateInstances.

Why wrong: Simply removing ec2:TerminateInstances from the user's identity-based policy does not guarantee the user loses that permission—they could still inherit it from a group policy, a managed policy, or a broad resource-based statement. An explicit Deny statement is more secure because it overrides any Allow from other policies, making it the definitive safeguard against the unwanted action.

Attach a separate managed policy that denies ec2:TerminateInstances to the user.

Why wrong: A separate managed policy that denies ec2:TerminateInstances could technically work, but it adds a second authorization document that must be attached and maintained. Without a condition scoping it to the user's ARN, such a policy is also more likely to be reused unintentionally, and it is less transparent than editing the user's existing policy to include an explicit Deny statement with the exact principal condition.

Amazon DynamoDB with encryption

Why wrong: DynamoDB is a NoSQL database, not a purpose-built secrets manager. While you could store secrets in a table and encrypt at rest with KMS, you'd have to build all access control, versioning, rotation, and audit features yourself. It lacks native secret rotation, automatic integration with Lambda for rotation, and fine-grained secret-specific access policies. Storing secrets in a general-purpose database also increases attack surface and operational overhead.

Amazon S3 with server-side encryption

Why wrong: S3 is object storage, not a secrets service. Server-side encryption protects data at rest but does not manage key versioning for rotation or provide secret lifecycle management. You would need manual processes to rotate values and update consuming applications. S3 also has broader access management that is not tailored to secret granularity, making it easy to over-expose. There is no built-in integration with RDS or SQL Server for automatic rotation.

AWS Systems Manager Parameter Store (SecureString)

Why wrong: SSM Parameter Store SecureString does encrypt values and offers basic access control via IAM, and it integrates with some AWS services. However, it does not provide native automated rotation of secrets or cross-account secret replication capabilities that AWS Secrets Manager offers. It lacks built-in secret rotation templates for RDS/Redshift, and no automatic secret versioning with staged rotation. For a DevOps engineer needing scheduled rotation and a retrieval API specifically for secrets, Secrets Manager is more appropriate.