AWS Security, Interview Questions.

AWS secures the cloud itself: facilities, hardware, hypervisor and managed service internals. You secure what you put in it: identities and permissions, data, network configuration, operating systems on EC2, and application code. For managed services the line moves up (with RDS, AWS patches the engine, but you still own access, encryption choices and network exposure).

IAM controls who can do what on which resource. Users are long-term identities, groups bundle users, roles are assumed temporarily (by services, people or other accounts) and give short-lived credentials, and policies are JSON documents defining allowed or denied actions. Prefer roles over long-lived keys.

The root user has unrestricted account access. Enable MFA (hardware preferred), remove root access keys, use it only for the few tasks that require it, keep the email and recovery contacts controlled, and alert on any root sign-in. Daily work uses roles or federated identities.

Security groups are stateful, attached to network interfaces, allow rules only. Network ACLs are stateless, attached to subnets, support allow and deny, and evaluate rules in number order. Use security groups as the main control, and NACLs as a coarse extra layer or to block specific ranges.

Turn on Block Public Access at account and bucket level, use bucket policies and IAM for access, enable default encryption, versioning, and server access or CloudTrail data event logging. ACLs are disabled by default on new buckets with bucket owner enforced. Use access analyzer to find unintended sharing.

The audit log of AWS API activity: who called what, from where, when. Management events record control-plane actions, data events record object-level and function-level access. Create an organisation trail to a protected bucket with log file validation, and send it to a separate logging account.

Key Management Service creates and controls encryption keys. Services use KMS keys to encrypt data via envelope encryption: a data key encrypts data and KMS encrypts the data key. Key policies and grants control use, and every use is logged in CloudTrail. Customer-managed keys give rotation and policy control.

A managed threat detection service that analyses CloudTrail, VPC flow logs, DNS logs and other sources for suspicious behaviour such as crypto mining, credential exfiltration or communication with known-bad hosts. It produces findings you route to Security Hub, EventBridge and your response tooling.

Authentication proves who the caller is (credentials, SSO, a role session). Authorisation decides whether that identity may perform the action, evaluated across identity policies, resource policies, permission boundaries, SCPs and session policies.

By default everything is denied. Evaluation checks for an explicit deny in any applicable policy (this always wins). Organisation SCPs and permission boundaries must also allow the action, and then an identity or resource policy must provide an allow. Within one account, a resource policy that names the principal can grant access without an identity policy, but across accounts both sides must allow.

Service control policies set the maximum permissions for accounts in an AWS Organization. They filter what is possible, but never grant permissions on their own, and they do not apply to the management account. Use them for guardrails: deny leaving the organisation, disable CloudTrail, use of non-approved regions, or removing encryption.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDisablingAuditTrail",
    "Effect": "Deny",
    "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
    "Resource": "*"
  }]
}

A managed policy set on a user or role that caps the maximum permissions its identity policies can grant. It lets you delegate role creation to developers without letting them create roles more powerful than themselves.

Use IAM Access Analyzer (external access findings and unused access findings), last-accessed data, and policy generation from CloudTrail activity to right-size. Remove wildcard actions and resources, replace users with roles, add conditions (source VPC endpoint, MFA, tags), and review regularly. Least privilege is iterative.

The instance metadata service hands role credentials to code running on an instance. IMDSv1 answers simple requests, so a server-side request forgery bug can steal credentials. IMDSv2 requires a session token via a PUT request and blocks many such flaws. Require IMDSv2 on all instances and set a hop limit of 1 where containers do not need it.

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-endpoint enabled

Use Systems Manager Session Manager: no inbound ports, no bastion keys, IAM-controlled access, and full session logging to S3 or CloudWatch. Block port 22 and 3389 in security groups, and use instance profiles for AWS access.

• GuardDuty: threat detection findings.
• Inspector: vulnerability scanning of instances, container images and functions.
• Macie: discovers sensitive data in S3.
• Config: records resource configuration and evaluates compliance rules.
• Security Hub: aggregates findings from these and partners, runs standards checks, and gives a central view.

Store them in Secrets Manager or Parameter Store (SecureString), fetch at runtime through roles, enable automatic rotation where supported, restrict by policy, and never place them in code, AMIs, environment dumps or repositories. Use secret scanning in CI.

Gateway endpoints (S3, DynamoDB) and interface endpoints (PrivateLink) let workloads reach AWS services without traversing the internet. Endpoint policies restrict which resources can be reached, and bucket policies can require requests to come from a specific endpoint, which prevents data copy to outside accounts.

