CCNA Cloud And Hybrid Infrastructure Security Questions

Function-level keys authorise invocation of only the specific function they belong to, not the whole Function App or subscription. A leaked key therefore permits unauthenticated calls to that single HTTP-triggered endpoint, matching the stem's scope.

Without Kubernetes RBAC, AKS grants every authenticated request full cluster-admin authority, since no authorisation layer evaluates subjects against roles. Combined with Microsoft Entra ID integration being absent, no identity-based binding restricts actions, so any compromised pod or user reaching the API server executes arbitrary cluster-level commands.

The service account key file contains a private key that can be used to authenticate as the service account. By running gcloud auth activate-service-account --key-file=KEY_FILE, the tester can assume the identity of the service account. With the editor role, they can then access and modify most resources in the project, achieving full compromise.

User consent settings permitting any user to grant permissions to third-party multi-tenant apps enable illicit consent grant attacks, where a malicious app obtains delegated access to mail, files and contacts without admin approval. This misconfiguration is a recognised Microsoft Entra ID attack vector.

The mounted token authenticates to the API server as its service account, so sending it as a Bearer credential grants exactly that account's RBAC permissions. This satisfies the stem's constraint that automountServiceAccountToken exposes a usable credential inside the compromised pod.

Setting the method's authorization type to None removes API Gateway's AWS_IAM signature check for that route, so requests reach the backend without SigV4 credentials. Any unauthenticated client can therefore invoke the method directly, bypassing the intended IAM authorisation.

The cloud-platform scope grants OAuth access tokens covering every GCP API, so the default service account can call any service; IAM bindings are the only remaining restriction, meaning over-privileged tokens widen the blast radius if the instance is compromised.

Querying the IMDS endpoint at 169.254.169.254 with the required 'Metadata: true' header lets the SSRF retrieve an OAuth2 token minted for the function's managed identity. Because that identity holds Contributor over the subscription, the token grants control-plane access, satisfying the privilege-escalation objective without needing credentials.

ClusterRole verbs get, list and watch on secrets, bound cluster-wide, let any holder read secrets in every namespace. Stealing the default service account token via an app flaw gives the external attacker that API access, satisfying the cluster-wide dump objective.

Key Vault secrets often store credentials such as service principal secrets or connection strings. If the managed identity can read secrets, the tester can extract a secret that contains credentials for a more privileged identity. Using those credentials, the tester can authenticate and escalate privileges within the Azure environment.

The combination of ec2:RunInstances and iam:PassRole lets the user launch an instance with an existing privileged role attached, then retrieve its temporary credentials from the instance metadata service. iam:CreateRole is unnecessary here, but PassRole is the pivot that satisfies the escalation constraint.

Embedding long-lived cloud provider API keys in publicly accessible repositories exposes credentials to anyone, enabling unauthorised access and resource abuse. This directly violates the stem's requirement to identify a critical logging and monitoring security deficiency, since leaked keys bypass audit controls entirely.

An Azure AD application with a client secret can be used to authenticate as a service principal. If an attacker compromises a global admin, they can create or modify an application and add a long-lived secret. This secret remains valid even after the user's password is changed, providing persistent access to resources the application is granted.

Azure VMs expose the Instance Metadata Service at 169.254.169.254. The managed identity token endpoint is /metadata/identity/oauth2/token, which returns an OAuth2 token for the specified resource. By requesting a token for the Key Vault resource, the tester can authenticate to Key Vault using that token.

AWS PrivateLink creates unidirectional elastic network interfaces in each VPC, letting service consumers reach providers over private IP addresses within the AWS backbone. This satisfies the stem's requirement for private connectivity across separate VPCs without internet exposure, unlike VPC peering, which demands non-overlapping CIDRs and transitive routing.

The `iam:PutUserPolicy` action with a `*` resource lets the user write an inline policy directly onto their own IAM identity. Because inline policies are evaluated immediately and can grant any action, the tester can inject `AdministratorAccess`-equivalent permissions, escalating from limited rights to full account control without needing existing admin privileges.

The create verb on pods/exec authorises spawning exec subresources, letting the holder run arbitrary commands inside any pod in the cluster, which enables credential theft, service account token abuse and potential node or cluster compromise.

Granting allUsers the Storage Object Viewer role binds the bucket to the public internet, letting anyone read its objects without authentication. Removing that IAM binding, along with any allAuthenticatedUsers entry, restores private access; this directly addresses the anonymous exposure described in the stem.

Exposing RDP to Any or Internet invites brute-force and exploitation attempts. Restricting the NSG source to trusted administrative networks, or routing management through Azure Bastion, removes public exposure while preserving administrative access to the virtual machine.

Disabling the 'Allow Blob public access' property at the storage account level blocks all anonymous read requests, overriding any container-level public access settings. This directly satisfies the auditor's finding by removing anonymous access to containers and blobs, ensuring authentication is required for every request.

Security groups are stateful allow-lists; permitting 0.0.0.0/0 inbound on 3389 exposes RDP to the entire internet, enabling brute-force and BlueKeep-style exploitation. The stem asks for risky configurations, and unrestricted source ranges on management ports qualify.