Use AWS Organizations with separate accounts per environment and workload, a dedicated log archive account, a security tooling account, and a shared services account. Apply SCP guardrails, centralise identity with IAM Identity Center, and use a landing zone for baseline controls. Accounts are the strongest isolation boundary.

S3 encrypts all new objects by default (SSE-S3), with options for SSE-KMS or client-side encryption. EBS volumes and snapshots, and RDS storage, use KMS keys chosen at creation (enable account-level default encryption). In transit, require TLS with a bucket policy condition on aws:SecureTransport.

Exposed storage, leaked access keys, over-privileged roles, unpatched or internet-exposed services, missing MFA, SSRF reaching metadata credentials, misconfigured public snapshots or AMIs, and absent logging. Most are configuration and identity problems, not AWS failures.

A role in account B trusts a principal in account A via its trust policy, and A's identity must be allowed to call sts:AssumeRole. The confused deputy problem occurs when a third party service with access to many customers is tricked into acting on your resources. Mitigate with an external ID condition for third-party roles, and aws:SourceArn and aws:SourceAccount conditions for service principals.

Detect with GuardDuty findings, CloudTrail anomalies (new regions, unusual APIs such as listing then enumerating), and billing alarms. Respond: deactivate the key, deny active sessions by policy conditioned on token issue time, review all API calls from the principal, remove created users, roles, keys, snapshots and compute, rotate secrets, and find the leak source. Automate the first steps with EventBridge and Lambda.

Organisation CloudTrail with log validation to an S3 bucket in a separate log archive account, with Object Lock, KMS encryption and a bucket policy denying delete. Add VPC flow logs, DNS query logs, ALB and WAF logs, Config history and GuardDuty, aggregated to a SIEM. Restrict who can touch the archive, alert on any change to logging, and set retention to meet regulatory needs.

Combine controls: VPC endpoint policies allowing only your buckets, bucket policies requiring requests from your organisation (aws:PrincipalOrgID), SCPs blocking public ACL changes, Block Public Access, restricted egress, GuardDuty S3 protection, Macie for sensitive data, and data event logging with alerting on bulk reads.

Identity policies attach to principals and say what they can do. Bucket policies attach to the resource and can grant cross-account access, enforce encryption and TLS, restrict by VPC endpoint or organisation. Same-account access succeeds if either allows (and nothing denies). Prefer bucket policies for guardrails and identity policies for job-specific permissions.

One narrowly scoped role per function, validate and sanitise input, use API Gateway auth (Cognito, IAM or JWT authorisers), throttle and WAF rules, keep secrets out of environment variables, update dependencies and scan packages, set short timeouts and concurrency limits to contain cost abuse, and log structured events with tracing.

Use OIDC federation so the pipeline assumes a short-lived role instead of stored keys, scope the role per repository and branch, scan code, dependencies and images, sign artefacts, require reviews and protected branches, use separate accounts for prod, and log deployments. The pipeline is a high-value target, so treat its permissions like production admin.

Restrict regions with SCPs, use customer-managed KMS keys with strict key policies, consider CloudHSM or external key stores for stricter control, tag and classify data, log key use, and document the shared responsibility split. Remember backups, logs and replicas may cross regions unless configured otherwise.

Isolate the instance (swap in a deny-all security group, keep it running for forensics), snapshot volumes and capture memory if possible, check how it was compromised (exposed service, weak credentials, vulnerable app, stolen role credentials), review the instance role's CloudTrail activity, rotate exposed secrets, rebuild from a clean image, and fix the entry point. Check other instances for the same indicators.

Turn on Block Public Access immediately, then review access logs and CloudTrail data events to see who read what and when, preserve evidence, determine the data involved, and involve legal and privacy teams for notification duties. Add preventive controls (SCP, Config rule, Macie) and fix the pipeline that created it.

Understand the real need, then offer a scoped role or a permission boundary, with short-lived elevated access and approval for exceptional tasks in a sandbox account. Use Access Analyzer policy generation from their actual activity to tune permissions. Security should make the safe path the fast path.

1. Deactivate and then delete the key.
2. Deny existing sessions for that principal by timestamp condition.
3. Review CloudTrail for all use of the key since exposure.
4. Remove anything created by the attacker (users, roles, instances, snapshots).
5. Replace with OIDC or role-based access and enable secret scanning.

Likely compromised credentials launching compute for mining. Check CloudTrail across all regions, disable the credentials, terminate the unauthorised resources, look for persistence such as extra IAM users, roles and access keys, and apply an SCP that denies unused regions. Set billing alarms and anomaly detection to catch this sooner.