Disabling MFA for global administrator accounts removes the second authentication factor protecting the highest-privilege identities, so a compromised password alone grants full tenant control. Emergency maintenance windows do not justify this exposure; privileged access should use temporary credentials or break-glass accounts with compensating controls.

Synchronisation rules and connector filters determine which objects and attributes reach Microsoft Entra ID. Reviewing them for misconfigured export rules or filtering gaps reveals whether the high-privilege group or its members can be surfaced despite the intended filter.

S3 ACLs granting public read and write let anyone list, download, and overwrite or delete bucket objects without authentication. This is a critical misconfiguration exposing data confidentiality and integrity, and is a classic cloud storage security failure.

An unauthenticated NodePort-exposed dashboard with cluster-admin rights lets any external attacker reach the web interface and create workloads. Deploying a pod with hostPath or privileged settings grants node access, escalating to full cluster compromise as the scenario describes.

The trust policy lacks an ExternalId condition, letting any principal in the external account assume the role and exploit the confused deputy flaw. Adding a Condition block requiring 'sts:ExternalId' binds assumption to a shared secret, satisfying the stem's remediation requirement.

Publicly Accessible plus 0.0.0.0/0 on port 3306 exposes MySQL directly to internet scanning and brute force. Restricting the security group to trusted CIDR blocks and disabling public accessibility removes that exposure, satisfying the stem's immediate-risk and control requirement.

CAP_SYS_ADMIN plus a read-write cgroup v1 mount lets the tester write to the release_agent file, which the host kernel executes outside the container's namespace. This directly satisfies the escape precondition the stem describes, yielding host-level command execution.

The Microsoft Graph endpoint /identity/conditionalAccess/policies returns the collection of conditionalAccessPolicy objects, including their state (enabled/disabled), conditions, grant controls, and session controls. With a token possessing Policy.Read.All or Policy.Read.ConditionalAccess, a tester can enumerate exactly which policies exist, whether legacy authentication is blocked, and which users or apps are excluded, directly informing the attack plan.

A publicly exposed API server on 0.0.0.0/0 without IP whitelisting or strong authentication lets unauthenticated attackers reach the control plane, enumerate resources and attempt privilege escalation. This directly satisfies the stem's high-risk cluster setup flaw criterion.

AWS evaluates all applicable policies together, and any explicit Deny overrides every Allow, whether from an ACL, bucket policy or identity policy. The public-read ACL grant is therefore negated by the bucket policy's explicit Deny, so anonymous requests receive Access Denied.

A hostPath volume bind-mounts a host filesystem path directly into the pod, bypassing the container's isolated mount namespace. Mounting '/' or '/proc' exposes host files, credentials and kernel interfaces, enabling escape by writing to host binaries or reading sensitive host data.

The root user holds unrestricted, non-revocable privileges across the entire AWS account, so using it for routine operations removes least-privilege boundaries and exposes every resource to accidental or malicious compromise. This is a significant identity and access management risk.

Plaintext connection strings in App Service application settings are readable by anyone holding Reader or Contributor on the resource, exposing database credentials directly. This satisfies the stem's attack path: no Key Vault reference means no separate secret access control.

With Secure transfer required disabled, the storage account accepts requests over plain HTTP, so credentials, tokens and object data travel unencrypted. An attacker positioned on the network path can capture that traffic, satisfying the question's focus on interception of data in transit.

Seamless SSO creates the AZUREADSSOACC$ computer account in on-premises AD, whose Kerberos decryption key Microsoft Entra ID shares. Domain-joined users obtain a Kerberos service ticket for that account, which the browser presents for cloud authentication. Compromising the account's key enables forging tickets for any user, satisfying the hybrid SSO constraint.

The trust policy's Principal element is what permits any account user to call sts:AssumeRole. Adding a Condition block — restricting the principal or demanding MFA via aws:MultiFactorAuthPresent — closes that gap while preserving legitimate role assumption, directly addressing the overly permissive trust relationship.

The role's trust policy names the external account as principal, so any identity in that account can call sts:AssumeRole. Absent an ExternalID condition, the confused-deputy weakness lets that account assume the role without proving it is the intended tenant.

Owner at root management group scope grants external guests full control over every subscription and resource, including RBAC changes. This violates least privilege at the broadest possible scope, making it a high-severity finding in the stem's review.

A trust policy allowing any AWS account in the partition to assume the role, with no ExternalId condition, enables the confused deputy problem: any third party can obtain the role's credentials. This is the insecure cross-account assumption configuration the review seeks.

SSRF lets the attacker reach the link-local IMDS endpoint (169.254.169.254), which issues OAuth2 access tokens for the assigned Managed Identity via its metadata endpoint. This satisfies the stem's chaining constraint, escalating from a web request forgery to authenticated access to Azure resources.

ListAccounts enumerates every account in the organization along with its ID, ARN, email, and status. From the management account, this provides the target list of member accounts that could be reachable through identity center permission sets or cross-account roles. Without this enumeration, the tester cannot know which accounts exist or where to focus escalation attempts, making it a necessary first step.

The IMDS endpoint is accessible from within the VM and provides OAuth2 tokens for the managed identity when requested with the appropriate header. By exploiting SSRF, an attacker can make the web application send a request to this endpoint and retrieve the token. This token can then be used to authenticate to Azure services that the managed identity has access to, such as Azure Resource Manager or Key Vault.